How to track changes in the Congestion Window

[wwx...@gmail.com]

Hi~

 I am a newbie on ubuntu and pantheon. The research I am doing recently needs to use the congestion window changes to throughput and latency and other influences. I can’t find the content I need when using pantheon, so I’m asking you How to make the data of the congestion window appear in the log。

Thank you

Wang Xue

[Francis Y. Yan]

Hi Wang Xue,

That's a good question, but unfortunately, it is generally not possible to use Pantheon to study the influence of congestion window on a scheme's performance. Here's the reason: Pantheon is agnostic to the tested schemes and does not have access to the congestion window used behind the scenes. In other words, these congestion-control schemes behave like "black boxes" to Pantheon.

That said, there are exceptions. E.g., you may retrieve the congestion window sizes of TCP schemes from kernel (tcp_info) or maybe iperf has some option to print them out. And you may also make changes to the source code of other schemes in the third_party/ folder and have them print pairs of timestamps and congestion window sizes, assuming that you are able to find in which variables the sizes are stored. Hope it helps!

Best,
Francis

 

--
You received this message because you are subscribed to the Google Groups "Pantheon" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pantheon-stanf...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/dbd59af2-c536-4fd5-8470-4281e917754ao%40googlegroups.com.

[王学]

Dear  Francis ,

Thank you very much for your reply and suggestions.

I am studying the impact of changes in the congestion window on throughput, etc. I am going to choose Copa and Indigo as reference. As a newbie, I don’t quite understand the steps you are talking about. I’m sorry for that, so if you can, can you teach me how to operate this process?

Anyway, thank you very much!

Best,

Wang Xue

[Francis Y. Yan]

Hi Wang Xue,

Sure thing. Taking Copa as an example: you will first want to look at pantheon/src/wrappers/copa.py and find which third-party repo is used as the implementation. It is pantheon/third_party/genericCC.

Next is the challenging part. You will need to read the source code of genericCC and figure out what variable saves the value of congestion window size. Then you can modify the code to print out its value over time (along with a Unix timestamp) to a log and associate this log with the actual performance of Copa. E.g., between time T1 and T2, Copa's congestion window changed from CWND1 to CWND2 (according to the log you created), and its throughput changed from Tput1 to Tput2 (according to the logs output by Pantheon).

Let me know if anything is not clear.

Best,
Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/7385f57b-4f65-4ff8-80ff-84d766a0f4c1n%40googlegroups.com.

[王学]

Dear Francis,

Thank you very much, I will try to change them, if there are other questions I will ask you again,hope this will not affect you.

 At the same time, I don’t know if you can provide me with operating data about Indigo, including:  congestion window ,  RTT ,  throughput ,  arrival rate ,  delay ,  Loss.

Anyway, thank you very much for your guidance and help.
Best ,

[Francis Y. Yan]

Hi Wang Xue,

All the data we have ever recorded can be accessed from our website https://pantheon.stanford.edu. If the data (e.g., congestion window) is unavailable from the website, that means unfortunately we don't have it either.

Best,
Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/c26b51f3-0519-415d-a303-fcbf6fe13539n%40googlegroups.com.

[人ー]

Hi Francis,

I want to trace changes of Cwnd too.

In case of run test.py by "python test.py local -f 1 --schemes cubic --data-dir dumbbell", How do I trace changes of Cwnd ?

Best,

Hitori

2020年9月15日火曜日 10:59:05 UTC+9 Francis Y. Yan:

[Francis Y. Yan]

We use iperf to evaluate Cubic, which means you would have to look into how cwnd can be exported or logged by iperf.

Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/4fd25dd6-5d43-4f7d-b993-c252a96273d5n%40googlegroups.com.

[人ー]

Hi Francis,

I could trace changes of Cwnd by using tcp_probe between different linux machines.

But in Pantheon, normal tcp_probe doesn't work wll by using mahimahi shell.

So, What changes do I need to work tcp_probe on mahimahi shell?

Paste the link of tcp_probe.

https://wiki.linuxfoundation.org/networking/tcp_testing

best

Hitori

2020年10月29日木曜日 14:45:08 UTC+9 franc...@gmail.com:

[Francis Y. Yan]

Hi Hitori,

It sounds great that tcp_probe can output congestion window sizes. I have not used it before but it looks that it only needs to know a port number.

When you test iperf with Mahimahi, can you just give tcp_probe the port number that iperf runs on? What error do you get?

Best,

Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/07e6bdb0-6465-455c-9d24-46aa56a60a33n%40googlegroups.com.

[人ー]

Hi, Francis

In my problem, behavior of cwnd is strange.
Looking at the emulation results,   sometimes size of cwnd decrease to10 [Segments].

What was the cause?  

I have attached the file of the emulation result .

Best,

Hitori

2020年11月15日日曜日 9:27:36 UTC+9 franc...@gmail.com:

[Francis Y. Yan]

Hi Hitori,

What do you mean by "strange"? In your setup with only "mm-delay 10", no packets will be dropped until the sender buffer is full. Usually you will want to add at least a bandwidth trace and a queue; could you try this more "realistic" setting below and let me know what tcp_probe outputs this time?

1) In one terminal, run

iperf -s -p 5001

2) In another terminal, run

mm-link <(echo 1) <(echo 1) --meter-all --uplink-queue=droptail --uplink-queue-args="packets=100"

first, and then inside the Mahimahi container, run

iperf -c $MAHIMAHI_BASE -p 5001 -t 60

Best,
Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/741ecb6d-cc7a-4bfd-afca-4cdb5bd2894an%40googlegroups.com.

[人ー]

Hi Francis,

I appreciate your swift response.

Mean of strange is sometimes size of cwnd become 10 [segments] . It wasn't seen when running iperf between another Linux OS.

I have attached the file of the emulation result with the presented settings .

And   attached the results of trace cwnd between another Linux OS.

best,

Hitori

2020年11月19日木曜日 15:08:02 UTC+9 franc...@gmail.com:

[Francis Y. Yan]

Your new experiment, i.e., how the cwnd varies over time, seems reasonable to me as it shows the classic "sawtooth" pattern. If there are packet losses and Cubic enters the slow start phase again, then its cwnd might be dropped to 10. Is that what you mean?

Best,

Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/d37872ae-f696-41ea-adbe-391b780a154an%40googlegroups.com.

[Jasper J]

Hi Francis,

Thanks for your effort to actively maintain this group.

I have similar objective related to this thread. I would like to log TCP related parameters (e.g., congestion window size, re-transmission flag etc).

Specifically, I would like to collect aforementioned parameters for cubic in locally emulated networks (e.g., using src/experiments/test.py local --schemes "cubic").

Could you elaborate a little bit more on how can I collect these parameters either using tcp_info or tcpdump?

Also, could you explain how virtual interface is interacted with Pantheon? In my case, I don't know how to use tcpdump for monitoring virtual interface for locally emulated networks.

Thanks,

Jasper

[Francis Y. Yan]

Hi Jasper,

First of all, tcpdump cannot be leveraged to monitor congestion window (CWND) sizes because CWND is not a field in TCP packets. It is just a notion / variable (optionally) maintained by congestion control algorithms.

For those congestion control schemes that are available in Linux kernel (Cubic, BBR, Vegas, etc.), you have a few options to access CWND:
1) If your program is able to manipulate the TCP socket, you could use a socket option called "TCP_INFO" to retrieve CWND from kernel. Please refer to our example here.
2) If option 1) is not feasible, e.g., when you are running iperf or other third-party programs that own the underlying TCP socket, you would have to find out if these third-party programs expose such information by themselves, or you would have to resort to other kernel tools. The kernel module "tcp_probe" used to be a choice but I did not use it before for this purpose. In the latest Linux distributions, tcp_probe seems to have been removed, making this task even trickier.

For other congestion control schemes that are homemade (Copa, Indigo, Sprout, etc.), there is no unified way to access CWND. They may even choose to not have the notion of CWND.

Regarding your last question, the usage of tcpdump to monitor emulated links is exactly the same as normal usage. For example, if you create a Mahimahi shell like mm-delay, then a virtual interface "ingress" will be created inside the shell. You may simply run "tcpdump -i ingress" inside it to capture packets, and to capture packets coming out of that interface, you just need to run something like "tcpdump -i delay-XXXXXX". Hope this is helpful!

Best,
Francis

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/c1dbeb9e-033e-4ce1-b6bc-81d5896c9a56n%40googlegroups.com.

[Jasper J]

Hi Francis,

It is definitely super useful!

As tcpdump is able to monitor all TCP variant, we are going to use tcpdump to collect tcp state variables (where we could probably estimate congestion window size).

I can run tcpdump on virtual interface, and I was confused that only UDP packets are monitored previously.

After removing 36 bytes overhead from monitored UDP packet, I can view TCP packets and TCP state variables in wireshark.

Thanks for your time answering the question!

Jasper

[Keith Winstein]

Hmm, you *could* do it that way, but it seems like a bit of a hack. Rather than running tcpdump outside the tunnel (and trying to manually de-encapsulate the tunnelled datagrams), why not just run tcpdump inside the tunnel?

To view this discussion on the web visit https://groups.google.com/d/msgid/pantheon-stanford/e4f611cc-9a10-40e5-9f8e-c76a5892f5adn%40googlegroups.com.

[Jasper J]

Thanks for your comment! I am not aware of I can do that. That is a better solution.  

I tied to use tcpdump to monitor all interfaces (tcpdump -i any) but I can only observe UDP packets. Then, I de-encapsulate the observed UDP packets using Wireshark (editcap -C 0:36 sample.pcap).