From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A8ADA3B2A4 for ; Sun, 25 Oct 2020 14:51:24 -0400 (EDT) Received: by mail-qk1-x735.google.com with SMTP id b69so6407743qkg.8 for ; Sun, 25 Oct 2020 11:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=WDMngQm6FETfhdOEzdZIR2RtSBjCO9ashQFYwdIONbk=; b=rZOK4I1ySQ4evWYyDptev4fJ6pTSqndaoVeur3sMujgBA6nZ7jVl/0auaWxPh8vIGF /4Zcp/PLQeyUx3drkGHSGpwxQtbbhyqzLHAxNp4wrYT/KTQtwUVobfEys4PwD6QCs0Im Hapik5IBMQ8CZmhqojpDepT1qrOXUAaXVJm3WG6fWurB0fT12/PzhImGL47nMS9QLenn 8uL23cgL38fW8Ve+uLavKh0oG+ufBrRmbR0WuGs48kUhFn62TWxw/XUJWGvcMf4AEpc8 dKdPPk+hPTK/EKE/DxptPpQBcISMw4bhfCNT4Hah46EMK2r4RIU0O6mKRL+ueDc1T9hd irFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=WDMngQm6FETfhdOEzdZIR2RtSBjCO9ashQFYwdIONbk=; b=jDNfuCE7yet6PHOmTf9RLJqcul75w6YYcmuB/iqEWYtx+uFQsWbKujYJm5aBBEns2d nKSGGbilIQbbrnMGTMEmqugyn4VUfLrOdRnRGYN9HD+iY3TwRWnXKL5zzV8cHeMWxZOq UjzFNUSFLlVhL8D0NxfzWM/XmR8D4mEjRrFIbInIV1InQ5qPL17hinTOuMEpnud0hq6c kMCKNbVR7I26p6lMHKgNN8MsQKjXor7nazbgJP7bulx21+WzKJsKe02kYWF29peFvI1R 5DQLRBv0GhMb2kWcKkjPUh2D3bVibK3pIp82B4GwEpo6bWvotuP8fb94uaqRdQTW4ZMF XHvw== X-Gm-Message-State: AOAM533GuWi38EYXTiRsFfTFqo1XWnoGE97TMamJc8s+VV0JE2+d/SgD YHI6d//0mvoTCP4mv365cnc= X-Google-Smtp-Source: ABdhPJwF+c8u/BjNQS6DNJjNX6w3e1oh4VTr1dhJSfhLaMNSR1aIF82ehxgEXN/P2OOYzY1Up0nnZw== X-Received: by 2002:a05:620a:15cc:: with SMTP id o12mr13348921qkm.356.1603651884179; Sun, 25 Oct 2020 11:51:24 -0700 (PDT) Received: from ?IPv6:2607:fea8:5620:593::c734? ([2607:fea8:5620:593::c734]) by smtp.gmail.com with ESMTPSA id 198sm5238419qki.117.2020.10.25.11.51.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Oct 2020 11:51:23 -0700 (PDT) From: David Collier-Brown X-Google-Original-From: David Collier-Brown Reply-To: davecb@spamcop.net To: bloat@lists.bufferbloat.net References: <87k0ve5oqs.fsf@toke.dk> Message-ID: <3d9a2c9f-52f0-9b9d-1804-7f93d76960b9@rogers.com> Date: Sun, 25 Oct 2020 14:51:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <87k0ve5oqs.fsf@toke.dk> Content-Type: multipart/alternative; boundary="------------052AA75D5143D3A1A1D0855E" Content-Language: en-US Subject: Re: [Bloat] Detecting FQ at the bottleneck X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 18:51:24 -0000 This is a multi-part message in MIME format. --------------052AA75D5143D3A1A1D0855E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------052AA75D5143D3A1A1D0855E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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
--------------052AA75D5143D3A1A1D0855E--