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
avt@ietf.org
http://www.ietf.org/mailman/listinfo/avt