RTP Payload Format for Generic Forward Error Correction
draft-ietf-avt-ulp-23

[Ballot comment]
The document lacks operational considerations information. The aspects that require clarification are the implications of the lack of backwards compatibility of the payload defined in this document with RFC 2733 and RFC 3009. A clarification was added in draft-22 about the fact that there are no interoperability issues, but yet there is no information or recommendations on the operational aspects of the transition between one version to the other. Do all hosts need to be upgraded simmultaneously if 2733 and 3009 are deployed, what will work and what will not work between two hosts that implement two different versions and is there a recommended strategy or scenarios of transition?

I would like to sort out the text to clarify Russ issue. Sam is going to send an email about text to type and few others and give them week to respond. I would like to fix Jon's comment - perhaps "Multimedia client" would work. Dan may propose some text. If we can call out to operators what happens with a client that does not understand this and is receiving multicast.

[Ballot comment]
In the MIME type registrations, especially in 13.3 (for text/ulpfec), it might be appropriate for the applicability section ("Applications which use this media type") to state something other than "Audio and video streaming tools" based on the MIME type being registered.

[Ballot comment]
In the MIME type registrations, especially in 13.3 (for text/ulpfec), it might be appropriate for the applicability section ("Applications which use this media type") to state something other than "Audio and video streaming tools" based on the MIME type being registered.

[Ballot discuss]
This is a discuss discuss.  Id like to understand how the registration
of a text subtype interacts with agreements between the MIME and RTP
communities about the use of text types in this instance.  I
understand that framed text types are supported, but it is my
understanding that the underlying content still needs to be something
that once extracted from the framing would be text-like.  That does
not seem to be true here.

[Ballot discuss]
The Security Considerations say:
  >
  > The integrity of the FEC packets can have a big impact on the
  > reconstruction operation. Changing some bits in the FEC payload can
  > have significant effect on the calculation and the correct recovery
  > of the payload packets. For example, change the length recovery
  > field can result in the recovery of a packet which is too long.
  > Also, the computational complexity of the recovery can be easily
  > effected for up to at least one order of magnitude.
  >
  This is confusing (at least to me).  I think of the FEC as an
  integrity protection mechanism.  Granted, it is not a keyed
  integrity protection mechanism.  So, this paragraph seems to
  advocate the use of an keyed integrity protection mechanism to
  protect the FEC.  Note that integrity protection mechanisms are
  often ignored because they do not obscure the protected data.
  This document points out that the FEC can be ignored for the
  same reason.

[Ballot discuss]
The document lacks operational considerations information. The aspects that require clarification are the implications of the lack of backwards compatibility of the payload defined in this document with RFC 2733 and RFC 3009. Do all hosts need to be upgraded simmultaneously if 2733 and 3009 are deployed, what will work and what will not work between two hosts that implement two different versions and is there a recommended strategy or scenarios of transition?

IANA Last Call Comments:


** IANA has Questions **

This document is obsleting RFC3009 which has references in
these registries.  What shall we do about the types defined in
RFC3009 and not mentioned in this document? 
Are they obsoleted, or remain?

------


Action #1:

Upon approval of this document, the IANA will make the
following assignments in the "Audio Media-Types" registry
located at

http://www.iana.org/assignments/media-types/audio/

Value REF
ulpfec [RFC-avt-ulp-21]




Action #2:

Upon approval of this document, the IANA will make the
following assignments in the "Vidio Media-Types" registry
located at

http://www.iana.org/assignments/media-types/vidio/

Value REF
ulpfec [RFC-avt-ulp-21]

Action #3:

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

Value REF
ulpfec [RFC-avt-ulp-21]


Action #4:

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

Value REF
ulpfec [RFC-avt-ulp-21]

We understand the above to be the only IANA Actions for this document.

This looks good and close to ready go.

The one question I had reading it, was it was not clear that it had captured the thing we agreed to about onelevel only. I think that is should be clear that when it used in offer/answer applications, if the application does not want to implement multiple levels, the application MAY implement only one level of protection and make sure that it always negotiates onelevelonly=1. If this text is in the document, my apologies for missing it - point me to the right place - if not, I think we might need to add a few sentences somewhere and I am happy to do that with an RFC Editor note if someone will propose one.

PROTO Write-up

(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?

I am the document shepherd. I have personally reviewed this draft,
and consider it ready for publication.

(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?

The document has had extensive review. I have no concerns about the
depth of breadth of review.

(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?

I have no concerns.

(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.

There is IPR that may be relevant to this document:

- https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=703
- https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=704
- https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=339

The licencing terms are unknown, which is clearly a concern.

(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?

The document considers the issue of parity FEC protection for RTP
packets. It is split into two main part: a bug fix for RFC 2733, and
an additional Unequal Layered Protection (ULP) mode extending the
mechanisms defined in RFC 2733. There is strong consensus that the
bug fix is necessary. There is only weak consensus regarding the ULP
additions, with some concern having been expressed that the
extensions are unnecessary and ineffective, and that the mechanisms
under development in 3GPP and the FECFRAME working group are to be
preferred.

(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
http://www.ietf.org/ID-Checklist.html 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?

Yes.

The idnits tool finds some non-RFC 3330 addresses in the draft, but
they are dynamically allocated multicast addresses, so I don't
believe this a concern.

The idnits tool claims (incorrectly) that reference [10] is not cited.

(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].

References have been split. Of the normative references, [4] is to an
internet draft, but that draft is currently in the RFC Editor queue.

(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 suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. 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?

The IANA considerations section exists, and contains four media type
registrations, consistent with the body of the specification, and the
existing media type registrations rules (both the generic rules, and
the additional RTP specific requirements).

(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?

There are no such sections.

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

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document specifies a payload format for generic Forward
Error Correction (FEC) for media data encapsulated in RTP. It is
based on the exclusive-or (parity) operation. The payload format
described in this draft allows end systems to apply protection
using various protection lengths and levels, in addition to
using various protection group sizes to adapt to different media
and channel characteristic. It enables complete recovery of the
protected packets or partial recovery of the critical parts of
the payload depending on the packet loss situation. This scheme
is completely compatible with non-FEC capable hosts, so the
receivers in a multicast group that do not implement FEC can
still work by simply ignoring the protection data. This
specification obsoletes RFC 2733 and RFC 3009. The FEC specified
in this document is not backward compatible with RFC 2733 and
RFC 3009.


Working Group Summary
Was there anything in WG process that is worth noting?
For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This document has been under discussion in the AVT working group
since the 48th IETF meeting, having been brought to AVT along with a
competing draft (draft-lnt-avt-uxp-00.txt) from the ITU-T SG16.
Considering their relative merits, AVT eventually decided to adopt
both drafts, this draft being simpler and conceptually backwards
compatible with RFC 2733, the UXP work being more complex (based on
Reed Solomon coding, rather than simple parity coding) but with
potentially better performance in some scenarios. Work on the UXP
draft was abandoned in 2004, and the ULP draft progressed to completion.

More recently, there has been some discussion of the merits of the
ULP work, compared to the schemes employed by 3GPP, and the ongoing
work in FECFRAME. We believe the FECFRAME proposals will likely form
the basis of future FEC work for RTP. Despite this, we believe it
necessary to publish the ULP draft all the same, since it contains an
important bug fix to RFC 2733, and since the layered extensions can
potentially offer improved performance in a manner that is
conceptually compatible with to RFC 2733.


Document Quality
Are there existing implementations of the protocol?
Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive
issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media
Type
review, on what date was the request posted?

Media type review on the -14 took place starting in December 2005,
with no objection (there have been no changes in the draft that would
change that consensus since then). Jonathan Rosenberg and Mark Watson
provided extensive last call comments and review.

Personnel
Who is the Document Shepherd for this document? Who is
the
Responsible Area Director?

Colin Perkins is the document shepherd. Cullen Jennings is the
responsible AD.

Expert Review from Jonathan Rosenberg


For audio streams, the bitstreams generated by many of the new audio
  codecs also contain data with different classes of importance. These
  different classes are then transmitted in order of descending
  importance. Applying more protection to the beginning of the packet
  would also be beneficial in these cases.

The motivation for audio here is weak. Can you reference specific audio
codecs for which this is true? It also seems like the value for audio is
significantly hampered since there are usually multiple frames per
packet. Thus, the protection would need to be scattered throughout the packet, not in the beginning. If there is really no applicability to audio it should state that.

Even for uniform-
  significance audio streams, special stretching techniques can be
  applied to the partially recovered audio data packets.

What is 'special stretching techniques'? This should be explained or discarded.

In cases
  where audio redundancy coding is used, more protection should be
  applied to the original data located in the first half of the
  packet. The rest of the packet containing the redundant copies of
  the data does not need the same level of protection.

Sure, redundancy coding is already a form of FEC. There is little incentive to layer yet another layer of FEC ontop of it. Thus, this use case seems like a stretch.

This approach has the advantage that media packets can be
  interpreted by receivers which do not support FEC. The overhead for
  using the FEC scheme is only present in FEC packets, and can be
  easily monitored and adjusted by tracking the amount of FEC in use.

This is true, but it doesn't mean that a sender can just send FEC packets without knowing if the receiver supports them. FEC needs to be negotiated through SDP just like any other media encoding. Consequently, each implementation still needs to support a mode where the other side knows about FEC, and a mode where it doesn't.

The packets of the two modes of FEC are distinguished by the
  Extension bit carried in-band in the FEC header. External signaling

This terminology - 'extension bit in the FEC header' - is very similar to the extension bit in the RTP header. I'd suggest using a different term from 'extension bit'.

Payload type: The payload type for the FEC packets is determined
  through dynamic, out-of-band means. According to RFC 3550 [1], RTP
  participants that cannot recognize a payload type must discard it.
  This provides backwards compatibility.

Yeah, but as above, its still going to be negotiated anyway.

The FEC mechanisms can then
  be used in a multicast group with mixed FEC-capable and FEC-
  incapable receivers, particularly when the FEC protection is sent as
  redundant encoding (see Section 14). In such cases, the FEC
  protection will have a payload type which is not recognized by the
  FEC-incapable receivers, and will thus be disregarded.

Ah, thats interesting. I think this backwards compatibility story is really just for multicast then. That should be clarified above.

  This header is 12 or 16 octets, depending on whether the long-mask
  flag (the L bit, see below) is set. The format of the header is
  shown in Figure 2 and consists of extension flag (E bit), long-mask

Figure 3 (Figure 3 is actually listed twice)

  a. A media packet SHALL be protected only once at each
        protection level higher than level 0. A media packet MAY be
        protected more than once at level 0 by different packets,
        providing the protection lengths of level 0 of these packets
        are equal.

I don't understand this rule. Certainly in the basic mode a packet can be protected by many FEC packets. Why does this change when unequal protection is applied?

  0                  1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Protection Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure 3: ULP Level Header Format (Level 0)

The reason for the different format for level 0 is never explicitly called out. Its because the other information that is needed - the mask in particular - is taken from the FEC header. I think this is somewhat confusing and non-intuitive. One would think that there would be a common FEC header with the SN-base and other data, followed by a header for each level, with the same format in each case. I'm not sure why this format was chosen, but its unintuitive.

In a related comment, the draft describes extended and basic modes as if they were radically different. But they're really not. Basic mode is identical to extended mode with one level (level 0), where the length is the length of the largest packet. Indeed, one could do away with basic mode entirely by specifying it that way. The cost would be the extra length field in each packet. Is that signficant? Doesn't seem so.

b. For a media packet to be protected at level p, it MUST also
        be protect at level p-1 in any FEC packets. Please note that
        the protection level p for a media packet can be in a FEC
        packet that is different from the one which contains
        protection level p-1 for the same media packet.

Hmm, I also don't understand this constraint. A MUST implies that something breaks if you don't follow it. But, clearly nothing breaks since FEC is optional generally speaking. The motivation here needs to be explained, or the requirement dropped.

    c. If an ULP FEC packet contains protection at level p, it MUST
        also contain protection at level p-1. Note that the
        combination of payload packets that are protected in level p
        may be different from those of level p-1.

I believe this constraint is because the level is never actually EXPLICITLy signaled. Rather, the level increases by 1 for each FEC header in the packet, starting at 0. That should be clearly stated.

For Protection Level n (n = 0, 1, ...), only Ln octets of data are
  set as the FEC Level n payload data after the Level n ULP header.
  The data is the Ln octets of data starting with the (Sn + 11)th
  octet in the FEC bit string, where:
  Sn = sum(Li : 0 <= i < n).

Ah, interesting. THis might explain why they require that, if a packet is protected at level n, its also protected at n-1. Without that, you would only be able to recover stripes of information. That may actually be OK; indeed per my comments above that might even be useful for audio codecs. In any case, this particular fact - that each level contains some number of bytes beyond the previous level - is not clearly called out in the overview. It needs to be.

  2.  For the FEC packet in T, compute the FEC bit string by
          concatenating the first 80 bits of the FEC header with the
          FEC payload.
      3.  If any of the protected bit strings generated from the media
          packets are shorter than the FEC bit string generated from
          the FEC packet, pad them to be the same length as the FEC bit
          string generated from the FEC. The padding of octet 0 MUST be
          added at the end of the protected bit string.
      4.  Calculate the recovery bit string as the bitwise exclusive OR
          of the protected bit string generated from all the media
          packets in T and the FEC bit string generated from all the
          FEC packets in T.

This text is inconsistent on whether there can be just one, or one or more FEC packets. I believe its more than one.

The recovery bit string of the current protection level as
          generated above is combined with the recovery bit string of
          all the other levels to form the (fully or partially)
          recovered media packet. Note that the recovery bit string of
          each protection level MUST be placed at the correct location
          in the recovered media packet for that level based on
          protection length settings.

You need to say how they are combined. It is through concatenation, I believe.


* Section 11 is really confusing on what the protocol ACTUALLY specifies. Its written more like a design discussion. Which approaches are in fact legal and supported?

15.1. FEC as a Separate Stream
  In the case discussed in this subsection, the FEC packets are sent
  as a separate stream. This means that they can be sent on a
  different port and/or multicast group from the media.
  Just like any media stream, the port number and the payload type
  number for the FEC stream is conveyed in its m line in the SDP.
  There is no static payload type assignment for FEC, so dynamic
  payload type numbers MUST be used. The binding to the number is
  indicated by an rtpmap attribute. The name used in this binding is
  "ulpfec". The address that the FEC stream is on is conveyed in its
  corresponding c line.
  The association relationship between the FEC stream and the payload
  stream it protects is conveyed through media line grouping in SDP
  (RFC 3388) [5] using FEC semantics (RFC yyyy) [6]. The FEC stream
  and the protected payload stream forms an FEC group.

I don't really understand why the FEC grouping spec is a separate specification. Typically the SDP mechanisms for a payload format are in the same draft as the payload format. I think its harder to read when they are separated, especially since there is such a detailed example of the grouping mechanism here.

The presence of two a=group lines in this SDP indicates that there
  are two FEC groups. The first FEC group, as indicated by the
  "a=group:FEC 1 2" line, consists of stream 1 (an audio stream using
  PCM) and stream 2 (the protecting FEC stream). T

Does this mean that the FEC stream is always the last stream? Does this mean that FEC groups can only ever have two RTP streams? I suspect this is specified in the other draft, but given the level of detail here it needs to be mentioned or else the drafts combined.

If the
  answerer accepts the usage of FEC, the answer simply accepts the FEC
  RTP session and the grouping in the offer by including them in the
  answer.

Hmm. That doesnt seem right. I don't think there is a requirement to actually use the same mids (in fact, I don't think you can require that) in the answer. So, I think what this is saying is that, the set of streams grouped together in an answer must match the set of streams grouped together in the offer, even if the mids differ. Or something like that. This requires more detailed spceification. Whether parameters are declared or negotiated via O/A is a constant source of confusion and needs to be very clear.

* Section 16 seems out of place. Much of it repeats the introduction, and the rest compares ULP with UXP. A reference to UXP is not even given, and I think the group isn't moving forward with it (though not 100% sure) so what is the point in the comparison?

* Sections 14 and 15 seem really similar, not clear why they are separate.

* Sections 14 and 15 should precede the IANA and security considerations sections - they are fundamental parts of the protocol spceification.

* Nothing in the document is said about RTCP. For example, can ULP be applied to recovery RTCP packets? Are the RTCP poackets in the FEC stream regular RTCP or recovery packets themselves? I believe that they are regular RTCP packets and there is no recovery of RTCP, but this should be stated.

* Per above the protocol is grossly underspecified for usage with SRTP, since the final mechanism is not described and there are no parameters defined for signaling what the order is for FEC and SRTP. This needs to be fixed.

* I don't think the mechanism is backwards compatible with the previous version of the specification; that should be called out

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

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

The draft has had adequate review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

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?

This updates an existing RFC produced by the working group,
correcting some minor problems with that RFC and adding new features.
There is strong consensus on the corrections, and reasonable
consensus on the new features (some have expressed the opinion that
the optional ULP extensions are correct but not particularly useful
given the constraints on the type of FEC code available).

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where
the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. There are normative references to
internet drafts that are in working group last call.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This document defines an RTP Payload Format for conveying generic
forward error correction (FEC) data for media streams, to obsolete
RFC 2733 and RFC 3009. The FEC data can be conveyed in band using RFC
2198 redundancy, or as a separate RTP stream. The draft corrects a
minor problem with RFC 2733, and adds the support for uneven level
protection, to provide improved FEC protection for some parts of the
data.

* Working Group Summary

The update to RFC 2733 went smoothly, and corrects a minor problem
discovered as a result of implementation experience. There was
considerable discussion to determine if uneven level protection based
on parity FEC based is useful for RTP, with the eventual rough
consensus being to include the feature. There is solid consensus on
the correctness of the specification.

* Protocol Quality

This draft updates RFC 2733, to correct problems discovered as a
result of implementation experience, and to add some new features.
The draft received extensive comments from Magnus Westerlund, Colin
Perkins, Michael Luby and Mark Watson, amongst others.

Sent some AD comments - ensure mmusic SDP FEC grouping LC at same time, please ask Mark Watson
for one more review.  Determined I'll ask for the ietf-types review since there's a text one...
Sending that today.