The RTP timestamps are certainly our friends. I am setting up to run some experiments with the various common buffer management algorithms to see what conclusions can be drawn from inter-packet arrival times. I suspect that the results will vary wildly from the RED-like algorithms to the more primitive tail-drop-like algorithms. In the case of RED-like algorithms, we will hopefully not get to much delay/bloat before the drop event provides a trigger. For the tail-drop-like algorithms, we may have to use the increasing delay/bloat trend as a trigger. As I think about the LEDBAT discussions, I am concerned about the interaction between the various algorithms - but some data should be informative. We may even be able to differentiate between error-driven loss and congestion driven loss, particularly if the noise is on the last hop of the network and thus downstream of the congested queue (which is typically where the noise occurs). In my tiny brain, you should be able to see a gap in the time record corresponding to a packet that was dropped due to last-mile noise. A packet dropped in the queue upstream of the last mile bottleneck would not have that type of time gap. You do need to consider cross traffic in this thought exercise, but statistical methods may be able to separate persistent congestion from persistent noise-driven loss. TL;DR - We can probably tell that we have queues building prior to the actual loss event, particularly when we need to overcome limitations of poor buffer management algorithms. Bill VerSteeg -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Friday, May 04, 2012 3:03 AM To: rtp-congestion@alvestrand.no Subject: [R-C] Packet loss response - but how? Now that the LEDBAT discussion has died down.... it's clear to me that we've got two scenarios where we HAVE to consider packet loss as an indicator that a congestion control algorithm based on delay will "have to do something": - Packet loss because of queues filled by TCP (high delay, but no way to reduce it) - Packet loss because of AQM-handled congestion (low delay, but packets go AWOL anyway) We also have a third category of loss that we should NOT consider, if we can avoid it: - Packet loss due to stochastic events like wireless drops. (aside: ECN lets you see the difference between the first group and the second: ECN markings are unambiguously in the first group. But we can't assume that ECN is universally deployed any time soon.) 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. - 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? Harald _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion