RTP Retransmission Payload Format
RFC 4588

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    avt mailing list <avt@ietf.org>, 
    avt chair <avt-chairs@tools.ietf.org>
Subject: Protocol Action: 'RTP Retransmission Payload Format' to 
         Proposed Standard 

The IESG has approved the following document:

- 'RTP Retransmission Payload Format '
   <draft-ietf-avt-rtp-retransmission-13.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-13.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.