From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 08BB93B25D for ; Sun, 3 Jul 2016 05:07:10 -0400 (EDT) Received: by mail-lf0-x22f.google.com with SMTP id l188so100909875lfe.2 for ; Sun, 03 Jul 2016 02:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/1HVh0HvVEZXlXqajPjHk8WK/xUX4GZj+pwHisvanxk=; b=i63xAGZtDiFyHEuTv7QAoQ4OqJlZpSsnSiybGNkRlPKS8w6X+CLBAJNfauF0n5iwQq +m3EOlx9OdhX35tl3PsNUNFDxM5y7Jfy+A1M4uHJJI2wpyrKQC1jwsmH4f/xRzpE1mWd mZlcM2XS0YbY+N23imlgxDv71lTs/ra9REKFomqZG0by2f2DNiS3AgPlnPYob8IOzPS4 R3vs/YoXJ7A6ZDpAzLtlHvDQJE82DthqxFzvi5PGQaL45scwOvJTQ6uCWIhJ1n/ojB9t dVVEqsLgSz2+hkcMPqvkjBUC7B3BeSq+JU/V4rHf+rI+UmxVKdvHLw9g/73+zSXstOGe 3SqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/1HVh0HvVEZXlXqajPjHk8WK/xUX4GZj+pwHisvanxk=; b=Zv2cyo7b56CABex9dV62f3XJlJhsmPVr1outsOt6OLzx1tpfis3GM6VZliGLfvr+WT hGgT5ehHS7wWXAQu8h/kTPMd3yZVgTgmIorKn0z1zxBoYirq4o3sOEfd2ywLzOqM5eu4 z1Lpxqv5owOOqjpixgml4mprlCaPufXVQ5XRufneReHNksUmF5NL+H4D9cH18uFZhUB7 a/n1TR5DDyHzah/4u1m5BRxi5lgFxLSMybLeTsSVQ1jyCRZXsjqPRd2c/lCPNm9vgyPh 9TK1ycXFCvUioGCLJIZ2W8MlfJ1A3PM1o2HBWgeRpJz1VBDzDoKgVe8qQdjcST8RdcPQ qxIQ== X-Gm-Message-State: ALyK8tIphfJ2HxlD0TG/drZYOxt6ZF511EuhN84efELPNKRlPd4L3HaZFq7qOQ3OJaSHzw== X-Received: by 10.25.84.73 with SMTP id i70mr1677380lfb.56.1467536829741; Sun, 03 Jul 2016 02:07:09 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-96-207.bb.dnainternet.fi. [37.33.96.207]) by smtp.gmail.com with ESMTPSA id u77sm3535791lja.18.2016.07.03.02.07.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Jul 2016 02:07:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Sun, 3 Jul 2016 12:07:06 +0300 Cc: Luca Muscariello , "make-wifi-fast@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <3F006EAE-7E18-4F08-AB2F-63EFC8695A4D@gmail.com> References: <87ziq2o07z.fsf@toke.dk> To: David Lang X-Mailer: Apple Mail (2.3124) Subject: Re: [Make-wifi-fast] On the 802.11 performance anomaly and an airtime fairness scheduler to fix it 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: Sun, 03 Jul 2016 09:07:11 -0000 > On 3 Jul, 2016, at 11:03, David Lang wrote: >=20 >>> do they delay the L2 Ack until the L4 ack comes back? If so, how = does that work on long-latency connections where it takes a long time = for the L4 ack to show up? >>=20 >> I=E2=80=99m pretty sure it=E2=80=99s only meant to work when the TCP = endpoint is local to the receiving station, assuring low turnaround = latency. This is the typical case, so it=E2=80=99s a win. >=20 > how is it the typical case that a wifi connection it to a local system = not to something over the Internet? Even in business settings, Internet = bound traffic can be the majority (cloud based e-mail, google docs, etc) >=20 >> With that said, there=E2=80=99s no fundamental reason why the = piggybacked L4 ack need be the one corresponding to the L2 ack. It just = needs to be a small packet that won=E2=80=99t unduly extend the airtime = occupied by the ack anyway, and which won=E2=80=99t mind being lost if = the L2 ack gets squashed. A scheme allowing a certain amount of slop in = this way would accommodate remote TCP endpoints as well as local ones. >=20 > Given the normal overhead of any txop, being able to piggy back a = small amount of real data at high speed with the L2 ack would be a = significant win in many cases. >=20 > For the common case of downloading from the Internet, the endpoint = system should be able to return a real L4 ack fast enough to piggy back = it on the L2 ack. >=20 > If that what is meant by the 'typical case'? Yes. I meant that, for example, a laptop performing a download would = both be the receiving station and the receiving TCP endpoint, which is = where TCP acks are generated. The fact that the *other* TCP endpoint is typically remote doesn=E2=80=99t= matter, because that is mostly sending data, not acks. - Jonathan Morton