On 19. sep. 2012, at 14:30, 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?
This is about combined congestion control for a group of flows in case they share the same bottleneck. Here's an example: Consider two hosts and two flows between them. If they share a bottleneck, you could use only a single congestion controller for both. The share between them is then totally under the sender's control - the result of scheduling, and not the result of "fighting it out" on the bottleneck. From the queue's point of view, you're dealing with one, not two flows, leading to a reduction in queue fluctuations at least. Examples of mechanisms designed to yield a benefit in such cases: Congestion Manager: http://nms.csail.mit.edu/cm/ TCP Control Block Interdependence: RFC2140. Example of a very prototypical implementation of a congestion-manager-like functionality via SCTP, yielding benefits, as a proof-of-concept: Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas. Example of a concrete scenario: in rtcweb, all traffic is (AFAIK) going to be multiplexed over the same UDP port-number pair. To be able to do any form of congestion control, it must therefore be assumed that all of these packets traverse the same path - which means that multiple flows multiplexed over this 5-tuple will share the same bottleneck. (and then, there are several measurement-based mechanisms for shared bottleneck detection out there; essentially, they look for correlations in some measured values such as one-way delay)
- 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)?
Many approaches are possible. I don't think that there is a concrete proposal out there already, but I suspect that there is some more concrete stuff on Matt Mathis' mind. He would be the right person to answer this. Cheers, Michael