Tunneling Multiplexed Compressed RTP (TCRTP)
draft-ietf-avt-tcrtp-08

[Ballot comment]
It seems likely to me that using ECRTP, L2TP and PPP-MUX together, as described in this document might be useful.  However, this document seems to be more of an applicability document than a protocol itself.  The way the document is structured, and the fact that it talks about TCRTP as a protocol was quite confusing to me -- I kept looking for the protocol that is being defined here, but I eventually came to the conclusion that there really isn't one.  Am I correct?

This document uses the acronyms CRTP and  ROHC without defining them.  It then seems to use the terms "ECRTP" and "CRTP" interchangeably in a way that is confusing to me.  For instance, the section "1.4 Enhanced CRTP" discusses CRTP and ROHC, not (apparently) ECRTP.  I am not sure why ROHC doesn't have its own section (and the indenting seems to indicate that something might have gone wrong in the production of the document).  I am also not sure why details about why a particular path was not chosen are included in the overview section.

Section 2.1 talks about models for how TRCTP could be "implemented" (although it really seems to describe use cases), but as far as I can tell, the document has not yet described what TRCTP is, other than to say that it combines three other mechanisms.

Section 2.2 indicates that the tunneling links described in this document will be "long delay".  Why is this the case?  L2TP tunnels are not all, inherently, long delay...  Are the authors refering to the WAN links that they talked about in the first section?  Is that the primary situation in which TRCTP is applicable?

[Ballot comment]
Missing IPR statements:
$ idnits <drafts/draft-ietf-avt-tcrtp-07.txt
idnits 1.26, (21 Apr 2004)

The document seems to use RFC 2026 boilerplate...
The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer
-- however, there's a paragraph with a matching beginning. Boilerplate error?

Warnings:
  The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer
  The document seems to lack an RFC 2026 Section 10.4(B) IPR Disclosure
    Invitation

[Ballot discuss]
I am not sure if this is worthy of a "discuss" or not, but since there are no open discusses on the document, I'll hold one for now so that I'm sure we'll have a chance to talk about this.

It seems likely to me that using ECRTP, L2TP and PPP-MUX together, as described in this document might be useful.  However, this document seems to be more of an applicability document than a protocol itself.  The way the document is structured, and the fact that it talks about TCRTP as a protocol was quite confusing to me -- I kept looking for the protocol that is being defined here, but I eventually came to the conclusion that there really isn't one.  Am I correct?

This document uses the acronyms CRTP and  ROHC without defining them.  It then seems to use the terms "ECRTP" and "CRTP" interchangeably in a way that is confusing to me.  For instance, the section "1.4 Enhanced CRTP" discusses CRTP and ROHC, not (apparently) ECRTP.  I am not sure why ROHC doesn't have its own section (and the indenting seems to indicate that something might have gone wrong in the production of the document).  I am also not sure why details about why a particular path was not chosen are included in the overview section.

Section 2.1 talks about models for how TRCTP could be "implemented" (although it really seems to describe use cases), but as far as I can tell, the document has not yet described what TRCTP is, other than to say that it combines three other mechanisms.

Section 2.2 indicates that the tunneling links described in this document will be "long delay".  Why is this the case?  L2TP tunnels are not all, inherently, long delay...  Are the authors refering to the WAN links that they talked about in the first section?  Is that the primary situation in which TRCTP is applicable?

[Ballot discuss]
I am not sure if this is worthy of a "discuss" or not, but since there are no open discusses on the document, I'll hold one for now so that I'm sure we'll have a chance to talk about this.

It seems likely to me that using ECRTP, L2TP and PPP-MUX together, as described in this document might be useful.  However, this document seems to be more of an applicability document than a protocol itself.  The way the document is structured, and the fact that it talks about TCRTP as a protocol was quite confusing to me -- I kept looking for the protocol that is being defined here, but I eventually came to the conclusion that there really isn't one.  Am I correct?

This document uses the acronyms CRTP and  ROHC without defining them.  It then seems to use the terms "ECRTP" and "CRTP" interchangeably in a way that is confusing to me.  For instance, the section "1.4 Enhanced CRTP" discusses CRTP and ROHC, not (apparently) ECRTP.  I am not sure why ROHC doesn't have its own section (and the indenting seems to indicate that something might have gone wrong in the production of the document).  I am also not sure why details about why a particular path was not chosen are included in the overview section.

Section 2.1 talks about models for how TRCTP could be implemented, but as far as I can tell, the document has not yet described what TRCTP is, other than to say that it combines three other mechanisms.

Section 2.2 indicates that the tunneling links described in this document will be "long delay".  Why is this the case?  Are the authors refering to the WAN links that they talked about in the first section?  Is that the primary situation in which TRCTP is applicable?

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART.

His review:

This seems mainly OK, but...

> 2.4.2. Tunneling and DiffServ
>   
>  RTP streams may be marked with Expedited Forwarding (EF) bits, as
>  described in [EF-PHB].  When such a packet is tunneled, the tunnel
>  header must also be marked for the same EF bits, as required by [EF-
>  PHB].  It is important to not mix EF and non-EF traffic in the same
>  EF-marked multiplexed tunnel.

Two problems in this. Firstly, the RFC cited is 2598, but that was
obsoleted by 3246. Secondly, 3246 has a normative "SHOULD" where the above
paragraph has a lower-case "must." If the present draft wants to strengthen
the requirement, it should use a normative "MUST" and cite RFC 2119.

There is heavy normative dependency on the following expired reference:

>  [RFCXXXX] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy,
>        "Compressing IP/UDP/RTP headers on links with high delay, packet
>        loss, and reordering", draft-ietf-avt-crtp-enhance-05.txt,
>        November 2002.

With a bit of hard work I discovered that this ended life as -07
and is now RFC 3545, but I really think draft authors should deal with
these things before sending a draft to the IESG.

I hope these two pieces of carelessness are not statistically significant
for the document as a whole.

[Ballot comment]
In section 2.2.2, what does "the ECRTP decompressor must operate correctly in the presence of out of order packets" mean?  This is vague.  Per an offline discussion with Allison, I would suggest adding this text that Allison shared with me:

"The order of packets for RTP is determined by the RTP sequence number.  ECRTP does not compress it out the way ROHC does.  Instead, ECRTP sends short deltas from the RTP seqno, and sends a full value every N packets, where N is an engineered constant tuned to the kind of pipe ECRTP is used for."

[Ballot comment]
In the Abstract, this statement:

  Those other methods may be more appropriate as
  proprietary protocols rather than standards.

seems odd and inappropriate.  If there are methods that are highly optimized for specific environments,
then those may be adopted for those environments, whithout regard to their being "proprietary".  It
seems like it would be more appropriate to say this is "BCP" for the overall context; other methods
may be better optimized for specific contexts, and leave it at that.

This also struck me:

1.3. Document Focus

  This document is primarily concerned with bandwidth savings for Voice
  over IP (VoIP) applications.  However, the combinations of protocols
  described in this document can be used to provide similar bandwidth
  savings for other RTP applications such as video.

The document doesn't actually seem to consider video (there is no
video Bandwidth calculation example, to take one element, nor
any recommended value for T).  Given that this is meant to be  a BCP,
I am uncomfortable with including anything that says "similar bandwidth
savings" without any demonstration.  It would also be useful for
the document to describe whether the authors feel you could
mux voice and video togethe and achieve reasonable results or whether
this is a subject for further study.

[Ballot comment]
In the Abstract, this statement:

  Those other methods may be more appropriate as
  proprietary protocols rather than standards.

seems odd and inappropriate.  If there are methods that are highly optimized for specific environments,
then those may be adopted for those environments, whithout regard to their being "proprietary".  It
seems like it would be more appropriate to say this is "BCP" for the overall context; other methods
may be better optimized for specific contexts, and leave it at that.

[Note]: 'This slipped through the cracks because it looked like it would slow down ECRTP - need to LC it now.' has been cleared by Allison Mankin

State Changes to Pre AD Evaluation                                from Requested                                        by Allison Mankin