Subject: Re: towards consensus: ForCES transport and group addressing

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 26 Nov 2003 11:26:51 -0800

I agree that in the local case that the packet loss and corruption is significantly lower than in the internet. However, that doesn't mean you can ignore the problem. You still need some reliability mechanisms - a number of the proprietary high-speed interconnects have HW reliability mechanisms (ACK, retransmit, sequence numbering, etc.) built in, even though they expect to experience a very low level of packet loss.

I would assume that the reliability of the underlying transport would have an effect on the amount of application-level reliability built into ForCES. If you make the base assumption that the underlying transport has little to no reliability, it seems like the reliability mechanisms that would need to be added to ForCES may be overkill and additional overhead for a transport that has some reliability already built in.  

The difficulty that I have with multicast is that adding reliability is complex. Reliable multicast is still in the experimental stage in the IETF and is a difficult problem to solve. Other high-speed interconnect activities that I've been involved with had reliable multicast as a desired feature, but ended up punting on it because of the complexity. So far the use cases and benefits don't seem to justify the additional effort.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation [mailto:[email-masked]] On Behalf Of Robert Haas
Sent: Wednesday, November 26, 2003 10:26 AM
To: [email-masked]
Subject: Re: towards consensus: ForCES transport and group addressing

At the risk of being redundant with Sandy's answer:

Deleganes, Ellen M wrote:

>The only real use for UDP without other protocol mechanisms is for those messages that don't require strict reliability. Given that, it seems of little value to make UDP a requirement on the FE unless the additional protocol mechanisms which make UDP reliable also become a requirement, which would probably be unattractive to FE vendors. 
>  
>
Whether UDP or TCP is used, or any other >transport< protocol, ForCES 
must anyway provide the means for >application< level reliability (Alex 
keeps pointing me to the reliability req section, but this has been 
taken care of since the FIRST netlink2 draft).

In the local scope (i.e., some high-speed interconnect, switch, etc), 
Internet-like packet loss is not expected. Or the interconnect is badly 
designed (i.e., lack of backpressure mechanisms).

>The problem with this is that FEs probably have less CPU capacity than the CE and adding another layer of protocol to the FEs to implement this reliability could detract from the FE's ability to process packets. By requiring support for multicast over UDP, the tradeoff is potentially saving some CPU cycles on the CE, but consuming more cycles on the FE by requiring additional protocol processing to provide the reliability levels required (or should be) for configuration messages.
>
This additional layer is required anyway, it's part of ForCES. So I 
don't see where is the problem. Actually, what I proposed would even 
save cycles by avoiding unnecessary TCP mechanims in the local scope.

>Regards,
>Ellen
>
>-----Original Message-----
>From: Forwarding and Control Element Separation [mailto:[email-masked]] On Behalf Of Robert Haas
>Sent: Tuesday, November 25, 2003 8:11 AM
>To: [email-masked]
>Subject: towards consensus: ForCES transport and group addressing
>
>In order to reach a consensus before we are exhausted posting on the 
>list, let me cristallize what could help unlock the situation.
>
>I presume we should be able to reach consensus on sth like (remains to 
>be defined in more detail):
>
>ForCES transport
>---------------------
> a) An FE MUST support UDP (or raw media encapsulation) as ForCES 
>transport if the FE is targeted at the local scope env.
> b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is 
>targeted at the global scope environment.
> c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as 
>ForCES transport if the FE is targeted at both local and global scopes.
>  (the same applies for the CE)
>
>FEs/CEs that support TCP will support UDP as well (I have never seen an 
>IP stack that offers TCP without UDP). Note that this does not prevent 
>from using TCP in the local scope if the FEs and CEs support it. Thus 
>TCP-proponents should be satisfied.
>
>
>In addition, could we reach consensus on sth like:
>
>ForCES group addressing
>------------------------------
> d) FEs and CEs MUST support group addressing in the ForCES protocol.
>
>Nobody is forced to USE such a group addressing (one can stick to 
>unicast ForCES-addressing and TCP transport in all cases). But if one 
>sees that group addressing fits ones needs (and many have voiced it on 
>the list), then one should be able to use it. Ultimately (and this is 
>probably best so), it's the user writing software in the CE who decides 
>what she/he wants to use.
>
>Note that the phrasing in a), b), c), and d) is meant to satisfy 
>interoperability. Not my ego.
>
>I have the impression that a number of participants in this WG, 
>including other protocol draft authors, tend to agree on these items. 
>Who would not agree (and on what) ?
>
>  
>

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 26 Nov 2003 17:28:42 -0500

Hi Ellen,

On Wed, 2003-11-26 at 14:26, Deleganes, Ellen M wrote:

> Other high-speed interconnect activities that I've been involved with
> had reliable multicast as a desired feature, but ended up punting on
> it because of the complexity.

Can you explain this a little more?
Was the reliable mcast being built into the hardware or you meant
the s/ware that rides on top?
Are you able to describe details of how this setup looked like?

cheers,
jamal