The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <1270.810549696@cs.ucl.ac.uk>, Jon Crowcroft writes:
> 
> we were talking about expierences with IP on ATM and decided we would
> like to start some kind of discussion on alternate protocol wrappers
> for IP around AAL5
> 
> 2 examples why we need it
> 
> 1/ Video on RTP on UDP/IP on AAL5
> 
> if we lose a single cell, we lose the whole packet
> however, note, early packet discard is NOT appropriate, since many
> video encodings are very loss tolerant, and you can also build
> recivers that do cell loss concealment extremely well. However, most
> AAL5 SAR recevier boards either do the reassemlby on board, and trash
> the whole packet if a cell is lost, or they do the reassembly to the
> host memory, but still trash the packet, even if they give yu an error
> indication (what a waste of all those dma cycles!)

Jon.  

Doesn't early packet discard have the word packet right in there?
Early cell discard is NOT appropriate.  If you can drop full packets
the rest of your argument goes away.

> we'd like to propoe peopel think about deliverying partial IP packets,
> and think hard about a siognal being propogated thru AAL5, IP and UDP
> to say "I know the CRC and UDP checksums fail, but i don't care"
> 
> 2/ TCP on IP on AAL5 on an ABR service
> 
> we'd like an explicit congestion bit (even if ATT don';t let us get
> the explicit rate,they'll still pass the congestion signal back sooner
> than packet loss in traditional TCP congestion detection) signal from
> AAL up thu IP....
> 
> this may not be quite the right WG to discuss this, but just sartting
> fro mthese two e.g.s i can think of a range of simple signals that
> require very modest modificatio nto the code (e.g in BSD or streams
> IP, the 2 ideas above are a few lines of code....i can eventhink of an
> API for deivering partial packets to an application....)

Seems more like and end2end-interest topic, since you mention it.

The semantics of the bit are important.  Due you set the bit as soon
as your queue crosses some line like a DECbit, or do you set the bit
judiciously such as Sally Floyd's suggestion to use RED to trigger
setting a congestion bit which makes the round trip and reduces the
window size like a TCP fast retransmit.  The latter, with Sally's
suggestions of a "congestion bit aware bit" for provisions to drop if
the TCP packets if the end system was not congestion bit aware would
work infinitely better than a DECbit scheme.

If ATM switch world decide to take the dumb approach of turning on the
congestion bit when congested, turning it off when not congested,
smart border systems (routers or hosts) may still be able to do
something like RED, tracking a percentage congested indication instead
of an average queue size figure at the point of congestion.  This
would be somewhat less effective, but certainly better than DECbit and
probably better than the last proposed semantics of ABR I've seen.

The bad news would be if we set aside one bit and switches set the bit
differently.  If anyone is going to set aside a congestion bit, there
should be more than one bit set aside (unless there is agreement on a
best scheme, which is unlikely).  At least one bit for reactive
schemes (like DECbit and ABR, setting the bit after you get congested)
and one for proactive schemes (like RED, periodically setting the bit
to indicate backoff at a rate determined by medium term indications of
loading, like RED's use of average queue size).

> thoughts?
> 
>  jon

Curtis

ps - those joining us late - RED is Random Early Detection.  See IEEE
TON (late 93ish?) or ftp://ftp.ee.lbl.gov/papers/early*.ps.Z (the
paper is in 5 parts, use mget, then cat and uncompress).  See also
tcp_ecn.*.ps.Z (where * is just the version number).  There are lots
of good papers there on congestion and performance issues, see
README.papers for a list.  While I'm at it, I might as well plug
ftp://ftp.ans.net/pub/papers/tcp-performance.ps, since it describes
some limited experience with RED and http://engr.ans.net/nap-testing/
since it describes additional experience with TCP performance,
including over ATM.  Also see tcpatm_dyn.*.ps.Z (at LBL?).