Hi,
provide further explanations here:
- Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck.
The original motivation for this was pretty simple. If you knew two flows with different elasticities were sharing a bottleneck, and seeing loss, you could make the congestion reaction on the more elastic flow, and leave the less elastic one untouched. Okay, I can understand this point. But if fact if you see congestion and you are elastic (up to a certain degree), you should lower your sending rate (or do whatever you can do) because there also might be other flows on the link that need the bandwidth even more urgent. I guess the only case I really see is if there is not enough bandwidth for both transmissions (such that both of the respective services do not work proper) and you have to decide which one to kill. But that's the circuit-breaker case and thus out of scope.
- Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM.
This was related to the "Internet suckage" metric. I don't know of a concrete proposal, but obviously things like measuring the queue and the delay variation could be first cuts.
Basically, if you're failing to deliver interactive traffic because of bufferbloat and competing flows, this would help to point the finger at the guilty party, so maybe it can be fixed.
hm, isn't this quite a topic on its own and actually might simply belong in the IPPM working group at least as long if there is no very specific case why something is different for RT traffic? Maybe it's not so much about the measurement techniques but the way how the interpret the measured metrics (when sending RT traffic)? Mirja