The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <2776.793560814@cs.ucl.ac.uk>, Jon Crowcroft writes:

> For TCP, you actually want less buffering - you want _exactly_ the IP
> MTU's worth of ATM cell payloads of buffering, and you really want the
> source to rate control exlicitly at the bottleneck speed. If not, you
> want _immediate_ loss at the bottleneck switch, as this wil lcause the
> source TCP to adjust its rate anyhow, leaving only 1 IP packetsworth'
> of play.

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).

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.

> Of course, the problem is that at the IP level, yo ucan't trivially
> tell which packets are TCP and which RTP, so there is a conflict in
> how to configure the hops in source adaptor and the switches...
> 
> However, all is not lost, as one can take an alternate approach: If we
> connect hosts via conventional networks to routers, and the routers
> via ATM, then the routers can aggregate traffic from many sources over
> the ATM "cloud". Then the solution may be different - for example, a
> VP between routers with mean=peak, and peak policing only, will behave
> just like a physical circuit for IP, which would suit TCP traffic ok.
> What you lose then is the benfit of ATM guarantees for the RTP based
> traffic.

Unless you use RSVP and queue the RTP ahead of the TCP give is a WFQ
weight appropriate for it's requirements.

> One possible solution would be to run RTP from hosts with ATM adaptors
> direct ('native') and all other IP traffic via routers.
> 
> In the some pilots, it would appear that only the router approach works
> right now, since the host adapators most people are using do not do
> rate control (pacing) properly, so even the small bursts of an IP
> packets worth can overrun some hop or other where there is an
> impedence mismatch. Quite where this is happening has yet to be
> determined (hard, without access to an (HP) broadband analyzer.
> 
> j.

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.

Curtis


(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.

Unfortunately, the technique referred to in the paper as CLP-based
congestion control, though it worked well, is simply not applicable
for Internet providers, things like the ATM NAP, and any IP
application on which the large existing base of hosts are not on the
ATM but sit behind a router (or many routers an miles of fiber running
clear channel DS3).  The CLP technique assumes that the device on the
ATM interface knows where in the TCP window cycle the current TCP flow
is at and setting the CLP bit accordingly.  This is never true for IP
routers, since they don't even bother to look to see if the packets
are TCP, and even if they did, could not track the progress of all the
TCP flows and even if they tried, have no way to know where in the
window cycle the TCP flow is.


PS- I suppose I could add a shameless plug for the following URLs:
  ftp://ftp.ans.net/pub/papers/tcp-performance.ps
  http://tweedledee.ans.net/nap-testing/		% updated 2/95
For anyone that hasn't seen this before.