General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Collier-Brown <davecb.42@gmail.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Detecting FQ at the bottleneck
Date: Sun, 25 Oct 2020 14:51:20 -0400	[thread overview]
Message-ID: <3d9a2c9f-52f0-9b9d-1804-7f93d76960b9@rogers.com> (raw)
In-Reply-To: <87k0ve5oqs.fsf@toke.dk>

[-- 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 --]

      reply	other threads:[~2020-10-25 18:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-25 15:06 Toke Høiland-Jørgensen
2020-10-25 18:51 ` David Collier-Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d9a2c9f-52f0-9b9d-1804-7f93d76960b9@rogers.com \
    --to=davecb.42@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=davecb@spamcop.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox