Stewart Stremler wrote:
I'm trying to say (and not well, it seems) that any pain suffered by
making NAT work with a reasonable protocol is _exactly_ _the_ _same_ _pain_
as making that protocol work with a default-deny protocol: you have to
go poke the device to say "let connections through to _this_ machine at
_this_ port". Consequently, NAT is just one extra step, or, if you
have your firewall assume the responsibility, it's not even that.
Not everyone wants "default deny all outbound" on their network.
That's a religious issue. We are going to have to agree to disagree.
And UDP packets are dropped before TCP packets anyway. (I suppose that
might result in lots more retries and resends, because acknowledgements
won't get through... but any router that has a congestion problem has
an easy solution: drop more UDP packets. No more congestion.)
Can I get a reference? I haven't heard of routers dropping UDP in
preference to TCP. That would require packet inspection. Now, UDP
won't retry, but that doesn't mean that the routers choose TCP over UDP.
I thought most of the Internet traffice was DNS, SMTP, and HTTP... when
did BitTorrent become a major player?
Quoting:
http://www.businessweek.com/technology/content/sep2005/tc20050927_3006_tc024.htm?campaign_id=rss_topStories
>BitTorrent works so well that it accounted for 30% of worldwide
>Internet traffic at the end of last year, according to traffic
>monitoring service CacheLogic.
Now, I can certainly question the validity of those numbers, but it
seems to be in the right ballpark. The issue is that torrents move a
*lot* of data. The fact that ISPs are buying expensive traffic shaping
boxes indicates that this is indeed large enough to notice.
TCP is hard to replace ... you end up implementing something that looks
an awful lot like TCP.
Absolutely. It looks like TCP but goes through NATs. Good enough.
And we all know what happens when something is "good enough".
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
