Subject: TML data channel transport protocol choice?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 27 Oct 2005 23:05:48 -0700

Hi Folks,

I would like to know what thoughts the WG has on the data channel
transport for the TCP/IP TML that is the default ForCES TML.

This is the main issue remaining before we can take this draft to WG LC.

There are couple of options available for the data channel transport
protocol:

TCP - This would work well with the TCP connection that is used for the
control channel. However, there are issues around behavior with routing
protocols such as BGP that themselves use TCP.

DCCP - This is the best theoretical option in terms of the properties it
possesses, i.e. no-reliable transport protocol with Congestion Control
(CC). The only issue with this in the past has bee lack of stable
implementations. But this was over a year back when I was doing some
experiments, I have been told that this is no longer the case.

UDP with some sort of rate limiting or CC - This option would
essentially be reinventing the wheel in terms of what has been done with
DCCP to some extent, unless we can find a straight forward way to do
this. Also, co-existence with TCP CC mechanism used by control channel
is unknown.

I would like to hear from the WG at this point. If we can reach a rough
consensus soon, that would be great.

Thanks

Hormuzd

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Oct 2005 23:03:44 -0400

My preference is for the DCCP option.

Operating without congestion control at all would be a bad idea.
Attempting to invent our own "simple" congestion control is a mistake.
And while using TCP is attractive, the operation of nested control loops 
(TCP application like BGP or telnet to console with TML TCP nested inside) 
is a notoriously error prone phenomena.

The concern about a stable stack is clearly important.  if there are 
indications that there are stable DCCP implementations, that would make the 
choice pretty clear for me.

Yours,
Joel

At 02:05 AM 10/28/2005, Khosravi, Hormuzd M wrote:
>There are couple of options available for the data channel transport protocol:
>
>TCP – This would work well with the TCP connection that is used for the 
>DCCP – This is the best theoretical option in terms of the properties it 
>UDP with some sort of rate limiting or CC – This option would essentially 
>be reinventing the wheel in terms of what has been done with DCCP to some 
>extent, unless we can find a straight forward way to do this. Also, 
>co-existence with TCP CC mechanism used by control channel is unknown.
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 29 Oct 2005 11:38:10 +0800

A general comment is,  after an experience with the ForCES implementation, I
strongly believe the TCP+ UDP would be the best and fundamental choice ForCES
users for their implementations, thought I think the TCP+DCCP  may not be
excluded totally from  customs who are more pioneer.

Note that UDP congestion has already been existing, while Internet is also still
running quite efficiently. I don't think DCCP will act as the liberator for this
issue. Focusing on UDP and resloving the congestion at specific application
cases is still the basic way for current Internet applications.

Joel,  also more comments inline of your text. Thanks.

regards,
Weiming

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: TML data channel transport protocol choice?

[W] Agreed.

[W] Really?  Why is it a mistake?  If it is a simple and efficient way, why not
choose it?

The concern about a stable stack is clearly important.  if there are
indications that there are stable DCCP implementations, that would make the
choice pretty clear for me.
[W] A simple DCCP implementation is not enough, I think.  For things like our
ForCES case, at least, we should evaluate how it acts together with TCP also.

Yours,
Joel

At 02:05 AM 10/28/2005, Khosravi, Hormuzd M wrote:
>UDP with some sort of rate limiting or CC - This option would essentially

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Oct 2005 08:47:17 -0400

UDP has no congestion control.  The IETF as a whole has realized that 
standardizing protocols without congestion control is a bad idea.
Following the example of our approach to security, there needs to be a 
mandatory-to-implement mechanism with congestion control.  There may be 
other optional mechanisms (raw backplane usage, etc.) for special 
circumstances.

The problem is that the folks who need to be handed congestion control are 
not the really sharp users who know what they are doing, but the relatively 
naive users who stretch the envelop of where the tool they have been handed 
should be used.

With regard to inventing out own, congestion handling (detection, response, 
& control) is quite tricky.  Very sharp people have gotten in wrong 
before.  The assumption that ~this is an easy case, this simple mechanism 
will work~ often turns out very badly.  If DCCP is not stable, there may be 
an argument that we need to invent a solution.  But in the presence of a 
verified and usable solution from another IETF working group, there is no 
good reason to invent our own congestion response..

Yours,
Joel M. Halpern

---

From: Weiming Wang <[email-masked]>
Date: Sat, 29 Oct 2005 23:17:35 +0800

----- Original Message -----

> standardizing protocols without congestion control is a bad idea.
Raw data transport is generically hard for congestion control. That explains why
after tens of years we have only a thing like DCCP, and why IETF could not find
a better substitute for UDP in so long a period.  This actually also means UPD
has been the best choice rather than a bad idea in terms of the solutions
available.

> mandatory-to-implement mechanism with congestion control.  There may be
I should note that the ForCES does not and also does not need to mandatory
precise and strict congestion control on redirect data transmission, the ForCES
does mandatory it on PL control messages.  The only requirement mandatory to
redirect data transport is it must not block control message transmission,
therefore putting a complex and complete CC on it MAYBE a luxury.

> & control) is quite tricky.  Very sharp people have gotten in wrong
Joel, I can understand your worry here, but as mentioned above,  the ForCES may
not have to face a very strict CC problem, or in other words, the issue we now
face, as I can see, is only the DoS prevention problem, just like that in many
other Internet applications.

> an argument that we need to invent a solution.  But in the presence of a
I'm not very objective to DCCP deployed for ForCES, but as you being an
experienced expert in IETF may know well, a transport layer IETF protocol acting
as the fundamentals for Internet, may need to take a very long time before it
can be evaluated.  UDP has been in place for tens of years while we still
evaluate it.  I  just worry it may be too early we now too highly rely on a
standard track TRANSPORT PROTOCOL  that has just got approved as RFC.  I also a
little worry that DCCP as a newer to us, it may in one place slow down the
ForCES progress, and in another place it may also has negative side effect for
ForCES applications.

Whereas, I'm not in the same page that we take DCCP into acount and may choose
it as an alternative TML, and to develop such TML in a pace just along with the
DCCP progress.

Thanks,
Weiming