Subject: Re: TML data channel transport protocol choice?

From: "Putzolu, David" <[email-masked]>
Date: Mon, 31 Oct 2005 07:57:07 -0800

Hi Joel.

Speaking for myself, I agree that we must not invent new protocols or
applications that add congestion-clueless ness to the Internet. However,
does the redirection side of ForCES qualify as a new protocol?  As best
I can tell, no ForCES-specific traffic is expected to be generated and
sent over the redirection.  Rather, all the traffic over the redirection
side will be traffic that is would normally be sent/received over the
Internet by regular routers, so the level of congestion-cluelessness on
the Internet would not be changed if UDP where to be used in the ForCES
TML.

What do you think Joel?  Is this splitting hairs?

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Sunday, October 30, 2005 1:37 PM
To: [email-masked]
Subject: Re: [FORCES] TML data channel transport protocol choice?

Is there an SCTP mode without retransmission?  I had understood SCTP to 
always offer reliable service.  And the redirect channel does not need 
reliability.  I know that they have put more capabilities in SCTP than I

had understood in other ways, so it is possible there is a suitable
branch 
here.

I have been informed that the state of DCCP implementations has gotten 
better.  And it is a standards track protocol.

Yours,
Joel M. Halpern

At 01:17 PM 10/30/2005, Alistair Munro wrote:
>Hi All,
>
>>On of the key reasons DCCP was developed is that its behavior is
designed
>>to work well with TCP>
>>Without care, the exact problem you describe will occur.
>
>As far as I can tell, DCCP does fit the requirements but
implementations 
>are experimental. Probably more experience is needed before DCCP can be

>recommended - however, it should not be ruled out.
>
>What about SCTP? Or did that get excluded already?
>
>Regards,
>
>Alistair
>
>--
>Alistair Munro,
>Principal Engineer, U4EA Technologies Ltd.
>City Point, Temple Gate, Bristol, BS1 6PL, U.K.
>E-mail: [email-masked]
>Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
>+44-7974-922-442;
>Fax: +44-117-373-6751
>Web: http://www.u4eatech.com

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Oct 2005 11:20:54 -0500

It may be splitting hairs, but it is a hair I gave serious consideration to 
before expressing my opinion. I think it does strongly affect the basic 
reason that we need congestion control (or don't) on the redirect channel.
If the network path the redirect packets were taking was (hypothetically) 
the same as the one that the packet would take anyway, then all we would be 
doing is putting an extra header on and sending the data packet.  Tunnels 
do not require extra congestion control.
However, the redirect packets are not taking that path.  The redirect path 
has two properties that I believe drive the need for congestion control.
Firstly, that redirect path is a funnel.  Packets needing control attention 
(routing protocols, possibly ICMP, maybe others) from all the interfaces on 
the NE will be going over the redirect channel.  While I would normally 
expect this to be a small set of traffic, under some circumstances it can 
be large.  And it is much more concentrated than on any data link of the 
NE.  (The traffic needing redirection is a small proportion of the traffic 
on each link, but can add up to quite a lot on the FE-CE link.)
Secondly, the redirect path is shared with the reliable, flow controlled, 
ForCES control protocol.  It is important that we make sure that overload 
of redirect traffic does not interfere with control operation.  (After all, 
if it does interfere, then there is no way for the CE to make it stop 
interfering, because the CE can not communicate with the FE to change the 
FEs behavior.)

So, I concluded that even though these redirect packets are normal IP 
packets, which can happily be discarded under stress / load, we need some 
congestion control on the redirect path.

Yours,
Joel