Request to review type in draft-ietf-fecframe-interleaved-fec-scheme
Hi, This document http://www.ietf.org/id/draft-ietf-fecframe-interleaved-fec-scheme-06.txt has been through an IETF last call. Unfortunately this hasn't been announced on this list either in WG last call or when the IETF last call started. Thus I would like a review before bringing this to the IESG. I would be thankful if the review could happen before the 7th of January. However, if a committed reviewer needs additional time due to the holidays that can be granted. But please tell me so that I can postpone the IESG review. Here is the media type template for the 4 types present in this document. 5.1. Media Type Registration This registration is done using the template defined in [RFC4288] and following the guidance provided in [RFC3555]. Note to the RFC Editor: In the following sections, please replace "XXXX" with the number of this document prior to publication as an RFC. 5.1.1. Registration of audio/1d-interleaved-parityfec Type name: audio Subtype name: 1d-interleaved-parityfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Begen Expires June 18, 2010 [Page 15] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. 5.1.2. Registration of video/1d-interleaved-parityfec Type name: video Subtype name: 1d-interleaved-parityfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not Begen Expires June 18, 2010 [Page 16] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. 5.1.3. Registration of text/1d-interleaved-parityfec Type name: text Subtype name: 1d-interleaved-parityfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. Begen Expires June 18, 2010 [Page 17] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. 5.1.4. Registration of application/1d-interleaved-parityfec Type name: application Begen Expires June 18, 2010 [Page 18] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 Subtype name: 1d-interleaved-parityfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport Working Group. Intended usage: COMMON. Begen Expires June 18, 2010 [Page 19] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. Thanks Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
* Magnus Westerlund wrote:
This document http://www.ietf.org/id/draft-ietf-fecframe-interleaved-fec-scheme-06.txt has been through an IETF last call. Unfortunately this hasn't been announced on this list either in WG last call or when the IETF last call started. Thus I would like a review before bringing this to the IESG. I would be thankful if the review could happen before the 7th of January. However, if a committed reviewer needs additional time due to the holidays that can be granted. But please tell me so that I can postpone the IESG review.
Here is the media type template for the 4 types present in this document.
I think it's confusing to re-iterate the same text in each template; the templates in RFCs are not used out of context, later templates should just reference the first one. I could not immediately find a rationale for registering the same sub type under 4 different top level types. It would be helpful if someone could post one to this list, and it should be added in the introductory section 5.1.
Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
I am not sure from this what the syntax is, the text makes it sound like rate="1001 Hz" might be it. Perhaps something like "The RTP time- stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to make it clearer. Alternatively "an integer ..." like some of the other parameters say.
o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds.
Here the syntax definition is also just "time".
Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media.
That's perhaps a bit too promotional and unspecific.
Additional information: None.
(I note that it is common for RTP-only types to omit this section.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Hi Bjoern, Many thanks for the review. I expect the author to comment also. I will respond due to my reasonable good familiarity with these issues as ex-AVT chair. Bjoern Hoehrmann skrev:
* Magnus Westerlund wrote:
This document http://www.ietf.org/id/draft-ietf-fecframe-interleaved-fec-scheme-06.txt has been through an IETF last call. Unfortunately this hasn't been announced on this list either in WG last call or when the IETF last call started. Thus I would like a review before bringing this to the IESG. I would be thankful if the review could happen before the 7th of January. However, if a committed reviewer needs additional time due to the holidays that can be granted. But please tell me so that I can postpone the IESG review.
Here is the media type template for the 4 types present in this document.
I think it's confusing to re-iterate the same text in each template; the templates in RFCs are not used out of context, later templates should just reference the first one. I could not immediately find a rationale for registering the same sub type under 4 different top level types. It would be helpful if someone could post one to this list, and it should be added in the introductory section 5.1.
I think that is an instruction that can be forwarded to AVT. However, I do hope that people on this list do agree The rational for registering this in the 4 top level types is that it needs to be possible to combine this FEC RTP payload format with media carrying RTP payload formats. As the media carrying RTP payload formats have any of the 4 top-level types and only one top-level media type is allowed in an RTP session. Thus the need to register this payload format in all the top-level types that is used by other RTP payload formats.
Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
I am not sure from this what the syntax is, the text makes it sound like rate="1001 Hz" might be it. Perhaps something like "The RTP time- stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to make it clearer. Alternatively "an integer ..." like some of the other parameters say.
Yes, I would agree, because the value is just the integer "rate=1001".
o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds.
Here the syntax definition is also just "time".
Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media.
That's perhaps a bit too promotional and unspecific.
Additional information: None.
(I note that it is common for RTP-only types to omit this section.)
Well, the RTP payload format specifies what you need and you are in a context that is much more bound then mail and HTTP. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
participants (2)
-
Bjoern Hoehrmann -
Magnus Westerlund