Subject: RE: [AVT] Re: reordering and rtp-retransmissions

From: [email-masked]
Date: Mon, 2 Dec 2002 11:44:06 -0600

> > Conclusion: Don't use XR to report which packets to
> > retransmit. It can however be used to give complementary data.

I agree with Magnus because these two types of feedback have different purposes.
When used with the retransmission payload format, NACKs are used as retransmission requests sent by the receiver to the sender. In other words, sending a NACK means that the receiver wants to receive the missing packet and the sender should try to resend this packet depending on the congestion state.

Conversely, extended reports are meant to give extended QoS information. If a receiver signals a packet loss in an XR report, it does not mean necessarily that it wants the packet to be retransmitted. Hence, if a sender was retransmitting packets based on the XR reports, this could trigger unnecessary retransmissions. 

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

---

From: "Timur Friedman" <[email-masked]>
Date: Mon, 2 Dec 2002 19:05:13 +0100

David Leon wrote:
> When used with the retransmission payload format, NACKs are used as
retransmission requests sent by the receiver to the sender. In other words,
sending a NACK means that the receiver wants to receive the missing packet
and the sender should try to resend this packet depending on the congestion
state.
>
> Conversely, extended reports are meant to give extended QoS information.
If a receiver signals a packet loss in an XR report, it does not mean
necessarily that it wants the packet to be retransmitted. Hence, if a sender
was retransmitting packets based on the XR reports, this could trigger
unnecessary retransmissions.
> David.

In preparing the XR draft we did not envisage the use of XR Loss RLE blocks
for individual packet-by-packet retransmissions.  The purpose of the report
blocks, as others have said, is to support monitoring.  Since the goal is
different, the rules that govern how losses are reported would be different.

XR Loss RLE report blocks can, of course, be used by adaptive applications.
An application might infer a multicast tree topology and loss rates along
links in that topology.  This could guide the activation of repair servers,
for instance.  But the timescale on which such inference would take place
would be much longer than the timescale of individual packet
retransmissions.  There would be good reason to transmit NACKs with greater
frequency than XR Loss RLE blocks.

- Timur

---

From: Jose Rey <[email-masked]>
Date: Wed, 04 Dec 2002 11:28:07 +0100

Hi,

thanks Timur for your comments. I'll try to summarize the discussion
until now:

- the RTX draft shall not specify how to use the report extensions (this
was never meant...)
- using the report extns to trigger retransmissions might be a problem
for multicast, for example because feedback supression is not as
efficient in the case of mixed recipients that do not understand the
extns.
- report extns RLE blocks were not envisioned to trigger retransmissions
- RTX draft recommends to use AVPF feedback mechanism to trigger rtxs.
(NACKs)

see further inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Timur
> Friedman
> Sent: Monday, December 02, 2002 7:05 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [AVT] Re: reordering and rtp-retransmissions
>
>
> David Leon wrote:
> >
> > I agree with Magnus because these two types of feedback
> have different
> purposes.

I understand the motivation behind the extns... you talk about governing
rules, what would be the difference in these rules? I don't fully
understand what you mean...

> XR Loss RLE report blocks can, of course, be used by adaptive

I kind of lack of a conclusion here... until now, my personal conclusion
is that in unicast streaming and for adaptive applications like rate
control, the sender could use (additionally to SRs and RRs sent less
often) XR loss RLE blocks to learn about lost packets. XR loss RLE
blocks are more efficient in terms of compression and overhead than RRs,
although they imply more functionality at server and client. Now, since
retransmissions MUST have rate control, why prohibit the application to
use XR Loss RLE blocks as it wishes? The current RTX draft text doesn't
prohibit to use them, so I would say we leave the text as is and
_optionally_ introduce some text explaining it could give problems in
multicast. From what Timur says, I think to understand he supports this
view, but I am not sure...
Please comment on this.

I don't intend to extend the discussion too long.. I would like to
understand why this limitation is needed/desired. Also, we all want to
get the draft done asap :)

> frequency than XR Loss RLE blocks.

My comments on the use on RLE blocks refer to the unicast case.
Multicast is problematic.

cheers,

José