Subject: Re: TML data channel transport protocol choice?

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Oct 2005 21:51:26 -0400

With DCCP, we could choose a behavior that provides discard rather than 
pacing.DCCP does not perform retransmission.
A home-brew rate control would have significant risk of interacting with 
TCP timers.

Yes, there is probably some risk of negative interaction of TCP 
applications and DCCP behaviors.  But any congested link produces some 
negaitve effects.  The point is to use something with reasonably low risk 
of problem.

Yours,
Joel

At 10:43 PM 10/29/2005, Weiming Wang wrote:
>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]>
>
> > 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: "Wang,Weiming" <[email-masked]>
Date: Sun, 30 Oct 2005 12:06:05 +0800

Some more comments as below.

One more thing for DCCP is, we are also very unclear how DCCP will act along
with parallel TCP.  This is the key point for avoiding DoS attack in the ForCES
case. Because DCCP does not retransmit packets, I have a prediect that DCCP will
still act more agressively than TCP. As a result, purely adopting DCCP actually
does not prevent DoS then. This means if we adot it, we  still have to find
other mechanism to avoid DoS, which leads to the same way as we face when we
have initially adopted UDP.

Thanks,
Weiming
----- Original Message -----

> A home-brew rate control would have significant risk of interacting with
Sub-section double ACKs, sub-section retransmission, and sub-section windowing
that does not match whole section TCP windowing,  all of these contribute to TCP
inefficiency.  DCCP only avoid the retransmission among these.  DCCP still
adopts AIMD, which obviously negatively interacts with the above TCP AIMD.

> negaitve effects.  The point is to use something with reasonably low risk
I agree with this,  therefore I tend to the method that we adopt CC only
moderately and especially in our case only when DoS attack happens. For normal
state, we just keep the transmission as raw as possible.

---

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

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.

Yours,
Joel M. Halpern

---

From: Alistair Munro <[email-masked]>
Date: Sun, 30 Oct 2005 18:17:44 +0000

Hi All,

> 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: Sun, 30 Oct 2005 16:37:13 -0500

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