The IP over ATM Mailing List Archive by date

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

 >This is false.  TCP needs buffering at a bottleneck.  TCP is very
 >bursty and its bandwidth is limited by how far it can get the window
 >open divided by the delay.  I estimate that buffering should be
 >slightly greater than the delay bandwidth product (using the bandwidth
 >of the link and counting end-to-end speed-of-light delay only, not
 >queueing delay - since end-to-end delays vary, use an estimate of
 >delays experienced by the majority of traffic or an estimated
 >average).

this is old news - i wasn't talking about buffering for the VC< i was
talking about the way the leaky bucket would operate, which is not
the same thing in quite a subtle way....

of course you need 1 bandwidth/delay products worth of buffering for
the current (non selective retransmit and congestion control
mechanisms in TCP to operate right - what you also need is something
that operates over the time scale of RTTs apparewntly like fixed
bandwidth except for the effects of other TCPs (which are oioperating
their control loops over RTT delays).....fine grain timescale
adjustment of the bandwidth avaialble at the bottleneck confuses TCP
badly

that's all i was saying....sorry if the way i piut it wasn't clear...
 
 >Testing a simulations using TCP both over media that does not cellify
 >and over ATM strongly supports the need for large buffers to maintain
 >high TCP goodput and link utilization.  A recently published example
 >is the paper in Feb 95 CACM, "Improvements to TCP Performance in
 >High-Speed ATM Networks" bu Michael Perloff and Kurt Reiss.  (see note
 >below).  It reports severe fairness problems and low TCP goodput when
 >switch buffering is too small.

sure.....totally concur
 
 >Is this the same pilot that Dario Ercole reported on at the San Jose
 >IETF?  If so, the totally anemic buffers in you switches is probably
 >your whole problem.  You can try to kludge around it with rate
 >shaping, but you are going to have to replace the switches with
 >something that has some buffering.

yes - i wish we could......i'm not at liberty to say what pilot it is
(sorry....maybe at the end of the year...)
 
 >(note) - The results in the CACM paper I am referring to is the very
 >low TCP goodput (30% link utilization) and severe fairness problems
 >experienced when buffering was way too small (240 cells or about 2.5
 >IP packets of buffering for FDDI MTU or just over one for ATM MTU).
 >Simply increasing buffering improved this (53% at 4000 cells, 72% at
 >8000 cells).  Other techniques improved it further.

the main thing we've been getting to work is RTP based stuff, which
can actually be made to work very well over the networks without large
buffers as the simple minded rate/bucket schemes in current large
switches approximate

cheers

 jon