AW: [e2e] TCP un-friendly congestion control

[Jon Crowcroft]

In missive <POEAJIPINMLEJBPAAILICEEOCCAA.michael.welzl at uibk.ac.at>, Michael Wel
zl typed:

 >>All right, let's introduce some controversy to this thread:

to change up a gear, what is needed is a pair of mechanisms that scale
togther  to
a) monitor and give feedback about traffic conditions in a region
and
b) react in a collective/aggregate way at sources 
(and possibly a shadow policing function to check that sources do so)

what is not needed is multiple service classes within the net
- just a family of mechanmisms that permit a tarrif and multiple end
system behaviours, and then a set of control systems that permit
networks to operate reasoanbly efficiently at reasoanble utilisation
across a wide operating range...

the reason i put a) so vaguely is that i dont see the need to apply a
monitor/feedbak scheme just at a single output queue (or input queue)
but it can recurse across a LAN, a wireless hop, a MAN< or a whole
ISP- by givign feedback, then users might be able to make informed
choices at different granularities of time and provider space too...
(i.e. one could imaging such feedback being part of route updates as
well as part of IP inline signaling...and being exposed by BGPng or
other scheme to the edge user or next AS)...

to continue to be stuck with packet loss as the only fedback clue is
clueless in the longrun imho - despite the cool work by caltech and
others....

when you find stress in a comms architecture at the low (wirelss access - see
all the gprs mess) and high end (as triggered this debate) then you
know its time for a change..

 
 >>> Networking research community at large should have a hard look at this
 >>> problem and come up with a better congestion control algorithm for this
 >>> regime. TCP has gone through too much tweaking and we need some
 >>> alternatives. However, it is not to say we should all abandon 
 >>> TCP. What I am
 >>> trying to say is that we need to modify TCP in more fundamental ways than
 >>> simple tweaks.
 >>
 >>I agree. And I think that a fundamentally new congestion control mechanism
 >>should not be introduced into the Internet as totally TCP-friendly
 >>( = downwards compatible ), but it should be slightly MORE aggressive than
 >>TCP. What I mean is that it should downgrade other TCP flows just a little
 >>bit more than regular TCP would, but not to a degree that would render
 >>these flows totally useless. "downgrade just a little bit more" would have
 >>to be quantified, measured and well understood, of course ...
 >>
 >>This would create an incentive for users to switch to the new
 >>mechanism, which would, eventually, be good for the network as
 >>a whole because the new mechanism would of course have to be better
 >>than TCP. This would have to be done very carefully, but I seriously
 >>believe that it is the right way to do it.
 >>
 >>The shooting season starts...    :)
 >>
 >>Best regards,
 >>Michael
 >>

 cheers

   jon