Subject: RE: [Pppext] Suggesting Improvements in RFC 1990.

From: "John Bray \(bray\)" <[email-masked]>
Date: Sun, 21 May 2006 15:30:01 -0400

> -----Original Message-----
> From: Hariharasubramanian CS [mailto:[email-masked]] 
> Sent: Saturday, May 20, 2006 7:08 AM
> To: [email-masked]
> Subject: [Pppext] Suggesting Improvements in RFC 1990.
> 
> Group,
> 
> This is to suggest some improvements in RFC 1990.  There are 3
> corrections. The first 

I believe your first "correction" would just add to the confusion.  It
also contains some unacceptable functional changes.  See my comments
below.

> & the second corrections are for making the
> points clearer for the reader.
> The third one invites a functional
> change.

While I don't have major objections to your other two suggestions, I
doubt they are significant enough to justify replacing RFC 1990.

> 
> Please review.
> Thanks in advance,
> Hariharasubramanian
> NetDevices India Pvt Ltd.
> 
> 
>                              Suggestion for Improvements in RFC 1990.
> 
> Correction 1
> 
> Section 2: General Overview Page 4
> 
> "The packets to be transmitted using the multilink procedure are
>   encapsulated according to the rules for PPP where the following
>   options would have been manually configured:
> 
>        o  No async control character Map
>        o  No Magic Number
>        o  No Link Quality Monitoring
>        o  Address and Control Field Compression
>        o  Protocol Field Compression
>        o  No Compound Frames
>        o  No Self-Describing-Padding
> 
>   According to the rules specified in RFC 1661, this means that an
>   implementation MUST accept reassembled packets with and without
>   leading zeroes present in the Protocol Field of the reassembled
>   packet.  Although it is explicitly forbidden below to include the
>   Address and Control fields (usually, the two bytes FF 03) in the
>   material to be fragmented, it is a good defensive programming
>   practice to accept the packet anyway, ignoring the two bytes if
>   present, as that is what RFC 1661 specifies.
> 
>   As a courtesy to implementations that perform better when certain
>   alignment obtains, it is suggested that a determination be made when
>   a bundle is created on whether to transmit leading zeroes by
>   examining whether PFC has been negotiated on the first link admitted
>   into a bundle.  This determination should be kept in force 
> so long as
>   a bundle persists.
> 
>   Of course, individual links are permitted to have different settings
>   for these options.  As described below, member links SHOULD 
> negotiate
>   Self-Describing-Padding, even though pre-fragmented packets MUST NOT
>   be padded.  Since the Protocol Field Compression mode on the member
>   link allows a sending system to include a leading byte of 
> zero or not
>   at its discretion, this is an alternative mechanism for generating
>   even-length packets.
> 
> 
> I suggest we rewrite this section as:-
> 
> The packets to be transmitted using the multilink procedure are
>  encapsulated according to the rules for PPP where the following
>  options would have been manually configured:
> 
>       o  No async control character Map
>        o  No Magic Number
>        o  No Link Quality Monitoring
>        o  Address and Control Field Compression
>        o  Protocol Field Compression
>        o  No Compound Frames
>        o  No Self-Describing-Padding
> 
>   Of course, individual links are permitted to have different
> settings for these options.
> 
> 2.1 Address and Control Field Compression:
> 
>   This document specifies that Address and Control Field Compression
> SHOULD BE   used to encapsulate packets using multilink procedures.

This sentence does not make sense when put together with the next
sentence.  The Address and Control Fields are forbidden, so it does not
make sense to talk about "Address and Control Field Compression".  The
use of the word "SHOULD", far from clarifying the text, will just add to
the confusion.  The FF 03 must be omitted, period.

> This means that it is explicitly forbidden to include the   Address
> and Control fields (usually, the two bytes FF 03) in the  material to
> be fragmented.. However, It is a good defensive programming  practice
> to accept the packet anyway, ignoring the two bytes if  present, as
> that is what RFC 1661 specifies.
> 
> 2.2 Protocol-Field-Compression
> 
>     This document specifies that Protocol-Field-Compression SHOULD BE
> used to encapsulate packets using multilink procedures. it is
> explicitly forbidden to include the leading zeros in the Protocol
> Field in the material to be fragmented..

The RFC currently says no such thing, and this would be a significant
functional change if adopted.  As currently worded, the RFC *allows*
implementations to compress the Protocol Field, but does not require
them to.  It merely *suggests* that PFC be applied if negotiated on the
member links in order to keep the payload on an even boundary, but that
is not a requirement.  The only requirement is imposed on the receiver,
which must be able to handle packets with or without the leading zero
(as stated below).

> However, according to the
> rules specified in RFC 1661, this means that an   implementation MUST
> accept reassembled packets with and without  leading zeroes present in
> the Protocol Field of the reassembled  packet.
> 
> Whether a bundle implements PFC and/or ACFC is dependent upon the
> first link admitted to the bundle. (This means that if the first link
> negotiates ACFC, then the bundle MUST NOT include Address and Control
> Fields in the material to be fragmented, irrespective of the ACFC mode
> of the other links.) This determination should be kept in force so
> long as the bundle persists.

Again, your discussion of ACFC is meaningless, since there are no
Address and Control Fields to compress.  And you are changing the
*suggestion* to apply PFC based on the link setting to a requirement.
That simply won't fly.

> 
> 2.3 Self-Describing Padding
> 
>  Member links SHOULD negotiate Self-Describing-Padding, even though
> pre-fragmented packets MUST NOT be padded. (This means that the
> material to be fragmented MUST NOT contain Pad octets, but the
> fragments themselves SHOULD contain Pad Octets.) Since the Protocol
> Field Compression mode on the member link allows a sending system to
> include a leading byte of zero or not at its discretion, this is an
> alternative mechanism for generating even-length packets. (More
> details in sec 3.1)

Actually, if anything, I would prefer the "SHOULD" to be changed to
"MAY".  I don't think I have ever actually seen SDP applied in
conjunction with multilink.

> 
> --------------------------------------------------------------
> ------------------------
> Correction 2:
> 
> Section 3: Packet formats Page 6
> 
> "Address & Control and Protocol ID compression
>   are assumed to be in effect. "
> 
> I suggest we append  this sentence with "in the material to 
> be fragmented"

You might want to add "and/or multilink encapsulated" since the packet
is not necessarily fragmented.

John

> 
> --------------------------------------------------------------
> -----------------------------
> 
> Correction 3:
> 
> Section 5.1.3 Endpoint Discriminator. Page 15
> 
> 
> "This option is not required for multilink operation.  If a system
>   does not receive the Multilink MRRU option, but does receive the
>   Endpoint Discriminator Option, and there is no manual configuration
>   providing outside information, the implementation MUST NOT assume
>   that multilink operation is being requested on this basis alone."
> 
> I suggest this paragraph be changed as:
> 
>   Endpoint Discriminator option SHOULD BE included for multilink
> operation, to facilitate unambiguous bundle allotment. However, If a
> system does not receive the Multilink MRRU option, but does receive
> the Endpoint Discriminator Option, and there is no manual
> configuration providing outside information, the implementation MUST
> NOT assume that multilink operation is being requested on this basis
> alone.
> 
> But, note that, without Endpoint Discriminator option, in the absence
> of manual configuration, it is possible that, two links of the same
> peer are connected to links of different peers, resulting in spurious
> behavior.
> 
> --------------------------------------------------------------
> -----------------------------
> 
> _______________________________________________
> Pppext mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pppext
> 

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: "Hariharasubramanian CS" <[email-masked]>
Date: Tue, 23 May 2006 17:46:28 +0530

> make sense to talk about "Address and Control Field Compression".  The

[HARI]John, You're mistaken here. When Address and Control Fields (ACF) are
forbidden, it means
that ACF compression is in place. Therefore my suggestion is to explicitly
state  "ACFC  is used to
 encapsulate the material to be fragmented ".

> which must be able to handle packets with or without the leading zero

[HARI] IMHO it can stay in the SHOULD clause, as it should generally be
followed by all.
 If you see this point as purely optional, then I would change it to  MAY
clause
from SHOULD.

> Address and Control Fields to compress.

[HARI] I think I've already made my point clear. Pl go through this
hyperlink.

http://www1.ietf.org/mail-archive/web/pppext/current/msg00256.html

 And you are changing the
> *suggestion* to apply PFC based on the link setting to a requirement.

[HARI] AFAIK, It was difficult for me to get an answer from the RFC for the
following question:

       What is the RFC's stand on how the bundle should choose PFC mode,
when the
       different member links negotiate different modes for the same PPP
parameter ?
       (In other words, If there are two links, one negoitiates PFC  and the
other doesn't, then which one
       should the bundle adopt ? )
IMHO we should make some clear statement in the RFC in this regard.

> "MAY".

[HARI] Agreed.

I don't think I have ever actually seen SDP applied in
> conjunction with multilink.

[HARI] But SDP SHOULD be negotiated on each link.

---

From: James Carlson <[email-masked]>
Date: Tue, 23 May 2006 08:44:02 -0400

Hariharasubramanian CS writes:
> that ACF compression is in place.

I'm afraid that's incorrect.

When Address and Control Field compression is enabled on a regular PPP
link, the sender *may* omit those fields.  It is not required to omit
them.  The recipient is required to accept them if present.

RFC 1990 specifies something different for the bundle level.  It isn't
just that ACFC is turned on; sending those fields is _incorrect_.

> Therefore my suggestion is to explicitly
> state  "ACFC  is used to

That doesn't make sense to me, either.

The Address and Control fields are part of HDLC, not part of PPP.  The
reason they're omitted from an MP fragment is that they simply form no
part at all of the data being transferred.  It's not a matter of
"compression" of any sort, but of getting the layering right.

They are prohibited, not merely compressed.

What RFC 1990 _suggests_ is that recipients be lenient towards
completely confused and broken peers that might insert these HDLC
headers into the middle of a plainly PPP message.  If I were to
improve RFC 1990 at all, I might suggest removing this text and just
saying that what belongs here is the PPP Protocol and Information
fields alone, and that adding stray HDLC headers is illegal.

> > implementations to compress the Protocol Field, but does not require
[...]
>  If you see this point as purely optional, then I would change it to  MAY

I think you're missing the point.  Adding the clause "forbidding" the
presence of a leading zero octet in the Protocol Field breaks
compatibility.  That behavior cannot be forbidden.

The current text says this:

   According to the rules specified in RFC1661, this means that an
   implementation MUST accept reassembled packets with and without
   leading zeroes present in the Protocol Field of the reassembled
   packet.  [...]

This means exactly what it says.  Receivers *must* be able to handle
packets as though standard Protocol Field Compression were enabled,
which means that the sender gets to choose whether it wants to
compress away the leading zero octet *OR NOT*.  We cannot now forbid
the sending of the leading zero octet without creating a compatibility
problem.

>        different member links negotiate different modes for the same PPP

It doesn't matter, because protocol field compression settings are
completely independent for the member links and for the bundle.

Each member link may choose to enable Protocol Field Compression.  For
those that do, the PPP Protocol Field "00 3D" may be expressed
instead as "3D."

Independently, the _bundle_ behaves as though Protocol Field
Compression were always enabled.  When the receiver reassembles the
fragments, the receiver must be able to deal with either "00 21" or
"21" for IP traffic (for example) in the reassembled message.

There's no interaction between these two things.

>        should the bundle adopt ? )

Neither.

> IMHO we should make some clear statement in the RFC in this regard.

The clear statement is already in the document.

   Of course, individual links are permitted to have different settings
   for these options.  As described below, member links SHOULD negotiate
   Self-Describing-Padding, even though pre-fragmented packets MUST NOT
   be padded.  Since the Protocol Field Compression mode on the member
   link allows a sending system to include a leading byte of zero or not
   at its discretion, this is an alternative mechanism for generating
   even-length packets.

Member links have their own options.

> [HARI] But SDP SHOULD be negotiated on each link.

I don't know of any that do, in part because there are so few systems
that use padding at _all_.  The document doesn't match reality.  (That
unfortunately happens with RFCs.)

This section should probably be rewritten.  I think the issue here was
making sure that padding, if it's used, is used properly on fragments.
Fragments can't be padded unless SDP is used -- ad-hoc padding will
corrupt the data.  (But, then, why would anyone want to pad a
fragment?  If you're doing that, doesn't it mean that you have more
data you could have sent instead of the pad?)

Given that almost nobody pads, it's mostly a moot point.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Mark Lanzo <[email-masked]>
Date: Tue, 23 May 2006 10:38:54 -0400 (EDT)

>  encapsulate the material to be fragmented ".

This is an MLP bundle under discussion, not an HDLC link.  A bundle does not
have HDLC framing nor any similar sort of framing which defines analogous
Address and Control fields.  You cannot compress that which is not there to
begin with.  ACFC is a concept which has no meaning or relevance to a bundle.

Now, I will agree that the RFC wording is confusing since its wording suggests 
that Address/Control fields (and compression thereof) have any relevance
whatsoever at the bundle level.   It would be better if the RFC explained that
packets at the bundle level are "pure PPP", consisting solely of PPP Protocol 
and Information fields and never contain any media-specific framing, but, I'd
echo John's sentiment that it is not worth a new revision of RFC 1990 just to 
change this.

> IMHO we should make some clear statement in the RFC in this regard.

The RFC does have a clear statement about that:

   "As a courtesy to implementations that perform better when certain
   alignment obtains, it is suggested that a determination be made when
   a bundle is created on whether to transmit leading zeroes by
   examining whether PFC has been negotiated on the first link admitted"

There is no requirement that the bundle choose its PFC mode based on
any link's characteristics.  One could never do it, always do it, 
or do it selectively by any criteria one wanted -- for example, 
balance the inner and outer Protocol fields on a Beginning fragment
to always keep the fragment payload on an even boundary.

I would interpolate that the intent behind the above suggestion is that 
unless a peer system has explicitly indicated that it does not mind 
receiving unaligned payloads (by negotiating PFC), that it is 
probably best if one not generate them at the bundle level either.

-Mark

---

From: Karl Fox <[email-masked]>
Date: Tue, 23 May 2006 11:11:06 -0400

If someone were to ask me (which they haven't), I'd say leave RFC  
1990 alone unless you fix it.  By "fixing it" I mean combining two  
links, each with probability of failure p, and providing a combined  
link with probability of failure p^2 rather than 2p as RFC 1990 does.

Karl

P.S.  I may be years out of date on this issue, but the last time I  
participated in an argument on the topic we couldn't come up with a  
way of making a single-link-failure not hose up the entire bundle, at  
least not until LQM shut it down and removed it from the bundle.   
Cleverer people than I may have solved this since then.

---

From: James Carlson <[email-masked]>
Date: Tue, 23 May 2006 12:57:33 -0400

> link with probability of failure p^2 rather than 2p as RFC 1990 does.

If you mean on a packet-by-packet basis, then p^2 sounds like "path
protection" (replication at the sender and discarding duplicates at
the receiver).  That's rather different from what the original goal
seemed to be, and likely wouldn't fit many (if any) of the existing
uses of MP.

If you mean on a link basis, then I don't think such a fix is needed.
It's a matter of implementation.