From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6018C3B2A4 for ; Thu, 21 Jun 2018 15:51:55 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1529610714; bh=icNSyxnEbIFXKtoRzWNR7VyiB3iMET6j1JpEfoLcTSg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cIGTWY7tKMeBqWziLfrnPoQR+yUevlWszsNa8sNWRuXggnNPHJ08VnokRLI2cWl4Z TDBE7pxoPFSx/yj7RJrpfSHsf/Wf9LPrzS/6FkloZ3P5JxWwzebkRCbHYsosp9pAtQ Vl7kmPAPszTMjiItGUlJOjZT2dZ8QNEWoqxCELOUfWg20XXvOe73dc457dl3IbaWcq tjdSk7nFuOonYuMMWatao2mpljiNnpeIoN6aUmzRm7Q13F+vGNxwekUq8w3Ju1/gii 0YX6mOe/xTU9YRW8rnUH/A9pYecGS0AFXCo33DKU8w+sH4fEci0AigZIKj/CL7lho+ F1lSKFEU6G8pQ== To: Sebastian Moeller , Dave =?utf-8?Q?T=C3=A4ht?= Cc: bloat In-Reply-To: <6DCE29AF-5F91-4F06-93A8-0F5D197C9D06@gmx.de> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <6DCE29AF-5F91-4F06-93A8-0F5D197C9D06@gmx.de> Date: Thu, 21 Jun 2018 21:51:55 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zhznq5no.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 21 Jun 2018 19:51:55 -0000 Sebastian Moeller writes: > To make up for the fact that wireless uses unfortunately uses a > very high per packet overhead it just tries to "hide" by > amortizing it over more than one data packet. How about trying > to find a better, less wasteful MAC instead ;) (and now we have > two problems...) Now really from a latency perspective it > clearly is better to ovoid overhead instead of use "batching" to > better amortize it since batching increases latency (I stipulate > that there are condition in which clever batching will not > increase the noticeable latency if it can hide inside another > latency increasing process). Seems that 802.11ax will have some interesting features to this end. Specifically, the spectrum can be split, allowing smaller chunks of it to be used for reverse path transmissions (full-duplex at last?). https://en.wikipedia.org/wiki/802.11ax#Technical_improvements Also, 1024-QAM on 160Mhz channels; omg... -Toke