From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5BB983B2A4 for ; Tue, 12 Jun 2018 19:04:53 -0400 (EDT) To: References: <345707C0-F15A-4CBB-A224-27C14BFEC0DF@apnic.net> <0376E49D-5BDC-45A7-83E9-01E4511DAE60@cablelabs.com> From: Anna Brunstrom Message-ID: <7cea36e4-fe1b-533b-8026-0d66ea40f145@kau.se> Date: Wed, 13 Jun 2018 01:04:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0376E49D-5BDC-45A7-83E9-01E4511DAE60@cablelabs.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ClientProxiedBy: Exch-A2.personal.kau (130.243.19.83) To Exch-A2.personal.kau (130.243.19.83) Subject: Re: [Bloat] geoff huston's take on BBR X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 23:04:53 -0000 On 2018-06-13 00:28, Greg White wrote: > > On 6/12/18, 8:39 AM, "Bloat on behalf of Geoff Huston" wrote: > > > > >I do agree that bbr treats aqm drops as "noise", not backpressure. And > >bbr scares me. > >I look forward very much to bbr one day soon doing some sort of sane, > >conservative, response to ecn marks. > > > I’m not sure that I understand this comment. > > Part of the pressure going on here is the issue of whether the endpoints can and should trust the signals and.or manipulation that they get from the network infrastructure. BBR is using a different form of feedback to control its send rate. Essentially BBR is taking a delay variance measurement 1 / 8 of the time to adjust its internal model of the end-to-end delay bandwidth product (every 8th RTT). ECN provides a constant information flow, and this certainly matches the requirements of loss-based TCP, where every ACK contributes to the TCP flow dynamic, but it does not seem to me to be a good match to BBR’s requirements. > > The idea with BBR is to drive the network path such at the internal routers are sitting just at the initial onset of queuing. In theory ECN will not trigger at the onset of queuing, but will trigger later in the cycle of queue buildup. > > [GW] That's "Classic" ECN. The proposed new version https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-02 starts marking right at the onset of queuing, which would allow a congestion controller to much more accurately stay right at the optimal congestion window, without all of the cycling phenomena and inferences that BBR uses. See https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-bbr-congestion-control-with-l4s-support-02 for work on BBR with L4S support by Ingemar Johansson. Or the second talk in the video from the session https://www.youtube.com/watch?v=rHH9wFbms80&list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS Cheers, Anna > > > > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat