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@xxxxxxxxx http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf