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

>
> 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 <richard@bennett.com> 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 (robb@funchords.com)
> Hillsboro, Oregon USA
> http://www.funchords.com/
>
> ------------------------------
>
> _______________________________________________
> ledbat mailing listledbat@ietf.orghttps://www.ietf.org/mailman/listinfo/ledbat
>
>
> --
> Richard Bennett
>
>

-- 
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/