From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f68.google.com (mail-pl0-f68.google.com [209.85.160.68]) (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 B48D43B29E for ; Mon, 25 Jun 2018 20:36:14 -0400 (EDT) Received: by mail-pl0-f68.google.com with SMTP id t6-v6so2277742plo.7 for ; Mon, 25 Jun 2018 17:36:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pt2eHxZXpIjAjZBLSLj1Ceb/YRAY86GR4phiLY95UMc=; b=L8DY5IttNsxpXJchKPd1XBVdp1Phmczkjv7Hn14qvrHvmvYQuU6/L78486egALU7xJ lQraFR04UVwmniSQSjS+2qHe8Bd2HIDaINLPZFK6rTNqZ9O1QK9oRUKxvnHK+rnwZGmF ut1SUv/nNLTlxCdDELAAIlwGCH3ZILfxFt/9bWbTaMaVR139epSnxrm/xYMb6OYgvliA 0xGeLnlFkrWq7Dm3vU3KtKbPWp9tGfaSPG1fvVqCMsLJpsu6w0ja+Ybk4bVSGX5Q9IkB 659hdaU1qMUqHxP6WksrNelGaydJPjCgsX9QTNbChJxkA7REzt/8AkMiCTgTsTbUEcrz /eLw== X-Gm-Message-State: APt69E0Cu5goi5aSLxLSP1weoHhQvao4ug1XZmgWNdyCRWlJoR/gswKj q+PQeNWGmc1a/ZGM6Bw5f2k= X-Google-Smtp-Source: ADUXVKLsufHYODjfa8wb7/C+Py87UR4FCqAF9Dev7C2z8FL+5FCFGEatiB1Mg6Xfe7FSyjPxQK5w9w== X-Received: by 2002:a17:902:20ca:: with SMTP id v10-v6mr14240727plg.255.1529973373766; Mon, 25 Jun 2018 17:36:13 -0700 (PDT) Received: from [192.168.25.18] (184-23-135-132.dedicated.static.sonic.net. [184.23.135.132]) by smtp.gmail.com with ESMTPSA id d132-v6sm227800pga.10.2018.06.25.17.36.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 17:36:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Simon Barber In-Reply-To: Date: Mon, 25 Jun 2018 17:36:11 -0700 Cc: Jonathan Morton , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> <25305.1529678986@localhost> <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com> <18224.1529704505@localhost> <87muvjnobj.fsf@toke.dk> <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com> To: David Lang X-Mailer: Apple Mail (2.3445.6.18) Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved 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: Tue, 26 Jun 2018 00:36:14 -0000 Most hardware needs the packet finalized before it starts to contend for = the medium (as far as I=E2=80=99m aware - let me know if you know = differently). One issue is that if RTS/CTS is in use, then the packet = duration needs to be known in advance (or at least mid point of the RTS = transmission).=20 Simon > On Jun 25, 2018, at 5:21 PM, David Lang wrote: >=20 > On Tue, 26 Jun 2018, Jonathan Morton wrote: >=20 >>> We only care about conserving txops when they are scarce, not when = they are abundant. >>> This principle is why a window system as crazy as X11 is = competitive: it naturally becomes more efficient in the face of load = (more and more requests batch up and are handled at maximum efficiency, = so the system is at maximum efficiency at full load. >>> Or am I missing something here? >>=20 >> The problem is that currently every data aggregate received (one TXOP = each from the AP) results in two TXOPs just to acknowledge them, the = first one containing only a single ack. This is clearly wasteful, given = the airtime overhead per TXOP relative to the raw data rate of modern = wifi. Relying solely on backpressure would require that the channel was = sufficiently busy to prevent the second TXOP from occurring until the = following data aggregate is received, and that just seems too delicate = to me. >=20 > If there are no other stations competing for airtime, why does it = matter that we use two txops? [1] >=20 > If there are no other stations that you are competing with for = airtime, go ahead and use it. If there are other stations that you are = competing with for airtime, you are unlikely to get the txop = immediately, so as long as you can keep updating the rf packet to send = until the txop actially happens, the later data will get folded in. >=20 > There will be a few times when you do get the txop immediately, and so = you do end up 'wasting' a txop, but the vast majority of the time you = will be able to combine the packets. >=20 > Now, the trick is figureing out how long we can wait to finalize the = rf packet >=20 > David Lang >=20 >=20 > [1] ignoring the hidden transmitter problem for the moment) > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat