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

From: "John Bray \(bray\)" <[email-masked]>
Date: Tue, 23 May 2006 08:53:09 -0400

I reiterate my earlier statement that I don't think your proposed
wording changes are significant enough to justify replacing RFC 1990.
However, see my responses inline.

> -----Original Message-----
> From: Hariharasubramanian CS [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 8:16 AM
> To: John Bray (bray)
> Cc: [email-masked]
> Subject: Re: [Pppext] Suggesting Improvements in RFC 1990.
> 
> 
> 
> On 5/22/06, John Bray (bray) <[email-masked]> wrote:
> 
> 
> 
> 	> -----Original Message-----
> 	> From: Hariharasubramanian CS [mailto:[email-masked]]
> 	> Sent: Saturday, May 20, 2006 7:08 AM
> 	> To: [email-masked] <mailto:[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
> 
> 
> 
> [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 ".

Not quite.  The Address and Control Fields we are discussing are used
for PPP in HDLC-like Framing (RFC 1662).  ACFC as specified in RFC 1661
is optional, meaning that transmitting peers need not omit them even if
the option is negotiated.  The Multilink payload is not using HDLC-like
Framing (it is not a serial interface, it merely emulates one), and the
Address and Control Fields are expressly prohibited.  Talking about ACFC
here just adds to the confusion IMO, and saying "SHOULD" will make
matters worse.  I think the text should simply have said that the
material to be fragmented MUST NOT contain the Address and Control
Fields and left it at that.

> 
>  
> 
> 
> 	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).
> 
> 
>  
> 
> [HARI] IMHO it can stay in the SHOULD clause, as it should 
> generally be followed by all.

That is precisely why it shouldn't say SHOULD.  It *shouldn't*
necessarily be followed by all.  There are often good reasons for *not*
using PFC on the multilink payload.

>  If you see this point as purely optional, then I would 
> change it to  MAY clause
> from SHOULD. 

It *is* purely optional.

> 
>  
> 
> 
> 	> 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. 
> 
> 
> 
> [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

I am quite familiar with ACFC, thanks.  Again, omitting these fields
from the packet is optional when ACFC is negotiated with HDLC-like
framing, but it is mandatory when talking about the multilink payload.

> 
> 
>  
> 
> 
> 	 And you are changing the
> 	*suggestion* to apply PFC based on the link setting to 
> a requirement. 
> 	That simply won't fly.
> 
>   
> [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.    

I don't think the RFC needs to make a clear statement.  It is entirely
an implementation decision, and since the receiving peer must be able to
reassemble and process the packet either way, I don't think it matters.
Trying to specify a precise behavior now will lead to interoperability
problems, because many current implementations will not be in compliance
with the new requirement.

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

Why?

John

>  
> 
> 
> 	>
> 	> --------------------------------------------------------------
> 	> ------------------------ 
> 	> 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: Vernon Schryver <[email-masked]>
Date: Tue, 23 May 2006 09:28:19 -0600 (MDT)

> From: "John Bray \(bray\)" <[email-masked]>
> To: "Hariharasubramanian CS" <[email-masked]>
> Cc: [email-masked]
>

That would be entirely true even if most of proposed changes were not
simply wrong.  Replacing RFC 1990 would inevitiably introduce new
placs where the wording confuses people.  At this date, more than 10
years after the first interoperable implementations, there cannot be
many significant bits of confusion.  There are textbooks that explicate
the current text.  Combined with the RFC and the open source implmentations,
they surely resolve any questions.

If there were to be a new RFC, I would:

 - change the name of the protocol to match common practice.
    I've always tried to follow the RFC and call it "MP", but most
    people call it something like "MLPPP."

 - get rid of or deprecate Self-Describing-Padding.
    I disagree with James Carlson.  I believe there are no existing
    implementations except perhaps student exercises that include
    Self-Describing-Padding.  I always thought self-describing-padding
    was a solution in search of a problem and not just in MP.  PPP
    implementations that lacked byte- agile DMA hardware could always
    use other tactics to reach an even number of bytes.  Today, hardware
    often uses buses a lot wider than 16 bits and have mechanisms to
    make them look narrow.  I think section 3.1 exists mostly to document
    a compromise between my steadfast objections to Self-Describing-Padding
    and some equally determined advocacy of it.

  - get rid of or deprecate section 5.
     Reliable PPP was another solution in search of a problem.  I vaguely
     recalled that RFC 1663 was deprecated, but it is still PROPOSED
     STANDARD in the Index and I can't find the RFC deprecating it that
     I thought I recalled.  Maybe I'm thinking of the RFC that reclaimed
     many dead and never used DHCP options.

  - get rid of most of the Endpoint Discriminator Option types and keep
     the couple that have actually been used, and might ever be used.

But again, the unavoidable new errors in a new version are not justified
by minor housecleaning.

Vernon Schryver    [email-masked]

---

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

Vernon Schryver writes:
>     Self-Describing-Padding.

How is that disagreeing with me?  I also said there are no known
implementations that do this, and the point of it at all is rather
obscure and almost completely without merit on non-terminal fragments.

-- 
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: Vernon Schryver <[email-masked]>
Date: Tue, 23 May 2006 14:41:12 -0600 (MDT)

> From: James Carlson <[email-masked]>
> To: Vernon Schryver <[email-masked]>
> Cc: [email-masked]

> How is that disagreeing with me? 

I was being flip.

>                                   I also said there are no known

You say "rather obscure and almost completely without merit on
non-terminal fragments."  That is an effusive recommendation compared
to what I think about it.  My views about it are more negative than
"completely without merit."

---

From: James Carlson <[email-masked]>
Date: Tue, 23 May 2006 16:47:36 -0400

> "completely without merit."

Fair enough.  I agree with you and I don't think padding really makes
any sense at all.  Making SDP Historic (along with the bits you
mentioned) might be a helpful move.

But _if_ for some reason you really _must_ do it, then you can't just
pad MP fragments arbitrarily, so the advice in the RFC was correct, if
somewhat (or completely) misleading.