The IESG has approved the following document: - 'RTP Retransmission Payload Format ' <draft-ietf-avt-rtp-retransmission-12.txt> as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-12.txt Technical Summary This specification is used in combination with the extended RTP profile for RTCP-based feedback (referred to as RTP/AVPF) to provide a retransmission repair approach that RTP applications can use. RTP AVPF provides a general negative acknowledgement (NACK) capability to which these retransmissions apply. Working Group Summary The Working Group was quite concerned about encumberment of the protocol by IPR, but eventually determined that the technology was the right one to proceed with, in a consensus of the group. There are applications of this work. Protocol Quality Transport review removed the ACK (positive acknowledgement) from AVPF and from this protocol. Although some words in here lean toward supporting "reliable" streaming media, its tools, NACK and discrete loss measurement with RTCP, stay with the mission of loss repair, and the RTP design is not changed fundamentally. Congestion control has been given support through a receiver-based assessment of when requesting retransmission again is acceptable. There remain a few points left to implementation: in particular, the decision of when NACKs should be sent in a higher loss situation because the environment is assessed to have non-congestive loss. Because there is a pressing need for this NACK technology and no Internet technologies have a solution to this yet, there should be a future revision of the specification after experience with this aspect. Indeed it is hoped that all the algorithms' performance will be reviewed in the field, as is fitting for retransmission and congestion avoidance algorithms. Colin Perkins was the WG Chair shepherd. Allison Mankin was the Responsible Area Director. Notes to the RFC Editor Section 5.2 OLD: 5.2 CNAME use In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same CNAME for an original stream and its associated retransmission stream. NEW: 5.2 CNAME use In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same RTCP CNAME [3] for an original stream and its associated retransmission stream. [add the word RTCP] OLD: 10.2 Note that the retransmission framework is not intended as a complete solution to reliable multicast. Refer to RFC 2887 [10], for an overview of the problems related with reliable multicast transmission. NEW: 10.2 Note that the retransmission framework is offered only for for small multicast applications. Refer to RFC 2887 [10] for a discussion of the problems of NACK implosion, severe congestion caused by feedback traffic, in large group reliable multicast applications. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
