Subject: [ledbat] limitation of increase

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 15 Feb 2011 16:11:21 +0100

Hi everybody,

the current LEDBAT spec doesn't seem to be correct. The text is stating that 
the increase should be limited to be not faster than standard TCP's increase 
but the pseudo code doesn't limitate the increase correctly.

I would like to propose to change the pseudo code to 

	cwnd += GAIN * off_target / TARGET / cwnd

instead of

	cwnd += GAIN * off_target / cwnd

Now GAIN=1 would limit the increase correctly and this is conform with the 
implementation of the uTP client from BitTorrent. 

This change would also slow down the decrease. That could disturb competing 
standard TCPs slightly. But it will not keep the TCPs from sharing the 
capacity equally. Moreover, a less aggressive reaction on delay changes will 
make LEDBAT more noise robust.

There are other proposals to change the decrease, e.g. to have an 
multiplicative decrease which could also help the intra-protocol fairness 
problem (if the queue get empty for a short time). I wouldn't wanne support 
this approach, as then LEDBAT will oscillate more strongly and thus not 
utilize the available capacity fully. I would say its more import to utilize 
the capacity fully than having intra-protocol fairness. If LEDBAT is friendly 
to every other TCP connection, it can also be friendly to another LEDBAT 
connection as the user will not care about the completion time when using 
LEDBAT. Maybe its even better to have one LEDBAT flow after the other using 
all the capacity.

Maybe there is a case where a higher GAIN factor for the decrease than for the 
increase makes sense (e.g. to distrub completing standard TCP's less) but I 
couldn't figure out any reasonable value for a 'decrease GAIN'.

Thus I would only like to add this 1/TARGET for the cwnd change and I will 
include a discussion on different decrease behavior as well as the pointers 
to recent papers. Any options?

Mirja