The IP over ATM Mailing List Archive by date

[Tim Dwight <0006078043@mcimail.com>]

... Jon Crowcroft said:

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

It is interesting you point this out.  Other groups intending to use
AAL5 have said similar things.  The ATM Forum's implementation 
agreement for audio/multimedia over ATM, also uses AAL5 - they have
raised these points.

To my knowledge there are (at least!) 2 places where whole frames are
discarded due to the loss of a few cells.  This may obviously take
place in the SAR layer at the destination;  it may also take place
in the network, if the switch is implementing "frame discard" (which
has -at least- 2 forms:  either throw away the rest of a frame after
congestion forces you to throw away an associated cell, or predict
imminent congestion and throw away the next complete frame).

In response to the latter, the new [4.0] ATM Forum signaling specification
will support the explicit indication of "frame discard".  The idea is to
control this on a per-connection basis.

I don't believe the issue of loss at the SAR layer, has been addressed.
I think it should be solved in the ATM domain, through per-connection
signaling.  Someone would have to propose how to do so, and bring a 
contribution to the Forum.  This WG could also offer a liason to the
ATM Forum (via Drew Perkins or Joel Halpern), either proposing a solution
or proposing that a solution be developed.

> 
> 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"


Are you familiar with Hiroshi Esaki's work regarding
forward error correction for data connections over ATM?  His (I could
say "our", but actually the ideas are mostly his) proposal is for a
"service specific convergence sublayer" (AAL sub-layer) to perform
recovery of lost or damaged data;  and also includes the option of
sending corrupted data which cannot be recovered, to the upper layer.

If you are familiar, then to what extent do you feel this FEC work
addresses your concern?

We are trying to turn this (Forward Error Correction service) into
an ATM Forum work item, and any support from this list would be both
timely and appreciated :-)

> 
> 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 sounds useful, but to be moreso I think it can't be limited to
"inter-layer" signaling.  The frequent problem is that the ATM interface
is in one device (e.g., a router) and the source of the data is in
another device (e.g., a host).  In this case, there would need to be
something like an ICMP message that could flow from the router to the
host, to convey the congestion information.

Sally Floyd has proposed some time ago, reviving the Source Quench
message for this purpose.  Her paper is (or at least used to be) in
ee.lbl.gov/papers/tcp_ecn.ps.

I am told that some NIC manufacturers think they can effectively solve
the "single-device" case, by doing blocking writes from the host
to the adapter.  The idea is that the IP layer in the host writes,
via some sort of driver, to the ATM layer in the adapter;  thus the
driver in the host may hang the host CPU as a way of flow-controlling
the source application long enough for the NIC buffer to drain.  I think
this is a bad idea, but have heard it discussed.

> 
> 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....)
> 
> thoughts?
> 
>  jon
> 

Regards,

Tim Dwight
MCI