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
