A RTCP-based Retransmission Protocol for Unicast RTP Streaming Multimedia draft-podolsky-avt-rtprx-00.txt Matthew Podolsky, Koichi Yano, and Steven McCanne U.C. Berkeley IETF, Audio/Video Transport Working Group November 1999

Outline Motivation Details Issues for feedback and discussion

Motivation People are already doing retransmissions of unicast RTP 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

Why Unicast? Already being used –Deployment now is practical Simplicity: multicast presents more issues –Scalability How to suppress requests How to limit the scope of multicast –Real Time Want to get retransmission ASAP

Proposed Format New RTCP packet type: RTCP_MACK –Backwards compatible (can just be ignored) Receiver can NACK an RTP sequence number and 16 surrounding sequence numbers Flexible –Draft specifies basic framework for request –Framework can be modified and/or extended through RX protocol subtype Eliminate current limitations on minimum time between RTCP feedback

Header Format RXP = Retransmission Protocol FSN = Frame Sequence Number BLP = Bit Loss Pattern (default: next 16 frames) |V=2|P| RXP | PT=RTCP_MACK | length | | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | protocol-specific extensions | |.... |

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

Issues for Discussion Focus on unicast or generalize to multicast? Include the SSRC? –Necessary for multicast –Group NACKs from multiple RTP sessions in single request Protocol subtype (RXP) vs. options –Desired point for multiplexing –Negotiate through dynamic RTP payload type? –Future revisions should fix a subset of protocols/behaviors

Issues for Discussion (cont.) Bit mask: cover preceding or succeeding packets? Security –Spam receivers by sending bogus NACKs