Michael Welzl
Wed, 07 Oct 2009 06:51:21 -0700
Hi,
Pasi asked for comments on MulTFRC...I don't see the application (yet) that will drive this forward and the user community that wants this to deliver whatever they need to do. If people have potential uses for this, then it would be really good to hear them.
I agree that getting such feedback would be great. Folks, please take a look, and if you think that this would be useful for a particular application, please speak up!
My take is that this is an interesting piece of research, and it could be safe - I think it's good to experiment with new CC methods, however I don't see the need to standardise each method, I question whether this will encourage production use of DCCP. In this case, I'm not yet persuaded there is a standardisation need.
- but encouraging the use of DCCP is exactly what I believe that our mechanism can do. And exploiting possibilities to make the protocol more attractive to its potential users is something that this group would urgently need in my opinion. Let's do a thought experiment, and consider streaming video as an application: if I try to look at the question "should we switch from what we already have to DCCP?" from the application designer's point of view, the most obvious next question seems to be "what's in it for me?". I think that the answer is: you can ensure that your application is behaving accordingly; some people might like you for doing that. What's probably more important, you can be sure that your application isn't going to significantly harm others on the same bottleneck, which is usually the user's access connection these days. If, like e.g. RealPlayer, Windows Media Player, Quicktime, your application already does its own congestion control which seems to work good enough, there's no point in switching, in my opinion. It just doesn't seem to be worth the effort. (For an entirely new application, "it becomes easier to develop your application" is also a plus, of course) Now, with MulTFRC, the answer to "what's in it for me?" is extended with:"... and you get a form of congestion control that will saturate the bottleneck
well, without causing significant harm (the 'N=6' case in section 3.2 of our draft)". Maybe that's not good enough, who knows? But it seems to me that the "pure DCCP" message above is also not good enough, and if we can improve the chances of deployment by making the protocol more attractive, we should go for it in my opinion. The above thought experiment discusses only one possible benefit, in one possible scenario. Other general benefits are: MulTFRC gives you a knob that you can tune, to adjust "aggression" of your congestion control mechanism, and you can make it even less aggressive than standard TCP. The latter ability could potentially make MulTFRC applicable for multipath usage. We elaborate on possible uses of MulTFRC in section 3 of the draft. I look at DCCP deployment as a scale. As with any other new protocol, there is a lot of weight in the "non-deployment" bowl: extra effort for switching, app designers waiting for support in the OS, firewall traversal... and right now, for DCCP, there isn't that much weight in the "deployment" bowl. If we can add a little more weight there, even without being able to guarantee that this one bit of extra weight will now do the trick and convince all the application programmers to start using it, then that's good, right? Cheers, Michael