Subject: Reliability in LAN

From: "Karthikeyan Subramaniam" <[email-masked]>
Date: 10 Apr 2003 07:50:55 -0000

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.

_______________________________________________________________________
Odomos - the only  mosquito protection outside 4 walls -
Click here to know more!
http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 10 Apr 2003 13:39:09 -0400

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

---

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

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

---

From: "Karthikeyan Subramaniam" <[email-masked]>
Date: 11 Apr 2003 03:18:16 -0000

My requirements are reliability mechanism based on UDP/IP. I 
have to optimise the packet transaction in the LAN using SACK and 
NACK effectively. One more thing as I have to build reliability on 
LAN, I need not follow hierarchial approach of data recovery 
(Method used to avoid overloading the sender). Is there any RFC or 
draft avaiable for reliable multicast mechanism based on these 
requirements?

Thanks
karthik

---

From: "Karthikeyan Subramaniam" <[email-masked]>
Date: 15 Apr 2003 06:47:54 -0000

Yes, my requirement can be considered as a simplified model of 
reliable multicast with only one hop. The requirement is to build 
generic reliable layer which any application can use to send 
data.

Is there any RFC/draft designed for this?

-karthik.

I don't understand what's the difference between them, because 
your condition could be considered as a simplified model of 
reliable multicast with only one hop ( or maybe that covers a VLAN 
).

If focusing on application layer QoS,  it could construct 
application layer multicast tree without consideration on 
underlying networks.

  Karthikeyan Subramaniam <[email-masked]> wrote:

My requirements are reliability mechanism based on UDP/IP. I
have to optimise the packet transaction in the LAN using SACK 
and
NACK effectively. One more thing as I have to build reliability 
on
LAN, I need not follow hierarchial approach of data recovery
(Method used to avoid overloading the sender). Is there any RFC 
or
draft avaiable for reliable multicast mechanism based on these
requirements?

Thanks
karthik
On Thu, 10 Apr 2003 Michael Luby wrote :
>direct solution to adding reliability to multicast without 
>losing
>any
>scalability.
>

Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China

---

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

> Sent: Thursday, April 17, 2003 12:45 AM
> To: Lloyd Wood; Manfredi, Albert E
> Cc: Karthikeyan Subramaniam; [email-masked]
> > From: Lloyd Wood [mailto:[email-masked]]
> > Sent: Wednesday, April 16, 2003 6:32 AM
> > To: Manfredi, Albert E
> > Cc: Michael Luby; Karthikeyan Subramaniam; 
> > 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
> > >
> > >
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> >
> 
>

---

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

I agree. My impression, perhaps wrongly, is that it was being suggested here that RFCs 3450-3453 somehow invalidate what was described in RFCs 2357, 2887, and 3048. I don't think they do.

Let's look at DATA transfers only. For data transfers, I don't agree that a FEC, with the possible addition of data carousel or layered coding, is always a viable option.

One of the applications of data carousel is the broadcasting of data packets. Without a return path, you have to make do with repetition of the data, until all receivers will have a high likelihood of having received the complete data download correctly. This works great in a broadcast, works well but is somewhat  wasteful in multicast, and becomes onerous and wasteful in unicast. Data carousel has to be designed for worst case scenarios. It loads the network down more than a TCP/IP (unicast) session would, for the same level of reliability. Packets have to be repeated enough times to compensate for the worst case corruption levels, must be repeated to compensate for packet loss due to congestion, and these repeated UDP packets in turn create congestion in the network, because they are non responsive.

So in a unicast, these techniques end up requiring more bandwidth for similar robustness as TCP/IP. But in broadcast, congestion is a non-issue. The network is sized according to the needs of the source. Besides, with no return path, it's the only game in town.

RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here:

1.1.  Application of FEC codes

   For some reliable IP multicast protocols, FEC codes are used in
   conjunction with ARQ to provide reliability.  For example, a large
   object could be partitioned into a number of source blocks consisting
   of a small number of source symbols each, and in a first round of
   transmission all of the source symbols for all the source blocks
   could be transmitted.  Then, receivers could report back to the
   sender the number of source symbols they are missing from each source
   block. 

This technique requires a resturn path, which is available in IP Multicast but not in broadcast, and this approach can be far more network friendly than data carousel.

I can also see another problem here, which is my use of the word "reliability." In RFC 3453, for example, "reliable" means "error free." As I used it, "more reliable" or "add reliability" are synonymous. They do _not_ mean "make it error free." Going back through the thread, I can see that created a problem.

Bert

> From: Tom Pusateri [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 4:03 PM
> To: Manfredi, Albert E
> Cc: Lloyd Wood; [email-masked]; [email-masked]
> Subject: Re: Reliability in LAN 
> 
> 
> 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.
> >
> >Thus, FEC certainly DOES increase reliability. It just 
> doesn't guarantee error
> >-free reception of every packet.
> >
> >Bert
> >
> >