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

From: Allison Mankin <[email-masked]>
Date: Wed, 19 Oct 2005 08:33:00 -0700

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

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 24 Oct 2005 06:01:39 -0500

Stewart,

> > ROHC (RFC3095) -- encourage
> > eCRTP (RFC3545)-- encourage

> So would the plan be to leave the above registry
> entries in the IANA draft and delete the other three?

Yes, I think that is Allison's suggestion.  

I've suggested that cRTP and IPHC be proposed as to-be-assigned in the
header compression over MPLS protocol draft pending consensus to include
them.

Thanks,
Jerry

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 26 Oct 2005 12:03:25 -0500

Hi Kristofer, All,

> I must admit that I'm confused by this discussion. After 
> browsing the draft in question, I don't see why you would
> need separate code points for CRTP, ECRTP & IPHC.
> 
> After all, you will be separating them via the "PW Control 
> Octet", and since they share identifier space there, I don't 
> see why they can't share that at the signalling as well (i.e. 
> the code points being discussed).
> 
> Since you are using the 3544 negotiation, you can still 
> decide which of the schemes to use separately, so I think 
> they should share a code point (disclaimer: I know nothing 
> about how the pwe3 works).
> 
> So, I'd like to see:
> OLD:
>    0x001B  cTCP [RFC1144] Transport Header-compressed Packets
>    0x001C  IPHC [RFC2507] Transport Header-compressed Packets
>    0x001D  cRTP [RFC2508] Transport Header-compressed Packets
>    0x001E  ROHC [RFC3095] Transport Header-compressed Packets
>    0x001F  ECRTP [RFC3545] Transport Header-compressed Packets
> NEW:
>    0x001C  IPHC/CRTP/ECRTP
>    0x001E  ROHC [RFC3095] Transport Header-compressed Packets
> 
> Which should work as well as the current allocation.

Your suggestion looks good to us, since we can distinguish between
header compression schemes PW Control Octet in the header and/or the RFC
3544 negotiation.  It would be good to see what others think in view of
the earlier proposals for separate code points for each HC scheme:
http://www1.ietf.org/mail-archive/web/pwe3/current/msg07064.html
http://www1.ietf.org/mail-archive/web/pwe3/current/msg07066.html
 
> As note, I removed 1144, and I think that one is highly 
> unsuitable. Just the fact that it does not handle TCP 
> Timestamps makes it quite a poor option today.

Agreed.
 
> Regarding banning IPHC/CRTP:
> If they can share code points, I think banning these schemes is just
> silly. Better to write some short text to warn about the risks and
> say that CRTP is not recommended on certain links. Regarding IPHC,
> as has already been pointed out, the COMPRESSED_NONTCP is a robust
> packet format, but we should not forget that one can also run
> TCP_NODELTA packets, and also read section 11.2 which provides
> optional means to improve further on this for TCP streams. Perhaps
> it could be useful to specify means for using this packet sequence
> number so that IPHC can be used to its full extent on these links?
> 
> So, a short section on the possible downsides involved in using
> each scheme over reordering/lossy links and suggested implementation
> adaptations 
> (*) is the only thing I think would be needed to allow all the
> schemes to be used in this case.
> 
> (*) "...IPHC should use TCP_NODELTA, ECRTP should send absolute
> values, ROHC should be adapted as in rohc-over-reordering yada yada
> in case of reordering channels..."

Agree with this approach, thanks for the suggestions.

Regards,
Jerry