Re: [Pppext] Suggesting Improvements in RFC 1990.

[James Carlson <james.d.carlson at sun.com>]

Hariharasubramanian CS writes:
> > 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.

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
>  encapsulate the material to be fragmented ".

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.

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

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.

>  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 ?

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.

>        (In other words, If there are two links, one negoitiates PFC  and the
> other doesn't, then which one
>        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.

> I don't think I have ever actually seen SDP applied in
> > conjunction with multilink.
> 
> 
> [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                    <james.d.carlson at sun.com>
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

_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www1.ietf.org/mailman/listinfo/pppext