Subject: Re: TML data channel transport protocol choice?

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 1 Nov 2005 20:34:35 -0500

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?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Nov 2005 21:47:24 -0500

Do we plan to specify that the protocol should operate with TTL set to 1 
(i.e. actually enforce closeness?)
If so, then we can look at whether that constraint is good enough.
If not, given that we know real world deployments always stretch teh 
envelop, I would be very uncomfortable with taking a path that was only 
reliable under such deployments.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 1 Nov 2005 22:05:58 -0500

>From the charter:
"
The main focus area of the working group will be control and
forwarding separation for IP forwarding devices where the
control and forwarding elements are in close (same room/small
number of hops) or very close (same box/one hop) proximity. Other
scenarios will be considered but at not the main focus of the
work.
"

I do however agree with you that Forces will find its way across
more than just the above constrained setup.

If the goal is to show up with a mandatory TML RealSoonNow, then
perhaps we could say that we mandate the UDP point of view of the
defined charter focus/scope (and state so in the TML description).
In the future we could have other TMLs that will go beyond that scope.

Does that make sense?

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 2 Nov 2005 11:30:22 +0800

I see that, in the multihop TML deployment,  the network is quite possible being
a publich netowrk, therefore,  only ForCES elements Applying DCCP actually also
does ganrantee the transport reliability for ForCES PL control message
transport, because, others may still possibly use things like UDP which will
congest the ForCES TCP still.

Therefore, we need to recognize if the defined TML should be specified to a
public or a private(leased) network or not.  Moreover,  publich network mostly
match the multihop case and private network may mostly match to single hop case.
As a result, to explicitly specify that a TML is a single hop and for private or
a multihop for public is a valuble specification.

thanks,
Weimnig

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 2 Nov 2005 11:35:16 +0800

Sorry a mistyping in the message as below.

----- Original Message -----
From: "Wang,Weiming" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 02, 2005 11:30 AM
Subject: Re: TML data channel transport protocol choice?

> does ganrantee the transport reliability for ForCES PL control message

SHOULD be 'does not garantee'.

---

From: Alistair Munro <[email-masked]>
Date: Wed, 2 Nov 2005 21:12:27 +0000

Hi All,

I agree with Jamal, quoted below as his message was some way back in the 
continuum.

> widely deployed it exists on just about any legacy device which could be

I can't add much to this, although we will have to address the multi-hop 
commodity network at some stage. There was an issue with head-of-line 
blocking with TCP, raised some time back. Was this resolved?

Concerning using IP multicast under the TML in this application, (Weiming's 
comment), I think this is a research topic right now. I can see the 
attraction, which is the usual one - point-to-multipoint saves bandwidth; 
but often reality doesn't achieve the promised gains.

When I asked about SCTP, it wasn't to propose it as a transport 
incidentally - just a question. I think it might have some attractions in 
certain configurations where its applicability statement matches the TML 
requirements, but I wouldn't leap in with it right now. I believe, however, 
that some consider it applicable for managing device interconnects where 
ForCES could reasonably be expected to be used, (not an endorsement, just 
an observation).

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: "Wang,Weiming" <[email-masked]>
Date: Thu, 3 Nov 2005 10:40:28 +0800

Hi Alistair,

Thanks for the comments.

----- Original Message -----
From: "Alistair Munro" <[email-masked]>
 Subject: Re: TML data channel transport protocol choice?

> but often reality doesn't achieve the promised gains.
I suppose you don't mean that UDP for multicast is still a research topic,
therefore I suppose you may mean the actual multicast for ForCES is a research
topic.

I cann't agree with your this idea in some way. I think it is a very real world
for us to adopt TML mulitcast when we choose UDP, just like the wild use of UDP
multicast for other applications. I don't see any technical blocking for such
use.  Multicast may be applied for PL msgs including redirect msg and Heartbeat
msg, which are very typical with the requirement for multicast.

thanks,
Weiming