From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 59E263CB69 for ; Mon, 6 Jul 2020 13:01:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594054905; 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=IvXqD6+F6XdUXB3nkAKtQ3BIwdtSoTfIh2jDpkcbz5wU7s9nn66KkYaxfyXrjgWR5e9Buk zNIKHXXgqoNXmB/AD6D5nV00q7B6a2F6DypslIXS9SYTWd6OtwFIAazfTaTA9bJAYHLzPH AyMWZThs7pALnWtV4QN4vRs/BNoTops= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-414-Jbu8bWFjOfu_fhtSx5llOw-1; Mon, 06 Jul 2020 13:01:40 -0400 X-MC-Unique: Jbu8bWFjOfu_fhtSx5llOw-1 Received: by mail-pg1-f198.google.com with SMTP id z187so30205316pgd.11 for ; Mon, 06 Jul 2020 10:01:40 -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=gqqY5HiKRREGigSzatZkl7K3rsOXFp0jLZ/WDBceyLTPLEzqculTNkEN+FwMAVQ2my 85Xy5DbCyECBXoR2X3S4edvD+D49k1aDGBzvN/F/0DHhQHgWNNw9n1q5o64MRoFP/PS5 GCDOsauq5MKBNwKuyNhl0F3cvaYt8ImEZ+4hTvxt3yWT7o5Qc42c3PsJQBddflEvM/2O g6QaKIKk4OyTe/NVI0P1thE53nSXlu303FRFXzxBvSqYlW8M1/NLjq5Ab7E1K2LKEyCg J/W22IJ7Ar5aC+NLWRQLjUQRNbOYTNHzOcewExGbGcBJDoHJG/01eC7HpwDDd5pXpWGx an6Q== X-Gm-Message-State: AOAM531ii/t09XhBlCTK/RHskRgXDAxgB2JdP8NjyojOw2qoKFDILqo2 b5vE4sSJt8ZYJ7SDCZKCTh6Ika9vC/dup2WEBa5A1B43mDDAUKZngQgYHplSA8dRVGSHTp8xekf 1sAeKDk6KTUOx4QiLCpja0r85V1lWZsjLg+M= X-Received: by 2002:a17:902:7c8b:: with SMTP id y11mr39961150pll.53.1594054899111; 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: [Make-wifi-fast] [Bloat] the future belongs to pacing X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:01:45 -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