Re: [ledbat] list of reasons for needing multiple TCP connections

Au contraire, Robb, in the course of a 24 hour period you will typically 
see a total of well over 4000 NAT table entries for BitTorrent when it's 
in use. The fact that BitTorrent doesn't use all the thousands at the 
same time isn't the issue, it's the fact that a mapping entry has to be 
made in the table each time a packet is sent from an end system behind 
the NAT to one in front of the NAT. TCP is actually more friendly to 
this problem than UDP, because it give the NAT a clue about when it's 
safe to free an entry. Stateless  UDP is much more of a problem.

RB

Robb Topolski wrote:
>
>
>     Most home "routers" have all been modified by now not to crash
>     when BitTorrent has opened thousands of TCP connections. These
>     connections consume mapping table resources and were a problem
>     until it they were garbage-collected.
>
>
> I claim to have no handle on what "most" home routers do, but I doubt 
> this assertion.
>
> NAT table size continues to be a problem with NAT limit, and not 
> because BitTorrent typically opens thousands of TCP connections (it 
> doesn't, nor do trackers generally provide the thousands of peer 
> addresses necessary to go with those connections), but because the 
> combination of the UDP-based DHT in addition to 100 TCP connections 
> and a decent amount of WAN-LAN traffic is enough to overcome NAT 
> tables in popular routers being sold today. 
>
> http://www.smallnetbuilder.com/component/option,com_chart/Itemid,189/chart,124/
> (note 200 is the upper limit of their test method, but of use to this 
> message is the number and market position of routers that support less 
> than 200)
>
> Belkin's F5D8232-4 is 41st in Amazon's sales rank for "routers" and 
> maxed out at 180 connections.
> Netgear FVS124G is 14th in "gigabit routers" and maxes out at 196.
> Apple's BL053LL/A is 1st in "gigabit routers" and maxes out at 128.
>
> Do they crash?  Beats me.  But NAT table size limit is definitely a 
> consideration.  The behaviors when those limits are reached are varied 
> and, even on some recently sold equipment, sometimes less than 
> graceful. One of the most common failure modes I've run across is that 
> DNS Relay stops working or the configuration pages stop responding 
> while pre-existing connections continue uninterrupted!  (I'm guessing 
> that the daemons supporting these functions either get killed or lack 
> enough memory to do anything, they themselves are shut out of the NAT 
> table, or maybe they won't launch when CPU load is greater than some 
> amount.) 
>
> I think it continues to deserve inclusion.  If someone has data to the 
> contrary, please bring it.
>
>
> -- 
> Robb Topolski (robb@funchords.com <mailto:robb@funchords.com>)
> Hillsboro, Oregon USA
> http://www.funchords.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>   

-- 
Richard Bennett