Subject: Re: TML data channel transport protocol choice?

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

I don't agree.
Consider that the IETF is pushing all protocols to consider congestion 
issues where they ignored them before.
I was talking with Scott Bradner.  He sponsored the original BoF for 
ForCES.  He sponsored the BoF in the transport area.  The reason he 
sponsored the BofF is that he considered (and still considers) it important 
that we deal with congestion control in all aspects of our work.

I have no objection in principle to alternative TMLs without congestion 
control.  (For some, such an omission is probably quite reasonable.)
But we have to have a mandatory to implement TML that works across a range 
of cases.
Thus, I would like to see DCCP used for the redirect channel for that TML.

Yours,
Joel M. Halpern

At 11:17 AM 10/29/2005, Weiming Wang wrote:
>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.

---

From: Weiming Wang <[email-masked]>
Date: Sun, 30 Oct 2005 09:43:11 +0800

Using DCCP in our case and appling it to the case like TCPoverDCCP also has the
potential to lead to the problem like TCPoverTCP. Note that the generic cause
for the extreme low efficiency of TCPoverTCP is the
CongestionControl-Over-CongestionControl algirithm.  By checking the
congestioncontrol method DCCP applies which is generally quite identical to TCP
only regarding the congestion control aspects, I have no feeling that the same
problem can be avoided compared with TCPoverTCP.

Thanks,
Weiming

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 30 Oct 2005 10:58:10 +0800

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

> that we deal with congestion control in all aspects of our work.
For PL control messages that originate and also destinate in one ForCES NE, I
have no doubt on this desire, but for redirect data, for which FE only acts as
one of the intermediate nodes, by which trasport may be across wide range of
networks, I don't see any value and extreme desire( except for DoS prevention)
to apply full CC for only such one node, while other nodes out of the FoCES NE
are still not CC  mandatory.
> But we have to have a mandatory to implement TML that works across a range
I'm not sure how we can have a mandatory one while we still have an alternative
one?  My simplest thought is we should have a basic one like TCP+UDP TML to
provide common users with an IP TML solution, then we can have a TCP+DCCP TML
for users who like to be more advanced after we have had DCCP quite evaluated.

> Thus, I would like to see DCCP used for the redirect channel for that TML.
I'd like to see this after more evaluation of the brand new protocol.

Thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 30 Oct 2005 09:07:41 -0500

In order to enable interoperability, there needs to be a TML that every 
ForCES implementation supports.  There can be other stacks in the 
implementaiton as well.  Local configuration will determine which stack is 
used if there are multiple choices in the implementaiton.
Without a "mandatory to implement" mechanism, two independent 
implementations do not have a mechanism that can be counted on to communicate.

This approach to the handling of optional mechanisms has been used by the 
IETF on many occaisons.  It is, for example, how we handle security.

Yours,
Joel M. Halpern