[113297] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Verizon EVDO Issues

daemon@ATHENA.MIT.EDU (Joe Provo)
Thu Apr 9 16:38:59 2009

Date: Thu, 9 Apr 2009 15:33:47 -0400
From: Joe Provo <nanog-post@rsuc.gweep.net>
To: nanog@nanog.org
In-Reply-To: <86ljq9x24b.fsf@seastrom.com>
Reply-To: nanog-post@rsuc.gweep.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Thu, Apr 09, 2009 at 11:45:08AM -0400, Robert E. Seastrom wrote:
> Daniel Senie <dts@senie.com> writes:
> > We observe this same kind of behavior with firewalls in the path
> > watching for dead sessions they can clean up. Appears they send RSTs
> > to both end points when they decide a session has gone away, as
> > that'll let end hosts figure it out sooner. Same workaround of turning
> > on keep=alives once a minute solves this too. The behavior in the case
> > of firewalls makes sense, as state tables have to be cleaned up
> > eventually.

Ish. 3360 argues against extraneous RSTs in general, in addition to some
specific cases (response to malformed or unknown TCP options, etc).
 
> While I agree with you that the behavior makes perfect sense, I submit
> that the controls are often set improperly (by default or due to
> configuration by underskilled technicians) - that is to say, without
> taking into account the likely behavior of TCP when the connection is
> in fact still open.  Consider the default keepalive interval on a
> selection of operating systems:
> 
> FreeBSD - 7200 seconds:
> root@clack [17] # sysctl -a | grep keepidle
> net.inet.tcp.keepidle: 7200000
> root@clack [18] # 
> 
> MacOSX - 7200 seconds:
> [Superfly:~] root# sysctl -a | grep keepidle
> net.inet.tcp.keepidle: 7200000
> [Superfly:~] root# 
> 
> Windows XP - 7200 seconds:
> http://support.microsoft.com/kb/314053
> 
> (notice a pattern here?)

You mean adherance to the minimum per Host Requirements (1122)?

> Seems to me that a well-engineered firewall will have enough memory in
> it that (in the application for which it is specified, with
> anticipated traffic levels) it doesn't have to be over-aggressive and
> try cleaning up flows that haven't seen any traffic in less than, say,
> two hours and ten minutes.

TCP vs application keepalives have been a religious topic for ages. 
It would seem that generous host idle windows in the modern Internet 
(increased speed, throughput, mobility, avilability and hostility
since 1122 was written) are a bit odd.  

Joe, who thinks purposefully long-lived TCP applications should 
     certainly have their own keep-alives
    
-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


home help back first fref pref prev next nref lref last post