Subject: RE: Reliability in LAN

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 17 Apr 2003 14:59:14 -0400

Guys,

I think we are digressing into meaningless semantic nit-picking. Adding "reliability" simply means that information is correctly received MORE OFTEN. That certainly fits the mission statement of any form of forward error correction. The FEC can compensate for some degree of packet corruption, so without having to add any protocol complexity, the data packets are delivered error free more often. Not always, just more often.

Being error-free means that the information is "always perfect," when received by the application. If it's screwed up, one of the ISO layers below the application layer fixes the problem.

If the transfer occurs only once in a blue moon, then error free is a must, or you might simply miss the data packet entirely. If the information is transferred continuously and an occasional corrupted packet can be ignored, then FEC alone with UDP/IP is acceptable.

I originally used streaming media as AN EXAMPLE of this type of transfer. Data can also fit this model, depending how the system is designed.

Thus, FEC certainly DOES increase reliability. It just doesn't guarantee error-free reception of every packet.

Bert

> -----Original Message-----
> From: Michael Luby [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 12:45 AM
> To: Lloyd Wood; Manfredi, Albert E
> Cc: Karthikeyan Subramaniam; [email-masked]
> Subject: RE: Reliability in LAN
> 
> 
> > -----Original Message-----
> > From: Lloyd Wood [mailto:[email-masked]]
> > Sent: Wednesday, April 16, 2003 6:32 AM
> > To: Manfredi, Albert E
> > Cc: Michael Luby; Karthikeyan Subramaniam; 
> [email-masked]
> > Subject: RE: Reliability in LAN
> >
> >
> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote:
> >
> > > True, but these all rely on forward error correction. FEC 
> is a good
> > > way to add reliability, but it doesn't create an "error-free"
> > > communications link, at least as "error-free" has been defined in
> > > the past. To be "error-free," you need some way of re-delivering
> > > packets which were not correctly received or not received at all.
> >
> > Thus, FEC does NOT add reliability.
> 
> I'd be curious to understand how your definition of 
> reliability differs so
> drastically from what is defined in the RMT working group 
> charter and the
> general working group RFCs, and in particular from what is in 
> RFC 3453 and
> RFC 3452 which show how FEC can provide reliability for data 
> delivery.  If
> you get a chance, it would be interesting if you read those 
> 3-4 RFCs so that
> you can clearly differentiate what you have in your head in 
> terms of what
> reliability means versus what is in these docs.
> 
> >
> > Perhaps it adds robustness...
> >
> > L.
> >
> > >
> > > I agree that scalability is an issue. The more reliable and
> > > error-free you want to be, the more the scalability problems will
> > > bite.
> > >
> > > In many applications of IP multicast, e.g. streaming media, you of
> > > course don't have to have true error-free comms, so FEC or simply
> > > accepting the occasional screw-up is perfectly acceptable.
> > >
> > > Bert
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael Luby [mailto:[email-masked]]
> > > > Sent: Thursday, April 10, 2003 2:15 PM
> > > > To: Manfredi, Albert E; Karthikeyan Subramaniam;
> > > > [email-masked]
> > > > Subject: RE: Reliability in LAN
> > > >
> > > >
> > > > One could also look at RFCs 3450, 3451, 3452 and 3453.  These
> > > > provide a
> > > > direct solution to adding reliability to multicast 
> without losing any
> > > > scalability.
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > Manfredi, Albert
> > > > > E
> > > > > Sent: Thursday, April 10, 2003 10:39 AM
> > > > > To: Karthikeyan Subramaniam; [email-masked]
> > > > > Subject: RE: Reliability in LAN
> > > > >
> > > > >
> > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you 
> have to build
> > > > > the reliability mechanisms on top of UPD/IP. These sometimes
> > > > > mimick what had been done in XTP multicast years ago.
> > > > >
> > > > > Bert
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Karthikeyan Subramaniam [mailto:[email-masked]]
> > > > > > Sent: Thursday, April 10, 2003 3:51 AM
> > > > > > To: [email-masked]
> > > > > > Subject: Reliability in LAN
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > >    Is there any draft or RFC available for 
> multicast reliability
> > > > > > in LAN?
> > > > > > I have an multicast application which needs an 
> reliable mechanism
> > > > > > to send packets, so that other member in the group 
> receive the
> > > > > > packet without any packet loss.
> > > > > >
> > > > > > thanks,
> > > > > > -karthik.
> > > _______________________________________________
> > > routing-discussion mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/routing-discussion
> > >
> >
> > 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> >
> 
> 
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 17 Apr 2003 13:02:45 -0700

I think Mike's point is being missed though. The algorithms he
cites from RMT are more than simple FEC. They do provide error free
delivery over time. By simply continuting to listen to the stream,
the original data can be reproduced exactly everytime. You'll need
to read the papers to see how this works.

Tom

In message <[email-masked]>
 you write:
>Guys,
>
>I think we are digressing into meaningless semantic nit-picking. Adding "relia
>bility" simply means that information is correctly received MORE OFTEN. That c
>ertainly fits the mission statement of any form of forward error correction. T
>he FEC can compensate for some degree of packet corruption, so without having 
>to add any protocol complexity, the data packets are delivered error free more
> often. Not always, just more often.
>
>Being error-free means that the information is "always perfect," when received
> by the application. If it's screwed up, one of the ISO layers below the appli
>cation layer fixes the problem.
>
>If the transfer occurs only once in a blue moon, then error free is a must, or
> you might simply miss the data packet entirely. If the information is transfe
>rred continuously and an occasional corrupted packet can be ignored, then FEC 
>alone with UDP/IP is acceptable.
>
>I originally used streaming media as AN EXAMPLE of this type of transfer. Data
> can also fit this model, depending how the system is designed.
>

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 17 Apr 2003 13:02:45 -0700

Tom