[Tmrg] Queue size - Towards a Common TCP Evaluation Suite
quetchen at caltech.edu (Tom Quetchenbach) Fri, 03 October 2008 21:32 UTC
From: "quetchen at caltech.edu"
Date: Fri, 03 Oct 2008 14:32:27 -0700
Subject: [Tmrg] Queue size - Towards a Common TCP Evaluation Suite
In-Reply-To: <48E3D7EA.8030703@caltech.edu>
References: <20080730103251.299310@gmx.net> <aa7d2c6d0808311521l2fb03761l350017c02548382a@mail.gmail.com> <48E3C1F5.40906@gmx.at> <aa7d2c6d0810011142q15db75fct588b62f467365141@mail.gmail.com> <48E3D7EA.8030703@caltech.edu>
Message-ID: <48E68F6B.6080203@caltech.edu>
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: (626) 395-8820 || Cell: (863) 370-6402 */
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Stefan Hirschmann
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Lachlan Andrew
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Stefan Hirschmann
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Lachlan Andrew
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Tom Quetchenbach
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Tom Quetchenbach
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Lars Eggert
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Tom Quetchenbach
- [Tmrg] Queue size - Towards a Common TCP Evaluati… Tom Quetchenbach
- [Tmrg] Queue size - Towards a Common TCP Evaluati… grenville armitage