Re: Last Call: Enhanced Compressed RTP (CRTP) for links with high delay, packet loss and reordering to Proposed Standard

["Ghyslain Pelletier (EAB)" <Ghyslain.Pelletier@epl.ericsson.se>]

I have reviewed draft-iet-avt-crtp-enhance-07.txt, and I have the
following comments to the IESG:

1) IPR section - needs to be extended
-------------------------------------
The IPR section needs to be extended with text D) from RFC2026 section
10.4.
See also http://www.ietf.org/ietf/IPR/ERICSSON-avt-crtp-enhance.txt.

2) Format of the document does not meet minimal requirements
------------------------------------------------------------
The document does not meet the minimal requirements in terms of format
and required sections, as described in: 

http://www.ietf.org/ietf/1id-guidelines.txt
http://www.ietf.org/ID-nits.html

In particular, the document has no headers or footers, which makes it
also difficult to refer to a specific page when commenting. In addition,
it is missing a table of contents - which it should have, based on the
length of the document.

3) What needs to be implemented for improved robustness is not clear
--------------------------------------------------------------------
When reviewing the document and focusing on separating the prescriptive
text from the descriptive text, it turns out that very little of the
contents of the eCRTP draft is actually normative from a standards point
of view. In short, the normative contents may be summarized as follow:

- the definition of the enhanced COMPRESSED_UDP format, the
  flags/sequence byte, which basically provides more flexibility than
  for CRTP, and this is more related to compression efficiency than to
  actual robustness of the algorithm;
- the definition and computation of HDRCKSUM
  (while its usage is only optional);
- the definiton of the C flag, to signal that HDRCKSUM has been
  inserted (which does not mandate anything from the decompressor OR
  decompressor perspective).

This might normally be considered as being enough - however, this
document specifically intends to make CRTP more robust and it is unclear
from the text what must really be implemented in order to achieve this
enhancement. I believe stricter logic and/or further clarifications are
needed to ensure that this document meets its objectives. This is my
main concern.

This also leads to the following interrogations regarding if the
normative content of the draft is sufficient in itself for implementers
to understand how to improve the robustness of CRTP:

3.1) Stricter decompressor and compressor logic for HDRCKSUM
------------------------------------------------------------
It is unclear how eCRTP needs to be implemented to achieve improved
robustness from CRTP. In particular, the following is defined as being
optional in the text:

- the compressor SHOULD use HDRCKSUM;
- if HDRCKSUM is used (via the C flag in the FULL_HEADER),
  the decompressor SHOULD validate each reconstructed packet;
- the value of N is left to implementations;

In addition, if eCRTP is expected to be used over links that may be
configured to deliver packets without checking for errors (as suggested
in the 5th paragraph of section 2.2), then I wonder if the compressor
should not always be mandated to use HDRCKSUM for IPv4 when the UDP
checksum is disabled? Also, I think that whenever HDRCKSUM is used, the
decompressor should be mandated to always validate the decompressed
header (i.e. should it not be a MUST instead of a SHOULD in section 2.2
regarding the decompressor actions?).

3.2) Clarifications on the implications of paramater N are needed
-----------------------------------------------------------------
ECRTP claims to improve the robustness of CRTP by using N repetitions
and absolute values for selected fields (thus by lowering the overall
compression efficiency). I think it would be very useful to explicitely
state in section 2.3 that the parameter N represents a tradeoff between
robustness and compression efficiency. This would be helpful for
implementers to better understand the implementation choices that must
be made when compressing headers over links with high packet losses and
residual BER.


The IESG wrote:
> 
> The IESG has received a request from the Audio/Video Transport Working
> Group to consider Enhanced Compressed RTP (CRTP) for links with high
> delay, packet loss and reordering <draft-ietf-avt-crtp-enhance-07.txt>
> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-19.
> 
> Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-07.txt

Ghyslain Pelletier
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Luleå, Sweden
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 70 609 27 73