[Bloat] Detecting FQ at the bottleneck

[David Collier-Brown]

That technique seems interesting, but are they addressing the right 
/problem/?

They note that delay-based congestion control is better, but old 
loss-based control out-competes it, so they propose to stop using delay 
in that case.

Logically, I'd prefer delay-based control to detect when the other end 
is transmitting aggressively, try to signal it to slow down using it's 
preferred signalling, and if that fails, beat the aggressor over the 
head with packet drops until the other end starts to behave itself (;-))

--dave

On 2020-10-25 11:06 a.m., Toke Høiland-Jørgensen via Bloat wrote:
> This popped up in my Google Scholar mentions:
>
> https://arxiv.org/pdf/2010.08362
>
> It proposes using a delay-based CC when FQ is present, and a loss-based
> when it isn't. It has a fairly straight-forward mechanism for detecting
> an FQ bottleneck: Start two flows where one has 2x the sending rate than
> the other, keep increasing their sending rate until both suffer losses,
> and observe the goodput at this point: If it's ~1:1 there's FQ,
> otherwise there isn't.
>
> They cite 98% detection accuracy using netns-based tests and sch_fq.
>
> -Toke
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20201025/6601aa18/attachment.html>