Subject: [AVT] RE: [rohc] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 May 2005 15:37:00 +0200

Jerry and others,

First of all, I must say you've done a great job with this update. The
technical solution is starting to get in shape, and so also the draft
itself. I just have a few issues that I believe should be given some
additional attention, and I'll start with the least technical one:

* References
  
 - There is one incorrect reference to RFC 3409, which I think has
   not much to do with this document. The correct document to refer
   to is RFC 3241, "Robust Header Compression (ROHC) over PPP".

 - There is one invalid reference [IPCP], I guess it should be [RFC1332]

 - As it is currently written, I believe [RFC3544] and [RFC3241]
   would be normative for this document. I believe some other
   references, e.g. some MPLS references, would also be normative.

 - There are many informative references, go through them and make
   sure they all are actually bringing any value as informative to
   this document (I am not sure about the MPLS references). It might
   also make sense to group them based on content (HD vs MPLS, etc),
   that would make it easier for the reader.

* Separation of functionality

  As previously discussed, I believe it would be useful to more
  clearly separate negotiation/setup/signalling from encapsulation. As
  it now stands, I am not sure I understand what purpose the separation
  of chapter 2 and chapter 3 serves. Chapter 2 is about both setup and
  encapsulation, while chapter 3 is about setup only.

* Requirements fulfilment

  In chapter 1, it is said that the outlined solution fulfils the
  requirements of [MPLS-HC-REQ]. I am not sure this listing is really
  needed, neither do I think it is fully correct.

  a) is true, that is a design decision for this document
  b) is also true, ok, it is the whole purpose of the document
  c) is not really achieved by this document, but depends on the
     header compression scheme used, and especially on how that
     scheme is implemented. This document can not guarantee anything
     in this regard, but it provides what it can to make this possible.
     What this document do indeed provide, is the mechanism to avoid
     multiple compression/decompression cycles, but that is b) above.
  d) "signal context identification", I do not know what is meant
     with that, neither do I know what standard protocols are referred
     to, is it the MPLS PW mechanisms that are meant, and/or the
     HC-over-PPP specifications (for the latter, see also below).
  e) this is implementation dependent on HC-protocol level, and it
     is out of control of this specification, which is dependent on
     the HC scheme implementation(s). Or do PW provide means for 
     in-order delivery?

  Overall, I do not see the point of listing these things here. I
  think it is sufficient to say that the solution(s) outlined in
  this document have been designed and chosen to address the
  goals and requirements of [MPLS-HC-REQ].

* "Flow Setup", end of chapter 2 introduction

  - Is this really only about "setup"? It does not look so to me.

  - I believe this can be generalized so that it is HC-scheme
    independent, should not be hard to do.

  - It is not clear whether 2) is mandatory or not, i.e. is it
    mandatory to have a bidirectional connection?

* "Flow setup", last bullet, "Free up CID when flow terminates"

  - How can one ever know that a flow has terminated? For UDP-based
    "flows", there is no such thing. Also, why should one free
    CIDs, I agree CIDs should be re-usable, but if memory is
    allocated for a certain number of CIDs, that memory should
    last as long as the HC instance(s) is(are) alive. It is the
    compressor that may choose to re-use a CID. This has been
    thoroughly discussed in the ROHC WG, captured in chapter 7
    of <draft-ietf-rohc-rtp-impl-guide-11.txt>.

* Link layer packet type field

  The requirement that link layers must provide packet type
  identification for HC packets does not apply to ROHC. Therefore
  I believe it is an improper design to require the extra
  multiplexing byte (Pkt Typ field) for all schemes. There is
  a negotiation of HC scheme done for the "channel", so why not
  say that for schemes that can not identify their own packet
  types, the extra byte is needed, as described. Or actually
  negotiate whether to have this byte, independent of HC scheme
  (although some require it).

* I think it makes sense to re-use the principles of RFC 3544 and
  RFC 3241, but I also think this document will actually have to
  define more specifically how the negotiation is done (with
  similar principles as in 3544 and 3241). Both RFC 3544 and RFC
  3241 are written as plug-ins to the PPP control protocol IPCP,
  so just referring to them here where there is no PPP or IPCP
  does not convince me about the completeness of the solution. 

Rgds,
/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ash, Gerald R (Jerry), ALABS
> Sent: den 22 april 2005 00:06
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: [rohc] RE: I-D
> ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
> 
> 
> Hi All,
> 
> Please review and comment on the (significantly) updated 
> draft "Protocol
> Extensions for Header Compression over MPLS"
> (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpl
> s-protocol
> -00.txt).
> 
> Here is a brief background and overview/explanation of the updates:
> 
> Work on requirements for header compression over MPLS
> (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-mpls-re
> qs-03.txt)
> is complete, and work on protocol extensions for header 
> compression over
> MPLS is underway (previous draft at
> http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-
> protocol-0
> 2.txt).  Chartering of the protocol work in the AVT working group has
> been submitted for approval with the following milestone:
> 
> Dec 05: Submit any extensions for RTP HC on MPLS networks for Proposed
> Standard
> 
> There has been considerable discussion on the previous protocol
> extensions draft
> (http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls
> -protocol-
> 02.txt) in the last couple of months.  I presented the update on the
> header compression over MPLS protocol extensions work at the 
> AVT meeting
> at IETF-62; slides and minutes are available at
> https://datatracker.ietf.org/public/proceeding_interim.cgi?mee
> ting_num=6
> 2 (look under AVT for minutes and slides).  The recent discussion and
> issues regarding the basic approach are summarized in the slides.
> 
> Header compression experts in the AVT and ROHC working groups wish to
> re-use, and extend, the existing layer 2 approaches for assignment of
> context identification (CID) and header compression parameter
> negotiation.  In a multipoint-to-point MPLS environment, one approach
> would be to have the various header compressors assign CIDs as they do
> now, with the possible need to resolve CID conflicts/collisions at the
> header decompressor.  Some comments were made that current header
> compression methods do not have to resolve CID collisions, however the
> synchronization source (SSRC) assigned in RTP could need
> collision/conflict resolution.
> 
> A second approach, suggested by Andy Malis and Loa Andersson, 
> is to use
> pseudowires and/or targeted LDP to create 'point-to-point' sessions
> between header compressor and header decompressor, thereby 
> avoiding any
> issue of CID collision.  The disadvantage of this approach is that it
> requires an additional 4-byte label to be carried with each packet.  
> 
> The updated draft based on the second approach is available at
> http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls
> -protocol-
> 00.txt.
> 
> Once again, please review and comment on the updated draft.
> 
> Thanks,
> Jerry

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 17 May 2005 16:00:49 -0500

Hi Lars-Erik,

We really appreciate your thorough reviews and helpful suggestions.

>    that would make it easier for the reader.

Agree to all the above suggestions.
 
>   clearly separate negotiation/setup/signaling from encapsulation. As
>   it now stands, I am not sure I understand what purpose the 
>   separation of chapter 2 and chapter 3 serves. Chapter 2 is about
>   both setup and encapsulation, while chapter 3 is about setup only.

OK, perhaps we could map current Sections 2 and 3 into the following
sub-sections:

Section 2.1: link layer encapsulation type field  (current Section 2.2)
Section 2.2: PW and HC scheme negotiation/setup/signaling (current
Sections 2.1 and 3)
Section 3: procedures summary (from "In Figure 1 ..." in current Section
2)

If you have another suggested organization, please let us know.

> * Requirements fulfillment
> 
>      in this regard, but it provides what it can to make this 
>      possible.  What this document do indeed provide, is the
>      mechanism to avoid  multiple compression/decompression cycles,
>      but that is b) above.

We can make it more clear that we meant to use existing CRTP, ECRTP or
ROHC procedures
to signal these natively.  The nice thing about the approach is that it
achieves functional separation from the PW signaling.

>      the HC scheme implementation(s). Or do PW provide means for 

Agreed that it is HC scheme dependent, however, PW does provide a means
for in-order delivery.

>   goals and requirements of [MPLS-HC-REQ].

We agree with your suggestion to replace the material with a statement
like the one above.
 
>     independent, should not be hard to do.

Agreed, we'll re-word to make it HC-scheme independent.
 
>     mandatory to have a bidirectional connection?

We think it is mandatory to have a bidirectional connection for
CRTP/ECRTP/ROHC with feedback channel, and also for voice signaling and
flow control (RTCP).
 
>     of <draft-ietf-rohc-rtp-impl-guide-11.txt>.

Agreed.  <draft-ietf-rohc-rtp-impl-guide> has a nice discussion on CID
re-use, which we'll reference.

>   (although some require it).

Dynamic negotiation of the multiplexing byte may require a bit more work
and complexity than is desirable.  Since the gateways need to be
configured for each HC type anyway, we could follow this suggestion by
saying that the extra byte will be needed for those HC schemes that can
not identify their own packet type.  That is, an extra byte will be
added by default once a certain HC type is configured.
 
>   does not convince me about the completeness of the solution.

Are you suggesting that we provide a more detailed specification to
extend the use of IPCP or similar scheme for HC parameter negotiation
over MPLS?

> /L-E

Thanks again,
Regards,
Jerry

---

From: Colin Perkins <[email-masked]>
Date: Thu, 19 May 2005 16:04:33 +0100

Jerry,

On 21 Apr 2005, at 23:01, Ash, Gerald R ((Jerry)), ALABS wrote:
> Please review and comment on the (significantly) updated draft  
> "Protocol
> (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls- 
> protocol
> -00.txt).

The new approach (using MPLS PW) looks to be a big improvement, and  
the draft seems to be taking shape. I do have a number of comments,  
however:

The definition of terms and reference to RFC 2119 needs to be moved  
within the body of the text, rather than being a separate unnumbered  
section. I'd suggest placing the paragraph at the start of Section 2.

Section 1, 2nd paragraph: "the compressed packet routed on an MPLS  
LSP using MPLS labels" --> "the compressed packet _is_then_ routed..."

Section 2, 1st paragraph: I found the phrasing about pseudowires  
transporting the "HC context and other control messages" a little  
confusing, implying that the context and control messages are  
transported separately to the compressed data packets. It might be  
clearer to say "MPLS pseudowires (PWs) are used to transport the  
header compressed packets between the ingress and egress...".

Section 2, 3rd paragraph: The sentence "Compressed packets and HC  
control packets are routed on a separate MPLS LSP/PW..." could be  
interpreted as a requirement to setup two PWs, one for the HC  
compressed data packets and one for the HC control packets. It might  
be clearer to state "Compressed data is routed on a separated MPLS  
LSP/PW from compressor to decompressor"?

Section 2.1, top of page 7: I agree that there is no problem with  
duplicate CIDs since they're received on separate sessions. However,  
the text can be read to imply that something other than normal CID  
processing is required. This confusion comes from the statement  
following ("...the HD can distinguish these this it knows the sour by  
means of the PW label"), which implies that there is a single HD for  
all PWs. It would be clearer if the draft made it explicit that each  
PW had a logically separate HD instance, independent of all other PWs.

Section 2.1, last paragraph: in order to assign a new PW type, the  
IANA must be given explicit guidance on what to assign. This requires  
a statement much like those in section 2.1 of the pwe3-iana- 
allocation draft, listing a numeric type to assign along with a  
description for that type.

Section 2.2: how are the reserved values to be allocated? The draft  
needs to either define an allocation policy (and IANA registry) or  
mandate that they MUST NOT be assigned.

Colin