Subject: Re: UDP encaps for SCTP and SCCP

From: Lars Eggert <[email-masked]>
Date: Tue, 18 May 2010 10:37:49 +0300

Hi,

the discussion has touched on lots of things related to UDP encaps, but I haven't seen anything I'd call consensus on the question below. I'd therefore like to ask folks to specifically state which option they support:

(1) do one SCTP-specific and one DCCP-specific UDP encaps
(2) do one generic UDP encaps that can be used with both
(3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)

Thanks,
Lars

On 2010-4-22, at 12:57, Eggert Lars (Nokia-NRC/Espoo) wrote:
> Hi,
> 
> as most of you probably know, there are two different proposals for how to encapsulate SCTP and DCCP inside UDP.
> 
> One approach proposes two protocol-specific encapsulation schemes (described in draft-tuexen-sctp-udp-encaps and draft-ietf-dccp-udpencap).
> 
> The second approach proposes a generic encapsulation scheme that can be applied to both SCTP and DCCP (draft-manner-tsvwg-gut).
> 
> As a community, we do need to come to consensus on which of these two approaches we want to follow when it comes to UDP encapsulation of SCTP and DCCP. I believe it would be very confusing if we were to standardize both approaches.
> 
> I'd hence like to ask folks to read the three documents and post their views to the [email-masked] list. I'm personally especially interested in hearing from folks who aren't on the author lists of the documents, but obviously, the authors expert opinions do matter.
> 
> Thanks,
> Lars
> 
> PS: I'm pushing on this topic, because UDP encapsulation is the last remaining work item in the DCCP working group before it can close...

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 May 2010 09:54:33 -0400

Hi Andrew,

> It would be even better if you could implement DCCP with UDP encap
with
> the baseline UDP networking facilities of Java.  A whole bunch of
> Android developers would grab that.

Oh, that's interesting.  Maybe if I can find some time I'll look at
porting dccp-tp to Android.

Tom P.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Andrew Lentvorski
> Sent: Tuesday, May 18, 2010 4:19 AM
> To: Lars Eggert
> Cc: DCCP working group; TSV Area; [email-masked]
> Subject: Re: [dccp] UDP encaps for SCTP and SCCP
> 
> On 5/18/10 12:37 AM, Lars Eggert wrote:
> > Hi,
> >
> > the discussion has touched on lots of things related to UDP encaps,
but
> I haven't seen anything I'd call consensus on the question below. I'd
> therefore like to ask folks to specifically state which option they
> support:
> >
> 1 or 2.  However, SCTP can go hang.  It's a protocol in search of a
> problem, IMO.
> 
> I have looked at using DCCP three different times, but I wind up
adding
> a few tweaks to my home-grown poor-man's DCCP-like system.  Every time
I
> implement yet another game with timely UDP hole-punched NAT packets, I
> cry that I can't use DCCP.
> 
> DCCP would probably displace every game library's custom-brewed NAT
> punching network code if you gave it a proper UDP encap.  If you want
> DCCP uptake, there's your target market.
> 
> It would be even better if you could implement DCCP with UDP encap
with
> the baseline UDP networking facilities of Java.  A whole bunch of
> Android developers would grab that.
> 
> While it would be nice for applications to talk DCCP directly to one
> another, the reality is that UDP encapsulation is the only way DCCP
will
> ever get any significant uptake.
> 
> -a
> 
> 
> 
> 
>

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 May 2010 10:08:05 -0400

Hi Lars,

Well, I like option 1.

I feel that option 2 is a chimera.  The 'G' in the GUT proposal stands
for "generic", but it is not entirely generic.  The decapsulation stage
is specific to the encapsulated protocol.  The GUT draft gives one decap
rule that is more-or-less suitable for TCP and DCCP.  It doesn't work
for SCTP.

You have to look in detail at the encapsulated protocols to see if a
proposed decap works.  With my non-detail understanding of TCP, it looks
like it works, but we'll need someone to look at that in detail.

For DCCP, the proposed decap makes partial checksums ineffective.  I
think it's OK to do that, but you need to state that explicitly in the
draft, and probably offer guidance on how to deal with partial checksum
feature negotiation.  You also need to deal with how to signal the use
of UDP encap, and the other things included in my draft.  Once you've
done that, you have my draft.

GUT has similar issues for SCTP.  SCTP uses a CRC checksum that doesn't
include the IP addresses, so the proposed GUT decap doesn't work for it.
What's needed is actually easier to do.  I don't know enough about SCTP
to know what else needs to be done.

As I've stated before, if you really think through a generic approach,
it becomes an overall scheme that can be used by all protocols, plus a
set of protocol-specific adaptations.  That's where we're at with the
DCCP- and SCTP-specific drafts.

Tom P.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lars Eggert
> Sent: Tuesday, May 18, 2010 3:38 AM
> To: [email-masked]
> Cc: DCCP working group; TSV Area
> Subject: Re: UDP encaps for SCTP and SCCP
> 
> Hi,
> 
but I
> haven't seen anything I'd call consensus on the question below. I'd
> > as most of you probably know, there are two different proposals for
how
> to encapsulate SCTP and DCCP inside UDP.
> >
> > One approach proposes two protocol-specific encapsulation schemes
> (described in draft-tuexen-sctp-udp-encaps and
draft-ietf-dccp-udpencap).
> >
> > The second approach proposes a generic encapsulation scheme that can
be
> applied to both SCTP and DCCP (draft-manner-tsvwg-gut).
> >
> > As a community, we do need to come to consensus on which of these
two
> approaches we want to follow when it comes to UDP encapsulation of
SCTP
> and DCCP. I believe it would be very confusing if we were to
standardize
> both approaches.
> >
> > I'd hence like to ask folks to read the three documents and post
their
> views to the [email-masked] list. I'm personally especially interested
in
> hearing from folks who aren't on the author lists of the documents,
but
> obviously, the authors expert opinions do matter.
> >
> > Thanks,
> > Lars
> >
> > PS: I'm pushing on this topic, because UDP encapsulation is the last
> remaining work item in the DCCP working group before it can close...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 May 2010 17:03:19 -0600

Lars,

I support 3. (Existing tunnelling should suffice.)

--brian

Lars Eggert wrote:                             (Tue, 18 May 2010 10:37:49)
> but I haven't seen anything I'd call consensus on the question below.
> I'd therefore like to ask folks to specifically state which option
> they support:
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 19 May 2010 08:04:36 +0200

> (3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)
I vote for (1) since I do not see that a (real) generic solution is
possible.

Best regards
Michael

---

From: <[email-masked]>
Date: Wed, 19 May 2010 07:36:36 +0100

3. neither

(a solution for 2. already exists. It's called UDP tunnelling.)

>> PS: I'm pushing on this topic, because UDP encapsulation is the last remaining work item in the DCCP working group before it can close...

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 May 2010 10:23:56 +0100

Tom,

>like it works, but we'll need someone to look at that in detail.

The G in GUT is certainly not true for host implementations, but 
importantly the wire protocol is generic for all e2e protocols it 
encapsulates, which is what is important for middleboxes.

>to know what else needs to be done.

Earlier on the tsvwg list I was proposing how to get GUT to do a 
partial checksum that only covers its own headers, stopping at the 
encapsulated headers.

> > remaining work item in the DCCP working group before it can close...

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 May 2010 10:28:55 +0100

Lars,

At 08:37 18/05/2010, Lars Eggert wrote:
>but I haven't seen anything I'd call consensus on the question 
>below. I'd therefore like to ask folks to specifically state which 
>option they support:
>

I vote for (2), which requires more work (and may turn out not to be 
possible), but GUT is a good start. It can also be used to encap new 
TCP options if/when they get dropped by middleboxes (e.g. MPTCP, 
window scaling, ECN).

Second pref is (3), given existing tunnelling can be used, but it's 
heavyweight for some apps.

Bob

> > as most of you probably know, there are two different proposals 
> for how to encapsulate SCTP and DCCP inside UDP.
> >
> (described in draft-tuexen-sctp-udp-encaps and draft-ietf-dccp-udpencap).
> >
> > The second approach proposes a generic encapsulation scheme that 
> can be applied to both SCTP and DCCP (draft-manner-tsvwg-gut).
> >
> two approaches we want to follow when it comes to UDP encapsulation 
> of SCTP and DCCP. I believe it would be very confusing if we were 
> to standardize both approaches.
> >
> their views to the [email-masked] list. I'm personally especially 
> interested in hearing from folks who aren't on the author lists of 
> the documents, but obviously, the authors expert opinions do matter.
> >
> > Thanks,
> > Lars
> >
> > PS: I'm pushing on this topic, because UDP encapsulation is the 
> last remaining work item in the DCCP working group before it can close...
>
>

---

From: Jukka Manner <[email-masked]>
Date: Wed, 19 May 2010 13:07:17 +0300

Hi,

Somewhat obviously, I support

2. a generic solution

since I believe it can be done. GUT is just one design which has a 
certain deployment scenario in mind and use cases. But I believe we can 
build on GUT and develop it further, or create an alternative general 
solution, why not.

At least we currently run ICMP, TCP with options, DCCP and SCTP through 
it (we haven't thought about multihoming, yet).

Jukka

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 May 2010 15:00:23 +0300

Hi,

> (3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)

my current count of folks who stated an opinion stands as follows. We're not voting - this is to help us determine where the consensus is.

(1) 3
(2) 3
(3) 2

This doesn't indicate consensus on which flavor if UDP encaps should be pursued, or if it should be pursued at all in the IETF. With the turnout this low, my current conclusion would be that we drop the topic and proposed work items.

Please state an opinion on 1, 2 or 3 if you care about this topic.

Lars

PS: The count comes from emails by Andrew, Tom, Brian, Michael, Lloyd, Bob, Jukka.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 May 2010 14:01:19 -0500

At 07:00 AM 5/21/2010, Lars Eggert wrote:
>my current count of folks who stated an opinion stands as follows. 
>We're not voting - this is to help us determine where the consensus is.
>
>(1) 3
>(2) 3
>(3) 2
>
>This doesn't indicate consensus on which flavor if UDP encaps should 
>be pursued, or if it should be pursued at all in the IETF. With the 
>turnout this low, my current conclusion would be that we drop the 
>topic and proposed work items.
>

I've waited a bit to see if we'd be closer to a consensus to go with, 
without my individual input.

with my (tsvwg) chair hat off - I'm not familiar with the specific 
need for DCCP encaps over UDP (I'm just being honest about my 
exposure with DCCP - nothing else), but I do want to see an SCTP 
encaps over UDP solution (alone or generic), therefore of the choices 
listed above, I'm not sure which to choose; and here's why:

if only one transport protocol needs to be encapsulated over UDP then 
that transport protocol ought to have a means that's not generic, but 
one more tuned to the specific transport protocol.

If we believe there needs to be more than one transport protocol 
encapsulated over UDP, that's the tipping point for me - and that 
would sway be towards #2.

So, #1 is no good for me, as I believe #2 ought to be the goal if we 
have more than one transport protocol being encapsulated over 
UDP.  #3 isn't an option either for me because (sorry Lloyd) I 
believe we have to address the need for SCTP encaps over UDP.

James
(with my chair hat off)

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 May 2010 21:35:43 +0100

Lars,

> Please state an opinion on 1, 2 or 3 if you care about this topic.

If DCCP is to be deployed, we need a standard UDP encapsulation  
scheme. Whether that's (1), (2), or some existing tunnelling scheme  
matters less than that we've documented "if you want to encapsulate  
DCCP in UDP, do it this way" for interoperability.

-- 
Colin Perkins
http://csperkins.org/

---

From: Randy Stewart <[email-masked]>
Date: Sat, 22 May 2010 05:33:26 -0700

Lars:

I vote for 1

R

> PS: The count comes from emails by Andrew, Tom, Brian, Michael,  

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Sat, 22 May 2010 05:35:12 -0700

One other side thing to remember is that the
draft as been implemented in FreeBSD/Mac (and its Windoz version).

I will ping Vlad and see if he has done it for linux.. I know
it was on his list...

R
On May 21, 2010, at 12:01 PM, James M. Polk wrote:

>> This doesn't indicate consensus on which flavor if UDP encaps  
>> should be pursued, or if it should be pursued at all in the IETF.  
>> With the turnout this low, my current conclusion would be that we  
>> drop the topic and proposed work items.
>>
> I've waited a bit to see if we'd be closer to a consensus to go  
> with, without my individual input.
>
> encaps over UDP solution (alone or generic), therefore of the  
> choices listed above, I'm not sure which to choose; and here's why:
>
> if only one transport protocol needs to be encapsulated over UDP  
> then that transport protocol ought to have a means that's not  
> generic, but one more tuned to the specific transport protocol.
>
> have more than one transport protocol being encapsulated over UDP.   
> #3 isn't an option either for me because (sorry Lloyd) I believe we  
> have to address the need for SCTP encaps over UDP.
>
> James
> (with my chair hat off)
>
>
>> Lars
>>

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Sat, 22 May 2010 05:43:26 -0700

There are several projects I have worked on that
DO use SCTP internally. Do they run on the big I.. in a way,
they are in routers.

Are they behind NAT's no.. since most NAT's with two exceptions do
not support SCTP.

There are other protocols that I am aware of in Datacenters as well that
have picked SCTP.

If you look at the IANA registry for Protocol ID's in SCTP I think there
are 28 PPID's assigned... now thats not a huge number but its also
not representative since many folks just pick their own PPID and use  
it.. not
paying attention to the registry.

R
On Apr 27, 2010, at 12:27 AM, <[email-masked]>  
<[email-masked]> wrote:

> I don't think that counts as a we-chose-to-use-SCTP end user...
>
> SIGTRAN infrastructure in the telephony providers doesn't go through  
> NAT. ergo, SCTP's most popular use doesn't need to go through NAT.  
> And DCCP doesn't need to go through NAT, because no-one uses DCCP...  
> so there's no need to tunnel these over UDP to get through NAT.
>
> actual applications running on an actual end-user computer with a  
> TCP/IP stack, please.
>
> On 26 Apr 2010, at 23:49, Brian F. G. Bidulock wrote:
>
>> L.Wood,
>>
>> Hmmm.  SIGTRAN requires SCTP.  SIGTRAN is widely
>> deployed and running your phone calls.
>>
>> --brian
>>
>> [email-masked] wrote:          (Mon, 26 Apr 2010 21:34:14)
>>
>> --x-- snip --x--
>>> On a related note, I spent years dealing with proponents of
>>> SCTP, and yet never encountered any actual
>>> we-chose-to-use-SCTP end users. So, are there any actual DCCP
>>> users out there?
>>
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>
> Lloyd Wood
> [email-masked]

-----
Randall Stewart
[email-masked]

---

From: <[email-masked]>
Date: Sat, 22 May 2010 21:18:25 +0100

Randall,

If you're referring to RBSCP, which is a weak TCP/SCTP PEP that
uses SCTP between tunnel endpoints, then yes, that is available
in SCTP-capable Cisco routers. But it's not in widespread use.

having a large number of IANA PPIDs for SCTP is simply
an indication that SCTP is overspecified. (Does anyone
even use partial reliability?)

Lloyd Wood
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Sun, 23 May 2010 12:03:24 +0200

> an indication that SCTP is overspecified. (Does anyone
I do not understand why having PPIDs means overspecified.
When writing a dissector for SCTP it is very handy to have an
indication which upper layer protocol is encapsulated in a
DATA chunk. If an upper layer doesn't want to do it, he can
always use 0.
> even use partial reliability?)
Yes. And it will hit the IETF eventually...

Best regards
Michael

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 May 2010 10:07:59 -0400

Hi,

I see some weak consensus emerging for option #1. Please continue to state your opinion; I'll close the call Friday.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 May 2010 12:02:37 +0300

Hi,

> I see some weak consensus emerging for option #1. Please continue to state your opinion; I'll close the call Friday.

I haven't seen any further follow-up, so we do seem to have weak consensus of going forward with option #1 (do one SCTP-specific and one DCCP-specific UDP encaps).

This means that TSCWG will progress draft-tuexen-sctp-udp-encaps and DCCP will progress draft-ietf-dccp-udpencap.

Thanks to all who stated an opinion.

Lars

---

From: Andrew Lentvorski <[email-masked]>
Date: Tue, 18 May 2010 01:18:49 -0700

I have looked at using DCCP three different times, but I wind up adding 
a few tweaks to my home-grown poor-man's DCCP-like system.  Every time I 
implement yet another game with timely UDP hole-punched NAT packets, I 
cry that I can't use DCCP.

It would be even better if you could implement DCCP with UDP encap with 
the baseline UDP networking facilities of Java.  A whole bunch of 
Android developers would grab that.

While it would be nice for applications to talk DCCP directly to one 
another, the reality is that UDP encapsulation is the only way DCCP will 
ever get any significant uptake.

-a

---

From: Andrew Lentvorski <[email-masked]>
Date: Wed, 19 May 2010 13:28:07 -0700

> I support 3. (Existing tunnelling should suffice.)

What is defined as "existing tunnelling"?

How do I get DCCP packets over UDP if I don't have root access to a machine?

I can create DCCP packets at a user level by linking in a user space 
DCCP library, but I have no way to put them on the wire without:

A) heavy root level access to bash the socket stack directly
B) heavy surgery to the DCCP library to add a UDP listening layer

Neither of those count in my book as "existing tunnelling" that any 
reasonable user could make use of.

If I'm missing something, I'm all ears.  I would *love* to be able to 
add DCCP to my programs on Windows, OS X and Linux.

-a

---

From: Eddie Kohler <[email-masked]>
Date: Mon, 24 May 2010 12:32:17 -0700

Hi Lars,

I vote for (1), SCTP-specific and DCCP-specific UDP encaps.

Although those specific encaps could be very similar, or in fact 
identical at first, there are enough protocol differences to recommend 
planning ahead for potential divergence.

At minimum there could be two documents that allocate different 
well-known UDP ports for SCTP-in-IP-in-UDP encapsulation and 
DCCP-in-IP-in-UDP encapsulation (which if I understand correctly is the 
"simple UDP tunnel" Lloyd prefers).  I would prefer this to GUT, which 
chooses to expend header space rather than port space.

FWIW, my preferred form of tunneling for DCCP would be DCCP-in-UDP 
encapsulation.  The DCCP header would be unchanged, except for the 
pseudoheader used for checksumming.  This pseudoheader would have source 
and destination addresses all zero; the padded IP protocol number for 
DCCP; and the padded DCCP length.  I believe this would suffice to pass 
current NAPTs, which won't modify the encapsulated DCCP ports.  The UDP 
header checksum could be 0 or not; if nonzero, the DCCP checksum could I 
suppose be ignored, but I don't feel strongly.  UDP-Lite could be used 
or not; I would hope the port number would be the same either way.

Eddie