The IP over ATM Mailing List Archive by date

[Hiroshi Esaki <hiroshi@ctr.columbia.edu>]

Hi Jon, 

# Sorry for little long mail.......

 jc> i think we will see video over IPX over AAL5 (and other strange
 jc> things) and need some technique
 jc>
 jc> the problem as we see it is that the intelligence to mask cell
 jc> erasures is application specific.....so easier to do by handing
 jc> partial AAL frames to the layer above....

Right. 


 jc> though there are FEC approaches to the problem, sometimes....

Yes, it is sometime, not always.  
We realized this point. 
Personalily, I think, FEC scheme does not help high speed 
data communication over ATM, due to heavily correlated cell losses, 
though FEC for high speed data communication was the first motivation
of FEC work around 1990. 
Actually, this is well-known in IETF world, I believe. 
 
# I think, for high speed data transmission, peak bandwidth allocation
  (maybe on-demand) or over-provisioning is the solution for ATM. 
  Yes, fragmentation of packet into cells is fatal. 


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

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

Wireless ATM may be one area that FEC can give a benefit. 
But, we feel that some applications (not all) get benefits by 
the use of FEC scheme.  

 [1] Rubust service 
    As you know, in the ATM, the communication resources are statistically 
    shared among multiple data flows. 
    In order to keep a QoS (delay and loss quality), some flow and 
    congestion controlles (e.g., CAC or reactive congestion control)
    are defined.  
    Many flow/congestion control rely on the well-behavior of the 
    hosts.  This is especially true for ABR service. 
    Well, we have policing (i.e.,UPC) to police each flow or we will 
    have per VC queuing at every switch node.   
    But, the former is not mandatry for all network segment and 
    may not be enough to control the flows. 
    With the later, could we assume "all" switches do per-VC queuing ? 
    As a result, I think the unexpected congestion and cell loss 
    will occur.   

 [2] Improvement of service quality 
    High speed application will not be able to get a benefit by FEC
    scheme. 
    But, not high speed application will get a benefit. 
    I think some applications require some latency requirement, and 
    the bandwidth requirement is not so large. 
    For this application, if the propagation delay is a fatal 
    contribution for latency requirement (it will be easily happen 
    for wide area data communication), FEC will help their performance. 
    I may think this kind of application may be a large amount in the 
    Internet. 

 [3] Large Scale Error-Free Multicast 
    The packet error propability will increase approximatelly 
    linearly according to the number of receivers, in the multicast 
    service.  There are many approaches to provide error-free multicast
    service.  
    # The architecture proposed by LBL/USC/Xerox is VERY cleaver 
      approach, anyway. 
    For large number of receivers, the probability of packet retransmsssion
    will be large without FEC scheme. 
    Since FEC can reduce the packet error probability (not for very high 
    speed multicast service), it will be useful for  multicast service. 
 
 [4] Large Packet Size 
    Even when the bit error probability is 10^-9, the expected 
    bit error for 65KB (maximum AAL data size) will be more than 
    10^-4, with random bit error. 
    For 9KB (default MTU size), it will be about 10^-4. 

How do you think ? 


Best Regards, 

Hiroshi Esaki