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

[Richard Bennett <[e-mail]>]

Setting an expiration period of 5 minutes for UDP entries in a NAT table 
will certainly kill UTP. Is that what you really want, Robb? The mapping 
entries have to be kept around as long as there's any likelihood of 
traffic coming in for them, which can be a very long time for P2P.

A little more tech and a little less snark would actually be beneficial.

RB

Robb Topolski wrote:
>
>     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.
>
>
> Good grief. 
>
> "In the course of a 24-hour period" is a huge qualifier, not to 
> mention irrelevant.  How big is the NAT table over the course of a 
> year?   You can really demonize P2P with a stat like that!! 
>
> The only relevant NAT table is the one you have, now. 
>
>     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.
>
>
> I don't know that TCP is any more or less friendly.  Sure, it gives 
> state, but you have to track that state and do an orphan timer.  
> Meanwhile, a lot of TCP apps send keepalives anyway, rendering all 
> that pretty much meaningless. 
>
>     Stateless  UDP is much more of a problem.
>
>
> With UDP, it's much less of a problem.  Devices can just expire the 
> entry after sufficient time has passed since the last traversal -- 
> which is what they already do.
>
> With TCP entries, owing to the chance that keepalives aren't used, my 
> favorite router sets a 2.5 hour timer.  With UDP entries, it's 5 
> minutes. 
>
>
>
>  
>
> On Mon, Dec 1, 2008 at 3:00 PM, Richard Bennett <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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 ([e-mail] <mailto:[e-mail]>)
>>     Hillsboro, Oregon USA
>>     http://www.funchords.com/
>>     ------------------------------------------------------------------------
>>     _______________________________________________ ledbat mailing
>>     list [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/ledbat
>
>     -- 
>     Richard Bennett
>         
>
>
>
>
> -- 
> Robb Topolski ([e-mail] <mailto:[e-mail]>)
> Hillsboro, Oregon USA
> http://www.funchords.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> ledbat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat
>   

-- 
Richard Bennett

_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat