From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 8296E3B25D for ; Sun, 3 Jul 2016 03:53:53 -0400 (EDT) Received: by mail-yw0-x22c.google.com with SMTP id l125so19396077ywb.2 for ; Sun, 03 Jul 2016 00:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fR39g8wAfp9bPIe36Trt6V7Uk7AOLnJiRxaBQNqEhus=; b=iKMxowX4i34V/0wUIP5W3DW4YZ/kkNR+tu6O5ABA9LzHLAK9i9jOCvCFpkxifM5SvF XaBZqUYVH+T/b3OJXu+D3TAIP21yK7CfQBGwzltH9nqBrlRG1abdqjmpb7xb1E6ku0+J n0FBdLdv/SLuWsl9EqBqldNo03l1utzf7dckpyO45XxKBSEZMS+G3qilzh5U+OwRtowv GxY/9sVTynvpdnSsxkntpvxdePeY8qWJb5wnDo90ZE4HN07hqRtZHezx8Y2yIP6SqRiM KZYBgCfQP3LHEOUXvBHqh/jpGs2QPFuACWksIdTM02OOUUopURxbXHwtiupcDCfVcd2a fEWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fR39g8wAfp9bPIe36Trt6V7Uk7AOLnJiRxaBQNqEhus=; b=WeaEJbCFfebxAfER5PTVm7R5wonwzGztJoed+uPHCXIhmz8AhLPWq+l+3YuKOU8c2s sJdIZq285ydkgzSqXS37LIhx82wAPm5ZF/jbszYTigIyhqJil6j1TvafxTFC0oV78Af1 +v0omzwXFpzD+q2M2AEU3Vd21llHa9NVJ69EP6tETjwh4p72TZmof/JtPNeqEACG6cbp ueM/EoPqnpKo7kbYZs2baZfv5yY37LNG4j8qc4k1JYtm6B7ch0vGOIDFaD/aWpa9U0VT O7g6nuviyeMdlTntAoomrKQ+GZFcsRcDrDcw6UnLhch+2738kW197o5gjs2vrdzkoNam 3Lkw== X-Gm-Message-State: ALyK8tKkje9rN8Ckl7K7j6HX7BkdPV14mUpj34pe2xmqJjrTYa3+Uv6aq7kwx0HyG954JFdNWj3OVPsG/7Ku3g== MIME-Version: 1.0 X-Received: by 10.129.50.83 with SMTP id y80mr3962315ywy.305.1467532432974; Sun, 03 Jul 2016 00:53:52 -0700 (PDT) Received: by 10.37.74.134 with HTTP; Sun, 3 Jul 2016 00:53:52 -0700 (PDT) In-Reply-To: References: <87ziq2o07z.fsf@toke.dk> Date: Sun, 3 Jul 2016 09:53:52 +0200 Message-ID: From: Luca Muscariello To: Jonathan Morton Cc: David Lang , "make-wifi-fast@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=001a11421de65d2b650536b685eb 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 07:53:53 -0000 --001a11421de65d2b650536b685eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://www.usenix.org/system/files/conference/atc14/atc14-paper-salameh.pd= f The paper I mentioned. Usenix ATC'14 not NSDI. On Sunday, 3 July 2016, Jonathan Morton wrote: > > > On 3 Jul, 2016, at 10:06, David Lang > > wrote: > > > > 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? > > I=E2=80=99m pretty sure it=E2=80=99s only meant to work when the TCP endp= oint is local to > the receiving station, assuring low turnaround latency. This is the > typical case, so it=E2=80=99s a win. > > 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 a= nyway, and > which won=E2=80=99t mind being lost if the L2 ack gets squashed. A schem= e allowing > a certain amount of slop in this way would accommodate remote TCP endpoin= ts > as well as local ones. > > - Jonathan Morton > > --001a11421de65d2b650536b685eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://www.usenix.org/system/files/conference/atc14/atc14-pa= per-salameh.pdf

The paper I mentioned.
Use= nix ATC'14 not NSDI.




On Sunday, 3 July 2016, Jonathan Morton <chromatix99@gmail.com> wrote:

> On 3 Jul, 2016, at 10:06, David Lang <david@lang.hm> wrote:
>
> 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?

I=E2=80=99m pretty sure it=E2=80=99s only meant to work when the TCP endpoi= nt is local to the receiving station, assuring low turnaround latency.=C2= =A0 This is the typical case, so it=E2=80=99s a win.

With that said, there=E2=80=99s no fundamental reason why the piggybacked L= 4 ack need be the one corresponding to the L2 ack.=C2=A0 It just needs to b= e a small packet that won=E2=80=99t unduly extend the airtime occupied by t= he ack anyway, and which won=E2=80=99t mind being lost if the L2 ack gets s= quashed.=C2=A0 A scheme allowing a certain amount of slop in this way would= accommodate remote TCP endpoints as well as local ones.

=C2=A0- Jonathan Morton

--001a11421de65d2b650536b685eb--