[AVT] RTP Retransmissions (was: RE: [AVT] Draft AVT agenda)

[Carsten Burmeister <[e-mail]>]

Dear All,

we have some comments on the RTP retransmission framework draft
(leon-draft), presented below. As you know there is an AVT draft about
retransmissions as well. The AVT draft has the same functionality as this
framework, especially sending the retransmissions on a different stream is
possible. Ispired by the comments of and discussions with David Leon and
Viktor Varsa, we included a new example in our draft how the payload formats
can be used to form a retransmission scheme, where the retransmissions are
sent in a different stream.

The leon-draft is in that way much more limiting. In this draft,
retransmissions MUST be sent in a different RTP session, with a different
sequence number space. Hence the main difference between the drafts is the
fact whether it should explicitly be forbidden to do the retransmissions in
the same stream.

I think that there are too many different applications and environments,
where retransmissions in RTP could enhance the performance by far, for one
retransmission scheme. Therefore we proposed the two payload formats of the
AVT draft, with which it is possible to design several schemes. I agree that
there *might* be applications that cannot cope with the retransmissions
being sent in the same stream as the original packets. (However note that
backwards compatibility is not an issue, because RTP receivers must discard
packets with unknown payload types.) But I also see many applications in
different environments that could benefit from sending the retransmissions
in the same sequence number space. Detetion of lost packets can be purely
based on the sequence number, which is much faster and less complicated than
using timers.

So for me the question arises, if there is any reason to forbid sending the
retransmissions in the same stream. If an application (e.g. using the RTP
conversational text) really has problems with this, it can send the
retransmissions on a different stream. The AVT draft allows that as well.
And as said before, I could think of several applications (e.g. MPEG-4,
RFC3016) and environemnts (e.g. mobile environment with bit errors on the
link, long RTT, limited bandwidth) where we can gain great performance
enhancements, if we detect the loss of a retransmission at once!.

Any comments?

Best Regards,
  Carsten


> Hello,
>
> We are planning to present an updated draft on the RTP retransmission
> framewrok.
> http://search.ietf.org/internet-drafts/draft-leon-rtp-retransm
> ission-01.
> txt
>
> We have modified the draft in order to address the comments
> received at
> the WG meeting as follows:
>
> *The retransmission packet payload format has been modified to better
> use RTP semantics.
>
> *Associating retransmission stream and SSRC:
> Retransmissions are required to be sent to a different multicast group
> from the original data. The original stream and the retransmission
> stream should have the same SSRC
>
> *Why not use the same SSRC and send to the same multicast group with a
> different PT?
> Original packets and retransmission packets would then have
> to share the
> same SN space. We think this would have several drawbacks:
> If packet loss has not been recovered, a receiver does not know if the
> missing packets are retransmitted packets or new data. This has
> drawbacks. For example, RTP conversational text (RFC 2793)
> uses missing
> sequence numbers to indicate missing text location to the user. This
> could not  be done reliably any longer.
> A receiver should estimate the TS of a missing packet before
> requesting
> its retransmission in order to determine if the packet if
> retransmitted
> could be received before its playout time. Depending on whether the
> missing packet contains first time sent data or retransmission data
> (which the receiver would not know if these two types of packets were
> found in the same stream) the TS may vary significantly and its
> estimation may be wrong.
> Besides, RTCP jitter value would become meaningless.
>
> *The same can be achieved with existing RLM and FEC techniques
> The FEC payload format may be used as an alternative to the
> retransmission format. However, we think it should be possible to use
> retransmission without having to implement FEC. It therefore
> makes sense
> to define a simple retransmission payload format.  Moreover we are not
> only defining the payload format but also protocol rules to perform
> retransmission.
>
> We are also planning to show performance evaluation results.
>
>
> David.
>
> > -----Original Message-----
> > From: ext Colin Perkins [mailto:[e-mail]]
> > Sent: Monday, December 03, 2001 12:29 AM
> > To: [e-mail]
> > Subject: [AVT] Draft AVT agenda
> >
> >
> > Folks,
> >
> > Enclosed is the draft agenda for the AVT working group
> > meeting at the Salt
> > Lake City IETF. Please send comments and corrections to the
> > working group
> > chairs, by Tuesday 4th December.
> >
> > Those who have agenda time scheduled are requested to prepare
> > a summary of
> > the issues they wish to discuss, and to send this to the
> > mailing list ahead
> > of the meeting. This gives folks that won't be attending the
> > opportunity to
> > post their comments and concerns, and potentially even reach
> > some consensus,
> > before the meeting time is consumed. It also gives other
> > participants the
> > opportunity to consider the issue in more depth. Summary
> > messages should be
> > sent to the mailing list by Tuesday 4th December.
> >
> > We also request that all presenters send us their slides
> > ahead of time. This
> > has multiple purposes:
> >
> >   - It streamlines the presentation process by having the
> > presentations on
> >     a single laptop.
> >
> >   - It avoids the delay that sometimes occurs in getting the
> > presentations
> >     sent to us after the meeting, for inclusion in the minutes.
> >
> >   - It allows us to preview the presentations to see if they
> > are following
> >     the guidelines for what should be covered during the meeting.
> >
> > Those presenting new drafts: briefly describe the basic
> > problem and your
> > proposed solution, discuss known issues, limitations and
> > problems, outline
> > where you want input from the working group, and how you wish
> > us to proceed.
> > When presenting work which has been previously discussed:
> > describe only the
> > changes from the previous draft, highlight unresolved
> > problems, and propose
> > future directions. Presenters are reminded of the
> > requirements for disclosure
> > of intellectual property relating to contributions, in
> > section 10 of RFC 2026.
> >
> > Agenda time is conditional on sending both a summary of open
> > issues and a
> > copy of your slides ahead of the meeting.
> >
> > We strongly encourage all participants to read all relevent
> > drafts before
> > the meeting, and to comment on the open issues raised on the
> > mailing list.
> >
> > Thanks for your assistance to try to conduct an effective meeting.
> >
> > Colin & Steve
> >
> >
> >
> > ==============================================================
> > =================
> > Audio/Video Transport WG (AVT)
> >
> > Monday, December 10 at 1930-2200
> > Wednesday, December 12 at 0900-1130
> > ===================================
> >
> > CHAIRS: Steve Casner <[e-mail]>
> >         Colin Perkins <[e-mail]>
> >
> > AGENDA:
> >
> > Session 1:
> >
> > - Introduction and status (Casner/Perkins)
> > 	10
> > 	Published or with RFC editor:
> > 		RFC 3158
> > 		draft-ietf-avt-dv-audio-04.txt
> > 		draft-ietf-avt-dv-video-04.txt
> > 	Under revision after IESG review:
> > 		draft-ietf-avt-rtp-amr-10.txt
> > 	Last call:
> > 		draft-ietf-avt-crtp-enhance-03.txt
> > 		draft-ietf-avt-tcrtp-04.txt
> > 		draft-ietf-avt-uxp-01.txt
> > 		draft-ietf-avt-ulp-02.txt
> > 		draft-ietf-avt-rtp-cn-04.txt
> >
> > - RTP Payload formats for MPEG-4
> > 	draft-ietf-avt-mpeg4-multiSL-02.txt
> > (Gentric)	10
> > 	draft-ietf-avt-mpeg4-simple-00.txt		(van
> > der Meer)	10
> > 	draft-curet-avt-rtp-mpeg4-flexmux-01.txt 	(Roux)
> > 	10
> >
> > - RTP payload format for GSM EFR speech
> > (Barany)	15
> > 	draft-barany-avt-efr-00.txt
> > 	draft-ietf-avt-profile-new-12.txt section 4.5.9
> >
> > - RTP Payload Format for EVRC, SMV and Frame-Based Vocoders
> > (Li)	15
> > 	draft-li-avt-vocoder-00.txt
> >
> > - RTP Payload Format for AC-3 Streams
> > (Flaks)		15
> > 	draft-flaks-avt-rtp-ac3-00.txt
> >
> > - MWPP: A resilient MIDI RTP packetization
> > (Lazzaro)	15
> > 	draft-lazzaro-avt-mwpp-midi-nmp-00.txt
> >
> > - RTP Payload Format for Distributed Speech Recognition
> > (Xie)		15
> > 	draft-ietf-avt-dsr-00.txt
> >
> >
> >
> > Session 2:
> >
> > - RTP payload format for JPEG 2000 video streams
> > (Edwards)	15
> > 	draft-edwards-avt-rtp-jpeg2000-00.txt
> >
> > - Update to RTP specification and profile
> > (Casner)	15
> > 	draft-ietf-avt-rtp-new-11.txt, .ps
> > 	draft-ietf-avt-profile-new-12.txt, .ps
> > 	draft-ietf-avt-rtp-mime-06.txt
> > 	draft-ietf-avt-rtcp-bw-05.txt
> >
> > - Secure RTP profile
> > (Carrara)	15
> > 	draft-ietf-avt-srtp-02.txt
> >
> > - RTP extensions for classification and priority
> > 	draft-carlberg-rtp-classifier-extension-00.txt
> > (Carlberg)	 5
> > 	draft-polk-avt-rtpext-res-pri-00.txt		(Polk)
> > 	 5
> > 	Discussion
> > 	10
> >
> > - Extended RTP Profile for RTCP-based Feedback
> > (Ott)		15
> > 	draft-ietf-avt-rtcp-feedback-01.txt
> > 	draft-burmeister-avt-rtcp-feedback-sim-00.txt
> >
> > - RTP retransmission
> > 	draft-leon-retransmission-01.txt		(Leon)
> > 	15
> > 	draft-ietf-avt-rtp-selret-03.txt
> >
> > - RTCP Extension for SSM Sessions with Unicast feedback
> > (Chesterfield)	15
> > 	draft-chesterfield-avt-rtcpssm-02.txt
> >
> > - Extending RTCP for call quality metrics
> > (Massad)	 5
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/avt
> >
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
http://www1.ietf.org/mailman/listinfo/avt