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

[quetchen at caltech.edu (Tom Quetchenbach)]

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
>