Subject: [AVT] RE: [PWE3] Re: Header Compression over MPLS & Allison's DISCUSS Commenton PWE3 IANA Allocation Draft

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 19 Oct 2005 10:42:14 -0500

Please let me know what you think about Allison's offer:

"I'll trade you, I'll support leaving in the registrations for ROHC and
eCRTP,
if the others are left out.  (And the registrations for the PW types
need to be removed from the AVT doc; I'd missed them being there)."

I'm not sure we're going to get much more than that, but let me know if
you think otherwise.  I'm still concerned RE leaving out CRTP, Allison's
quote doesn't convince me it should be left out.

Please post your own replies to Allison if you like.

Thanks,
Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Allison Mankin
Sent: Wednesday, October 19, 2005 11:33 AM
To: Ash, Gerald R (Jerry), ALABS
Cc: [email-masked]; pwe3; Lars-Erik Jonsson (LU/EAB); Malis, Andrew G.;
Hand, James C, ALABS; Goode, B (Bur), ALABS; IETF AVT WG; raymond.zhang
Subject: [PWE3] Re: Header Compression over MPLS & Allison's DISCUSS
Commenton PWE3 IANA Allocation Draft 

Hi, Jerry,

> Carsten Bormann made a comment on RFC1144 problems at IETF-63 [in
> the context of the avt document header compression over mpls], but I
wasn't
> aware that cRTP and IPHC were also in the "problem" category.  In
> particular, cRTP is widely deployed and IMO should be supported for
> Header Compression over MPLS.

The IETF consensus on CRTP is reflected in ECRTP, RFC 3545 (and
also explained as the text goes on).  Here's the statement:

   CRTP was designed for reliable point to point links with short
   delays.  It does not perform well over links with high rate of packet
   loss, packet reordering and long delays.

   ...this document defines modifications and extensions
   to CRTP to increase robustness to both packet loss and misordering
   between the compressor and the decompressor

   ...The enhanced CRTP, as
   defined in this document, is thus suitable for many applications in
   the scenarios discussed above, e.g., tunneling and other virtual
   circuits.

Not that MPLS has a high rate of packet loss, or necessarily long
delays, but it is definitely a tunnel, and the kind of environment
that ECRTP, but *not* CRTP was defined for.  Just because a protocol
is widely deployed does not mean it should be viewed as applicable in
all environments.

Although the document for AVT is not baked yet, and could be changed,
we can see the in-WG review by Carsten that you mention as the Expert
Review, so
I'll trade you, I'll support leaving in the registrations for ROHC and
eCRTP,
if the others are left out.  (And the registrations for the PW types
need to be removed from the AVT doc; I'd missed them being there).

As I said about IPHC in my Discuss, I just don't know.  eCRTP uses it,
but it's a framework.  Used by itself, I'm not sure it's very robust.

Allison

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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Oct 2005 17:17:07 +0100

Jerry,

I agree with Allison that ECRTP is better suited to this environment  
than is CRTP. At a minimum, this draft should strongly discourage use  
of CRTP, and I would not object to its removal.

Colin

---

From: [email-masked]
Date: Wed, 19 Oct 2005 09:51:25 -0700

Hi Jerry,

Although cRTP has wider deployment, it is mainly deployed for enterprise voice
over SP's network with their VPN.   Considering the application for voice
transport  as applicable to this draft, I would say eCRTP is much preferred.
But it would be good to hear from the vendors if there are ECRTP implementations
and what are the expereince with them before we leave cRTP out completely.

Regards,
Raymond