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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 21 Oct 2005 07:23:12 -0500

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

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

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Tue, 25 Oct 2005 11:42:41 +0200

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

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.

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 adaptions (*) 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..."

BR,
   Kristofer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ash, Gerald R (Jerry), ALABS
> Sent: Monday, October 24, 2005 1:02 PM
> To: Stewart Bryant
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; pwe3; IETF 
> AVT WG; Allison Mankin
> Subject: [rohc] RE: Header Compression over MPLS & Allison's 
> DISCUSS Commenton PWE3 IANA Allocation Draft
> 
> Stewart,
> 
> > 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
>