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

From: "Deleganes, Ellen M" <[email-masked]>
Date: Tue, 25 Nov 2003 16:06:48 -0800

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. 

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.

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: Sandy Pavel <[email-masked]>
Date: Wed, 26 Nov 2003 10:06:56 -0500

If I understand well your message here is: use only TCP because it has
built in reliability and don't use UDP because building reliability on
top of UDP would take too many cycles from the FE CPU.

There are a few problems with this:

- the TCP reliability does not come for free. Both CE and FE CPUs have
to spend cycles on it.
- no matter how one would turn the problem, communication reliability
can only be insured with some sort of feedback.
- does not make much difference, in terms of number of CPU cycles, where
they are spent: at the transport protocol level or at the application
level.

Therefore your arguments do not hold at all.

TCP has the advantage of allowing for a simpler application programming
paradigm (including maybe simpler protocol state machines). But we
should not forget that TCP does not behave very well in a congested
network ( the backoff mechanism will reduce the amount of TCP traffic
favouring the other traffic). All this imposes more restrictive
requirements on the actual traffic management for the medium used for
CE-FE communication. (please see the literature on this subject)

As a real world example, consider two protocols that have been proposed
for traffic engineering in MPLS: RSVP-TE and CR_LDP. CR-LDP uses TCP for
transport reliability; RSVP uses only application (protocol) level
reliability (when it uses it). Political considerations aside, RSVP-TE
is doing well, CR-LDP less so. One of the major problems I have noticed
is that the overly complicated and cumbersome reliability mechanism
(very intelligent otherwise) provided by TCP is very slow compared with
an application level mechanism tailored to the problem at hand. Again, I
am not asking to take my word for it; please consult the literature that
provides more rigorous results. 

I am not arguing against TCP (I guess it is too late for this) but we
should be careful when we argue in favour of TCP just because it has
reliability implemented.

Regards,
Sandy

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Deleganes, Ellen M
Sent: November 25, 2003 7:07 PM
To: [email-masked]
Subject: Re: towards consensus: ForCES transport and group addressing

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. 

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.

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

ForCES transport
---------------------

ForCES group addressing

---

From: Robert Haas <[email-masked]>
Date: Wed, 26 Nov 2003 19:25:33 +0100

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

>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 unle…
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 pro…
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.