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
