inline:
Lars Eggert wrote:
On 2008-2-15, at 16:21, ext Bernard Aboba wrote:
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.
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.
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
jdrosen(_at_)cisco(_dot_)com
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf