Subject: Re: TML data channel transport protocol choice?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 2 Nov 2005 14:08:09 -0800

Thanks for the information on DCCP, Jamal.

Just wanted to say that I too agree with the general sentiment of having
one mandatory or default TML and then other alternatives TMLs. The
authors of the existing TML wg draft are open to accommodating any of
the appropriate transports/mechanisms being discussed, once we reach a
WG consensus on one.

Thanks
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, November 01, 2005 5:35 PM
To: [email-masked]
Subject: Re: [FORCES] TML data channel transport protocol choice?

Folks,

Apologies that i havent participated in this discussion; I have been
tied up elsewhere.

I agree to the general sentiment of standardizing a mandatory TML, RSN.

DCCP is now part of the stable Linux kernel - version 2.6.14. I am not
sure about other OSes. Dont know if i care about them ;->
Experience-wise: We have implemented only TCP at this point - including
its use for the redirect. We do not wish to stick to just TCP.

If one was to say we are restricting the ForCES initial release to a
single hop; i can see the possibility of UDP as well being a valid
candidate. Congestion control - given the constraints of a single hop
(aka close proximity)- should be sufficiently handled via QoS control.
I am not even thinking of rate control - rather something simple like
strict priority queuing. Pick best effort for redirect. Queue fills up,
drop.

At this point i am indifferent as to whether it is DCCP or UDP. We can
implement either in a very short period.
The only con i see with DCCP is its lack of wide deployment; UDP is so
widely deployed it exists on just about any legacy device which could be
used as a FE.

cheers,
jamal
 
On Mon, 2005-31-10 at 11:20 -0500, Joel M. Halpern wrote:
> 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
> 
> At 10:57 AM 10/31/2005, Putzolu, David wrote:
> >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?