Verizon EVDO Issues

Joe Provo nanog-post at rsuc.gweep.net
Thu Apr 9 19:33:47 UTC 2009


On Thu, Apr 09, 2009 at 11:45:08AM -0400, Robert E. Seastrom wrote:
> Daniel Senie <dts at 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 at clack [17] # sysctl -a | grep keepidle
> net.inet.tcp.keepidle: 7200000
> root at 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




More information about the NANOG mailing list