RTP Profile for RTCP-based Retransmission Request for Unicast session Koichi Yano (Canon) Matthew Podolsky, and Steven McCanne (U.C. Berkeley) (FastForward Networks) IETF, Audio/Video Transport Working Group March 2000 draft-podolsky-avt-rtprx-01.txt

Outline Changes from the former draft A new profile –RTCP interval –NACK packet format Issues for discussion

Motivation People are already doing retransmissions of unicast real-time streams (e.g. RealNetworks, MS) No existing standard –Incompatible implementations Standardizing retransmission format would allow: –Code re-use (open source) –Interoperability between clients and servers Restricted for unicast streams –Simplicity & practical deployment Incremental deployment –No change of RTP (payload) packet format

Changes from the first draft Pose as a new profile Include SSRC in NACK Simplified: only for NACK –The former draft defined Multi-purpose ACK –NACK is enough for most purposes Exclude RX-proto type or a flag field –Simplicity –Ease of implementation

A New Profile Define a new profile, RTP/RX, which inherits all of AVP profile, except –RTCP interval Allows for immediate NACK –New RTCP type for NACK First sequence number and 16-bit bitmask Include SSRC

RTCP Report Interval Propose eliminating minimum interval between RTCPs –Still keep a maximum average BW limit (5%) –Recommend use of a token bucket Motivated by performance – timely retransmissions Bandwidth should be fine for unicast

NACK Format |V=2|P| RC | PT=RTCP_NACK | length | | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 | | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 | | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |

Issues for Discussion Simple but enough? Congestion Control –NACK is useful enough for Congestion Control? –Should the deployment be stated in the draft? Receiver Report –How to calculate lost fraction? Only original data transmission or including retransmission After recovery (to know goodput) –Should we extend RR? # of sent NACKs # of recovered packets # of duplicate packets

Issues for Discussion (cont.) FSN and following bitmask or LSN and preceding bitmask? –FSN can be used for watermark of received (given up) packets? But open ended problem –LSN can be deployed for congestion control thru telling receiving edge? –Maybe FSN (or LSN) should not mean a lost packet Security –Denial of service through bogus NACKs Multicast –NACK packet format is deployable for multicast

Next Step Is there consensus to adopt this as a task item? More description relating to SDP, RSTP More description of sender and receiver’s recommended behavior –Sender should send retransmission immediately after NACK reception –Receiver should measure average response time –Set timer after NACK –Resend NACK Implementation