Subject: Re: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 )

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 03 Apr 2006 11:41:26 -0400

Tim Shepard wrote:

> Is there a document anywhere describing how the TCP to SCTP transition
> is supposed to be accomplished?  Are we going to be running dual-stack
> for a number of years or decades while the transition is underway?

I am not aware of any document describing how the transition is
*supposed* to be accomplish. However, Ryan Bickhart wrote a document
describing a TCP-to-SCTP translation shim that he developed for
assisting the transition. The idea is...

1. run dual-stack
2. specify which TCP apps make sense to use SCTP
3. then shim translates TCP calls to SCTP transparently
	a. attempts to talk SCTP to peer
	b. if peer doesn't support SCTP, falls back to TCP

This shim makes it possible to run TCP apps over SCTP without any
changes whatsoever to the application.

http://www.cis.udel.edu/~amer/PEL/poc/pdf/BickhartMSthesis.pdf

-- 
Armando

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Wed, 05 Apr 2006 16:09:31 -0400

Tim-

> for a number of years or decades while the transition is underway?

I guess I don't quite follow this.  You make it sound as if there is
some grand plan or some great need to move all apps from TCP to SCTP.
Mutliple transport protocols are just fine.  (Note: I am *not* saying
that particular apps should not switch.  Clearly, there are apps that
may be better matched to SCTP.  I am just noting that we're above the
waist of the hourglass here.)

> Should tcpm's charter be expanded to include similar tweaking of SCTP?

I hope not. :-)

> Or should we have an sctpm WG?

Certainly that is a possibility (and, I believe has been discussed).

When TCPM was setup we noted that we needed at least some coordination
with SCTP and DCCP when things were changed in the TCP algorithms, as
these other protocols could need changed, as well.  Further, if there
was a draft that considered both protocols (e.g., RFC3708) then where it
would be discussed (TCPM vs. TSVWG) would be figured out when the time
came --- with both groups being kept in th loop.  (TSVWG being the place
where SCTP work has been done these days.)

allman

---

From: Tim Shepard <[email-masked]>
Date: Wed, 05 Apr 2006 17:03:53 -0400

> some grand plan or some great need to move all apps from TCP to SCTP.

I don't mean to say that there is.   I'm asking if there is.  (AFAIK,
there is not.)

It's just that in a few times in the past year (including on the
thread I branched off of with this thread) when some improvement has
been proposed for the networking stack that today usually contains
TCP, often someone will dismiss the proposal with some statement
about how if such improved functionality is needed, then SCTP should
be used instead of TCP.

I am curious to know how we should best direct our efforts.   Should
it be to transition applications to use SCTP?  

If so, let's get going and declare TCP a legacy protocol.

If not, then I guess we will continue to work on improving TCP to do
things that SCTP might already be capable of, bringing the benefits
to applications that run over TCP (today, and in the future).

I guess this is an architectural question.

Perhaps I should restart this thread on arch-d.

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Apr 2006 14:12:56 -0700

> If so, let's get going and declare TCP a legacy protocol.

Or, more specifically, not change TCP for niche uses that are already
supported by other protocols. Just because we're recommending that these
uses apply SCTP doesn't mean that a shift to SCTP is appropriate everywhere.

> to applications that run over TCP (today, and in the future).

That would be appropriate IF the extensions were of general utility AND
needed to be added at the transport layer. That isn't the case for a
number of SCTP extensions, IMO.

Joe

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Apr 2006 21:26:02 -0400

> I don't mean to say that there is.   I'm asking if there is.  (AFAIK,

IMO, there is no good reason to have such a transition. Let's be
honest here. SCTP has some interesting (and useful features), but they
are largely of interest only to specialized applications (that is,
they are irrelevant to 95% of the applications that run on top of TCP
today). Why on earth would they want to run on top of SCTP, much less
"migrate" to SCTP?

In the case of SCTP's "multihoming facilities", for example, they are
AFAIK, primitive, and we have little real experience with
them. Indeed, I viewed them (when I reviewed the original specs) as
largely hooks for potential future work, but that the details needed
to be sorted out.

I'll probably get flamed for saying that. So, let me ask those that
disagree to provide pointers to documents and research showing
experience with those multihoming capabilities and what we have
learned from them. 

Thomas

---

From: <[email-masked]>
Date: Thu, 6 Apr 2006 09:05:14 +0300

Thomas,

>I'll probably get flamed for saying that. So, let me ask those 
>that disagree to provide pointers to documents and research 
>showing experience with those multihoming capabilities and 
>what we have learned from them. 

I'm not sure if I can provide pointers, but 3G radio networks are
using SCTP for control plane signaling - this is not the traditional
SS7 over IP.  I can point to the specs if you are intersted.  There
is the SS7 over SCTP work, this is starting to resemble IP trunking
- except for the control plane; so not the traditional SS7 backhaul
over IP.  Also, as I understand it is being used heavily for SMS
transport 
because of scalability needs - in many regions, the amount of SMS's sent
is larger than emails.  Some AAA & billing systems are running over SCTP
and I have been seeing more RFPs for SIP over SCTP - proxy-to-proxy
usage.
However, these are a specific usage case of SCTP (but I'd like to
suggest
that many of the TCP enhancements also apply to usage of SCTP in these
environments - as Mark Allman pointed out).

We've been playing with SCTP on small, multi-interface devices and it
seems to actually work quite well for non-realtime application
scenarios,
with the benefit that it doesn't require infrastructure (but we've
had to make sure that firewalls let SCTP pass).  I think this would
be roughly the same usage as TCP-MH that some people are talking about.

In terms of research findings, there are some good articles here:
http://www.eecis.udel.edu/~amer/PEL/poc/index.html

For example:
http://www.cis.udel.edu/~amer/PEL/poc/pdf/MILCOM03-ladha.pdf

A good summary here:
http://www.cis.udel.edu/~amer/PEL/poc/pdf/IEEE.Computer.SCTP.pdf

And some downloads here:
http://www.eecis.udel.edu/~amer/PEL/

(I can send more ... but as Tim suggested, maybe this should be taken
to the ARCH-D list).

In following HIP, SCTP, SHIM6 and MIP as general solutions to
multihoming,
in my estimate, SCTP & MIP are probably the best understood solutions
at this point.  I don't want to say that either are more or less
complete,
nor put a priority on one or the other; but just that there is more 
deployment experience with MIP & SCTP.

John

---

From: <[email-masked]>
Date: Thu, 6 Apr 2006 09:16:16 +0300

Tim,

Re-ordering your mail slightly:
 
>What should I (or we) do?
>
>In the int-area meeting in Dallas, it was pointed out that some folks
>are designing protocols for IPv4 only, with no IPv6 story.   It was
>suggested that drafts should have an "IPv6 considerations" section.
>
>Should the various drafts in tcpm WG for tweaks to TCP's 
>behaviour have an "SCTP considerations" section?

I would support including support for SCTP in TCPM - in many cases
it requires little-to-no extra work.

>For the past year or two, I've heard "SCTP" proffered by many 
>people as the answer to a variety of questions.
>
>I've given the SCTP specification a very quick scan last week 
>while in Dallas, and I've learned bits and pieces about it 
>over the years.
>SCTP does indeed seem to be cool, and a better framework into 
>which to put all sorts of desired functionality.

For some light reading, you might want to look at:
http://www.ietf.org/rfc/rfc3257.txt	

>So if SCTP is the answer (to multihoming, multipath, general 
>locator agility, etc.), and the applications I want to use 
>between my multi-homed laptop and the various servers that I 
>use are things like ssh, imap, and xmpp, what steps do I need 
>to take to start experiencing all of the wonderfulness that is SCTP?

I think Ned Freed has talked about why IMAP over SCTP would be 
a good thing, we could probably get someone to get XMPP running
over SCTP with little to no major effor ... etc. My feeling is
that actually just getting things up and running over SCTP 
rather than making TCP-MH would be easier, however deployment
is always 'interesting' - my guess is that servers could
easily support TCP & SCTP, but getting SCTP on popular 
OS's can be more challenging.

John