Re: [iccrg] LEDBAT++, rLEDBAT, and slowdowns

[marcelo bagnulo braun <[e-mail]>]

Forgot the reference:
[1] Rethinking the Low Extra Delay Background Transport (LEDBAT) Protocol
Carofiglio, Giovanna; Muscariello, Luca; Rossi, Dario; Testa, Claudio; 
Valenti, Silvio
ISSN: 1389-1286 , 1872-7069; DOI: 10.1016/j.comnet.2013.02.020
Computer networks. , 2013, Vol.57(8), p.1838-1852

El 09/09/19 a las 10:35, marcelo bagnulo braun escribió:
> Hi Neal,
>
> Thanks for the explanation. I can see now that uncoordinated slow 
> downs is not enough to provide a bounded delay.
> I have an additional question related to this, that maybe you can 
> provide some insight.
> Some papers, like [1], have proposed an AIMD variation of LEDBAT to 
> achieve interledbat fairness. Since laedbat late comer advantage is 
> essentially the problem of a late comer misestimating the base delay, 
> and bloating the queueing delay, seems essentially the same problem. 
> So the question is wouldnt AIMD solve the problem? I mean, wouldnt 
> AIMD provide fairness and keep the queueing delay added by the ledbat 
> flows bounded as well?
> Thanks, marcelo
>
>
> El 06/09/19 a las 17:25, Neal Cardwell escribió:
>> However, if we apply the slowdown described in LEDBAT++
>>> (unsynchronized), then f1 would reduce its window and because f1 is the
>>> one expelling the other flows out, this would allow f1 to have a more
>>> accurate measure of the base delay, enabling the AIMD fairness to kick
>>> in and preventing the increase of the queueing delay.
>> As noted above, if the fair share of inflight data is less than the
>> standing queue, when f1 reduces its window it will not drain the queue
>> fully, so its base delay estimate will ratchet up to a value that
>> includes the queueing delay from all the other flows queued at
>> the bottleneck, even if all the others are LEDBAT++ flows.
>>
>>
>>> In summary, because errors in estimating the queuing delay causes one
>>> flow to grow more than the others, when this particular flow slows 
>>> down,
>>> will allow a more accurate measure of the base delay, enabling AIMD
>>> fairness mechanisms to reconverge to a fair split.
>>>
>>> So, I am not convinced that it is not enough with the slow down 
>>> proposed
>>> in LEDBAT++.
>> When you say a slow-down "will allow a more accurate measure of the
>> base delay," I think a key question is: more accurate than what, 
>> exactly?
>> An uncoordinated slow-down will allow a more accurate measure
>> of the base delay than the most recent RTT samples, but it will not
>> allow a measure that is more accurate than (or even matching)
>> the current base delay estimate.That's because uncoordinated
>> slow-downs can cause feedback loops, where flows measure
>> ever-increasing RTTs from the queues created by other flows
>> that are also unable to "anchor" their base delay estimates, so
>> are also allowing ever-increasing amounts of data in flight.
>>
>>> I am not sure this is true for all combinations of parameter values, i
>>> need to look into this.
>> Yes, I think further testing of LEDBAT++/rLEDBAT in multi-flow scenarios
>> would be worthwhile.
>>
>> A simple scenario that should illustrate this issue:
>>   o RTT of 100ms
>>   o bottleneck with 10*BDP of buffer space (allowing 1 sec of queuing)
>>   o 3 bulk LEDBAT++/rLEDBAT flows
>>
>> Per the dynamics discussed above, my theory is that in such a scenario
>> the queuing delay will grow until the buffer is oscillating near full 
>> and
>> there is ~1sec of queuing in the steady state. That is, rather than
>> "Low Extra Delay" there will be 1sec of extra delay. :-)
>>
>> best,
>> neal
>>
>