Subject: Re: pppcn

From: "Kevin Purser (QA/EMC)" <[email-masked]>
Date: Tue, 16 Sep 2003 15:09:36 -0500

Hello All,

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.

Kev

Abstract:

   If the Internet is accessed via cellular networks, the Point-to-Point
   protocol (PPP) is most commonly used for configuration of the
   circuit-switched or packet-switched link.  Thus, this PPP
   configuration time comes in addition to the usual call-setup time for
   the cellular connection.  In many cases this will result in a fairly
   long "wait time" as perceived by end users before actual application
   data can be transmitted.

   This proposal describes a solution in which the PPP configuration
   time can be significantly reduced (on the order of seconds) in cases
   where both peer protocol entities can be modified according to this
   proposal, which involves modifying standard PPP.  In cases where one
   PPP peer is modified and the other utilizes only standard PPP, the
   modified peer can fallback to standard PPP operation.  This fallback
   mechanism will not noticeably affect the PPP setup time, and serves
   to ensure interoperability.

 <<draft-purser-pppext-pppcn-00.txt>>

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 16 Sep 2003 17:35:14 -0600 (MDT)

> From: "Kevin Purser (QA/EMC)" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>

> 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-masked]

---

From: Karl Fox <[email-masked]>
Date: Tue, 16 Sep 2003 23:42:54 -0400

> has been published here and elsewhere (e.g. James Carlson's book) more

 From "PPP Design and Debugging," by James Carlson, pages 68-69:

"An example in Chapter 7 shows that PPP can fully negotiate even in 
complex cases within a few round-trip times and that this negotiation 
is easily faster than switched-circuit setup times, even on ISDN.  Some 
users, however, view PPP negotiation as too slow for some applications, 
perhaps based on their experiences with bad PPP implementations.  These 
designers have many times proposed complex mechanisms to maintain state 
across sessions in order to bypass normal PPP negotiation.  These 
proposals are usually termed "fast reconnect" or "short hold."  These 
proposed protocols, such as draft-ietf-pppext-scm-00.txt, greatly 
weaken security and are completely unnecessary.
     As the example in Chapter 7 shows, PPP is already faster than the 
inherent delays in circuit set-up, but PPP can be made faster still, if 
necessary.  A technique proposed by Vernon Schryver reduces this delay 
to a single-round trip time, at the expense of a minor but generally 
compatible violation of RFC 1661 and a possible time-out delay with 
some peers.  It does not require any new PPP options or protocols."

Buy the book.  Read Chapter 7.  Build a blindingly fast PPP 
implementation that does all you want and more, without changing the 
protocol at all.  Other people have done it this way; you can too.

Karl Fox
PPPEXT Working Group Chair

P.S.  Thank you, James Carlson, for such a powerful tool.

---

From: James Carlson <[email-masked]>
Date: Wed, 17 Sep 2003 08:39:38 -0400

>  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-masked]>
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