inline: Michael Thomas wrote: > Jonathan Rosenberg wrote: >> Harald Tveit Alvestrand wrote: >> >>> While I disagree with Jonathan's assertion that we should insert an >>> entirely useless (for all but NAT) UDP header in front of all new >>> protocols we design, >>> >> >> Well, I'd hardly characterize, "allowing it to work across the public >> Internet" as a property that is useless. Statements like, "useless for >> all but NAT" trivialize what the Internet has evolved into. There is >> NAT everywhere. Lets accept it and design for what the Internet is, >> and not for the Internet as we wish it would be. >> >> You may not like it, but its reality. >> > > Well, if we're talking about reality, why don't we talk about UDP? > UDP is an imperfect fit for NAT's and firewalls because it's stateless > and the stateful ALG needs to educe state from those packets. If > it's an protocol riding on top of UDP, the ALG is bound to get it wrong > at times. Which as far as I've heard happens all the time. As in, UDP > is no panacea. True. Though if you do keepalives with some regularity (typically, 20 seconds), it works in a lot of cases. Unfortunately, until recently there were no standards that defined what these timers should be. Now we have RFC 4787 which does define rules, but of course you cannot depend on the larger timers it recommends yet, since it has seen limited deployments. > > If you really want to put a stake in the ground here, it seems to me that > TCP is on a lot firmer ground. Why else would a lot of these IM protocols > and things like Skype use TCP fallback? It's because it's the only thing > that reliably works and they're not in the business of navel gazing about > whether they shouldn't do that because of its architectural ugliness. Absolutely. TCP is much more reliable. This is why ICE will probe for UDP and TCP and allow VoIP to fallback to TCP if there is no other choice. However, this is usually an artifact of firewall and not NAT; that part of it is an arms race. > > More heresy: maybe we should work on hacks to TCP to allow it to > have non-reliable e2e delivery so that it was more friendly to real time > protocols built on top of it. As you probably know folks absolutely have done this for exactly the reason you cite. -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