Subject: RE: AW: PPP Frames on tunnel

From: "Shriver, John" <[email-masked]>
Date: Tue, 1 Aug 2000 07:26:38 -0700

Let's be honest about why the Address and Control fields are there in PPP.
PPP was a grand compromise deal between Cisco, Proteon, ACC, Wellfleet (were
they there then?) and a few other early router vendors to have a consistent
data link.  None of the vendors were willing to redesign their hardware to
me compatible with PPP.  Someone was using a serial controller that was one
of those old "smart" X.25 controllers, and could not deal with packets not
having the address and control fields.  So they were made part of the
default standard configuration, but anyone not using that brain-dead chip
could negotiate it away.

Similarly, PPP allows link layer padding bytes because (at least) Cisco and
Proteon had boards that could only send packets of an even number of bytes.

Any arguments that the address and control fields on PPP were there for any
useful reason are completely specious.  Let's not reinvent history.

What's two bytes among friends.  Any header blows the 1500 byte frame...

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 01 Aug 2000 11:37:27 -0400

> data link.  None of the vendors were willing to redesign their hardware to

Your PPP history certainly goes back further than mine, John. Thanks for
the lesson.

> useful reason are completely specious.  Let's not reinvent history.

This thread wasn't about why PPP Address and control fields are present
in PPP, but why they remained present on the tunnel. A tunneled PPP
frame terminated at an LNS does not utilize the serial chipsets you
refer to... It's all a virtual interface at that point. As far as
alignment of the PPP datagram, the L2TP offset can ensure that on the
tunneled packet.

The "back ourselves into a corner" comment was a quote (as I remember it
from a bakeoff long ago) from one of the original authors of the L2TP
spec... I am not trying to reinvent anything.

> What's two bytes among friends.  Any header blows the 1500 byte frame...

True. One of the arguments given at the time and still somewhat valid
today. One catch is whether or not you know if you should tack on the
header. If the LAC did not go through LCP, short of snooping the
negotiation, it is impossible to know. The link-info draft would solve
this, but no one has implemented it that I know of. As would an
additional framing type. The prudent thing to do these days would be to
always tack on the framing as PPP can handle the FF03 whether ACFC was
negotiated or not.

- Mark

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 01 Aug 2000 09:02:53 -0700

At 11:37 AM 8/1/00 -0400, W. Mark Townsley wrote:
>The prudent thing to do these days would be to

... unless the packet in question already has the FF03. Otherwise, you can
end up with FF03FF03002145.... which PPP will have a hard time dealing with.

---

From: James Carlson <[email-masked]>
Date: Tue, 1 Aug 2000 13:01:08 -0400 (EDT)

> Let's be honest about why the Address and Control fields are there in PPP.

That's true for the reason HDLC fields are there in the default
encapsulation of PPP over simple point-to-point links, but this does
nothing to explain the need for those fields over tunnels.  Indeed,
there's much more precedent to assert that PPP should *NOT* include
these fields.  That they're present in L2TP is an anomaly.

The RFC 1663 argument doesn't work so well for me, either.  LAP-B
can't tolerate reordering and (generally) only makes the end-to-end
loss problems with L2TP *worse*.  Delaying all flows because the
tunnel itself is experiencing congestion only increases the amount of
useless retransmission at the transport layer and lowers performance.
If you do run 1663, you ought to be terminating the LAP-B session at
the LAC and not carrying it across the tunnel, but there's
unfortunately no draft that describes how or why to do this.  (Of
course, this also implies that the present mechanism that transports
LCP transparently from the LNS isn't right, either.)

> useful reason are completely specious.  Let's not reinvent history.

It's not reinventing history to say that the PPP frame has been
traditionally taken to be the PPP Protocol and Information fields
alone, exclusive of HDLC Address, Control, and FCS.  See RFCs 1598,
1973, 2363, and 2364.  See also the definition of the PPP MRU in 1661.
That L2TP does it differently is not a feature, but a bug.

We got here by market forces, not so much by deliberate action.

-- 
James Carlson, Internet Engineering       <[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
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 01 Aug 2000 16:07:40 -0400

> useless retransmission at the transport layer and lowers performance.

Precisely the reason Flow Control was removed from L2TP. Something that
was admittedly difficult given the precedence in PPTP. 

I wasn't necessarily recommending use of 1663, just stating for the
record some of the arguments from the time.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 01 Aug 2000 17:30:12 -0400

> end up with FF03FF03002145.... which PPP will have a hard time dealing with.

Of course. This is what I intended, but thanks for the needed
clarification.