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

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

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:[e-mail]]
> Sent: Friday, June 29, 2001 4:25 AM
> To: [e-mail]
> 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
> [e-mail]
> http://www.ietf.org/mailman/listinfo/avt
> 

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