On 9/19/2012 8:30 AM, Mirja Kuehlewind wrote:
Hi,
I know I'm late to comment, but after reading the charter again, I have to admit that two points are not absolutely clear to me. Maybe someone can 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.
Why do I need to identify shared bottleneck? The task of congestion control is to shared the bottleneck capacity in some way. Usually I will end up with a different share if the same or a different congestion control algorithm is used by the competing flow(s). Is the idea here to detect a shared bottleneck and then change the congestion control behavior to achieve a different share than I would otherwise? I there a concrete scenario or approach how what to do this and why this is needed in case a shared bottleneck is detected?
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.
- 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.
I believe I got the idea behind this but I not really sure how to realize it. Are you expecting some explicit feedback from the receiver (or even other components)? Is there a concrete proposal already how to do this? What are you planning to do if you have detected an RT schedule failure? Change the congestion control in some way (to be more aggressive)?
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. -- Wes Eddy MTI Systems