Subject: RE: [AVT] Comments on the selective retransmission draft

From: "Leon David (NRC/Dallas)" <[email-masked]>
Date: Thu, 19 Jul 2001 13:51:27 -0500

Carsten and all, 

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

I'm indeed surprised that so few people seem to be involved in this
work.

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

The draft is now in the ID directory
http://search.ietf.org/internet-drafts/draft-leon-rtp-retransmission-00.
txt

> 
> > Thanks a lot for your answers. I've been studying the draft
> > again and I
> > have the following concerns (please correct any misunderstanding):
> > 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.
> 
> 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.

For example, if 3 packets are sent in a row with the first and third
packet containing data sent for the first time and the second
retransmitted data. If the second packet is lost, the RTP receiver does
not know if there are missing data between the first and third packet.
The receiver may be able to detect missing data from the bitstream
and/or RTP timestamp but can we assume this is true for any type of data
which may be sent over RTP?  

> 
> 
> > How does this retransmission scheme affect RTCP statistics? In
> > 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.
> 
> > 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')
> 
> 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.

I don't know how well the SN gap will be supported by old receivers. 

> 
> 
> > -A reliable loss detection mechanism which always detect the type of
> > lost packets.  The number of packet priorities should not be
> > limited to
> > 2.
> 
> 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.

I could imagine that more than 2 levels might be useful. For example:
*packets which are absolutely necessary to decode data from other
packets
*packets which are necessary to decode data from other packets but whose
lost may be concealed  
*packets which are not necessary to decode other packets. 
> 
> 
> > -existing RTP header compression schemes should work well with RTP
> > retransmissions.
> >
> 
> 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.

Because of these non-linearity and PT changes, you have a drop in
compression efficiency. This efficiency drop would also affect the
receivers which do not implement the draft.    

> 
> 
> > 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.
> 
> As said before, I will comment on that later. For now thanks for the
> comments and let's keep the discussions going!

I'm looking forward to your comments.

Regards, 
David.

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