[e2e] Is a non-TCP solution dead?
Michael Uni
michael.welzl at uibk.ac.at
Wed Apr 16 13:51:45 PDT 2003
Hi Panos,
> so TCP congestion control has become sort of a sacred cow, there is no
space
> for innovation/experimentation there -and developments are very (very)
slow -
> if there are several behaviours (inside tcp) the app developpers or
> administrators could just select what is "best", with a little info about
> network path properties - they could solve many of their problemes,
> but they risk being called antisocial
I think that such a thing could and should be done in the stack, by an
intermediate
layer - i.e. the app should be able to specify QoS (well ... some sort of
QoS at
least - do I prefer less loss or a higher bandwidth, can I deal with high
rate
fluctuations, ..) while the stack should be informed about the network
explicitely
or implicitely (by measuring) and somehow try to make the best of what is
available.
This could, for example, mean choosing between DCCP congestion control
mechanisms, tuning TCP, altering packet sizes, using an actual QoS mechanism
if there is one available ... but the key point is that this should be
transparent to
the application so it could evolve independently.
Best regards,
Michael
More information about the end2end-interest
mailing list