[Tmrg] Queue size - Towards a Common TCP Evaluation Suite

[quetchen at caltech.edu (Tom Quetchenbach)]

I looked into this a little bit more yesterday. I did a Wireshark packet
capture at the same time as the ping, and got very different results for
the TCP and ping packets.

Here is a plot of the ping RTT (as before, the x-axis is really only an
estimate):

http://wil-ns.cs.caltech.edu/~quetchen/dialup-tests/2008-10-08/ping_rtt.png

And here is what Wireshark gives me when I ask it for an RTT graph:

http://wil-ns.cs.caltech.edu/~quetchen/dialup-tests/2008-10-08/wireshark_rtt.png

(I started six flows, about a minute apart, by hand. The Wireshark plot
is for the longest-lived flow. The ping data starts about 15 seconds
before the first flow.)

So, perhaps the ping results are not quite to be trusted.

Has anybody else done any investigation of this? Especially interesting
would be if you could use Linux's tcp_probe module to plot the TCP RTT.
Unfortunately my modem only works in Windows, but I may be able to rig
something up using another computer as a gateway and get some
measurements this way.

-Tom

Tom Quetchenbach wrote:
> No, I didn't write any scripts; I just did it by hand.
> 
> I did write a little tiny python script (~10 lines) for generating data
> that can be fed to gnuplot from the Windows (XP) version of ping. That's
> how I made the plots. If you want it, it's here:
> 
> http://wil-ns.cs.caltech.edu/~quetchen/dialup-tests/plotping.py
> 
> -Tom
> 
> Lars Eggert wrote:
>> Hi,
>>
>> in case you scripted these tests, can you share that script? I'd be
>> interested to generate some data for GSM, EDGE, 3G and 3.5G networks to
>> share with the RG.
>>
>> Thanks,
>> Lars
>>
>>
>> On 2008-10-4, at 0:32, ext Tom Quetchenbach wrote:
>>
>>> I tried some experiments with my dial-up connection yesterday. I had to
>>> download several files at once to reach what seemed to be close to a
>>> maximum delay.
>>>
>>> Here is a summary of my results:
>>>
>>> Uncongested:
>>> min: 140ms, max: 171ms, mean: 154ms
>>>
>>> Congested (six large background flows from kernel.org servers):
>>> min: 3936ms, max: 6780ms, mean: 5407ms
>>>
>>> So, max(congested) - min(uncongested) = 6640 ms
>>>
>>> My modem reported a connection speed of 54.6 Kbit/s, so
>>>
>>> 6.650 s * 54.6 Kbit/s / 8 = 45 Kbyte/s
>>> 45 Kbyte/s / 1.5 Kbyte/packet = 30 packets
>>>
>>> This was around 10-11 AM PST on 2008/10/03, using Windows XP
>>> Professional (service pack 3). The background traffic was between two
>>> and six large files from ftp://ftp2.kernel.org, http://kernel.org, and
>>> http://mirrors.kernel.org. The ISP was AT&T in Pasadena, CA.
>>>
>>> Here are my raw data:
>>>
>>> http://wil-ns.cs.caltech.edu/~quetchen/dialup-tests/ping-output/
>>>
>>> And, in the interest of putting off real work, here is a rough plot of
>>> ping RTT vs. time:
>>>
>>> http://wil-ns.cs.caltech.edu/~quetchen/dialup-tests/ping_rtt.png
>>>
>>> Would it be worth re-running the test with smaller packets, to see if
>>> the queue size in this case is specified in bytes or packets? I think I
>>> can convince Windows to change its MTU. I was also planning on testing
>>> with hping2 (which uses TCP SYN packets instead of ICMP echos) and
>>> comparing the results. I'll do this sometime this weekend or Monday.
>>>
>>> -Tom
>>>
>>> Tom Quetchenbach wrote:
>>>> My ISP gives me dial-up access as a backup to my DSL, so I'll try to
>>>> play around with it at some point.
>>>>
>>>> -Tom
>>>>
>>>> Lachlan Andrew wrote:
>>>>> Thanks Stefan.
>>>>>
>>>>> Those numbers are interesting.  I'm surprised that there was 8s delay
>>>>> when congested.  I'm wondering if  ping  packets are treated
>>>>> differently.  (Many systems give ICMP packets lower priority.) Still,
>>>>> 35 packets sounds a reasonable buffer size.
>>>>>
>>>>> Does anyone else on the list have any data to support or contradict
>>>>> this?  My parents-in-law use dial-up, so I'll try to check their
>>>>> connection soon.
>>>>>
>>>>> Cheers,
>>>>> Lachlan
>>>>>
>>>>> 2008/10/2 Stefan Hirschmann <krasnoj at gmx.at>:
>>>>>> Greeting Andrew and all other readers,
>>>>>>
>>>>>>> Lachlan Andrew wrote:
>>>>>>>> 2008/7/30 Stefan Hirschmann <krasnoj at gmx.at>:
>>>>>>> Greetings Stefan,
>>>>>>>
>>>>>>> Thanks for your interest in the test suite.  I apologise for the long
>>>>>>> delay in getting back to you.
>>>>>> I apologize for this long delay too. But it was not easy to find
>>>>>> anyone
>>>>>> with a 56K POTS modem still in use.
>>>>>>
>>>>>>
>>>>>>>> In the "Common TCP Evaluation Suite draft-irtf-tmrg-tests-00"
>>>>>>>> there is the section:
>>>>>>>> "3.2. Delay/throughput tradeoff as function of queue size"
>>>>>>>> describing the buffer sizes of the routers, but only for the
>>>>>>>> access link scenario.
>>>>>>>>
>>>>>>>> I wanted to extend the values to the other scenarios and noticed
>>>>>>>> a problem with it.
>>>>>>>> The BDP of the Dial-Up Link scenario is 64Kbps * 0.1 s / 8 = 0.8
>>>>>>>> KByte -> 0.8 / 1.5 = 0,53 packets.
>>>>>>>>
>>>>>>>> So even if I use the BDP the value is much too small. A rounding
>>>>>>>> to one is IMHO also not realistic. What value should be used as a
>>>>>>>> minimum buffer size and why?
>>>>>>> The Dial-Up scenario is there partly for POTS modems, and partly for
>>>>>>> GPRS.  You should find out the buffer size used by either one of
>>>>>>> those
>>>>>>> (and then it would be great to post it to the list!).
>>>>>>>
>>>>>>> If you have access to a dial-up connection, you could try to measure
>>>>>>> the buffer size:  Ping the next-hop node with an idle link, and then
>>>>>>> while downloading something large.  The difference in RTTs will
>>>>>>> give a
>>>>>>> good estimate of the buffer size.
>>>>>> OK I have done it. The test were made:
>>>>>> DATE: 2008/10/01 around 19:30
>>>>>> Used 56K POTS Provider: Tele2 Austria
>>>>>> Operating System: Windows XP Media Centre Edition
>>>>>> Large background traffic: A linux kernel image from
>>>>>> ftp://ftp2.kernel.org
>>>>>>
>>>>>> The exact testprotocol is at the end of the email.
>>>>>> The most important datas are:
>>>>>> uncongested:
>>>>>> Minimum = 134ms, Maximum = 148ms, Mean = 141ms
>>>>>>
>>>>>> congested:
>>>>>> Minimum = 5963ms, Maximum = 8541ms, Mittelwert = 7177ms
>>>>>>
>>>>>> The correct formula should be:
>>>>>> max(queuing time) = max(congested) - min(uncongested)
>>>>>> 8407 ms = 8541 ms - 134 ms
>>>>>>
>>>>>> 56 KBit/s is 7 KByte/s. 6 KByte/s is a realistic value for the real
>>>>>> usable value. In this case:
>>>>>> time * bandwidth = amount of data
>>>>>> 8,541 s * 6 KByte/s = 51,246 KByte
>>>>>>
>>>>>> If you say, that the packetsize is 1,5 KByte than:
>>>>>> 51,246 KByte / 1.5 KByte =  34,164
>>>>>>
>>>>>> So 35 is the Queuesize in packets.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers Stefan
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now the complete console log (was a German Windows vesion):
>>>>>> ===============================================================================================
>>>>>>
>>>>>> Microsoft Windows XP [Version 5.1.2600]
>>>>>> (C) Copyright 1985-2001 Microsoft Corp.
>>>>>>
>>>>>> C:\Dokumente und Einstellungen\Leo>ping www.google.at
>>>>>>
>>>>>> Ping www.l.google.com [209.85.129.147] mit 32 Bytes Daten:
>>>>>>
>>>>>> Antwort von 209.85.129.147: Bytes=32 Zeit=148ms TTL=244
>>>>>> Antwort von 209.85.129.147: Bytes=32 Zeit=146ms TTL=244
>>>>>> Antwort von 209.85.129.147: Bytes=32 Zeit=136ms TTL=244
>>>>>> Antwort von 209.85.129.147: Bytes=32 Zeit=134ms TTL=244
>>>>>>
>>>>>> Ping-Statistik f?r 209.85.129.147:
>>>>>>   Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
>>>>>> Ca. Zeitangaben in Millisek.:
>>>>>>   Minimum = 134ms, Maximum = 148ms, Mittelwert = 141ms
>>>>>>
>>>>>>
>>>>>> C:\Dokumente und Einstellungen\Leo>ping -w 9999 www.google.at
>>>>>>
>>>>>> Ping www.l.google.com [209.85.129.104] mit 32 Bytes Daten:
>>>>>>
>>>>>> Antwort von 209.85.129.104: Bytes=32 Zeit=7027ms TTL=244
>>>>>> Zeit?berschreitung der Anforderung.
>>>>>> Antwort von 209.85.129.104: Bytes=32 Zeit=8541ms TTL=244
>>>>>> Antwort von 209.85.129.104: Bytes=32 Zeit=5963ms TTL=244
>>>>>>
>>>>>> Ping-Statistik f?r 209.85.129.104:
>>>>>>   Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1 (25% Verlust),
>>>>>> Ca. Zeitangaben in Millisek.:
>>>>>>   Minimum = 5963ms, Maximum = 8541ms, Mittelwert = 7177ms
>>>>>>
>>>>>> C:\Dokumente und Einstellungen\Leo>
>>>>>>
>>>>>
>>> -- 
>>> /* Tom Quetchenbach
>>> * WAN-in-Lab / Netlab, Dept of Computer Science, Caltech
>>> * 1200 E California Blvd, MC 256-80, Pasadena CA 91125
>>> * Lab: [phone]  ||  Cell: [phone]
>>> */
>>> _______________________________________________
>>> Tmrg-interest mailing list
>>> Tmrg-interest at ICSI.Berkeley.EDU
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
> _______________________________________________
> Tmrg-interest mailing list
> Tmrg-interest at ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest

-- 
/* Tom Quetchenbach
 * WAN-in-Lab / Netlab, Dept of Computer Science, Caltech
 * 1200 E California Blvd, MC 256-80, Pasadena CA 91125
 * Lab: [phone]  ||  Cell: [phone]
 */