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

From: "Hand, James C, ALABS" <[email-masked]>
Date: Wed, 19 Oct 2005 18:59:52 -0500

I'm not aware of any ECRTP implementations at this point.

I'm also not aware of any great clamor for ECRTP.  We're using cRTP
pretty widely on international frame relay links, and we're not exactly
sucking wind from it.  The environment described in which we're running
cRTP does NOT generally have a high rate of packet loss, in a large part
due to the fact that the cRTP traffic is VoIP, which is not bursty, and
is prioritized in a real-time QoS class.  The same would be true of
header compression over MPLS.

I was recently involved in some standards work related satellite IP
modems, and I was the one selling ECRTP to the vendor community.  Many
of these boxes implement RFC 2508 cRTP, and although the vendor
community seemed to agree that ECRTP or RoHC was probably better suited
to the satellite environment, again there did not appear to be any
intense demand or sense of urgency for a replacement for legacy cRTP.

So I would prefer not to require that an implementation of Header
Compression over MPLS be coupled with an upgrade from cRTP to  ECRTP.  I
don't see that that's necessary.  From my viewpoint, saving the
processing load of hop-by-hop compression/decompression cycles is more
important than moving to ECRTP universally.

I would also like to see RFC 2507 available, for the simple reason that
some existing "cRTP" implementations use the COMPRESSED_NON_TCP packet
type from RFC2507 in order to compress T.38 fax packets, which are
typically sent in the same flow (source/dest IP, source/dest UDP ports),
as the RTP VoIP media that was originally set up for the call, but don't
use RTP.  The ability to compress T.38 fax headers minimizes the
difference between the bandwidth used for a voice call vs. a fax call
and minimizes the impact of fax on QoS admission control.  Also,
COMPRESSED_NON_TCP is supposed to be fairly resilient to the kind of
things I think people are worried about with respect to cRTP/ECRTP.  The
following is a quote from RFC 2507:

   Differential coding is not used for non-TCP streams, so compressed
   non-TCP headers do not change the context.  Thus, loss of a
   compressed header does not invalidate subsequent packets with
   compressed headers. Moreover, the generation changes only when the
   context of a full header is different from the context of the
   previous full header. This means that losing a full header will make
   the context of the decompressor obsolete only when the full header
   would actually have changed the context.

So anyway, I'm for keeping in cRTP and IPHC.

Thanks,
Jim Hand
AT&T
732-420-3017
> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, October 19, 2005 12:17 PM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: Lars-Erik Jonsson (LU/EAB); Malis, Andrew G.; Hand, James 
> C, ALABS;
> Goode, B (Bur), ALABS; IETF AVT WG; raymond.zhang
> Subject: Re: [AVT] RE: [PWE3] Re: Header Compression over MPLS &
> Allison's DISCUSS Commenton PWE3 IANA Allocation Draft 
> 
> 
> 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
> 
> 
> 
> 
> On 19 Oct 2005, at 16:42, Ash, Gerald R ((Jerry)), ALABS wrote:
> > 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
> >
> 
> 

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 21 Oct 2005 08:07:44 +0100

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

- Stewart

---

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.

> > 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.
 
>    packet loss, packet reordering and long delays.
> 
>    to CRTP to increase robustness to both packet loss and misordering
>    ...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.
> 
> 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,
> 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

---

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

> 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
> 
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
>