RE: ACFC

Hi James,

Thanks a lot for the reply.

I had another small follow up question. When would we (if we ever would)
have data traffic having uncompressed fields, even when compression was
negotiated (both ACFC and PFC)?

I know the RFC states that we should treat both un-compressed and
compressed header fields in the same way when compression is negotiated.

Thanks,
Vishwas
-----Original Message-----
From: James Carlson [mailto:[email protected]] 
Sent: Thursday, October 13, 2005 6:20 PM
To: Vishwas Manral
Cc: [email protected]
Subject: Re: [Pppext] ACFC

Vishwas Manral writes:
> 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).

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 protected]>
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
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext