Re: RE: AD request / L2 Triggers Chapter Statement
Vernon Schryver <[email protected]> Wed, 10 Jul 2002 08:41:22 -0600 (MDT)
| Newsgroups | gmane.ietf.pilc |
|---|---|
| Message-ID | <[email protected]> |
> From: Lloyd Wood <[email protected]> > ... > > On the other hand even 90 seconds is faster you can reasonably hope > > to do anything with an existing TCP/IP connection no matter how many > > L2 triggers you have, because no L2 trigger on your laptop is going > > affect the far end of a TCP connection. > > It doesn't need to. It only needs to affect the near end, so that > it's known that sending out a packet and waiting for a response is a > waste of time and the application(s) can go do something else instead. > > An analogy: If you're gagged, don't waste your breath saying 'Mppph! > Mppph!' and waiting for people to do what you say. Suppress it until > the gag comes off and spend the time thinking about a compelling plea > for your life instead. That makes no sense to me in this context, because the gag of a tunnel or other radio problem afflicts both parties for at least some applications that have been mentioned (e.g. VoIP). Your "not wasting your breath" also can't be a matter of turning off the radio to save power or something similar, at least not in this context, because even if appropriate, that's nothing to do the application. Internet application hiccups of seconds to 10s of seconds are not exactly new. I'm at a loss to think of a real application that might want to do besides blink a red "trouble" light while patiently waiting for the timers in TCP or its own UDP using code to repeatedly say "Mppph Mppph" until giving up or the gag disappears. Maybe that lack of practical interest is why the various application-L2 interfaces have not shaken down to 1 standard plus the embrace-and-extend varient as has happened with the rest of the network API. (Does anyone still really support STREAMS, not to mention "QIOs" and other stuff?) 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/