Forward-Shifted RTP Redundancy Payload Support
draft-ietf-avt-forward-shifted-red-08

[Ballot comment]
Section 2

  The traditional backward-shifted
  redundant encoding scheme (i.e., redundant data is sent after the
  primary data), as currently supported by RFC 2198 [RFC2198], is known
  to be ineffective in dealing with such consecutive frame losses.

It would be useful to provide a reference for this statement.

[Ballot comment]
1. [no longer appropriate]

2. It is strange that Section 2.1 mentions the pros and cons of sending redundant data inband vs. out-of-band, but does not explain why this document chooses the inband approach.

3. [fixed in -07]

[Ballot discuss]
[updated 2011-06-10]

Taking over a DISCUSS from Alexey Melnikov...

1. It is not clear to me why this document is registering 2 new MIME types,
instead of just registering a new optional parameter "forwardshift" for the
already registered audio/red MIME type. Handling of these 2 new MIME types
without the "forwardshift" parameter seems to be identical to the handling of
audio/red.

2. [fixed in -07]

3. [fixed in -07]

[Ballot comment]
[1. no longer appropriate]

2. It is strange that Section 2.1 mentions the pros and cons of sending redundant data inband vs. out-of-band, but does not explain why this document chooses the inband approach.

3. In Section 3, the last paragraph states that (1) the sender MUST NOT change the contents of a packet and (2) if the sender violates the MUST NOT then the receiver behavior is undefined. Given that anything not specified in the document is by that very fact undefined, I think clause (2) is unnecessary.

[Ballot discuss]
[updated 2011-03-29]

Taking over a DISCUSS from Alexey...

1) It is not clear to me why this document is registering 2 new MIME types,
instead of just registering a new optional parameter "forwardshift" for the
already registered audio/red MIME type. Handling of these 2 new MIME types
without the "forwardshift" parameter seems to be identical to the handling of
audio/red.

2) audio/red is registered in RFC 3555, Section 4.1.21. The list of mandatory
and optional parameters in RFC 3555 is quite a bit longer, yet this document
claims that the MIME type is based on audio/red.

3) For the Security Considerations section in the MIME registration you might also
borrow some text from the Security Consideration of RFC 3555 (Section 5).

[Ballot discuss]
Taking over a DISCUSS from Alexey...

1) It is not clear to me why this document is registering 2 new MIME types,
instead of just registering a new optional parameter "forwardshift" for the
already registered audio/red MIME type. Handling of these 2 new MIME types
without the "forwardshift" parameter seems to be identical to the handling of
audio/red.

But even if you need to register a new MIME type, I advise against registering
the text/fwdred variant, as the payload is not textual.

2) audio/red is registered in RFC 3555, Section 4.1.21. The list of mandatory
and optional parameters in RFC 3555 is quite a bit longer, yet this document
claims that the MIME type is based on audio/red.

For the Security Considerations section in the MIME registration you might also
borrow some text from the Security Consideration of RFC 3555 (Section 5).

[Ballot comment]
This document establishes a second way to communicate the same information, but there is no indication
when this method should be used.  I wonder if this creates an interoperability problem.

Specifically, inclusion of the media type "fwdred" but omitting the optional parameter "forwardshift" indicates
that "the sender will have the same behaviors as defined in RFC 2198."  The document does not include any
rationale that indicates when this would be desirable.  The only difference I can see is that the receiver is aware
the sender understands forward shifting but did not choose to use it.  Given that this parameter is declarative
I do not see how this information is useful.  Why do we need this new mechanism and when should it be used?

[Ballot comment]
Section 2

  The traditional backward-shifted
  redundant encoding scheme (i.e., redundant data is sent after the
  primary data), as currently supported by RFC 2198 [RFC2198], is known
  to be ineffective in dealing with such consecutive frame losses.

It would be useful to provide a reference for this statement.

[Ballot discuss]
Building on Lars' Comment. If the Appendix is Informational then I am
confused by a paragraph in Section 2 that says...

  In contrast, the forward-shifted redundancy, when used in combination
  with the anti-shadow loss management at the receiver (as described in
  Appendix A), can effectively prevent service interruptions when a
  mobile receiver runs into such a shadow.

The placement of this paragraph implies that the primary use of the
forward-shifted mechanism defined in this document is to prevent service
interruptions when a receiver passes through a shadow. But, that use
seems to require Appendix A, which would mean that Appendix A is
normative and should be moved into the body of the document.

[Ballot comment]
1. I concur with Alexey's DISCUSS.

2. It is strange that Section 2.1 mentions the pros and cons of sending redundant data inband vs. out-of-band, but does not explain why this document chooses the inband approach.

3. In Section 3, the last paragraph states that (1) the sender MUST NOT change the contents of a packet and (2) if the sender violates the MUST NOT then the receiver behavior is undefined. Given that anything not specified in the document is by that very fact undefined, I think clause (2) is unnecessary.

[Ballot comment]
Section 3., paragraph 7:
>    Note, generally in a forward-shifted session, the timestamp offset in
>    the additional header SHOULD be set to '0'.

  When would it be valid and useful to not set it to zero?


Appendix A., paragraph 0:
> Appendix A.  Anti-shadow Loss Concealment Using Forward-shifted
>              Redundancy

  I assume this appendix is informational, i.e., not part of the
  normative specification. It may be useful to explicitly mark it as
  such.

[Ballot discuss]
This is a discuss-discuss.  To be clear, I am not asking for any change in the document at this time.  I will
either clear or make the discuss actionable after the telechat.

This document establishes a second way to communicate the same information, but there is no indication
when this method should be used.  I wonder if this creates an interoperability problem.

Specifically, inclusion of the media type "fwdred" but omitting the optional parameter "forwardshift" indicates
that "the sender will have the same behaviors as defined in RFC 2198."  The document does not include any
rationale that indicates when this would be desirable.  The only difference I can see is that the receiver is aware
the sender understands forward shifting but did not choose to use it.  Given that this parameter is declarative
I do not see how this information is useful.  Why do we need this new mechanism and when should it be used?

[Ballot discuss]
1) It is not clear to me why this document is registering 2 new MIME types, instead of just registering a new optional parameter "forwardshift" for the already registered audio/red MIME type. Handling of these 2 new MIME types without the "forwardshift" parameter seems to be identical to the handling of audio/red.

But even if you need to register a new MIME type, I advise against registering the text/fwdred variant, as the payload is not textual.

2) audio/red is registered in RFC 3555, Section 4.1.21. The list of mandatory and optional parameters in RFC 3555 is quite a bit longer, yet this document claims that the MIME type is based on audio/red.

For the Security Considerations section in the MIME registration you might also borrow some text from the Security Consideration of RFC 3555 (Section 5).

IANA questions/comments:

- you ask to register the text/fwdred media type, but nowhere in the
document do you actually define the usage for textual data. The
document focuses on audio data.

- the document talks about video data, but doesn't register a
video/fwdred media type. Do you want/need to register that?


Action 1:

Upon approval of this document, IANA will make the following assignment
in the "Audio Media Types" registry located at
http://www.iana.org/assignments/media-types/audio/

fwdred [RFC-avt-forward-shifted-red-05]


Action 2:

Upon approval of this document, IANA will make the following assignment
in the "Text Media Types" registry located at
http://www.iana.org/assignments/media-types/text/

fwdred [RFC-avt-forward-shifted-red-05]

1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Taylor is Document Shepherd. I have read this version and believe it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

I believe the document has had adequate review, although only four people have
commented on it over the course of its life. The scope is quite specific, so
that a broader review isn't really necessary.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No IPR declarations have been posted.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

It represents the concurrence of a few individuals with others being silent.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Idnits is satisfied. Media type review drew no response.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references are normative. No reference issues.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

All OK.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Two small SDP examples verified by inspection only.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document defines a simple enhancement to RFC 2198 to support RTP
sessions with forward-shifted redundant encodings, i.e., redundant
data sent before the corresponding primary data. Forward-shifted
redundancy can be used to conceal losses of a large number of
consecutive media frames (e.g., consecutive loss of seconds or even
tens of seconds of media).

Working Group Summary
The need for this work was questioned at the outset, but the arguments
advanced in its favour were sufficient to satisfy the people concerned.
As a result of its very specific scope, the work drew comments from
few people, but the Document Shepherd is satisfied that the reviews
were sufficient.

Document Quality
Colin Perkins bears special mention for his careful reviews at the
beginning and during Working Group Last Call. Media type review was
posted on January 4, 2010.