Re: ACFC
"Paul W. Howard" <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Vishwas, I think you will find that other implementations agree to ACFC and PFC primarily to increase their ability to connect with the plethora of PPP clients out there but have no intention of actually taking advantage of the permission. As noted eariler Ack'ing these options is merely acknowledging that you have permission to do the compression, not that you are required to do the compression. With today's higher speed links, there's very little value in doing this compression so it's fairly common to find it being acked and then not used. You would probably regret treating the uncompressed as "slow" path frames in this situation. Paul Howard James Carlson wrote: >Vishwas Manral writes: > > >>You rightly guessed it. It is the "common" case, I was enquiring about. >> >>I was wondering if cases where we had uncompressed fields even when ACFC >>and PFC were configured, we may not necessarily handle it in the fast >>path and yet handle it in the slow path. >> >> > >The standards say nothing about "fast" or "slow" -- those are >implementation and customer acceptance issues. They say only that it >must work. > > > _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext