On Mar 4, 2011, at 12:58 PM, Christian Huitema wrote: > There is actually much to be said for the idea of "let the applications > figure out what they're going to do as a result." Something like the > end-to-end argument. We don't want to force the network to do heroic feats if > the problem could be solved simply in an end-to-end manner. It seems that "PI > everywhere" belongs in the "heroic feats" category.
I'm sort of all right with that idea, provided (a) you give the applications enough information so that they can figure it out without having to have their own dedicated infrastructure, and (b) the solution for the application isn't overly complex, and doesn't significantly impair performance or reliability. nptv6 by itself, as currently defined, falls a bit short of that. At least one missing piece is the lack of a built-in mechanism to allow an application on the "inside" of the NPTv6 to discover its "outside" address. Though I agree with Fred about many of the cost-benefit tradeoffs (and will reply to his recent message in more detail when I have a bit of time). > There is indeed evidence that the problem can be solved end-to-end. This is > why we developed STUN, TURN, ICE. These solutions are not perfect, and they > don't cover TCP very well. (I know TURN does cover TCP, but at the cost of a > TCP relay, i.e., not very well.) If the end to end groups knew for sure that > "this is the deal," applications and transport protocols would surely evolve. STUN, TURN, ICE are not e2e solutions. They require support from the "middle". Any solution that requires a 3rd party server to sit in public address space and mediate between the endpoints (even if just to establish a connection) imposes a high barrier to deployment of new applications. > There are however two big limitations to solutions like STUN, TURN or ICE. > First, it is entirely possible to engineer a middle-box that breaks them, by > making the mappings hard to discover. >From my perspective, breaking things is exactly what the vast majority of >middle boxes do. Frankly, I don't know how to engineer any protocol that a >middle box can't break. The only question is how obvious they make the >breakage. Usually what middle boxes do is break things without being obvious >that they're at fault. That's why they're such a big problem. > Second, if the mappings are volatile and short lived, the end to end systems > are forced into a pattern of frequent polling which drains the batteries of > mobile devices. This is definitely a limitation. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
