Subject: Re: FE-CE data path

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 15 Mar 2005 12:09:53 -0800

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Tolga Asveren
>
> Ive mentioned SCTP a few times so far as an alternative.
[TOLGA]If reliability is provided externally -by running TCP/SCTP etc...
on
service endpoints, and I think this is assumed in the context of this
discussion-, wouldn't SCTP also an overkill, afterall it also would
provide
an additonal layer of reliability, which would consume computing
resources?
For such a setup, the only problem I see with UDP is lack of congestion
control, which is the reason for DCCP.

[HK] I agree, there is no difference between using TCP or SCTP for the
data channel. They both have the same problems. What is fundamentally
needed is unreliable transport with congestion control. DCCP fits this
perfectly. The only problem I have with DCCP is that there are no
running stacks right now which are compliant with the latest specs. I
have tested some of the older stacks which are available but they are
not stable either. So yes, it is getting close to RFC status but without
any running code...which surprises me!

The other option which comes to mind is what Joel proposed, using UDP or
some kind of tunneling with some rate control mechanisms. I have my
doubts whether this will work, similar to what Joel expressed.

regards
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Mar 2005 04:26:54 -0500

The real problem is not _reliability_ as provided by TCP - rather the
Head of Line Blocking presented by TCP (which is clearly visible when
you run a reliable protocol on top of it such as mentioned OSPF).

PR-SCTP resolves this. Look at RFC 3758.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Mar 2005 16:04:52 -0500

I think that there is a different issue.
TCP and SCTOP will both choose to provide retransmission.
For the data channel, we want adaptive congestion control (rate limiting) 
with dropping of old packets.  We do not want ever want data channel 
packets retransmited.

In contrast, the control channel actually requires retransmission for 
reliability.

Are you suggesting a non-retransmitting mode of SCTP as an alternative to 
DCCP for the data channel?
If so, I would be interested in the details of what that mode does.  (Also, 
since most of us associated SCTP with the reliable mode, I at least jumped 
to the conclusion you meant reliable SCTP when you initially suggested SCTP 
without a qualifier.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Mar 2005 05:32:28 -0500

Joel,

I missed one subtle thing from your earlier email which became obvious
reading Furquans last email - in that we are only talking about data
"channel".

Yes i was suggesting SCTP-PR instead of DCCP. I wouldnt call it
non-retransmiting; however it is tunable to remove HOL.

However, upon further reflection, even i would not advocate the
mandatory use of SCTP-PR in this case. 

My reasons are slightly different than what Furquan and Shuchi: I do
think issues they faced of "reliability tunings" such as timers mismatch
etc that result in HOL, can be overcome with SCTP-PR/UDP/DCCP (but not
TCP).  
However, I dont think that we can force an implementation scheme.
A lot of commodity hardware exists that can encapsulate the data
channel packets in some header such as GRE, VLAN etc. Enforcing that
such packets MUST be encapsulated in SCTP is going to be a perfomance
problem and not very practical. 

cheers,
jamal