From: jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu (Noel Chiappa)
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.
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.
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).
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 vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf