Subject: RE: [Pppext] ACFC

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 14 Oct 2005 06:26:09 -0700

Hi James,

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.

Thanks,
Vishwas
-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Friday, October 14, 2005 6:22 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: RE: [Pppext] ACFC

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

Any time the sender feels like it.

Perhaps I'm not understanding the question correctly.  If you're
actually asking whether this is "common" or not, or if there are
particular deployment scenarios in which it happens, I don't know.

If your goal here is somehow to avoid implementing this correctly, so
that all your system handles is header-compressed messages, then I'd
strongly caution against that.  Being more strict than what the RFC
requires is a good way to end up with interoperability problems.

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

And, indeed, you must.

If you don't like that, then you can always refuse to use these
options instead.

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

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

---

From: James Carlson <[email-masked]>
Date: Fri, 14 Oct 2005 09:28:03 -0400

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

---

From: Karl Fox <[email-masked]>
Date: Fri, 14 Oct 2005 10:18:57 -0400

Just make sure you don't reorder packets, or things will break.

Karl

---

From: "Paul W. Howard" <[email-masked]>
Date: Fri, 14 Oct 2005 11:09:10 -0400

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