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

["Robb Topolski" <[e-mail]>]

On Mon, Dec 1, 2008 at 5:29 PM, Reinaldo Penno <[e-mail]> wrote:

> 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)
>
>
Hey Reinaldo!

Yeah, I know (except for #5, I don't know what that is).  Still seems like a
lot of them seem to choose #19 - Slowly Grind to a mystifying Halt or #14 -
Reboot without explanation.  (Although the reboot is probably a watchdog
function reacting to the grinding halt!)

  :-)

PS:  Is it possible that some devs just don't know what to do when the table
is full or nearly full?  I know that these guys are working on SDKs from a
small handful of vendors, but I've never actually seen one or the
documentation that comes with it.

-- 
Robb Topolski ([e-mail])
Hillsboro, Oregon USA
http://www.funchords.com/



-- 
Robb Topolski ([e-mail])
Hillsboro, Oregon USA
http://www.funchords.com/

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