Subject: RE: Reliability in LAN

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

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.

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

---

From: "Michael Luby" <[email-masked]>
Date: Thu, 10 Apr 2003 16:35:52 -0700

The approach in these RFCs is to use FEC beyond what you are imagining: when
delivering data reliably you keep sending FEC packets until enough have
arrived to recreate the data, and thus there is no need ever to redeliver
lost packets or incorrectly received packets, you just receive some more and
stop receiving when you have enough, where enough is the length of the
original data. This essentially does create a virtual error-free
communications link with maximum bandwidth utilization, even if the actual
communications link is not error-free and does lose and/or corrupt packets.

For streaming applications there are also benefits to using FEC, but this is
outside the scope of these RFCs.
Mike

> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Thursday, April 10, 2003 11:46 AM
> To: Michael Luby; Karthikeyan Subramaniam; [email-masked]
> 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.
>
> 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
>
>

---

From: "Michael Luby" <[email-masked]>
Date: Thu, 10 Apr 2003 16:35:52 -0700

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 16 Apr 2003 14:32:10 +0100 (BST)

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.

Perhaps it adds robustness...

L.

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

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 16 Apr 2003 14:32:10 +0100 (BST)

L.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 17 Apr 2003 15:52:35 +0100 (BST)

On Wed, 16 Apr 2003, Michael Luby wrote:

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

FEC reduces the probability of corruption leading to frame loss at
the receiver. It cannot, by itself, provide reliability. (My view is
in section 1.1 of RFC3366, which, unlike the RFCs you cite, is BCP.)

The RMT charter correctly indicates that FEC is but one 'building
block', and that use of FEC alone is open-loop. TCP is reliable; TCP
is closed-loop. For me, reliability implies a closed loop with error
handling/notification, and RFC 3452 and 3453 show no such thing.

Basically, we've spent more time talking to wireless link designers
about coding etc. I'm not convinced that FEC belongs up the stack, and
I wouldn't call 'reliable' multicast using only FEC reliable either.
'less unreliable', perhaps; more robust, definitely. But still quite
uncertain.

L.

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

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 17 Apr 2003 15:52:35 +0100 (BST)

L.

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 16 Apr 2003 21:45:14 -0700

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

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.

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 16 Apr 2003 21:45:14 -0700