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

[Reinaldo Penno <[e-mail]>]

Hello,

Any NAT developer has a bag of tricks to deal with state shortage. He/she
can:

1 Drop any new sessions/conn
2 Nuke the oldest one
3 Nuke the mostly idle one
4 Combination of 2 & 3
5 Use tickle
6 Set up timers depending on application ports
7 Use ALGs to track end of dialog
8 Smart nuke of a per application basis (e.g. Safe to nuke IM, but only nuke
business VoIP control as last measure)

I could go on.

The strategy chosen depends on availability of ALGs, configurable timers,
home routers vs. access vs. something else, etc.

As far as TCP (not application) keep alive goes, it is 2 hours. A lot of
stuff can happen in two hours.

Thanks,

Reinaldo

On 12/1/08 3:35 PM, "Richard Bennett" <[e-mail]> wrote:

> 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]> 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.
>>>>  
>>>>  

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