[R-C] Packet loss response - but how?

[Varun Singh]

Hi Harald,



On Fri, May 4, 2012 at 10:02 AM, Harald Alvestrand <harald at alvestrand.no> wrote:

[snipped the top half of the email.]

> Now - the question is HOW the receiver responds when it sees packet loss.
>
> Some special considerations:
>
> - Due to our interactive target, there is no difference between a massively
> out of order packet and a lost packet. So we can regard anything that comes
> ~100 ms later than it "should" as lost.

I agree that packets can be discarded by the receiver due to late arrival.

So the 100ms may seem like a good number, but perhaps this number should come
from the application (via the constraints API)?
Moreover, interactive applications usually
define some kind of optimal end-to-end delay (about 150ms?) and
maximum end-to-end delay
(about 400ms?). So based on the latency of the path the 100ms could be adjusted.
The receiver also has a dejitter buffer which can compensate for *some* packet
re-ordering. AFAIK receiver does this by calculating the packet skew or drift
for each packet it receives and adjusts the playout delay.
Usually using a sliding window average, and window sizes for drift
calculation are between 100, 250 packets.

> - Due to the metronome-beat nature of most RTP packet streams, and the
> notion of at least partial unreliability, the "last packet before a pause is
> lost" scenario of TCP can probably be safely ignored. We can always detect
> packet loss by looking at the next packet.
>
> Thoughts?

Can you comment on what the current RRTCC would do if the discarded
packet is included in the rate calculation or not. Or how does the
value computed by RRTCC compare to the Receiver Rate, the Receiver
Goodput and the sending rate?

In the algorithms that I worked on using TMMBR for video, the receiver
would undershoot to the goodput in cases of intervals with losses and
discards.  In case of few bursty losses in an interval, it would go
down to the receiver rate.


The receiver can calculate:
Receiver Rate: RTP packets received in an interval (including:
duplicate, retx packets etc)
Goodput: RTP packets that were actually played out in the interval
(excludes: discarded packets etc)
Sending Rate: difference between the octets sent in consecutive SRs
*may* give the sending rate in the interval. (Assuming that an SR was
not lost.)
Usually, Sending Rate >= Receiver Rate >= Goodput.