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.