Subject: RE: (ML)PPP State Machine Issues

From: Henrik Kristensen <[email-masked]>
Date: Fri, 25 Feb 2000 10:57:14 -0800 (PST)

I wasn't trying to start a big discussion. It appears RFC1661 is
perfect by definition, in which case I must be wrong.

Just let me add in closing:

  Duplicates can happen (for example in what's described as "crossed 
  connection" in RFC1661 sect.4.1's table or, if one end times out a 
  number of times(TO+) before the other end's first CONFACK gets 
  back.)

  I still think my changes would be backwards compatible with 1661-
  conformant implementations. (However some of my changes would not 
  have any effect when "talking to" a 1661-conformant version. For
  example, if the other end doesn't reuse the Identifier, we don't
  ignore CONFREQ.)

  The "zero check" was an extra protection AGAINST altering the 
  standard behavior in the zero case..:
  For RCR+ is received in state OPENED (9):
      IF  Identifier is unchanged
      AND Identifier is different from zero
      AND Magic number option is present
      AND Magic number value is unchanged
      THEN sca/9
      ELSE tld,scr,sca/8

(Obviously, I've extended my stay on this list by now. My apologies.)
--Henrik

> From [email-masked] Fri Feb 25 10:15 PST 2000
> Delivered-To: [email-masked]
> Date: Fri, 25 Feb 2000 11:14:48 -0700 (MST)
> From: Vernon Schryver <[email-masked]>
> To: [email-masked]
> Subject: RE: (ML)PPP State Machine Issues
> 
> > From: Henrik Kristensen <[email-masked]>
> 
> > 1) Ignore Duplicate CONFACK received in state OPENED.
> >
> > Described in RFC 1661 [1], sect.4.1 as a "crossed connection", in
> > some cases duplicate Configure-Ack's may be received in state OPENED,
> > causing the generation of a new Configure-Request and a move back to
> > state REQSENT. Depending on the actual scenario (delays and state to
> > the other end), this can cause either delayed link establishment or, 
> > start configuration loops (e.g. involving further timeouts).
> > ...
> 
> It is impossible to receive a duplicate Configure-Ack unless you either
> fail to check packet ID's, or if you send Configure-Requests with duplicate
> ID's.  Otherwise, there is no such thing as the very idea a duplicate
> Configure-Ack.  If you do bend the standard by re-using ID's on your
> Configure-Requests, then you must do something about the consequences.
> 
> 
> > 2) Ignore "Truly Duplicate" CONFREQ received in state OPENED.
> >
> > In one scenario, link establishment can fail if one end of the link,
> > after having reached state OPENED receives a duplicate Configure-
> > Request (RCR+) which would cause it to go back to state ACKSENT and
> > generate what is effectively another duplicate Configure-Request
> > (RCR+) towards the other end. The other end might in the meantime
> > have received a Configure-Ack (RCA) and reached state OPENED but,
> > upon receipt of this new Configure-Request (RCR+) go back to state
> > ACKSENT, and the cycle would repeat indefinitely.
> >
> > The solution to this is to ignore duplicate Configure-Requests which
> > may have been caused by timeouts or delays on the link.
> > ...
> 
> That is a mistake.  PPP links are universally assumed to deliver
> all packets (that they deliver) in the order in which they were
> sent.  That implies that if you ignore a Configure-Request from a
> peer that is compliant with RFC 1661, then you will break the link.
> The peer will be waiting for your Configure-Ack.  You cannot ignore
> the peer's Configure-Request, even if it has the same ID as its
> previous Configure-Request.
> 
> Are you failing to change or check the LCP packet ID?
> 
> 
> > ...
> > That is, if Identifier and Magic number are present and equal to the
> > last received values, and Identifier is different from zero, send
> > Configure-Ack and remain in state OPENED. Otherwise, act as
> > originally specified in RFC 1661 [1].
> > (Many implementations default to starting with Identifier value zero,
> > hence the extra check against Identifier = zero.)
> 
> Some other implementations start with an intentionally random ID,
> and will use an ID of zero after having used a non-zero ID.  Anything
> that assumes anything special about ID 0 is a mistake.
> 
> 
> > 3) Reuse Identifier when REtransmitting CONFREQ.
> >
> > In order for the second change to be effective, it is also necessary 
> > to reuse the same Identifier when retransmitting a CONFREQ (i.e. on 
> > TO+ event). This is already mentioned as allowed (though neither 
> > recommended for or against) in RFC1661.
> 
> I may have been the person who argued vigorously for re-using ID's when
> retransmitting Configure-Requests and for changing the draft to allow
> them.  I know that I eventually decided it was a bad idea for my own code.
> Regardless, if you do re-use ID's, you "MUST NOT" assume that the peer
> will know or understand that you are doing so.  You also "MUST NOT" assume
> that the peer is or is not re-using ID's.  If you do re-use ID's, then
> you "MUST" also warp your own implementation of the state table as
> required, probably including introducing the non-standard idea of a
> "duplicate Configure-Ack", although I do not know how you can define a
> "duplicate Configure-Ack" and still interoperate with existing
> implementations.  As I said, I eventually decided that re-using ID's is
> a bad idea at least for my own code.
> 
> There are a bazillion PPP implementations in the field.  They work, do
> not get stuck, and do not make unnecessary trips through the initial
> states.  Anything you do that requires changes in the state table that
> they implement is wrong, even if the changes result in a better protocol.
> I suspect that re-using ID's is exactly such an idea, that the protocol
> would have been better (e.g. quicker to converge on a lossy link) if it
> allowed for in duplicate ID's, the original state table, but that duplicate
> ID's cannot be retrofitted.
> 
> 
> Vernon Schryver    [email-masked]
> 
>

---

From: James Carlson <[email-masked]>
Date: 25 Feb 2000 14:51:42 -0500

> perfect by definition, in which case I must be wrong.

If you're taking it personally, don't.  There's ample evidence that
getting all of RFC 1661 correct in a given implementation is not quite
easy.  If you're asking for help, don't forget that this is a working
group mailing list, and take the replies in the helpful spirit that
they're given.  ;-}

>   number of times(TO+) before the other end's first CONFACK gets 

Real duplicates of Configure-Ack just can't happen.  Nobody sends
Configure-{Ack,Nak,Rej} except in response to an explicit
Configure-Request.  Any implementation that resends these messages
without solicitation is completely broken.

Since all of those are explicitly triggered messages (not timed),
apparent duplicates can't happen at all unless these two things (or
any of a number of analogous implementation errors) are true:

	- You're sending the same ID number when handling the restart
          timer, and

	- You have your restart timer set shorter than the link's RTT.

Jumping back to the start of the discussion, it's quite likely that
the restart timer is too short.

>   example, if the other end doesn't reuse the Identifier, we don't

I'm with Vern on this one.  Assuming *ANY* characteristics -- initial
values, special values, monotonicity, et cetera -- of the peer's ID
number in its Configure-Request message is a bug, not a feature.  If
you have to do that, then something else is quite wrong.

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: Archie Cobbs <[email-masked]>
Date: Fri, 25 Feb 2000 12:37:36 -0800 (PST)

> group mailing list, and take the replies in the helpful spirit that

For what it's worth..

Here are four changes I had to make to the RFC 1661 state machine
to resolve certain race conditions:

   RCR+ in state STOPPED: add tls
   RCR- in state STOPPED: add tls
   OPEN in state CLOSED:  add tls
   DOWN in state CLOSING: add tlf

Note: I'm not claiming RFC 1661 is broken, just that my implementation
of it was broken until these changes were added.

What this does is insure that the lower layer always knows what
it is supposed to do -- i.e., either come up or stay down.

For example, without the "tlf" action in state CLOSING upon receipt
of a DOWN event, the lower layer still "thinks" that it's needed,
because a "tls" was the last thing it heard from this layer, when
in actuality if you're in the CLOSING state it's not needed.

In my implementation this problem led to a modem redialing when it
was supposed to stay on-hook, etc.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com