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

From: "Leon David (NRC/Dallas)" <[email-masked]>
Date: Thu, 6 Dec 2001 11:24:03 -0600

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:[email-masked]]
> > > Sent: Monday, December 03, 2001 12:29 AM
> > > To: [email-masked]
> > > 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 <[email-masked]>
> > >         Colin Perkins <[email-masked]>
> > >
> > > 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
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/avt
> > >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/avt
> 

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

---

From: Carsten Burmeister <[email-masked]>
Date: Mon, 10 Dec 2001 19:02:28 +0100

Dear David and all,

please find some comments to your e-mail below. Basically there are two
issues discussed within this mail.

First we discuss the updated AVT draft about retransmissions in RTP. The
changes in the draft include a new example usage of the retransmission
payload formats, where the retransmissions can be sent in a different RTP
session. We included this to ease the discussions about this solution that
were initiated by you. The applications and environments, where we want to
use the retransmissions (e.g. media streaming in mobile environments) get a
much better performance if we send the retransmissions in the same RTP
session. In the future there might be more different applications, which use
retransmissions in a special way. Therefore I propose that we design the
retransmission framework as general as possible to support these
applications and only as limited as needed to avoid interoperability issues.
Please see more detailed comments below.

Second we discuss some detailed technical issues with the two different
retransmission schemes. Summarizing it can be said that the application we
have in mind is more efficient and easier to implement when sending the
retransmissions in the same RTP session and without the overhead of setting
up a new RTP session (and RTCP) only for the retransmissions. For these
issues there are also some detailed comments below.

> format and rules how to use the payload format) in order to incorporate

We changed several things in the draft. Therefore we need some comments from
the group now. The example usage of the retransmission payload formats,
where we show that it is possible to send the retransmissions in a different
RTP session is also new. We did not consider this possibility at first and
still have doubts on the performance of this solution. However, since you
want to use the retransmissions this way and as you see merits in doing it
this way, we thought that having an example in the draft, showing that this
is possible with our payload formats could be beneficial, also for the
discussions. For the applications we have in mind, which is e.g. media
streaming in mobile environments, it makes much more sense to send the
retransmissions in the same session.

> our original and updated draft.

No. The AVT-draft does not use two 'retransmission modes'. The aim of the
draft was to support more or less all retransmission schemes that make sense
for certain applications. I think from this discussion it is already clear
that there is a benefit of being able to support different retransmission
schemes for different applications. *If* we would send the retransmissions
in a different RTP session, the application we have in mind would be simply
not efficient enough (performance and implementation/computational effort)
and much more complex. So the option of sending the retransmissions in the
same RTP session should definitely be supported. Sending the retransmission
in a different RTP session, seems to make sense for your application. So we
could support that as well, if needed we can show this in the example.

> generally not a good design.

Please see my comments above for the benefit of supporting more than one
very restrictive retransmission scheme. The point here is that they do not
solve the *same* problem!

> there are several problems with this mode.

As said before, we included the example to get comments from the group. In
general we do not see any harm in having this example in the draft. But we
also see no problems in removing it again. I see that you would rather have
it in there, are there other opinions?

> please tell what the reasons you're thinking of are?

Sending retransmissions in the same stream allows faster detection of lost
packets and a solution where no additional timer is needed. See my comments
below for more details.

> I guess your point is here how to  detect a retransmission attempt did

My point is here that you need an additional timer on the receiver side to
detect the loss of a retransmission, which is overhead and leads to other
problems (see below).

> implement at the sender and the receiver.

I do not think that this is simple. First you need an additional timer,
which can be quite some effort on devices with less computational power.

Second you need an RTT measurement, which you do not have from RTP, if your
receiver does not send SR. A typical example usage of retransmissions is
media streaming, where the receiver is not an RTP sender and thus has no RTT
estimation.

Third having a timer, based on a RTT estimation leads to either some wrong
decisions or a long response time if the RTT is to some extend variable,
which it usually is. So either you send a lot of retransmission requests for
packets that will arrive later anyway, or you send the retransmission
requests quite late, which means that the retransmissions might not arrive
in time. You have to face this compromise if you use timers here.

> send a request as soon as you detect a missing SN.

And this is why we can react faster and without necessarily the need for a
timer. Actually, we send the retransmission requests of course according to
the RTCP timing rules. But besides that you are right, we send the
retransmission request as soon as possible, directly after detecting the
packet loss. By doing it this way, we ensure that we are able to send as
many retransmission attempts as possible to get the best possible
performance.

The additional delay that you get by waiting for an additional
'retransmission request timer' at the receiver, could cost a retransmission
attempt and that is why we base the loss detection for all packets rather on
the sequence number. Especially lost retransmissions benefit from a fast
loss detection, because these are already quite late anyway.

> There is a

Normally you do not need a judgement on the receiver side whether to send a
retransmission request. Usually the bandwidth on the back channel is not
that limited that it cannot cope with some useless retransmission requests,
which are quite small and appended to RTCP RR anyway. The sender should
decide about the retransmission, because it has the exact timestamp and a
RTT estimation. It has to decide about the transmission anyway, because of
the congestion control section of RTP and AVP.

*If* you want to have a judgement on the receiver side whether to send a
retransmission request you need to estimate the timestamp of the lost
packet. It is possible to use the SEL payload format (also described in the
AVT draft) and to exactly compute the timestamp of the lost packet. Also a
simple judgement of the timestamp is possible if we accept that the
measurement might be wrong for a lost retransmission (we can accept that,
because the server needs to do the final retransmission decision anyway).

> time to retransmit a packet and send a retransmission packet.

I think you mean a retransmission request. So what? There would be a useless
retransmission request on the back-channel. You send the RR anyway, so
appending e.g. a 'generic NACK' as described in the 'RTP Profile for
Extended RTCP Feedback' is not much overhead. The sender will finally decide
about the retransmission, which it has to do according to the congestion
control section in RTP and AVP anyway. As said before the retransmission
decision would be more naturally placed in the sender.

> The sender

Please see my comment above, why the retransmission is not sent.

> the latter if you don't use timers.

Lost retransmission requests are always problematic if you use NACKs.
However you do not have to use timers. There are several other solutions,
such as protecting your back channel, using ACKs, sending the retransmission
request in several consecutive NACKs (using the BLP as described in 'RTP
Profile for Extended RTCP Feedback' without any overhead) or a combination
of any of those.

Finally it has to be said that we do not aim to be 100% reliable, there are
other protocols for that. We want to have retransmissions in a timely
manner, not necessarily reliable but fast!

> three times,  you use three retransmission headers in the same packet,

We are talking about 2 byte additional header per retransmission. Compared
to what is sent anyway this is neglectable.

Best Regards,
Carsten