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

["Ash, Gerald R \(Jerry\), ALABS" <gash at att.com>]

Hi Allison,

Thanks a lot for your quick reply.

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

I think you raise a valid point here, but it is not clear that CRTP
*cannot* operate properly using the proposed header compression over
MPLS/pseudo-wires.  For example, I'm aware of at least one
implementation of CRTP over pseudo-wires (e.g., a FR VC transported over
a PW).  This is a different approach than provided in the draft, but
still CRTP over PW subject to the possible packet loss and delay issues
mentioned above.  AFAIK, the implementation works fine. 

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

Thank you for the offer.  

Given the ubiquity of CRTP, the comments made on the AVT list, and the
example implementation I mentioned above, could we perhaps agree to also
leave CRTP in the draft and use Colin's suggestion to encourage use of
ECRTP and discourage use of CRTP?  

Regarding IPHC, Jim Hand makes some interesting comments in
http://www1.ietf.org/mail-archive/web/avt/current/msg05965.html.  You
said "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."  Given these comments, perhaps we could leave IPHC as TBD in
the draft?

So that would leave in the next revision of the HC over MPLS protocol
draft:

cTCP (RFC1144) -- delete
IPHC (RFC2507) -- TBD (subject to further expert review)
cRTP (RFC2508) -- discourage
ROHC (RFC3095) -- encourage
eCRTP (RFC3545)-- encourage

Would that be acceptable?

Thanks,
Regards,
Jerry

_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3