> - Is TCP using packet delay considered as part of the solution for
> bufferbloat?
Not on this list, apparently. However, there has been a fair amount
of research on that approach in the late noughts. I'd suggest
you search for papers on TCP Vegas, TCP-LP and LEDBAT.
In particular, LEDBAT is v
> But it is hard, and the delay based algorithms are fundamentally
> flawed because they see reverse path delay and cross traffic as false
> positives.
I'm not sure what you mean. All modern delay-based congestion
algorithms that I am aware of use one-way delay as an indicator of
congestion, not
* Juliusz Chroboczek | 2013-04-03 20:16:50 [+0200]:
>> But it is hard, and the delay based algorithms are fundamentally
>> flawed because they see reverse path delay and cross traffic as false
>> positives.
>
>I'm not sure what you mean. All modern delay-based congestion
>algorithms that I am awa
>> All modern delay-based congestion algorithms that I am aware of use
>> one-way delay as an indicator of congestion, not RTT.
> It depends on what you define as modern [...] Vegas? Yeah-TCP? Nope.
Vegas is some 20 years old, if memory serves. I'm not familiar with Yeah-TCP.
(TCP-LP and LEDBAT
Is your TCP mod available? This would be useful on Android phones, to
avoid background downloads (e.g. updates) from disrupting applications
(Skype).
Simon
On 03/20/2013 06:01 PM, Jonathan Morton wrote:
One beneficial approach is to focus on the receive side rather than the
send side. It is
