RE: pppcn

> From: "Kevin Purser (QA/EMC)" <[email protected]>

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

A better question is "draft/rfc prohibits this pre-loading"? 

An even better question is "how could any standard prohibit it"?  What
you cannot test for cannot be prohibited.

The idea of the pre-loading is that as far as the PPP peer is concerned,
each PPP packet arrives as if with a 0 or smaller RTT.  As soon as
the PPP peer finishes sending its LCP Configure-Request, it discovers
that it has received the Configure-Ack.  So it processes it and sends
its authentiation packet, and instantly receives a response.  It's
as if there is a super-fast tunnel that delivers the PPP handshakes.

The idea is the same as SMTP command pipelining, which is itself
a retreading of an even more ancient idea.


Vernon Schryver    [email protected]


P.S.  yes, of course, if you could check for this hack just as you
 can check for the illicit SMTP command pipelining used by some spammers.