[Tmrg] Round table: Buffer sizes

[Sally Floyd]

(Going back to some October 2 email.  Apologies, again...)

>  If (big if!) physical routers predominantly have
> buffers in packets, then I'd prefer to   start   with a subset of the
> core tests which only use buffers in packets.

Yep.  I would *guess* that most routers can be characterized
as having buffers in packets (e.g., having slots for packet headers,
with the actual packet stored elsewhere).  I don't know for sure,
however.

Recent experiments show that 26% of DSL hosts tested show a
RED-style drop policy on their upstream queues.  (Dischinger et
al., "Characterizing Residential Broadband Networks', IMC'07,
"http://www.imconf.net/imc-2007/papers/imc137.pdf".)  So it *is* getting
to be time for realistic scenarios to include some form of AQM, as well
as Drop-Tail.

...
> Motivated by past debates over different labs' tests, I was also more
> interested in repeatability than realism.  If we get different results
> using simulation from dummynet or different results using dummynet
> from real WAN testbeds, it would be ideal if the results are "clean"
> enough to find out what   causes   the difference.  Than means many of
> the tests may lack important attributes like "web" cross traffic --
> although of course there must also be enough tests with cross traffic
> to see how the algorithm will perform in practice.
>
> Once one or two tests have been defined precisely enough to be
> repeatable by different labs, it would of course be good to extend to
> a "wider core", like the one you describe.

I would like to encourage a wider scope, with vaguely-realistic 
scenarios
including a realistic range of connection sizes.  And if two testbeds
give qualitatively different results, then the troubleshooting of the 
differences
can include simplifying the scenarios one step at a time.

...
> Since the TCP algorithms themselves determine the percentages of
> traffic, we should specify the traffic in terms of the number of
> flows   with each MTU, rather than the amount of traffic.  How about
> specifying 90% of flows use 1500-byte, and 10% of flows use 536-byte?

Something like that sounds good to me.  Using setsockopt(TCP_MAXSEG) ,
as suggested by John.  And with reverse-path traffic  providing the 
40-byte
ACK packets.

- Sally
http://www.icir.org/floyd/