Subject: towards consensus: ForCES transport and group addressing

From: Robert Haas <[email-masked]>
Date: Tue, 25 Nov 2003 17:10:44 +0100

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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Nov 2003 13:36:42 -0500

I see two kinds of problems with this:
1) Given that an FE being design can not ensure where it will be deployed, 
it follows that all FEs (and CEs) would have to support both UDP and TCP / 
SCTP transport.  (I do not believe that "targeted" is a useful or 
meaningful attribute of an FE or a CE.)
2) If we are going to support UDP, we need to specify the retransmission 
(including backoff), flow control, and congestion reaction algorithms.

On a related note, I do not know what it means to say that FEs and CEs MUST 
support group addressing.  This could mean the simple statement that the 
messages must contain higher level target IDs.  It could mean that we must 
have mechanisms to manage the configuration and use of group addresses.  It 
could mean any number of things.

Yours,
Joel M. Halpern

At 05:10 PM 11/25/2003 +0100, you wrote:
>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.
>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 
>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.
>
>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

---

From: Robert Haas <[email-masked]>
Date: Tue, 25 Nov 2003 20:38:57 +0100

Joel M. Halpern wrote:

> 1) Given that an FE being design can not ensure where it will be
> deployed, it follows that all FEs (and CEs) would have to support both
> UDP and TCP / SCTP transport.  (I do not believe that "targeted" is a
> useful or meaningful attribute of an FE or a CE.)

You could also argue that some FE manufacturers will only address the
local scope market, because the FE they make is meant to be attached to
a switching fabric to which the CE is also attached. Since most of the
argument until now was due to the mixing of local/global scopes, I
thought it is useful to address them separately, even if we end up
having FEs supporting both (most likely case).

>
> 2) If we are going to support UDP, we need to specify the
> retransmission (including backoff), flow control, and congestion
> reaction algorithms.

You should consider also that there exist backpressure mechanisms in
switching fabrics that can help achieving this. And we don't need to
specify complex algorithms to start with. Probably we'll never need to.

>
> On a related note, I do not know what it means to say that FEs and CEs
> MUST support group addressing.  This could mean the simple statement
> that the messages must contain higher level target IDs.  It could mean
> that we must have mechanisms to manage the configuration and use of
> group addresses.  It could mean any number of things.

Therefore the point behind my attempt to first agree on what we want,
and then discuss how to provide it. From your answer I conclude that you
consider group addressing should NOT be part of ForCES and that TCP is
the only tolerable transport.

I am curious what others think of this attempt to reach some consensus.

--
Robert Haas

---

From: Alex Audu <[email-masked]>
Date: Tue, 25 Nov 2003 13:52:36 -0600

All the agreed upon must-have features of ForCES have been documented
in the requiremnents document. So, why make a new set of requirements at
this stage?

Regards,
Alex.

---

From: Robert Haas <[email-masked]>
Date: Tue, 25 Nov 2003 21:03:41 +0100

Alex,
You should not view what I sent as protocol requirements, rather as 
actual answers to the requirements. I am fully OK with the draft 
requirements, but this does not make us progress much. What's your 
answer in that case ?

-Robert

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 25 Nov 2003 15:29:22 -0500

Since you invoke the requirements and charter at every opportunity,
let me remind you your favorite section, on reliability, apologies to
other people, so which part rejects having both UDP and TCP?

---------------
 6)Reliability 
   a) The ForCES protocol will be used to transport information that 
     requires varying levels of reliability. By strict or robust 
     reliability in this requirement we mean, no losses, no corruption, 
     no re-ordering of information being transported and delivery in a 
     timely fashion. 
   b) Some information or payloads, such as redirected packets or packet 
     sampling, may not require robust reliability (can tolerate some 
     degree of losses). For information of this sort, ForCES MUST NOT 
     be restricted to strict reliability. 
   c) Payloads such as configuration information, e.g. ACLs, FIB 
     entries, or FE capability information (described in section 7, 
     (1)) are mission critical and must be delivered in a robust 
     reliable fashion. Thus, for information of this sort, ForCES MUST 
     either provide built-in protocol mechanisms or use a reliable 
     transport protocol for achieving robust/strict reliability. 
   d) Some information or payloads, such as heartbeat packets that may 
     be used to detect loss of association between CE and FEs (see 
     section 7, (8)), may prefer timeliness over reliable delivery. For 
     information of this sort, ForCES MUST NOT be restricted to strict 
     reliability. 
   e) When ForCES is carried over multi-hop IP networks, it is a 
     requirement that ForCES MUST use a [RFC2914]-compliant transport 
     protocol. 
   f) In cases where ForCES is not running over an IP network such as an 
     Ethernet or cell fabric between CE and FE, then reliability still 
     MUST be provided when carrying critical information of the types 
     specified in (c) above, either by the underlying link/network/ 
     transport layers or by built-in protocol mechanisms. 
---------------------------------

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 25 Nov 2003 15:40:26 -0500

I think we should pull this conversation to the IESG so we can pull back
the requirements draft because obviously it doesnt meet the requirements
that most people need. This is precisely what i was worried about when
you have Hormuzd editing the draft and trying to be a lawyer at the same
time.

Do you know how i can do that?

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Tue, 25 Nov 2003 15:17:28 -0600

Hi Robert,

I think what your suggestions smell like protocol requirements. However, you
can find answers/guidance  to these suggestions/questions in the requirements
document. See the following:

  6)Reliability

   7)Interconnect Independence
   The ForCES protocol MUST support a variety of interconnect
   technologies. (refer to section 5, requirement# 1)

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Tue, 25 Nov 2003 15:30:49 -0600

You can use any CE/FE interconnect. But for any of your solution, you
MUST explain how you achieve reliability and security to meet the
requirements.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Tue, 25 Nov 2003 15:40:16 -0600

Hi Jamal,

This is a strange way of solving problems. Definitely the ForCES
requirements predate any protocols being proposed to satisfy the
said requirements. At least, that is what should take place. What I
think you are proposing is a problem definition to fit the solution you
have provided. This is quite interesting, and I don't think it is the best
problem solving approach. Sometimes this approach works, but often times,
it doesn't. I believe this is one of those times it fails.

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 25 Nov 2003 16:59:44 -0500

On Tue, 2003-11-25 at 16:40, Alex Audu wrote:
> said requirements. At least, that is what should take place.

I wouldnt say that was the case - and i think it this is the cause
of all this pain we are going through. FACT was released much earlier on
before the requirements draft was complete. A few months later, netlink2
followed. What i remember is netlink2 came out at the end.

>  What I

The requirements were not collected then a proposal made.
So i dont know what you mean by "this is one of the times it fails".
Rather there was  a proposal and requirements were spun around it.
I am sure if i wasnt around the requirements would have read "FACT".

I apologize for being so cynical - i am tired of these circular
discusions. We obviously see a need for multicast and you dont - what
baffles me is what scares you so much you want to kill it?
If it is as bad as you claim - what is there to fear?

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Tue, 25 Nov 2003 16:56:47 -0600

Hi Jamal,

No one is proposing that any thing be "killed".  And no one has written on
this list (at least to my knowledge) that multicasting is a bad thing. Far from
it. What I understand from the concerns raised is:."OK, explain how you
intend to propose multicasting over UDP in the ForCES environment and
yet meet all the critical requirements of ForCES (like reliability and
security)".

I don't think the solution to that is to go change the requirements.  I mean,
that
process has long passed!

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 25 Nov 2003 22:35:48 -0500

So, Alex ... if we showed you how to do that are you gonna stop these
circular arguements or will you be looking for something new? ;->
[Reminds me of a canadian politician who once stood in parliament waving
a piece of paper saying that the paper had proof the internet had
porn. This was back in the very early 90s - porn, huh? It happens that
porn was a great contributor to internet growth and technology.
Unfortunately through the wonders of democracy the guy ended up getting
elected as premier of ontario].
I guess the moral of the tale is: I am now pretty sure noone arguing
against multicast has actually understood the scope of the problem.
I will give you a hint: the tree has a depth of one (ttl == 1).
Multicast packets dont cross routers. Draw yourself a diagram; a line to
represent the physical wire then attach nodes(CEs/FEs) to it. Now
investigate this problem for reliability, congestion control and come
back with a list of protocols that handle this scope _very well_. Dont
bother going to the RMT WG. They talk about multicast packets crossing
routers there mostly. Ask google - she will list plenty for you; just
pick one you like.

cheers,
jamal

---

From: avri <[email-masked]>
Date: Wed, 26 Nov 2003 20:38:19 +0900

hi,

I just came back from a bit of vacation and had the pleasure of reading
through the many messages that compose the multicast thread.  Made for
an exciting couple of hours on a dreary day.

Though the thread baffles me.

- it is as if 2 of the 3 contending protocols are fighting for
supremacy on the subject of multicast support.  With 3 protocols in
contention it is difficult to understand the positioning and posturing.

- I do not understand in what way multicast support is a criteria for
choosing a protocol.  As I understand the requirements it is neither
required not precluded by the requirements.  From the arguments it
seems like there may be cases where it comes in useful, though there
seem to be issues that need to be resolved in other cases.  As one of
those who is not committed to any of the protocols, I don't see it as a
necessary criteria for choosing and believe that it should be optional
whether a protocol uses multicast as long as it meets the other
requirements.  In many ways it seems as though it may be more of an
implementation issue then a protocol selection criteria.

a.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Nov 2003 09:31:36 -0500

There are two dimensions that I see still needing attention:
1) Even with only one "hop", reliability, congestion control, flow control,
and security still need to be addressed.  I might agree that for in-box the
last may be skipped.  The rest apply anyway.  (The reason many existing
backplane mechanisms do not worry about such things is that the
relationship between the control processor, the control load, the backplane
capacity, and the forwarding blade capacity are carefully engineered.  That
can not be assumed in a standard for use in mixed-vendor environments.)

2) Based on experience in multiple working groups, work aimed at one
limitted scope tends to get applied to other scopes.  I suppose that one
could try to put in mechanisms to actually control the scope that can be
applied.  But that is quite complex in its own right.

Yours,
Joel M. Halpern

At 10:35 PM 11/25/2003 -0500, you wrote:
>Now
>back with a list of protocols that handle this scope _very well_.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 26 Nov 2003 18:08:51 -0500

We strongly believe that multicast is very important.
The authors of the netlink2 draft will address all these issues
in the next release. We hope this will close this discussion
and give people interested in using multicast the opportunity to do so.

cheers,
jamal