* [Bloat] Detecting FQ at the bottleneck
@ 2020-10-25 15:06 Toke Høiland-Jørgensen
2020-10-25 18:51 ` David Collier-Brown
0 siblings, 1 reply; 2+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-10-25 15:06 UTC (permalink / raw)
To: bloat
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Bloat] Detecting FQ at the bottleneck
2020-10-25 15:06 [Bloat] Detecting FQ at the bottleneck Toke Høiland-Jørgensen
@ 2020-10-25 18:51 ` David Collier-Brown
0 siblings, 0 replies; 2+ messages in thread
From: David Collier-Brown @ 2020-10-25 18:51 UTC (permalink / raw)
To: bloat
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
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@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@spamcop.net | -- Mark Twain
[-- Attachment #2: Type: text/html, Size: 2259 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-10-25 18:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-25 15:06 [Bloat] Detecting FQ at the bottleneck Toke Høiland-Jørgensen
2020-10-25 18:51 ` David Collier-Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox