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

[lars.eggert at nokia.com (Lars Eggert)]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1611 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20081004/357505d4/attachment.bin