Re: RE: AD request / L2 Triggers Chapter Statement

> From: Lloyd Wood <[email protected]>
> To: James Carlson <[email protected]>
> cc: Joe Touch <[email protected]>, Phil Neumiller <[email protected]>,
>    pilc <[email protected]>

> ...
> > 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    [email protected]

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/