Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance

From: [email-masked] (Noel Chiappa)
Date: Sat, 25 Sep 2004 08:49:04 -0400 (EDT)

> From: Leif Johansson <[email-masked]>

    > I have one that shot down my ssh sessions after 5 minutes of aparent
    > inactivity .. This is a *major* supplier of soho equipment. Moreover it
    > was clear from the support-forum that this was a concious choice.

It's not at all clear to me that this was the wrong engineering choice on
their part. If they didn't GC dead connections after some sort of timeout (and
would it make any significant different whether it was 5 minutes, or 1 hour)
it would consume resources and perhaps lead to problems. 

Although I suppose they could impose an LRU algorithm on state blocks,
instead. I'd have to think about it for a while, to see if there were other
problems caused by not GC'ing inactive mappings.

Furthermore, it's relatively easy to avoid the SSH session problem - my
default login on Unix boxes has for many years now included starting this
shell script in the backgound:

    while 1
    echo " "
    sleep 600
    end

precisely to avoid having them shut down due to NAT timeouts (no matter how
long I go without typing on them).

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 25 Sep 2004 07:31:03 -0600 (MDT)

> From: [email-masked] (Noel Chiappa)

> problems caused by not GC'ing inactive mappings.

Problems in doing it right?  hmmmmph.  More recent boxes from some of
the same vendors that have killed my ssh sessions do not kill my ssh
sessions despite days of inactivity.

That's not to say the newer boxes don't still have problems that can
only be solved--er--attacked by power cycling when they stop responding
every week or so.  My current tactic involves solid state relays that
driven by taking less than 5 ma from an RS-232 pin 20 and simple code
that looks for signs of illness in the junk.  (Yes, I know of far better,
UL certified implementations.  They cost more than the NAT junk.)

Besides, if "GC" refers to "garbage collection," my prejudice is that
you don't garbage collect active data.  I've had the junk kill active
ssh sessions.  Whether they run a timer or just have bugs that appear
after an hour or two, only someone with access to source could say.

> long I go without typing on them).

I try to avoid building failures into anything, especially if the
failures are obscure and intermittent.  That might keep an ssh session
alive despite boorken NAT junk, but depending on imponderables including
tty "driver" output buffering vs. application context switching on the
ssh server side, it will also occassionally break curses programs
including `top`, `sysstat`, `vi`, and `emacs`.

Having a standards committee write more documents that say "DON'T BE
STUPID!" sounds unlikely to solve many problems in NAT boxes, even if
committee "solutions" weren't the hallmark of the design and implementation
of garbage, probably including the junk NAT boxes at issue.

Vernon Schryver    [email-masked]

---

From: [email-masked] (Kai Henningsen)
Date: 29 Sep 2004 22:52:00 +0200

[email-masked] (Noel Chiappa)  wrote on 25.09.04 in <[email-masked]>:

> their part. If they didn't GC dead connections after some sort of timeout
> (and would it make any significant different whether it was 5 minutes, or 1
> hour)

Oh yes, it would make a BIG difference. 5 minutes idle in a ssh session is  
probably more common by a factor of 100 or so than 1 hour idle. Not that  
killing 1 hour idle connections is all that excusable, but at least it's a  
*far* rarer problem.

MfG Kai