> From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
> To: James Carlson <james.d.carlson@east.sun.com>
> cc: Joe Touch <touch@ISI.EDU>, Phil Neumiller <pneumiller@meshnetworks.com>,
> pilc <pilc@ietf.org>
> ...
> > I still don't see how link unavailablity is *reasonably* translated
> > into TCP connection sniping -- particularly as a default policy.
>
> What default policy? Provide the information to be used on a
> case-by-case basis, that's all.
It's been only close to 10 years that BSD flavored UNIX has offered
information about interfaces coming and going to any appliation that
cares to pay attention, and without timers or continual asking by the
application. Before routing sockets, the information was available
although only with the obnoxious getifaddrs() hacks. I don't recall
hearing of any old applications that care other datagram based code
such as routing deamons and conferencing systems.
I don't see how this stuff makes any sense for TCP. Even the systems
that tear down TCP connections quickest are far too slow for real time
voice. No one will tolerate minutes of silence when the remote system
has problems. L2 triggers might help at most 50% of such problems.
They can only cause some indication to the local user about local
problems. They don't do much for the other user(s).
I hope anyone who has been paying attention to the side effects of
the NAT boxes that forge RSTs would hesitate to suggest that idea.
Vernon Schryver vjs@rhyolite.com
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Tue Jul 09 2002 - 10:33:36 EDT