Subject: RE: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.tx t

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 14 Jan 2004 16:13:09 +0100

Hi all,

I agree with all Colins comments, and I have further commented on
two of them, as well as providing some additional points below.

/L-E

> In section 3, the requirements list ECRTP without discussion. 
> I think ECRTP is an appropriate solution, but it would be
> useful to motivation the choice by discussing the requirements
> for the compression. This is particularly important, since
> there are alternative algorithms (e.g. ROHC) that may be
> considered.

I would really like to see such a discussion, or even better,
actually cover both ECRTP and ROHC. That should not make the
work much harder, it rather makes sense to do both at the same
time.

> In section 3, the draft notes that protocol extensions may be 
> required for ECRTP. Are these changes to ECRTP or a mapping
> of ECRTP onto a new "link" layer? If the latter, the draft
> could do with clarification.

I guess the latter is the case...

L-E.1:
Is really "Hop-by-hop ECRTP over MPLS" the correct title? I
think this is really about the opposite, i.e. HC over multiple
MPLS hops. I would suggest:
  "Requirements for Header Compression over MPLS",
as that would also cover both ECRTP and ROHC (then we can
decide later whether to cover ROHC or not) and we get rid of
the hop-by-hop confusion.

L-E.2:
The abstract is rather long, can we do something about that?
Since the details are in the intro, we can remove some, I think.

L-E.3:
The following text is confusing, and it is also an example where
I think my previous comment on "hop-by-hop" apply (section 2):
"More important in almost all locations is decreasing the
access bandwidth.  While hop-by-hop ECRTP over MPLS clearly
helps decrease bandwidth requirements, it also avoids
compression-decompression cycles at every router hop.  So
although bandwidth is getting cheaper, the value of compression
does not go away. In addition, IPv6 will increase the size of
headers and therefore increase the importance of header
compression for VoIP flows."

I do not know exactly what the above text wanted to say. The
argument that bandwidth cost is still important has been
addressed in the top of the section and could potentially be
summarized before starting the processing discussion), an
alternative text could be (end of current paragraph plus
2 new paragraphs to follow the current one):

  "So although bandwidth is getting cheaper, the value of
  compression does not go away.

  While hop-by-hop header compression could be applied to
  decrease bandwidth requirements, that would instead imply a
  processing requirement for compression-decompression cycles at
  every router hop. Therefore, end-to-end header compression over
  MPLS seems to be a viable alternative to get the compression
  benefits without introducing costly processing demands on
  intermediate nodes.

  It should further be noted that IPv6 will increase the size
  of headers, and therefore increase the importance of header
  compression for VoIP flows."

L-E.4:
The third paragraph of section 2 is also confusing. Is not 
the idea to use existing HC techniques along with MPLS
labels, in principle???

L-E.5:
Goal a in section 3 could explicitly say MPLS networks, i.e.
"a. provide more efficient voice transport over MPLS networks,"

L-E.6:
Goal c, should it not say "not significantly increase..."???

L-E.7:
The uppercase MUST, SHOULD, etc are not defined to have a
special meaning, so it is meaningless to use them if we do
not give them special meaning. Note that you have to define
their meaning yourself, you can not simply point at 2119, as
those definitions only apply to standards track document.
I would use lower case words.

L-E.8:
Requirement b could simply say "should use existing protocols,
such as ECRTP and/or ROHC,...."

L-E.9:
For requirement d, I would suggest "Should make use of..."

L-E.10:
The example scenario makes me even more convinced that
"hop by hop" is NOT the right terminology for what we are
aiming for, as it is rather the opposite, we want to avoid
hop-by-hop compression.

Overall, I agree with Colin that this is a significant 
improvement from the last document version. Good work!

BR
/L-E

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 15 Jan 2004 10:19:42 +0100

Ash and others,

Unfortunately, Magnus had sent me the draft and I assumed it was
the new official version, but I guess it was a pre-version. The
official one is again an improvement, so you can ignore my
comments L-E.1 and L-E.10 below, but I still believe it would make
sense to generalize ECRTP to "Header Compression", i.e. to include
ROHC in the scope.

Cheers,
/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 14 januari 2004 16:13
> To: 'Colin Perkins'; Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]
> Subject: RE: [AVT] RE: I-D
> ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.tx t
> 
> 
> Hi all,
>