ietf
[Top] [All Lists]

Re: [dkim unverified] Re: I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt]

2008-02-14 09:23:25
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(_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

<Prev in Thread] Current Thread [Next in Thread>