From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 657763B2AE for ; Thu, 29 Sep 2016 16:44:01 -0400 (EDT) Received: by mail-it0-x22b.google.com with SMTP id u134so7732201itb.1 for ; Thu, 29 Sep 2016 13:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qTV2mCl62Cb1JKf9boYDOtT8BBvvCLoAqSrHLONg7eo=; b=fVSrDdd9O5GbwAqGhHtjYIuD3XvsdHs/5VjZBFIiXKf1g+Tson9XiuGKzcADh5oK3i cKDbHinyDO/Dy8ROFzubwaiuDYbB0Rq5jnP1xV54fSmsA4SVNwXvRWW7Drw3EH27+YVE vnWrwtThW7o08s2IpRXcJBaaz08FPMsOLzd8htrpW/zLFCfKJQP2BZVwcZku3StCanTt fip+ATmfku1nCe4dG1emnm9/JdLhTdgdhRSSH6oIY6i+Z55LzYqMapYtaI4LhmPKJMEM yzH7DlOgxNDa2OR7OJYP+ACUarsCPS7ZuHd7gZGPvV+PsGN5YvFgc8fqqimnaA+OvdBJ ozCA== 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:from:date :message-id:subject:to:cc; bh=qTV2mCl62Cb1JKf9boYDOtT8BBvvCLoAqSrHLONg7eo=; b=Ml92XyBw+pHkqJwglVWJZsRpRUk/qi4pezDA3LSGfdHi9cK94L2IPqMnOHxzptVmLJ /X155Gl6Emgusp+uo2hBDoVreIn0kPyXbyu5zfLpe9qwHoTU33LRlunjPRhbTr7VsrCt 5xktOyHEh7FTjEW8ie6BiIXTl/oVangcJ2GotD65O/e/5twtqJNYgpNIIWTYCQYGCHX0 TlncWfJzeaHnvhJp41Vof42l9PwUB7qmhb77cuvBo2rzyB9iXNbtjK8o2LON0Kch3PAs 6Lt3oavFZZu8f6o1tpQOt1m9JiNGW0gJUNots0QaRk/P5/LfLFmKoxBvivJoSKLy4rGe OTGg== X-Gm-Message-State: AA6/9RlxmLsQR1eZvLHjaOZjsODQ73JHCwNSGYraGfUpuWzduNAZZSA5g/guWLIaFh9Qgw7BfOtepFwDiojwqA== X-Received: by 10.107.172.4 with SMTP id v4mr5708576ioe.49.1475181840808; Thu, 29 Sep 2016 13:44:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.126.72 with HTTP; Thu, 29 Sep 2016 13:43:40 -0700 (PDT) In-Reply-To: <6D370F33-92FF-42D0-AE6F-3425AE9DAFA3@gmail.com> References: <32E6B0A0-6014-4510-9D97-02645F0EFDFD@gmail.com> <27B5A7E3-203D-468F-B487-BFFC9294D857@gmail.com> <6D370F33-92FF-42D0-AE6F-3425AE9DAFA3@gmail.com> From: Andrew Shewmaker Date: Thu, 29 Sep 2016 14:43:40 -0600 Message-ID: To: Jonathan Morton Cc: Dave Taht , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=94eb2c058e7499c1d7053dab892d Subject: Re: [Cake] cake for net-next 4.8 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 20:44:01 -0000 --94eb2c058e7499c1d7053dab892d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 28, 2016 at 5:34 PM, Jonathan Morton wrote: > > > On 29 Sep, 2016, at 02:26, Dave Taht wrote: > > > > All along I'd been assuming > > that a specialized TCP of some new flavor yet-to-be-agreed-upon would > > negotiate ECN and most/all its packets would be marked ECT(1), rather > > than ECT(0), and a new AQM would treat a flow like that differently, > > but still mark that flow with a CE that the endpoint would interpret > > differently. > > > > Are you saying ECT(1) would, instead, be used as a "weaker or harder" C= E? > > The former appears to be the solution TCP Prague are keen on. It doesn= =E2=80=99t > seem like a robust, deployable solution to me, despite the tremendous > amount of effort that=E2=80=99s gone into that class of solutions. > > The latter is my suggestion - to use the distinction between ECT(0) and > ECT(1) as a hint, rather than a command, to slow down. I also think we > should move computation of the congestion window to the receiver, as that > greatly simplifies the reverse-path signalling problem. > I agree that there's some big potential advantages to that. But I wouldn't say the congestion window calculation should be moved to the receiver, so much as duplicated by the receiver. Here's a link to a receiver-side congestion control patch I've been working on: https://github.com/systemslab/tcp_inigo/tree/master/inigo_receiver It uses TCP timestamps to keep track of the accumulated differences in one way delays, and adjusts the receive window similarly to DCTCP. The mininet tests I've run show some promise making CUBIC and Reno share more fairly and tightening up their RTT distribution, but I need to do a lot more testing. I'm looking forward to Eric Dumazet's usec resolution time stamp support being upstreamed so that my receiver-side technique might become useful in data centers. > You may remember my description of ELR. I started documenting it more > formally, and then got distracted by something more urgent... > > - Jonathan Morton > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Andrew Shewmaker --94eb2c058e7499c1d7053dab892d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 28, 2016 at 5:34 PM, Jonathan Morton <chromat= ix99@gmail.com> wrote:

> On 29 Sep, 2016, at 02:26, Dave Taht <dave.taht@gmail.com> wrote:
>
> All along I'd been assuming
> that a specialized TCP of some new flavor yet-to-be-agreed-upon would<= br> > negotiate ECN and most/all its packets would be marked ECT(1), rather<= br> > than ECT(0), and a new AQM would treat a flow like that differently, > but still mark that flow with a CE that the endpoint would interpret > differently.
>
> Are you saying ECT(1) would, instead, be used as a "weaker or har= der" CE?

The former appears to be the solution TCP Prague are keen on.=C2=A0 = It doesn=E2=80=99t seem like a robust, deployable solution to me, despite t= he tremendous amount of effort that=E2=80=99s gone into that class of solut= ions.

The latter is my suggestion - to use the distinction between ECT(0) and ECT= (1) as a hint, rather than a command, to slow down.=C2=A0 I also think we s= hould move computation of the congestion window to the receiver, as that gr= eatly simplifies the reverse-path signalling problem.
=
I agree that there's some big potential advantages to= that. But I wouldn't say the congestion window calculation should be m= oved to the receiver, so much as duplicated by the receiver. Here's a l= ink to a receiver-side congestion control patch I've been working on:

https://github.com/systemslab/tcp= _inigo/tree/master/inigo_receiver

<= div class=3D"gmail_default">It = uses TCP timestamps to keep track of the accumulated differences in one way= delays, and adjusts the receive window similarly to DCTCP.

The mininet tests I've run show some = promise making CUBIC and Reno share more fairly and tightening up their RTT= distribution, but I need to do a lot more testing.

I'm looking forward to=C2=A0Eric Dumazet's=C2=A0usec resolu= tion time stamp support being upstreamed so that my receiver-side technique= might become useful in data centers.


You may remember my description of ELR.=C2=A0 I started documenting it more= formally, and then got distracted by something more urgent...

=C2=A0- Jonathan Morton

_______________________________________________
Cake mailing list
Cake@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake



--
=
Andrew Shewmaker
--94eb2c058e7499c1d7053dab892d--