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

I think, Roland is right about fairness.
More generally AIAD is unfair, which turns out to be a stability issue.
This is also known for Vegas.

So even if RTT_min is known AIAD is a bad design choice.
Still it remains to infer RTT_min.

There is a reference that I report below that can be useful to fix LEDBAT
for what concerns
intra/inter protocol fairness seen from a stability perspective.

A. Tang, X. Wei, S. H. Low and M. Chiang,
"Equilibrium of Heterogeneous Congestion Control: Optimality and
Stability,"
in *IEEE/ACM Transactions on Networking*, vol. 18, no. 3, pp. 844-857, June
2010.
doi: 10.1109/TNET.2009.2034963

On Tue, Sep 10, 2019 at 9:36 AM Bless, Roland (TM) <roland.bless@kit.edu>
wrote:

> Hi Marcelo,
>
> Am 09.09.19 um 17:34 schrieb marcelo bagnulo braun:
> > I am not sure i understand your answer though. I mean the whole problem
> > of LEDBAT latecomer advantage is that the late comer misestimates the
> > base delay (i.e. RTT_min?) and then it adds the target delay on top of
> > the wrongly estiamted base delay.
>
> Yes.
>
> > So, i dont understand what do you mean that the mechanism assumes
> > knownledge of the base delay. Clearly, i am missing something here,
> > could you educate me?
>
> As Luca wrote, their proposed algorithm requires a _perfect knowledge_
> of RTT_min, i.e., transmission and propagation delay
> without any queueing delay.
>
> Note that, even if one would have perfect knowledge of queueing delay,
> the latecomer advantage would turn into a latecomer disadvantage,
> because the latecomer would back-off. Fairness remains still
> an issue then...
>
> Regards
>  Roland
>
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg
>