The IP over ATM Mailing List Archive by date

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

this is very informal....

however, as we get to mixing IP over atm from hosts attached to atm
clouds, and from routers connected by atm clouds, some of the
'conclusionsish' bits might bear looking at....


notes on IP & ATM: Shaping and Policing. 

In the Internet, there are 3 basic traffic patterns
from applications that cause significant traffic loads:

1/ TCP over IP [FTP, HTTP etc]
2/ UDP over IP [NFS, DNS]
3/ RTP over IP [Mbone applications: vic/vat/wb]

Traffic as seen at the IP layer:

TCP applications are reactive. They can expand to use whatever
bandwidth is available. They backoff when bandwidth decreases as soon
as they learn - they learn through detection of lost packets. TCP
generaly has variable, but not particularly bursty traffic patterns.

UDP based applications do not back off, and typically are massivley
bursty - NFS for instance sends (by default) 8K of data in a single
request or response, and this will be typically as fast as the source
can send.

Both UDP and TCP usually use the MTU as seen at the host interface for
local traffic, and a default otherwise - this can be around 512 bytes
(but is settable).

RTP applications are _mainly_ smooth, and relatively steady.
VAT sends audio, typically at just over 64kbps and at 140 byte
packets. With silence supression on, vat is a classic "on/off" source. 
Vic sends video, and is more variable, but still has a mean and peak,
though the packet size varies (from around 100-700 bytes).

Traffic as seen at the ATM layer:

IP is encapsulated at source in AAL5 frames, which are then shredded
into 48 byte payloads. Without any source "rate control", these will
be sent at line rate. Thus a single IP packet of 700 bytes, for
example, results in 15 cells at line speed. Depending on whether the
host adaptor does this shredding directly from host memory, or else
dma's first to buffers on the card, there may be speed coupling
problems here.

If the source host rate limits within a VC, then the cells will be
sent at the rate set, and so long as the layer above, the IP source,
and the layer above that (TCP, UDP or RTP) don't exceed the rate,
buffers won't be exhausted, and cell loss will not be experienced.

If the rate control is not accurate, or else is above the rate of the
slowest link in the path from source adaptor to sink, then there is a
high chance that even if the source application is "well behaved"
the cell rate for the bottleneck is exceeded temporarily, unless there
is shaping.

Shaping is basically the use of buffers to trade jitter for delay - as
cells arrive more closley (i.e. the temporary cell rate is higher than
the mean or even peak, up to some number of cells) they are stored for
slightly longer intervals that their interarrival times, and slowly
"leaked" out to the net at the appropriate rate. Basically, the
scheduling of cells is done by varying the delay between them - this
can be done at source or in intermediate switches. If done at source,
it requires global knowledge of bottlenecks. If done in switches, it
can be done at the edges of bottlenecks only.

This will work well for RTP based applications provided that the buffering 
is AT LEAST the IP packets worth of cells, and probably somewhat more, and 
the VC at the bottleneck is set to peak rate the same as the peak RTP rate.
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.

With DNS and NFS, there is no obvious solution. Basically, ATM is
still unsuited to bursty transaction oriented traffic, full stop.
[NFS _can_ be run over TCP if need be, then the rules above apply].

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.

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.