Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast

From: [email-masked]
Date: Sun, 14 Mar 2004 19:08:34 EST

Hello Jeff,

Certainly using multi-unicast instead of multicast to avoid incidents of ACK 
implosion,
gives us the time dimension to play with.  The CE only needs to send out a 
manageable
number of messages at a time. 

Cheers,
Alex.

In a message dated 3/12/2004 8:34:10 PM Central Standard Time, 
[email-masked] writes:
Alex,

Using unicast to avoid multicast ack implosion devolves into the worst 
case of  not only
a unicast ack for every packet, but also the unicast packet causing the 
ack. Im afraid we
need to accept some level of complexity to enable the scaling we need.

Cheers,
Jeff

Alex Audu wrote:

> Hello Patrick,
>
> Sorry it took me this late to respond.  I really don't know what a 
> "MUST if  available"
> means.  The main issue with multicast is that there are still a lot of 
> unresolved issues
> about it viz:
> 1) In a critical environment like the one we are talking about,  we 
> need ACKs to give
>     a warm-fuzzy feeling that FEs are getting what the CEs are 
> blasting at them.  What is
>     the implication of this as number of FEs rise into the thousands?  
> You run the risk
>     of  tons of ACKs comming back and overwhleming the CE. That is 
> essentially a
>     flooding attack on the CE. I believe it is called ACK implosion in 
> literature.  A lot
>      of ways have been proposed to avoid this,..like selective 
> ACK/NACK,..etc. These
>     suggested solutions are pretty complex.
>
> 2) As the number of FEs grows, the  chance of packet loss increases in 
> the network
>     when doing multicast.  You have to fall back on retransmits  to 
> accommodate this.
>      That essentially whipes out the percieved benefits of mulitcast.
>
> 3) How do you synchronize your packets and make sure they are recieved 
> in order at the
>     the FEs?  You have to build something extra into  your application 
> or the FoRCES
>     protocol to take care of such issues.  And if you don't specify 
> it, there is danger of
>     different implementations resulting in interoperability issues.
>
> 4) And there are issues of security to address.
>
> In short, I am not sure we know enough about multicast to mandate its 
> use in a
> critical envirnonment. If we are not concerned about timing, sure, we 
> can retransmit
> a couple of times untill all the endpoints get the data. But we 
> resorted to multicast  to
> save time in the first place.
>
> Regards,
> Alex.