Subject: Re: I-D Action: draft-rosenberg-internet-wait-hourglass-00.txt

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Feb 2008 06:21:04 -0800 (PST)

Lars Eggert said:

"A big driver for SCTP was for use a signaling protocol. Other SDOs are  
using SCTP for signaling in their network architectures, and are also  
now introducing NAT functionality at controlled places in these  
architectures. This is why I believe and have argued that an IETF BCP  
that documents how to correctly NAT SCTP is the right thing to  
produce. (And, FWIW, DCCP. There's some interest in that as well, but  
not such an immediate one as for SCTP.) As a SIP-area person, this  
mode of operation should be familiar to you.

Will this BCP make SCTP available behind a home NAT? Nope. But it  
provides a specification that people can refer to who design network  
architectures that are more tightly controlled than the end user  
Internet, i.e., where people can define and then require their NATs to  
have this functionality."

I agree with Lars here -- having a specification is the first step.
However, I would suspect that clearly specifying how SCTP and DCCP 
work with NAT would eventually make it possible to obtain a home NAT 
supporting those protocols, particularly if implementations were made 
available within the popular distributions (e.g. DD-WRT) on which those 
home NATs are frequently based. 

On another note, I think it makes a difference whether UDP/TCP is combined 
with IP at the waist, or whether UDP/TCP is considered a lower layer on 
which IP, etc. can run.  That is, whether we have general NAT traversal 
mechanisms which support a wide array of applications, or whether we end 
up having to modify each individual protocol.  The draft seems to suggest 
the latter approach.  I disagree. 
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Feb 2008 16:44:13 +0200

> home NATs are frequently based.

Completely agree. And as a coincidence, earlier today a Linux  
developer posted this on the DCCP mailing list:

On 2008-2-14, at 21:18, ext Ian McDonald wrote:
> As regards to work underway there is an implementation in the Linux
> kernel to provide NAT/connection tracking for DCCP and it is believed
> to work well - basically does the same as UDP/TCP. This has been in
> the Linux kernel for sometime now, so may be of some use for this
> work.

But note that this isn't - yet - based on any IETF spec. But the  
author of the likely BEHAVE work item on this and the implementors of  
the Linux code are chatting, I believe.

Lars

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 11:39:52 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernard Aboba
> Sent: Friday, February 15, 2008 6:21 AM
> To: [email-masked]
> Subject: Re: I-D Action: 
> draft-rosenberg-internet-wait-hourglass-00.txt
> 
> Lars Eggert said:
> 

There is a milestone in BEHAVE for a SCTP NAT, along the lines of
BEHAVE's milestones (some completed) for TCP, UDP, and ICMP.  We also
have a milestone for a DCCP NAT.

> available within the popular distributions (e.g. DD-WRT) on 
> which those home NATs are frequently based. 

I am not aware of the status of SCTP NAT code, but I did learn
this week that there is a Linux implementation of DCCP NAT.

> the latter approach.  I disagree. 

A simple UDP tunneling protocol sounds useful, too.

There are currently two drafts for running SCTP and DCCP over
UDP.  I look forward to discussing the benefits of a 
per-protocol UDP tunneling approach versus a generic, simple 
UDP tunnel approach.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2008 17:58:28 -0500

inline:

> the Linux code are chatting, I believe.

You are missing the main point here, though.

So lets say I am building an application and I want to extend that 
application to users that may be NATted. Now, I have a choice. I can 
build that application to run on SCTP, which may be advtantageous. In 
that case, I'll be able to reach a user based equal to those whose NAT 
have been upgraded to support this SCTP ALG feature. Or, I can tunnel it 
over UDP or TCP, and reach 100% of my customers.

Now, I'm not a marketing guy, but I'm pretty sure if I have to pick 
between reaching 100% of my customers or 1%, I'd pick the 100%.

And so, that application gets written ontop of TCP or UDP and not SCTP. 
And so, SCTP doesn't get used here, and the demand for SCTP in NAT 
remains low because, well, there are no apps for it. So you'll have some 
projects and people will play around with it, but the impetus for mass 
market deployment is just not there.

This vicious cycle can be broken, but usually its because the new 
feature is sufficiently innovative and valuable that it can help drive 
the cycle much faster than normal. Much as I love transport protocols, I 
don't think they fit into that category in terms of end user functionality.

So why bother? WHy not just define it up front, to just ride ontop of 
UDP? You can add congestion control or whatever else you want - all you 
need to do is 'pay' for this extra 8 bytes in every packet for the UDP 
header. In an era where home bandwidth is now measured in TENS of 
megabits, are you seriously worried about that overhead?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Feb 2008 23:21:41 -0800 (PST)

> This vicious cycle can be broken, but usually its because the new feature is
> sufficiently innovative and valuable that it can help drive the cycle much
> faster than normal. Much as I love transport protocols, I don't think they fit
> into that category in terms of end user functionality.

Right.  In general, application developers have been slow to rewrite their 
applications to support new networking capabilities, including IPv6, QoS, 
SCTP/DCCP, etc.  Given this, I doubt that redefining SCTP/DCCP to run over 
UDP would make much difference to developers who first need to be 
convinced of the value of alternative transports.  

Similar arguments can be made against rapid takeup of application-specific 
tunneling protocols.  Now if you make available a generic tunneling mechanism 
that "just works" and requires no application changes, then the 
answer might be different.

---

From: Lars Eggert <[email-masked]>
Date: Sat, 16 Feb 2008 10:16:19 +0200

Hi,

On 2008-2-16, at 0:58, ext Jonathan Rosenberg wrote:
> build that application to run on SCTP, which may be advtantageous.  
> In that case, I'll be able to reach a user based equal to those  
> whose NAT have been upgraded to support this SCTP ALG feature. Or, I  
> can tunnel it over UDP or TCP, and reach 100% of my customers.
>

I wasn't disagreeing with your main point, which is about end user  
applications that need to work right now potentially for everybody on  
the network.

I was saying that there are large private and semi-private networks  
where the entity running them has control and new protocols can and  
are deployed over IP. The Gig effort, for example, or various operator  
networks. There is a benefit to not needing to tunnel.

Lars