Subject: [Pppext] ACFC

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 13 Oct 2005 00:07:00 -0700

Hi,

I have a doubt about ACFC. 

RFC1661 clearly states the reasons why PFC is not done for LCP frames. I
wanted to know if ACFC can be done for NCP frames(or for any other
control frames). Besides, what is the reason ACFC is not done for LCP
frames?

Thanks,

Vishwas

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

---

From: James Carlson <[email-masked]>
Date: Thu, 13 Oct 2005 08:50:17 -0400

Vishwas Manral writes:
> control frames).

For NCP?  Sure.

It can't be done for LCP, because LCP is *how* you negotiate ACFC.  If
you allow it there, you end up with a chicken-and-egg problem.

> Besides, what is the reason ACFC is not done for LCP
> frames?

The above.  If you want a formal reason, the options negotiated by any
xCP (including NCPs and LCP itself) are not put into effect until the
xCP reaches Opened state.  Until that point is reached, all optional
features must be in the defined "default" state.

Thus, until you've negotiated ACFC via LCP and LCP is in Opened state,
you can't actually do ACFC compression, and if you leave Opened state
(by sending a new LCP Configure-Request message to start
renegotiation), then you must revert to the defaults as well.

I suppose there's an edge case here: one could possibly argue that
there's no reason to disallow ACFC on non-Configure-* LCP frames sent
while in Opened state, such as LCP Echo-Request.  However, it's not as
though LCP is itself very high rate traffic that would benefit from
removing just two octets from any message, and it's nearly impossible
to justify that level of complexity.  It's much simpler to just say
that LCP messages are never compressed with ACFC.

In addition, it is necessarily the case with almost all PPP options
that they merely *permit* the sender to use the requested feature, and
do not *compel* the sender to use it.  In other words, if you
negotiate ACFC, you don't actually have to compress out those fields
if you don't want to, and the receiver *MUST* handle frames that
contain the HDLC Address and Control fields at all times.

Thus, including those fields does not do harm, and it does good by
reducing complexity.

(And, obviously, as LCP is protocol C021, PFC cannot possibly apply.
PFC works only if the upper octet is 00.)

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