Subject: [AVT] reordering and rtp-retransmissions

From: "Andrei Gurtov" <[email-masked]>
Date: Wed, 20 Nov 2002 20:00:00 +0200

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

---

From: [email-masked]
Date: Tue, 26 Nov 2002 10:19:26 -0600

Hi Andrei,
 
> 
> 
> 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).

We'll add this recommendation.

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

We can't require such a rule because the number of NACKs sent by the receiver should typically be very limited and it is unpredictable when the sender will receive  the next ACK/NACK. I think it is best to handle packet reordering at the receiver, i.e. waiting before requesting a missing SN.

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

draft-ietf-avt-rtcp-report-extns-01.txt can't be used alone for retransmission since it doesn't define the necessary timing rules. 
Retransmission requires the extended feedback profile or possibly other suitable profiles which may be defined in the future.
The report extensions would be an overkill for the sole purpose of retransmission. As far as I understand, they have a different purpose as they're meant to provide detailed QoS metrics to service providers. 

David.

> 
> 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.
> >
> > 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
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt