Subject: RE: [AVT] Comments on the selective retransmission draft and new draft submitted.

From: "Leon David (NRC/Dallas)" <[email-masked]>
Date: Mon, 16 Jul 2001 11:18:14 -0500

Carsten and all, 

Thanks a lot for your answers. I've been studying the draft again and I
have the following concerns (please correct any missunderstanding):
If retransmitted packets are sharing the same SN space as the original
RTP packets, a receiver is not able to tell if a loss packet is a packet
sent for the first time or a retransmitted packet. It seems to me that
an RTP receiver should always be able to detect missing data into an
incoming  stream and pass this information to the decoder for error
concealment.  
How does this retransmission scheme affect RTCP statistics? In
particular, what would be the effect on the jitter value?

We would like an RTP retransmission solve these problems and in addition
meet the following requirements:
-A multicast session where RTP retransmissions are used could be joined
by receivers whether or not they implement RTP retransmission ('backward
compatibilty')
-A reliable loss detection mechanism which always detect the type of
lost packets.  The number of packet priorities should not be limited to
2. 
-existing RTP header compression schemes should work well with RTP
retransmissions.

As material for further discussion on these issues, we submitted a
proposal on an RTP retransmission framework to meet these requirements
draft-ietf-leon-rtp-retransmission-00.txt.  If you want to get this
draft before it appears in the draft directory, email me for a copy.
Comments are greatly appreciated. 

Thanks a lot, 
David. 

> -----Original Message-----
> From: ext Carsten Burmeister [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 4:25 AM
> To: [email-masked]
> Subject: RE: [AVT] Comments on the selective retransmission draft
> 
> 
> Dear David,
> 
> thanks for your comments to the retransmission draft. Please 
> see my comments
> (and hopefully also clarifications) inline. Any further 
> discussions are more
> than welcome!
> 
> >
> > Hello,
> >
> > I have reviewed the 'retransmission payload format' draft
> > (draft-ietf-avt-rtp-selret-01.txt) and I have the following
> > comments/questions. Please clear any misunderstanding in my 
> reading of the
> > draft.
> >
> > *Detection of high priority packet loss
> > It seems that the detection mechanism for high priority packets
> > specified in
> > the draft does not work.
> > The draft says 'If the receiver gets a low priority packet, 
> it has only to
> > verify if it has received the indicated last important packet'.
> > For example let us assume that the following packets are sent. I
> > show below
> > the packet sequence number, the packet type (RTX or LP) and 
> the sequence
> > number of the indicated last important packet for an LP type packet:
> > SN, RTX
> > SN+1, LP, SN
> > SN+2, RTX (lost)
> > SN+3, LP, SN+2 (lost)
> > SN+4, RTX
> > SN+5, LP, SN+4
> > SN+6, LP, SN+4
> > If packet SN+2 and SN+3 are lost, the receiver won't be able to
> > detect that
> > the important packet SN+2 is lost and that it should request
> > retransmission
> > for that packet.
> > Here is another example:
> > SN, RTX
> > SN+1, LP , SN
> > SN+2, RTX (lost)
> > SN+3, RTX
> > SN+4, LP, SN+3
> > SN+5, LP, SN+3
> > SN+6, LP, SN+3
> > If the important packet SN+2 is lost, the receiver won't be 
> able to detect
> > it. More generally, if important packets are sent consecutively, the
> > receiver is able to detect (at best) the loss of the last
> > important packet.
> > In practice, this is a major limitation. In effect, we should
> > expect bursts
> > of important packets. For example, an I frame would be typically
> > fragmented
> > in consecutive packets which would all be of high priority.
> >
> 
> Yes, your are right: For these cases it does not work the way 
> you describe
> it. But, let me start from the beginning:
> 
> In the first versions of our draft we had a different header 
> format, with
> different fields, one of those was the second sequence 
> number. With this
> field the problems you described did not occur. However the 
> drawback was
> that you MUST send an additional header for all packets, even 
> though you
> might need not the functionality of selective retransmission requests.
> That's how we came to the new format.
> 
> Here, if we do not need the selective retransmission request 
> functionality,
> we can send all packets in the usual way, without an 
> additional header. Only
> the retransmissions are transmitted with the new payload 
> format. This would
> be the usual case, where the bit rate on the back channel is not that
> critical, so that retransmission decisions are made only at 
> the server.
> 
> The client could make such retransmission request decisions 
> only by other
> means, not subject to the draft. In general it would send a 
> retransmission
> request for all lost packets. Please note that one feedback packet may
> contain several retransmission requests, by the means of the 
> bit mask of
> lost packets, described in the 
> draft-fukunaga-avt-low-delay-rtcp-02. (A new
> version of the draft, merged with the new timing rules to 
> send RTCP feedback
> will be submitted within the next days!)
> 
> But we considered also the following case, where we need the selective
> retransmission request functionality: The client has a very 
> low bit rate
> connection back to the server (maybe a control channel is used or the
> allowed RTCP bit rate limits the number of feedback messages 
> ...) and only
> very few high priority packets are sent downlink, e.g. once a 
> second or even
> less. In this case the Low-Priority payload format can be 
> used. The problems
> you described above are not likely to occur, because there 
> are only very few
> high priority packets. If there were more, the client would 
> not be able to
> request retransmissions anyway, because of the limited bit rate on the
> return channel.
> 
> Besides that, the client is able to detect the loss of 
> several packets. It
> can also detect that at least one high priority packet was 
> among the lost
> packets. Hence a clever client implementation would request the
> retransmission of all lost packets. This is no overhead on the
> return-channel, because it can send up to 15 retransmission 
> requests in one
> feedback packet as described above. The final retransmission 
> decision is at
> the server, and the server knows about the priority of the packet.
> 
> > *Multiple retransmission algorithm:
> > Instead of retransmitting a packet with its original SN, a 
> retransmitted
> > packet sequence number 'is increased by one over the previous
> > packet sent'.
> > It has the following consequences:
> > Multiple retransmission does not work if the NACK is lost 
> on the feedback
> > channel. This seems to be a very strong limitation on the scheme. A
> > retransmission scheme should be robust to loss on the 
> feedback channel.
> 
> Yes, we are not 100% reliable. But we do not claim to be neither. The
> decision was to use a timer based scheme, ACKs or NACKs. The 
> timer-based
> scheme has the drawback that additional delay is introduced, 
> especially if
> you have variable RTTs. ACKs have the drawback of quite high 
> traffic load on
> the back channel. However you are free to use ACKs. There are also ACK
> messages defined in draft-fukunaga-avt-low-delay-rtcp-02 and 
> thus also in
> the new draft that will appear now (please note, that ACKS 
> are limited to
> unicast!).
> 
> Since our focus was clearly on "near-real-time" rather than 
> reliability, we
> have chosen to use NACKs, also in the examples of the 
> retransmission draft.
> The payload formats are not limited to NACKs, however very 
> useful in that
> case.
> 
> > For a retransmitted packet, the original SN is unknown by the
> > receiver (only
> > TS is known): The original sequence number is definitely 
> needed by the
> > receiver. It will tell in which order to pass the packet to 
> the receiver.
> > The timestamp is not enough for that purpose.
> >
> 
> Retransmissions are sent in the retransmission payload 
> format. Page 6 of the
> draft shows the format of the additional header. There you 
> can see that a
> Delta RTP Sequence Number is transmitted (or the least 
> significant bits, if
> we care about additional header sizes). This value is the 
> difference of the
> current RTP SN to the original RTP SN. Thus the client is able to
> reconstruct the original RTP SN.
> 
> > *LP packet retransmission:
> > It is not clear wether the receiver is allowed to request the
> > retransmission
> > of low priority packets. If it is forbidden, there is a lack of
> > flexibility
> > in the scheme. If it is allowed to request low priority 
> packets, the whole
> > purpose of selective rtx is defeated
> >
> 
> We defined only the payload formats and gave two examples how 
> these could be
> used for different use cases. Of course you are allowed to send
> retransmission requests for all packets. However you are 
> bound to the timing
> rules of RTCP, which give you some limitations (see
> draft-wenger-avt-rtcp-feedback-02 and the new merged draft 
> with the feedback
> formats, that will be submitted these days for details about 
> the new RTCP
> timing rules we would like to use. But also the new timing 
> rules give strict
> limitations, however you are sometimes allowed to give 
> "virtual" immediate
> feedback.).
> 
> I do not think that the purpose of selective rtx is defeated! 
> RTCP bit rate
> is limited and thus a scarce resource. If you detect that you 
> have lost only
> low priority packets, you can save a feedback message. Saving 
> one feedback
> message now, means that you might be able to send the next 
> feedback message
> more early, and here you might want to request high important packets.
> 
> I hope that helps a little bit. Comments are welcome!
> 
> BR,
>    Carsten
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www.ietf.org/mailman/listinfo/avt
> 

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

---

From: Carsten Burmeister <[email-masked]>
Date: Wed, 18 Jul 2001 09:39:03 +0200

Dear David and all,

Thanks for the nice discussion. At last something is happening with the
retransmission stuff.

I read your draft, which you sent to me. However, as it is not yet in the ID
directory, I will wait with my comments until then. Please see in the
meanwhile some replies to your mail inline.

> have the following concerns (please correct any misunderstanding):

For our applications, we have in mind, this is not a problem. Normally the
RTP packets are somehow selfdescribing and thus a signalling of a gap within
the packet stream to the application should not be necessary. However I
asked a similar question at the last IETF meeting as an open issue for our
draft. It is in the meeting minutes as follows:

"Open issues include: non-constant SN-TS relation when retransmissions
occur (but this also occurs due to silence suppression, so this is not a
problem), and gaps in the received sequence number space (as seen by the
application, not in the RTP packets) once the data has been recovered
(this is an application design issue, not a protocol issue)."

The feedback from the group or at least from Colin, as I understood it, was
that unless the application does something weird with the RTP sequence
number, this is not a problem.

> particular, what would be the effect on the jitter value?

This is one reason why we included the retransmissions in the RTP sequence
number space. With this it is possible to get the correct statistics
regarding packet loss, loss fraction, etc. For the jitter we might have to
add some wording in our draft.

> by receivers whether or not they implement RTP retransmission

Maybe there is still a small misunderstanding in the functionality of our
proposal. You do not have to use any additional header for normal RTP packet
transmissions at all and this is the way that you would normally use the
payload format (described as the first example in our draft).
- You send packets as usual. No additional header. Backwards compatibility!

- The client sends retransmission requests for all lost packets. However not
necessary a single feedback packet for each retransmission request.

- The server is the one with the greatest knowledge of the stream. It
decides at reception of a loss report, if the packet should be retransmitted
or not. (Congestion Control might prevent the server from sending a
retransmission or the server might decide to send the retransmission
(because this was an important packet), and do not send the next packets at
all (not even for the first time)). However this server behaviour is not
subject to our draft and should be left to the implementers!

- Retransmissions get a two byte additional header and are transmitted in
the same sequence number space. This allows a fast detection of lost
retransmissions.

If you do it this way (only one out of several possibilities to use our
payload formats!) you can transmit your stream without any problems with
backwards compatibility. The "old" receiver would simply discard the
retransmissions, but get the original stream.

> lost packets.  The number of packet priorities should not be

For us this is not needed. If the server knows the priorities of the
packets, why would it necessarily want to signal every details of that to
the client? It is the server that makes the retransmission decision. Only to
save some bandwidth on the return channel can be a motivation for that. If
the bit rate on the backward channel is really that limited, two priorities
are probably still enough: retransmit or not.

> -existing RTP header compression schemes should work well with RTP

Because of the retransmissions in the same sequence number space, header
compression should work well. The important point is that the SN increases
linearly. So transmitting the retransmission with a SN in the same SN space
increases the compression efficiency and robustness.

The timestamp increases non linear to the SN if a retransmission was sent.
However, header compression can deal with that. It must, because you do not
have this linearity for video most of the time and for voice only if you do
not use silence suppression. So for video you normally still transmit part
of the timestamp in every header and for voice you have (at least in RoHC)
very tricky mechanisms that can deal with silence suppression and also with
the retransmission unlinearity.

> Comments are greatly appreciated.

As said before, I will comment on that later. For now thanks for the
comments and let's keep the discussions going!

BR,
    Carsten