From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 D04DC3B29E; Fri, 1 Dec 2017 08:17:08 -0500 (EST) Received: by mail-qt0-x232.google.com with SMTP id a16so12928893qtj.3; Fri, 01 Dec 2017 05:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tqNe+EiENOTIbe2QURLkUaxvatg/lh5tBkSWC8GFWvI=; b=qlNaNbrS+IKng3MQonH8ZU5DQTysg4H2+elJz2agQzXKENiVLFXokbm14wEj8YWI0J sWW2uYJFhLgP+PuNlisbp9IruuimgDC0l/3loks/Zhupt8MXWXYoqM48Q5myClUeg1u0 HkCrnJNRZ3nZ8Y19YI0KxzfuA6/5oSakOE48vVruaxrNvkeTdLvbNUe1c32OcnzS4Swo 9pXmBOAFwNAi06IX/4UkeGeTJTduvYOS+ARvPyTP4DYpxh1oKL/lmag4o3OS40PKTUjK GMAbhd3afIrldYRhv6T/rX4Ul2eQsytqI1BQ3L7p2uGN3nTOnDur+lKexpjfxh9vf/QR +83g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tqNe+EiENOTIbe2QURLkUaxvatg/lh5tBkSWC8GFWvI=; b=tgoFLL3JNY5WMt227V77B1/7hLKdLYC7ffazszzZQu9l95UXwh9iKXp4GlQm8//orA 5PGSRJymtfHFTcCwPq7JMlRUN3wfBRJF1rkO3+TiGvV3E7KxkuNxekTswjOz9zdTPBGn 2QzL9byNoVFfzq4w6YlvZZLdUPO6HZwfXRCAhxL0DAFmVCdi3Op5VbbM4QaRRsVApwvt 8coHz+lq/4XHx/ESryVijwXcb7TWrln0BmUfp+KIP+HcqhwHBAXbk9gBbJx13B9yZfax C7fIb3b/rsibbMHsgaTXHyTsEMYHgU06cpYOjj3IqNMfHt88nb0EAeTUS+JYrQWdDtjj kC9A== X-Gm-Message-State: AKGB3mLAn/2mMe0ihuGVM6AivvjSDobvpVfTDYhFhQNwRLfdVg1YAGfW sRx/YrK1onO5wxKbZ0LANn2N6/XswM/OjtwqiQ8= X-Google-Smtp-Source: AGs4zMbbJtsynl9SXm9UmAoWmrgX1vyGT4mHz02fZ8ILFgpvbOhgdvDNSlBgMt2SDHnmqCvLpvwUNE1derBQKBgMAZU= X-Received: by 10.237.37.85 with SMTP id w21mr8649712qtc.268.1512134228413; Fri, 01 Dec 2017 05:17:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Fri, 1 Dec 2017 05:17:07 -0800 (PST) In-Reply-To: <87wp2638yo.fsf@toke.dk> References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> <1512037480.19682.10.camel@gmail.com> <6b494910-1373-afb0-5b93-99b725391fb3@gmail.com> <87wp2638yo.fsf@toke.dk> From: Luca Muscariello Date: Fri, 1 Dec 2017 14:17:07 +0100 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Jan Ceuleers , bloat , make-wifi-fast@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="001a1141fd728991db055f472f23" Subject: Re: [Make-wifi-fast] [Bloat] benefits of ack filtering 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: Fri, 01 Dec 2017 13:17:08 -0000 --001a1141fd728991db055f472f23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I understand the text right, FastACK runs in the AP and generates an ACK on behalf (or despite) of the TCP client end. Then, it decimates dupACKs. This means that there is a stateful connection tracker in the AP. Not so simple. It's almost, not entirely though, a TCP proxy doing Split TCP. On Fri, Dec 1, 2017 at 1:53 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Jan Ceuleers writes: > > > On 01/12/17 01:28, David Lang wrote: > >> Stop thinking in terms of single-flow benchmarks and near idle > >> 'upstream' paths. > > > > Nobody has said it so I will: on wifi-connected endpoints the upstream > > acks also compete for airtime with the downstream flow. > > There's a related discussion going on over on the make-wifi-fast list > related to the FastACK scheme proposed by Meraki at this year's IMC: > > https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf > > It basically turns link-layer ACKs into upstream TCP ACKs (and handles > some of the corner cases resulting from this) and also seems to contain > an ACK compression component. > > -Toke > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a1141fd728991db055f472f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I understand the text right, FastACK runs in the AP and= generates an ACK on behalf (or despite) of the TCP client end.
Then, i= t decimates dupACKs.=C2=A0=C2=A0

This means that t= here is a stateful connection tracker in the AP. Not so simple.
I= t's almost, not entirely though, a TCP proxy doing Split TCP.


= On Fri, Dec 1, 2017 at 1:53 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk= > wrote:
J= an Ceuleers <jan.ceuleers@gmai= l.com> writes:

> On 01/12/17 01:28, David Lang wrote:
>> Stop thinking in terms of single-flow benchmarks and near idle
>> 'upstream' paths.
>
> Nobody has said it so I will: on wifi-connected endpoints the upstream=
> acks also compete for airtime with the downstream flow.

There's a related discussion going on over on the make-wifi-fast= list
related to the FastACK scheme proposed by Meraki at this year's IMC:
https://conferences.sigcomm.o= rg/imc/2017/papers/imc17-final203.pdf

It basically turns link-layer ACKs into upstream TCP ACKs (and handles
some of the corner cases resulting from this) and also seems to contain
an ACK compression component.

-Toke
_____________________= __________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--001a1141fd728991db055f472f23--