From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <toke@toke.dk>
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 EEDD93B29E
 for <make-wifi-fast@lists.bufferbloat.net>;
 Fri,  1 Dec 2017 07:48:23 -0500 (EST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023;
 t=1512132500; bh=2L2xYSLRrvhC0hpADyCav9nrRXOHik5vpc+I6t/7PkA=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=iv7jfloXLIGgUGmlEwog6TlKvWuv/0c/RhFsH0IROBAozq2dcX6Jlim/exOsFR+vk
 09qaOd89Slx76FwvTsjM9VUaERtYjVkaVnNVagp/Nl/Zb8X3232jxXuRuaL5jxvOCH
 Vwcb6agvCOPPNQfv7eTed3zSH31OqruQJ4HciI2dalRx21XgOo6ateLCrDoz3F50Vy
 rGR2UcDz+1gRnJkXE5x5Rl+r9c172zz1mzzgYIJZuGtJuC3A9QK8xzdfKvFEldeN5L
 jt0z6IoB9nHEr0sbGEblLaQVDm9LujTwB9CVtmN61r1KpF0aVCoPKafz+abqLw31SH
 AvsFExmyFyvYw==
To: Simon Barber <simon@superduper.net>
Cc: Jonathan Morton <chromatix99@gmail.com>, Dave Taht <dave.taht@gmail.com>,
 make-wifi-fast@lists.bufferbloat.net
In-Reply-To: <97FED3CC-CFF8-47EE-987B-81771EDB6128@superduper.net>
References: <87lgionrl5.fsf@toke.dk>
 <CAA93jw4kcc8xDqXKBKO8JghEHxw8t=RxxY4OYsAEQhK_O5teLg@mail.gmail.com>
 <CAA93jw7bGf5_Yd6LQ==DaVcJSwLi1N1UCe1f-M4gMBgQ1U98JA@mail.gmail.com>
 <CAJq5cE2v+uQnc3qsAeqbp9SJYOo1gaN6EU-Hdkb1J2-t5YNO3A@mail.gmail.com>
 <87po80407u.fsf@toke.dk>
 <CB2657DF-6CC1-40C7-A22C-FB5CD5DCE098@superduper.net>
 <F03A75BA-B098-4F4F-99E1-84BBC2F9C56E@toke.dk>
 <97FED3CC-CFF8-47EE-987B-81771EDB6128@superduper.net>
Date: Fri, 01 Dec 2017 13:48:19 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87374u4nsc.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Make-wifi-fast] Fwd: Re: [iccrg] TCP behavior across WiFi
	pointers ?
X-BeenThere: make-wifi-fast@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: <make-wifi-fast.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/make-wifi-fast>
List-Post: <mailto:make-wifi-fast@lists.bufferbloat.net>
List-Help: <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 01 Dec 2017 12:48:24 -0000

Simon Barber <simon@superduper.net> writes:

> Certain things, yes, others - not so much. No congestion control for
> example. It=E2=80=99s very much the common case that the wireless client =
is
> the TCP endpoint, and it=E2=80=99s rare to see drops, but they do happen.
> FastACK keeps the TCP ACK rate controlled by the wireless bandwidth,
> unlike a proxy. This is the key innovation here.

Right, actually went and read the paper now. Seems clear enough; a few
questions, though:

- From figure 12 it looks like you are also implicitly doing ACK
  compression? I.e., if you get two packets with seq n and n+1 you will
  only send an ACK back to the sender for n+1?

- Did you measure the latency impact of FastACK? You mention you will do
  that once it's deployed, but does that mean you didn't measure this at
  all in the testbed?

-Toke