Re: pppcn

Karl Fox writes:
>  From "PPP Design and Debugging," by James Carlson, pages 68-69:
[...]
> P.S.  Thank you, James Carlson, for such a powerful tool.

*blush*  Thanks!

There may be an underlying issue here that's related to what Vern
Schryver said.  Is the link usable at all with such an atrocious RTT?
If it's for the usual sort of web-surfing activities, the answer seems
to be "no," in as much as the PPP RTTs are just the tip of an iceberg.
"Building the unusable" probably shouldn't be an explicit part of the
working group charter.

But what of transaction-oriented systems?  Suppose the end node
intends to do only one or two packet exchanges with some peer before
ditching the link?  In that case, the PPP RTTs could loom
comparatively large in the picture.  (This is sort of analogous to the
situation with modems: ordinarily, the training time is insignificant
in the overall usage, but for transaction-oriented systems where only
a few hundred bytes are sent, it's a killer, and there are thus
special 1200bps "fast-connect" modems designed just for that purpose.)

I think the pre-loading scheme still fixes the PPP problem in this
case, and is both simpler than and equivalent to the "masked"
approach, but it's possible that a bigger fix (e.g., dispensing with
link layer authentication and perhaps PPP as well and turning to
network or higher layer authentication) might be better.

The question turns back to a perennial favorite: so, what is the
actual problem to be solved?

-- 
James Carlson, IP Systems Group                <[email protected]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677