Re: pppcn
Vernon Schryver <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
> From: "Kevin Purser (QA/EMC)" <[email protected]> > To: "'[email protected]'" <[email protected]>, > "'[email protected]'" <[email protected]>, > "'[email protected]'" <[email protected]> > I would like to submit the following I-D for consideration by > the PPPEXT WG. Please feel free to send comments/questions/flames > directly to me. If our public attention was justifiably requisitioned by the original message, then our responses should be public. What is about about Scandanavian telephone companies that makes this issue so compelling that the same non-problem and similar non-solutions are raised every few years? It makes no sense in most of the rest of the world. Hasn't it been Ericsson that has repeatedly proposed modifying PPP to dealy the supposed multi-second connection setup times of PPP? The problem makes no sense in most of the rest of the world because no PPP connection that is useful in this century has round trip times that are so long that 3 extra round trips can total "on the order of seconds." Any PPP connection where a few extra RTTs are objectionable is useless to any likely modern application, because modern applications are so profligate with both bandwidth and round trips. Exactly what modern application is usable on a link with effective RTTs of 0.75 seconds? Exactly what application can tolerate packet loss rates so hight that 3 RTTs turn into 7 on average? This solution is not quite as bad as previous Scandanavian telco efforts that proposed to give up entirely on authentication, However, this one still misses the obvious solution to the non-problem that has been published here and elsewhere (e.g. James Carlson's book) more than once. This proposal may be intended to be that obvious solution, but it fails by defining a new "masked packet" protocol. The obvious solution does not require any changes to the on-the-wire PPP protocol. It is for both peers to anticipate each others' sequence and magjic numbers and options, and to send a single burst of LCP, authentication, and IPCP packets. This solution requires no changes in PPP state machines except for what might be called "pre-loading. Vernon Schryver [email protected]