Subject: [tsvwg] Seeking SCTP Deployment Data

From: Samuel DeLaughter <[email-masked]>
Date: Thu, 1 Mar 2018 16:09:15 +0000

Hi All,

I am doing some research on SCTP and am trying to find data on the current scope of its deployment.  Does anyone here have information that they may be able to share?  Perhaps you run a network that has seen some SCTP traffic, or you work on an application that uses SCTP.  To my knowledge the only major application that currently utilizes it is WebRTC, does anyone know of others?  Any help would be greatly appreciated.

Thank You,
Sam

--
--
Samuel DeLaughter
Doctoral Student & Research Assistant
Advanced Network Architecture Group
MIT Computer Science and Artificial Intelligence Laboratory

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 1 Mar 2018 18:20:56 +0100

> On Mar 1, 2018, at 5:09 PM, Samuel DeLaughter <[email-masked]> wrote:
> 
> Hi All,
> 
It is used in telephony signaling networks, where it is originally designed for.
This includes mobile networks, but it is not limited to them.

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 1 Mar 2018 19:34:35 +0100

I can’t resist using this opportunity for a commercial break:

Negative views around SCTP that I heard (“can’t be deployed” … “not used by anyone” …) motivated me to start rolling the ball that became the TAPS WG, several years ago. The logic was:

- If you just replace TCP with SCTP, you don’t normally get much benefit (more resilience from multihoming, and not much else).

- So, app programmers would have to explicitly write programs against it, to make use of its features to benefit from it.

- They won’t, because it’s not used much, and rumors say that it doesn’t work (of course it traverses the Internet just fine above UDP, and while NATs naturally create problems, it seems to often work fine natively in non-NATed networks) - so this is an effort that is often in vain, and then you’d have to add all this machinery to try if it works, fall back in case it doesn’t work, map the requested services onto other protocols, etc.

As a result, you get a self-fulfilling prophecy of non-deployment, just because of a design flaw of the Internet’s transport layer that binds applications to protocols instead of services.

=> this machinery should not be the app programmer’s job. It should be what the transport layer does for apps.

Hence, go TAPS !  :)
The open source TAPS implementation NEAT provides easy access to SCTP to people, including all the machinery mentioned above:
https://www.neat-project.org <https://www.neat-project.org/>
https://github.com/NEAT-project/neat <https://github.com/NEAT-project/neat>

The point of TAPS is of course to not be tied to SCTP - it’s about replaceable protocols in general. But, our code gives you SCTP if you want to play with it (please do !).

Cheers,
Michael

> On Mar 1, 2018, at 6:20 PM, Michael Tuexen <[email-masked]> wrote:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Mar 2018 14:42:06 -0600

With my apologies to the US political/election system ...

On Thu, Mar 1, 2018 at 12:34 PM, Michael Welzl <[email-masked]> wrote:

> Negative views around SCTP that I heard (“can’t be deployed” … “not used
> by anyone” …) motivated me to start rolling the ball that became the TAPS
> WG, several years ago. The logic was:
>
> - If you just replace TCP with SCTP, you don’t normally get much benefit
> (more resilience from multihoming, and not much else).
>
> - So, app programmers would have to explicitly write programs against it,
> to make use of its features to benefit from it.
>
> - They won’t, because it’s not used much, and rumors say that it doesn’t
> work (of course it traverses the Internet just fine above UDP, and while
> NATs naturally create problems, it seems to often work fine natively in
> non-NATed networks) - so this is an effort that is often in vain, and then
> you’d have to add all this machinery to try if it works, fall back in case
> it doesn’t work, map the requested services onto other protocols, etc.
>
> As a result, you get a self-fulfilling prophecy of non-deployment, just
> because of a design flaw of the Internet’s transport layer that binds
> applications to protocols instead of services.
>
> The open source TAPS implementation NEAT provides easy access to SCTP to
> people, including all the machinery mentioned above:
> https://www.neat-project.org
> https://github.com/NEAT-project/neat
>
> The point of TAPS is of course to not be tied to SCTP - it’s about
> replaceable protocols in general. But, our code gives you SCTP if you want
> to play with it (please do !).
>

"I'm Spencer Dawkins, one of the Transport Area Directors, and I approve of
this message" :-)

Spencer

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 1 Mar 2018 23:44:08 +0000 (UTC)

Cisco used SCTP as the transport mechanism between its NCE accelerators.
SCTP was also used in its RBSCP software accelerator, which is less widely used.

(Many other accelerators use SCPS variants or custom protocols; I'm not aware of 
other use of SCTP.) 
Lloyd Wood [email-masked] http://about.me/lloydwood 

________________________________
From: Samuel DeLaughter <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Friday, 2 March 2018, 3:09
Subject: [tsvwg] Seeking SCTP Deployment Data

Hi All,

Thank You,
Sam

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 2 Mar 2018 10:25:20 +0000

> SCTP was also used in its RBSCP software accelerator, which is less widely used.

Wasn't it also an option on the cisco boxes for exporting NetFlow records?

It is also available as a match criteria in some routers ACLs / Firewalls,
but for some vendors only as a 3 tuple match.  I've used it when configuring
filter rules.

DF

---

From: Astrid Smith <[email-masked]>
Date: Sat, 3 Mar 2018 06:55:11 -0800

Hello Sam,

I'm not sure how much I can say publicly, but SCTP is an actively
supported protocol at F5 and we have a number of customers using it in
production.

From what I can tell these deployments don't generally face the public
internet.  Rather, they tend to be internal to the customer's network,
or used to interface with another organization's network.  One example
I see a lot of is Diameter communication links within and between
telecoms, using SCTP as a transport protocol for LTE signalling
(roaming, billing, access, that sort of thing).  I'd guess that nearly
all Diameter messages travel over an SCTP link at some point in their
lifetime.

These deployments are in a controlled network environment, so the SCTP
doesn't need to be sat on top of UDP in order to transit the commodity
internet intact (particularly, the home "plastic routers" which cause
so much heartache).  Also, being invisible to people who aren't inside
a telco, it can be easy to overlook :)

I've seen other protocols run over SCTP, but rarely.  Most application
protocols aren't designed to use the services that SCTP has on offer,
and so they expend effort to create the functions they need in a TCP
or UDP environment, often partially duplicating what SCTP can already
do.  Taking one of these and putting SCTP under it doesn't make a lot
of business sense, even as much as I personally like SCTP and would
like to see more of it in the wild.

-- 
astrid smith     -------------------
--<[ c y b e r  |  s o f t w a r e  |  e n g i n e e r ]>--
    ------------                     ------------------

On Thu, Mar 01, 2018 at 04:09:15PM +0000, Samuel DeLaughter wrote:
> Hi All,
> 
> I am doing some research on SCTP and am trying to find data on the
> current scope of its deployment.  Does anyone here have information
> that they may be able to share?  Perhaps you run a network that has
> seen some SCTP traffic, or you work on an application that uses
> SCTP.  To my knowledge the only major application that currently
> utilizes it is WebRTC, does anyone know of others?  Any help would
> be greatly appreciated.
> 
> Thank You,
> Sam
> 
> --
> --
> Samuel DeLaughter