The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Sep> msg00013



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Alternate Encapsulations/Signals for IP on AAL5

  • From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
  • Date: Fri, 08 Sep 95 15:20:13 +0100
  • CC: ip-atm <ip-atm@matmos.hpl.hp.com>


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

right - it would seem appropriate since its not exactly IP _over_ ATM,
as a general MPOA issue!

i think we will see video over IPX over AAL5 (and other strange
things) and need some technique

the problem as we see it is that the intelligence to mask cell
erasures is application specific.....so easier to do by handing
partial AAL frames to the layer above....

though there are FEC approaches to the problem, sometimes....
 
 >> 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?

sometimes, but see above...

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

ok - i think FEC has its place, though mainly in genuine lossy nets
(e.g. wireless ATM...)

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

yes - sorry, i should have cited this too - that was the basis for what
i said!!!

thanks for your comments!

cheers

 jon