Subject: Re: l2tp-digest V1000 #171

From: Barney Wolff <[email-masked]>
Date: Mon, 17 Jan 2000 21:43 EST

Um, well, ordering of data vs control packets is not guaranteed by
the intervening transport medium.

There are really only three ways to go (that I can think of :)

1.  LAC snoops LCP, knows the right ACCM, snoops the protocol field,
applies appropriate ACCM depending on protocol.  Expensive for the LAC,
but it can ignore SLI.

2.  LNS sends SLI, waits for ack before sending first data with
new ACCM.  Hard, without an output queue that can be stalled.
Expensive, if you have to stall output every time you send an
LCP Echo.

3.  LNS sends SLI, sends data to which new ACCM should be applied,
and hopes packets don't get re-ordered.  LAC makes sure it does not
itself re-order packets, and hopes the transport medium didn't lose
or re-order the SLI.  The LAC must not be so dumb as to act on the
SLI before prior data packets have been sent out.  Maybe the LAC
is smart enough to send LCP with the default ACCM, even without
an SLI to tell it to.  I would have thought this would be a
requirement, to avoid the silliness of having to surround an LCP
Echo by SLIs, but I can't find it in 2661.  I seem to recall the
silicon-based life forms protesting.

After all, the worst that happens if the wrong ACCM is applied is
that the packet is ignored, and packets get lost once in a while
anyway.

Regards,
Barney Wolff

> From: Jacob Teplitsky <[email-masked]>
> Date: Mon, 17 Jan 2000 18:14:08 -0800 (PST)
> 
> Why LNS/PPP API can't delay sending SLI with ACCM bits until
> it sends/receives a packet with a Protocol ID less than  0xC000 ?

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 18 Jan 2000 23:29:56 -0800

> applies appropriate ACCM depending on protocol.  Expensive for the LAC,

If you look at my proposal, it is essentially this, except:

1. The LAC never has to sniff if an SLI is not received
2. The LAC only sniffs a few packets, only after the SLI is received,
and only until it determines no more LCP packets will be sent, which is
likely for only a few packets and likely not during heavy traffic.

> Expensive, if you have to stall output every time you send an

Uggh.

> silicon-based life forms protesting.

Not guaranteed. I am not 100% sure about ACCM treatment on LCP echos by
these "strict" PPP implementations. My thought is that they can handle
this (e.g. once ACCM negotiation is completed, it is OK), but you're
right, you can be completely sure. Trying to surround LCP echos is truly
silly and not guaranteed to work.

> that the packet is ignored, and packets get lost once in a while

No, the worst is that the packet is *always* dropped, so LCP never
completes, and the call itself is dropped.