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

From: [email-masked]
Date: Fri, 22 Nov 2002 13:09:22 -0600

Andrei,
 
The issue deals with how a receiver performs loss detection. The retransmission payload format does not mandate a specific algorithm for loss detection.
 
The receiver should obviously not send a retransmission request as soon as a sequence number is missing but should add some extra delay to compensate for packet reordering. We could add this recommendation to the draft so that implementers be aware of packet reordering.
 
David.

-----Original Message-----
From: ext Andrei Gurtov [mailto:[email-masked]]
Sent: Wednesday, November 20, 2002 12:00 PM
To: [email-masked]
Cc: Leon David (NRC/Dallas)
Subject: reordering and rtp-retransmissions

Hi,
 
Does the current version of the rtp-retransmissions draft include some protection against spurious retransmissions in presence of reordering? For example, TCP includes a threshold of 3 DUPACKs for this purpose. 
 
Measurement studies in the Internet show that packet reordering is quite common.
 
Thanks,
Andrei
www.cs.helsinki.fi/~gurtov

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

---

From: "Andrei Gurtov" <[email-masked]>
Date: Tue, 26 Nov 2002 10:35:23 +0200

David,

It's a very good idea to add the recommendation to the draft. Otherwise, I
suspect IESG would have something to say about it. It's probably not a big
problem when a sender reports the feedback for multiple packets at once
(e.g. in a larger multicast group) but could be a problem when the receiver
is in ACK or immediate feedback mode (in terms of AVPF).

Could it be that the sender SHOULD NOT retransmit a packet reported missing
unless it has ACK/NACK of a third packet ahead from current? This is sort of
equivalent to 3 DUPACKs in TCP. Instead, the sender could also wait for a
time it normally takes to transmit 3 packets.

Btw, there is some overlapping between
draft-ietf-avt-rtcp-report-extns-01.txt and
draft-ietf-avt-rtcp-feedback-04.txt; they both define a way to report lost
packets to the sender. Is this a good thing, i.e. both proposals are useful
but for different purposes? Could they both be used with
rtp-retransmission-03?

Thanks,
Andrei

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, November 22, 2002 9:09 PM
Subject: RE: reordering and rtp-retransmissions

> Andrei,
>
> The issue deals with how a receiver performs loss detection. The
retransmission payload format does not mandate a specific algorithm for loss
detection.
>
> The receiver should obviously not send a retransmission request as soon as
a sequence number is missing but should add some extra delay to compensate
for packet reordering. We could add this recommendation to the draft so that
implementers be aware of packet reordering.
> Does the current version of the rtp-retransmissions draft include some
protection against spurious retransmissions in presence of reordering? For
example, TCP includes a threshold of 3 DUPACKs for this purpose.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Nov 2002 14:46:57 -0500

>is in ACK or immediate feedback mode (in terms of AVPF).

Agreed, this seems like a useful recommendation. 

>time it normally takes to transmit 3 packets.

I don't think this is reasonable, since the reliability and ordering
requirements of RTP flows are very different from those of a TCP.

>but for different purposes? Could they both be used with

Cheers,
Colin

---

From: Jose Rey <[email-masked]>
Date: Thu, 28 Nov 2002 11:27:53 +0100

Hi all,

please see in-line ...

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Colin
> Perkins
> Sent: Wednesday, November 27, 2002 8:47 PM
> To: Andrei Gurtov
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVT] Re: reordering and rtp-retransmissions
>
>

On this last paragraph: I agree with Andrei in that there is still some
overlapping. In fact, since using the XR packet type as opposed to the
usual RRs would allow for more frequent feedback and extended reporting
possibilities, it will be useful to be able to use them with the AVPF.
My question here would be: how does an SDP look like when certain RTCP
report extensions are supported? In the AVPF different kinds of feedback
are signalled through some lines like:

a=rtcp-fb:98 nack
a=rtcp-fb:98 ack

but how do you do it for the new reporting extensions? This is missing
in the current report-extns draft. I guess some new parameters for the
different extensions like "rle", "drle", "tsrb", etc... for the
"a=rtcp:" attribute should be defined.  Of course, this assumes
implicitly that the PT=XR as per the rtcp-report-extns draft is
supported.

Comments?

José

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Nov 2002 12:37:17 +0100

Hi,

See my comments below:

>implicitly that the PT=XR as per the rtcp-report-extns draft is
Yes, there is overlap in loss indication. However I think there is no 
need to define in the RTP retransmission draft define how to use the XR 
packets to report losses. The reason is: First, to have more frequent 
feedback suitable for retransmission you need to implement extended RTCP 
feedback (AVPF). If you implement the timing you can as well implement 
the ACK and NACK format, i.e. RTCP packet type RTPFB. This requires you 
to implement minimal extra functionality. If you would implement XR you 
would need to implement more functionality. If you would like to have 
extra statistics outside of what RTPFB NACK gives you when doing 
retransmission one should also implement XR. If a sender does not 
understand XR it can still issue retransmission based on RTPFB NACK. I 
think it is important that we do not create points of operation that 
will not be compatible.

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

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jose Rey <[email-masked]>
Date: Thu, 28 Nov 2002 13:50:33 +0100

Hi Magnus,

see inline...

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, November 28, 2002 12:37 PM
> To: Jose Rey
> Cc: Andrei Gurtov; [email-masked]
> packets to report losses.

The rtx-draft shall, of course, not define how to use these extensions.

> The reason is: First, to have more frequent

I don't think you would have the problem you mention since by signalling
feedback capabilities in the first place, a session using certain
reporting extensions would never be established if the receiver doesn't
support those extensions. Theere is added functionality needed, and this
is what I mean with "Of course, this assumes implicitly that the PT=XR
as per the rtcp-report-extns draft is supported." above.

I agree that there would be an additional cost involved, but once the
extensions are implemented (for example, if some other measurements are
needed) I don't see why it shouldn't be left up to the implementer which
method to use as long as supported by the sender. I agree this might be
an issue in multicast if other receivers don't support these extensions,
as there would be no feedback suppression, but this also could be
pointed out in the text.

I would therefore recommend to implement always the ACK and NACK
messages (as a minimum) but also allow to report losses using the
extensions if the server supports it.

cheers,

Jose

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