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

["Leon David (NRC/Dallas)" <[e-mail]>]

Hello,


Please find answers to your comments below.

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

First of all, there are some significant changes between your new draft
and its earlier version. Your earlier draft was requiring sending
retransmission packets and original packets in the same RTP stream. Your
earlier payload format could not support sending the retransmission in a
separate stream. You were encoding the retransmitted SN as a delta to
the RTP SN which does not work if packets are sent in a separate stream.
So you did not just include an example how to use your payload format to
send retransmission in a separate stream but changed your draft (payload
format and rules how to use the payload format) in order to incorporate
our scheme.

So your new scheme uses two retransmission 'modes':
-retransmission and original packets in the same stream as you were
proposing in your earlier draft. 
-retransmission and original packets in separate stream as described in
our original and updated draft.
 
Defining multiple modes of operations to resolve the same problem is
generally not a good design.

>
> 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 assumed that since you've added our mode to your scheme, you agree
that this mode is necessary. So the question is whether we should use an
additional mode (sending RTP packets and retransmitted packets in the
same stream). As I have written in the summary sent to he mailing list,
there are several problems with this mode. 

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

So you're saying that although retransmitting in a separate stream may
cause problems, there are many reasons why it should be done. Could you
please tell what the reasons you're thinking of are?

>Detetion of lost packets
> can be purely
> based on the sequence number, which is much faster and less
> complicated than
> using timers.

This statement may confuse someone who is not very familiar with the
drafts. So let me clarify that of course lost packets are detected
simply looking at a missing SN. No timers are needed. 
I guess your point is here how to  detect a retransmission attempt did
not work. 
You will find below a comparison on how the two schemes can cope with
failed retransmissions.


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

So let's look into more detail at the issues when a retransmission
packet is lost.
 
With our scheme, when the receiver requests a packet, it sets a timer
which will timeout when the retransmission did not succceed. The timer
is basically dependent on the round-trip time. If the receiver estimates
there is time to send a second request, it may then rerequest the
packet. This is very simple as this is the only thing you need to
implement at the sender and the receiver.
 
On the other hand, with your scheme you don't wait for a timeout and
send a request as soon as you detect a missing SN. There is a
fundamental problem with this approach.  Let us assume that a
retransmitted packet is sent and lost. The receiver detects a missing
sequence number since the retransmission packet is sent in the same
stream as the data. However, the receiver does not know that this
missing packet is a retransmitted packet. The receiver estimates from
consecutive packets (which are themselves original packets) the TS of
the missing packet and thinks it has time to perform retransmission.
However, since the missing  packet is a retransmission packet, the TS
estimate is much less than the real TS. The receiver will think it has
time to retransmit a packet and send a retransmission packet. The sender
retransmits this packet once more. When the packet gets to the receiver,
it is too late to be used and it is just discarded. Hence, you waste
bandwidth retransmitting packets which can not be used. 
 
In addition, you also need to use timers in your scheme because a
retransmission may failed either because the retransmitted packet was
lost or the retransmission request was lost. You won't be able to detect
the latter if you don't use timers.
 
Besides,  your scheme also increases the overhead needed to retransmit a
packet multiple times. If you retransmit twice the same packet, you use
two retransmission headers in the same packet. If you use retransmit
three times,  you use three retransmission headers in the same packet,
etc....

 
Regards,
David.
 
>
> 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
> 

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