RE: pppcn

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.
> 
> If our public attention was justifiably requisitioned by the original
> message, then our responses should be public.

I stand corrected.

> 
> 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?

I personally tend to agree with this.  Nonetheless, CDMA2000 has incorporated the use of PPP to set up packet data sessions...
 
> 
> 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.

Yes, this is exactly what we were aiming for- at least from reading rfc1661, I understood that sending this burst of packets was not allowed.  What draft/rfc describes this "pre-loading"?

Kev

> 
> 
> Vernon Schryver    [email protected]
>