1 / 10

RTP Profile for RTCP-based Retransmission Request for Unicast session

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

rico
Télécharger la présentation

RTP Profile for RTCP-based Retransmission Request for Unicast session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. 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

  5. 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

  6. 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

  7. NACK Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=RTCP_NACK | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSN | BLP | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |

  8. 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

  9. 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

  10. 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

More Related