Comments on: My rebuttal to “NAT not a problem” contingent http://mrblog.org/2006/09/27/my-rebuttal-to-nat-not-a-problem-contingent/ Mr Blog. Very technical, or silly, sometimes absurd. Sat, 21 Jan 2012 19:31:53 +0000 hourly 1 http://wordpress.org/?v= By: Alex http://mrblog.org/2006/09/27/my-rebuttal-to-nat-not-a-problem-contingent/comment-page-1/#comment-578 Alex Sat, 24 Mar 2007 23:33:07 +0000 http://mrblog.televolution.net/?p=238#comment-578 So what are some actual applications that you want to implement that require NAT traversal? If p2p is so wonderful, why are there so few good applications. What do you want to build? So what are some actual applications that you want to implement that require NAT traversal? If p2p is so wonderful, why are there so few good applications. What do you want to build?

]]> By: MrBlog http://mrblog.org/2006/09/27/my-rebuttal-to-nat-not-a-problem-contingent/comment-page-1/#comment-577 MrBlog Thu, 28 Sep 2006 02:11:42 +0000 http://mrblog.televolution.net/?p=238#comment-577 Hi Aswath. If we indeed have to live with NAT (and since nobody but me seems to care about it, we probably do), then we sure as heck could use with some better standardization and improved clarity and consistency for restoring end-to-end apps (without the overhead of Skype-like solutions).<br /> <br /> I personally don't like uPnP as a solution, but I don't care. If it worked and were standard, I could live with it. But that's the exact problem we have now. None of these NAT boxes work in consistent ways and it changes every week (with the next rev of ODM code from overseas) even on the same box with the exact same model number.<br /> <br /> UPnP, for example, essentially doesn't work in practice. There's no use building devices that rely on it, because (a) it's not ubiquitous, and (b) implementations are not consistent or reliable. These are the problems that need to get solved, and I don't care if the solution is UPnP or ICE or whatever, so long as there were pressure in the marketplace for companies to actually implement something that worked consistently and reliably.<br /> <br /> Right now, that's what missing. No one is telling these vendors that their stuff is broken and that they need to fix it. And that pressure has to be hard (as in economic value) since solving the problem requires competencies at the ODM levels that is not presently in place. So the market will have to demand that this problem be solved, and it's not on anyone's agenda today.<br /> <br /> And it doesn't help, when top experts say "NAT is not a problem." Hi Aswath. If we indeed have to live with NAT (and since nobody but me seems to care about it, we probably do), then we sure as heck could use with some better standardization and improved clarity and consistency for restoring end-to-end apps (without the overhead of Skype-like solutions).

I personally don’t like uPnP as a solution, but I don’t care. If it worked and were standard, I could live with it. But that’s the exact problem we have now. None of these NAT boxes work in consistent ways and it changes every week (with the next rev of ODM code from overseas) even on the same box with the exact same model number.

UPnP, for example, essentially doesn’t work in practice. There’s no use building devices that rely on it, because (a) it’s not ubiquitous, and (b) implementations are not consistent or reliable. These are the problems that need to get solved, and I don’t care if the solution is UPnP or ICE or whatever, so long as there were pressure in the marketplace for companies to actually implement something that worked consistently and reliably.

Right now, that’s what missing. No one is telling these vendors that their stuff is broken and that they need to fix it. And that pressure has to be hard (as in economic value) since solving the problem requires competencies at the ODM levels that is not presently in place. So the market will have to demand that this problem be solved, and it’s not on anyone’s agenda today.

And it doesn’t help, when top experts say "NAT is not a problem."

]]> By: Aswath http://mrblog.org/2006/09/27/my-rebuttal-to-nat-not-a-problem-contingent/comment-page-1/#comment-576 Aswath Thu, 28 Sep 2006 00:17:25 +0000 http://mrblog.televolution.net/?p=238#comment-576 I agree with your characterization of the problems created by NAT and also Skype's approach has its limits. I also feel that over a period of time, we have become addicted to NAT and are exploiting it beneficially. So we have to "live with NATs". I think, in many instances (like consumer deployments, which seems to be your focus here) one can achieve the benefits of end-to-end by using UPnP in both the NAT and the clients. It will be instructive to know of your thoughts on this matter.<br /> <br /> Thanks<br /> Aswath I agree with your characterization of the problems created by NAT and also Skype’s approach has its limits. I also feel that over a period of time, we have become addicted to NAT and are exploiting it beneficially. So we have to "live with NATs". I think, in many instances (like consumer deployments, which seems to be your focus here) one can achieve the benefits of end-to-end by using UPnP in both the NAT and the clients. It will be instructive to know of your thoughts on this matter.

Thanks
Aswath

]]>