Hi Harald, On Fri, May 4, 2012 at 10:02 AM, Harald Alvestrand <harald@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.