Stewart Stremler wrote:
Only two downsides: (a) no ephermeral server ports on the 'Net, and
(b) user-selectable server ports. But I see those as an application
issue, and a _good_ thing.
And what happens when two users both specify port 4000? What happens
when you have 8 dedicated ports and now you have a 9th user.
Presumably you oppose DHCP as well. Why use ephemeral IP addresses when
we can just configure the hosts with fixed addresses? I'll pass.
The problem is that you are conflating NAT with firewall. I want an
application-level traversable NAT, period. I'm not asking you to open
ports on your firewall. I'm not asking you to allow traffic that you
don't want. If you want your firewall to block this, fine. I have no
problem with that.
However, you are arguing that NAT should never be traversable by
applications. Your same arguments of "should be user configurable"
argue against this.
I'm not asking to take any control away from you. But you are asking to
take control away from *me*.
You can rail against this all you want. However, history shows that if
you don't provide a good solution for what people demand *now*, a bad
solution will arise and then you will have to live with it.
See: cone translation and SO_REUSEPORT
Or worse, if people don't fix this NAT traversal problem soon, TCP
traffic will start to fall and be replaced with UDP. People will create
myriad different, incompatible, buggy replacements for TCP that run over
UDP. And UDP doesn't have to respect the TCP congestion algorithms. It
can be a bad citizen.
All that would have to happen is for *one* BitTorrent application to
switch to a pure UDP solution that requires no user configuration of
ports and 25-30% of all Internet traffic would from switch from TCP to
UDP in *days*. Look how fast traffic encryption got picked up by
BitTorrent.
After that, someone will get the bright idea to strap this into Apache
and Firefox because UDP traffic gets around traffic shaping by your ISP
because it looks like XBox Live, et al. Game over. TCP dies.
The only thing stopping this is that designing a TCP replacement has
quite a bit of complexity (just ask the Nintendo DS wireless networking
guys <heh>). However, it only takes *one* good hacker to solve the
problem. After that, it all falls like dominoes.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
