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