From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8BC983B2A4 for ; Mon, 6 Jul 2020 13:01:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594054902; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NxjG6IKFcXRQjqIHGWMzcQhRNuuLgVa1Vj8wnSHk4Cs=; b=Imrd/PURSi/U7rGLPz4nh7F6D6AsgOLxWjJFjgy0+HERAlNji/3e4jdnJydH9SAUyzDtOo hXO6PapFWDZI7/y9r4XeBf2NuMRbqKPS1pft0uE0Gq98mkUMyAqJdEpMPRELfrIumbkzC9 7fpTjBmW3i9/ZF4Ae9bNPvypHUXU/AQ= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-eEedkdEaP9ao5Tagj10l_w-1; Mon, 06 Jul 2020 13:01:40 -0400 X-MC-Unique: eEedkdEaP9ao5Tagj10l_w-1 Received: by mail-pf1-f198.google.com with SMTP id x62so1047386pfc.20 for ; Mon, 06 Jul 2020 10:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=NxjG6IKFcXRQjqIHGWMzcQhRNuuLgVa1Vj8wnSHk4Cs=; b=KRszAWCYL/3bzBwE1pldEBpUaJ6SJJb4yrj2VQ/sz0kAtDFRvKznameMccnSmeJs+4 oKKzn7Zu5xmsnnD4IoEVP5GpZlbl1T9OMog7il5cE43hnIbVoUQfFyQN26uHUfW4D6e3 4hgKYK1BoAMfZ9UlywTZXtDqW0Bsj2/8aOOVQXWX31zeL8ezZITqeAL0+Mm7zSCy0EdL lSAkEiV8SHzUtBFxh8y9pOGJSJNHhzvwEjf9ju8yHTz5E6iB/V9q4WkaN9qJFV16RqgH lAHJuUioy3EvMHA6ee3zECSDTkfHSYAKBrgEOs6Ecqnwd9rsqKxbaDkdWBMFW0wPvwVY vPTw== X-Gm-Message-State: AOAM5302jYA9sFym6voMNq/EmfouDpiGvUdDaWc1TNRb4EU4k/lTTfx1 tUa52aFlDGvqn3HZOw/VG4KxtE4SXJCeVDZpyA2yXwK7A+XMviLOxaRjMLU66XBJL90JigWdtqJ iad+vCQrmKZc5nFlXuXM4jr8= X-Received: by 2002:a17:902:7c8b:: with SMTP id y11mr39961144pll.53.1594054899062; Mon, 06 Jul 2020 10:01:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbeiyfiX57RzxvtBUYNA0ppKXRhbiC0cyWHxn7JVpRDUa7axFC9a7HwFza81IHYBKLNP7HHQ== X-Received: by 2002:a17:902:7c8b:: with SMTP id y11mr39961128pll.53.1594054898784; Mon, 06 Jul 2020 10:01:38 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id v10sm3416149pfc.118.2020.07.06.10.01.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2020 10:01:38 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 284E31804ED; Mon, 6 Jul 2020 19:01:33 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Daniel Sterling , Luca Muscariello Cc: Make-Wifi-fast , Carlo Augusto Grazia , bloat , jamshid@whatsapp.com In-Reply-To: References: X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 06 Jul 2020 19:01:33 +0200 Message-ID: <87o8oslgr6.fsf@toke.dk> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=toke@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [Bloat] [Make-wifi-fast] the future belongs to pacing 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: Mon, 06 Jul 2020 17:01:42 -0000 Daniel Sterling writes: > On Mon, Jul 6, 2020 at 10:09 AM Luca Muscariello wrote: >> If BBR can fix that by having a unique model for all these cases that would make deprecation, as intended in the paper, >> likely to happen. > > Interesting! Thank you all for helping a layperson like me understand. > > Obviously getting CC / latency control "correct" under wifi is a > difficult problem. > > I am wondering if you (the experts) have confidence we can solve it -- > that is, can end-users eventually see low latency by default with > standard gear? > > Or are shared transmission mediums like wifi doomed to require large > buffers for throughput, which means low latency can't be something we > can have "out of the box" -- ? Is sacrificing throughput for latency > required for "always low" latency on wifi? To a certain extent, yes. However, this is orthogonal to the congestion control being used: WiFi gets its high throughput due to large aggregates (i.e., 802.11ac significantly increases the maximum allowed aggregation size compared to 802.11n). Because there's a fixed overhead for each transmission, the only way you can achieve the maximum theoretical throughput is by filling the aggregates, and if you do that while there are a lot of users contending for the medium, you will end up hurting latency. So really, the right thing to do in a busy network is to lower the maximum aggregate size: if you have 20 stations waiting to transmit and each only transmits for 1ms each instead of the maximum 4ms, you only add 20ms of delay while waiting for the other stations, instead of 80ms (best-case, not counting any backoff from collisions, queueing delay, etc). -Toke