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

[lachlan.andrew at gmail.com (Lachlan Andrew)]

Greetings Stefan,

Thanks for your interest in the test suite.  I apologise for the long
delay in getting back to you.

2008/7/30 Stefan Hirschmann <krasnoj at gmx.at>:
>
> 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.

I don't have figures for GPRS either.  (Lars?)  However, GPRS
typically has lots of delay (500ms or more).  This is made complicated
by opportunistic scheduling etc., but if we assume it is all queueing
delay, then it would be about 3 packets.

> Also when I looked at the document I noticed that there is no scenario between 64 kbps and 11 Mbps. By now, nearly the whole ADSL edge connections are larger than 64 kbps and smaller than 11 Mbps. Is there a reason why there is no scenario in this range?

We are trying to keep the suite small.  The focus has been on larger
bit rates because that is where most problems with TCP have been found
in the past, but also wanted to make sure that any proposal still
works at low rates (64k).

I think the general opinion was that the medium-rate problems would
mostly also show up in the low-rate or high-rate tests.

You are right that should consider having a 1Mbit/s test too.  How
about we wait until we have a prototype implementation, and then we
can see how long the tests take, and whether we can afford to add an
extra one?

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: [phone] Fax: [phone]
http://netlab.caltech.edu/lachlan