Subject: Re: FE-CE data path

From: "Deleganes, Ellen M" <[email-masked]>
Date: Tue, 15 Mar 2005 17:08:21 -0800

Even if there are good and stable DCCP implementations soon, this
doesn't mean it will become production soon. Won't that be an issue?
Even SCTP isn't all that widely deployed and it still has some of the
technical problems people were raising regarding TCP.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Khosravi, Hormuzd M
Sent: Tuesday, March 15, 2005 4:53 PM
To: [email-masked]
Subject: Re: FE-CE data path

Yes, I am not holding my breath for this either. I tested a few DCCP
implementations before and none were stable. They caused a kernel panic
as soon as I ran a few tests. I do hope, just as you that we find some
good stable DCCP implementations soon.

Are there any timelines set by the Linux community to support DCCP in
the standard kernel release ? If not, would you have an idea of
approximately how far out this might be?

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, March 15, 2005 4:46 PM
To: [email-masked]
Subject: Re: [FORCES] FE-CE data path

I should know  a little more about the subject because I got Arnaldo
started on Linux DCCP. I havent looked at the code in sometime, but:
I doubt very much i would want to deploy that code with any product i am
responsible for. Mostly because it hasnt been really tested probably by
anyone other than Arnaldo - or deployed for that matter . I am pretty
sure full of spec misconduct as a result of the above. I think in due
time it will be ready - but i wouldnt use this as a reason to say DCCP
is ready. 

cheers,
jamal

On Tue, 2005-03-15 at 18:23, Khosravi, Hormuzd M wrote:
> Joel,
> 
> I agree in spirit with what your proposing regarding using DCCP for
the
> data channel and we have mentioned it in the draft as well.
> 
> Regarding implementation, here is the latest info that I got from the
> DCCP WG couple of days back...
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Naadir Jeewa
> Sent: Monday, March 14, 2005 12:09 PM
> To: [email-masked]
> Subject: Re: [dccp] Any dccp implementations compliant with the latest
> specs ?
> 
> Arnaldo Mela @ Conectiva, and I have been working independently on
such
> an implementation. Mines not very good, so I'll probably on Arnaldo's
> code base from now on.
> I need to extract it out of the main BitKeeper tree into a separable
> module. I'll do that by the end of the week and stick it on CVS at
> www.sf.net/projects/linux-dccp once I've done some exams on Wednesday.
> CCID and feature handling need to be added, and a good way of
> implementing those CCIDs needs to be decided upon - perhaps something
> similar to Stephen Hemminger's forthcoming patch to the TCP congestion
> control mechanisms
> ( http://marc.theaimsgroup.com/?l=linux-net&m=110920482303293&w=2 ).
> 
> Yours,
> Naadir
> 
> On Mon, 2005-03-14 at 11:51 -0800, Khosravi, Hormuzd M wrote:
> > I was wondering if there are any DCCP implementations for Linux
Kernel
> > compliant with the latest DCCP specs going for RFC ? If no, are
there
> > any such efforts in play ?
> > 
> > 
> > Thanks
> > Hormuzd
> > P.s. I had checked on this sometime last year, hopefully things have
> > progressed on this now.
> 
> --------------------
> 
> I haven't looked at this in more detail. But the previous
> implementations that I looked at were not promising at all. If you
have
> any thoughts on this "no running code" issue, let me know?
> 
> Thanks
> Hormuzd 
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, March 15, 2005 2:03 PM
> To: [email-masked]
> Subject: Re: [FORCES] FE-CE data path
> 
> I have a basic problem with this.  We are trying to design a
congestion 
> controlling datagram transfer protocol.  We are not the right place to
> do 
> that.  Congestion control is known to be very tricky, and obvious
> answers 
> often have very non-obvious implications.  (Just getting the delay
> bounded 
> DiffServ stuff to work right took some interesting effort, and I had
> some 
> very good folks to work with.)
> 
> it is possible that DCCP is too complex, but there is really no
> difference 
> between an encapsulation driver (GRE) and a small protocol stack (DCCP
I
> hope.)
> 
> I will endeavor in the near future to take a good look at the DCCP 
> documents to see what they really give us and what it will take to use

> it.  (The last protocol I wanted to use did not have the capabilities
I
> was 
> looking for.)
> 
> If DCCP is not usable, we are in for a lot of very tricky work to get 
> congestion control right, particularly since we need it to interact 
> properly with TCP on the same link.
> 
> Yours,
> Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 15 Mar 2005 20:22:47 -0500

True SCTP isnt as widely deployed as say TCP or UDP; 
I dont think SCTP has the same technical problems as TCP as i was
pointing out earlier if you use SCTP-PR.

cheers,
jamal

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 16 Mar 2005 10:37:27 -0500

Just 2 cents from an outsider:

-Considering Fast Retransmit mechanism, will HOL a real issue even for TCP,
for FE-CE communication -hopefully they don't communicate over big-I
Internet :-)-?

-Related with a former comment questioning the importance of computation
associated with connection oriented protocols with redundancy, e.g. TCP,
SCTP: People might want to use FORCES to build things except routers, and
for certain cases the computation associated with redundancy might matter.

   Tolga

> [mailto:[email-masked]]On Behalf Of Jamal Hadi Salim
> Sent: Tuesday, March 15, 2005 8:23 PM

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 16 Mar 2005 10:49:31 -0500

a correction:

redundancy should read reliability below....

> [mailto:[email-masked]]On Behalf Of Tolga Asveren
> Sent: Wednesday, March 16, 2005 10:37 AM