From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 7C5EE3B2A3 for ; Sat, 29 Apr 2017 00:32:24 -0400 (EDT) Received: by mail-lf0-x241.google.com with SMTP id x72so8776538lfb.1 for ; Fri, 28 Apr 2017 21:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7P5ozHMesfIRsC3HOrKD+Z88rrJuGAajod4nj0yZh7E=; b=jQHSoaP4nTX8LI69hGoZolkoEIOLZ1D7i54UCOKUkKl/jP5MjIiHudNnkzjODu6bk4 Sv+R1gQeKSYkiSBcirQIvRtuYwhKFGtHe6LavRyaCeomw1pq3FcTsae0RoQaqJ0f+Mi7 nCvel/YTavjzo2/xa0uKjZwy4QrdsLtF+JvPuwnImgajg4CCZbOhOqt5RLK9uLqq3cyy AZ4u3+xenvbtiurCOHSeLhUcBAnUlbXecwcwqxpdcgT6AQQE96VziRZzDYwpU/89cNtx al5DnZwECAcy9lEtG2sqoAUJgb8LbVZPKtmNa24y3ItjjcRPKYKthnJ+Uiu1fKpKV14l +rmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7P5ozHMesfIRsC3HOrKD+Z88rrJuGAajod4nj0yZh7E=; b=YJOFLjv/NgADGAP2ez30tg1qa7/4CPxlGV5aJN/vmT2ckZVpNkcM/fPvBJ9zA5wy3N lpRERJ1SN7r63+YH5ZX+9nCABasiKhv15NR68CcUfehoH0+Om2ZW2xAFc2/nfbi7X6/m 1urrWe13XuJffubsWbQuHkVzR3J2Em4JS0nseYP7IXSKJtD+UYISQNHlnQ/klfObYHhP wdDavcYVJCu1o/pzicDqzW4MbdRmEccOAhShWv9i/wZdH/jzO+74Xn8cX8SQ5BdRRXBg ZF4W8NNBpxuz+TG3rYHxq8cyKmtjca405I8Pmw8dX99MUU+A4R6+nJAUoS0XC8zdYU7N 4qUw== X-Gm-Message-State: AN3rC/4FM+VSn7c53Zh3AcJQ6FUQBXeHVZEPy6+mrtw1pVXnfhFXhOZj Ko6vLMvexcIXJA== X-Received: by 10.25.160.147 with SMTP id j141mr4395248lfe.19.1493440343046; Fri, 28 Apr 2017 21:32:23 -0700 (PDT) Received: from [192.168.100.12] (37-219-103-185.nat.bb.dnainternet.fi. [37.219.103.185]) by smtp.gmail.com with ESMTPSA id f195sm1381444lfe.63.2017.04.28.21.32.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Apr 2017 21:32:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> Date: Sat, 29 Apr 2017 07:32:19 +0300 Cc: xnor , David Lang , Cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <77335E95-3774-4F55-BD78-50335D811603@gmail.com> References: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> To: Andy Furniss X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] cake default target is too low for bbr? 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: Sat, 29 Apr 2017 04:32:24 -0000 > On 29 Apr, 2017, at 01:26, Andy Furniss wrote: >=20 >>>> As I understand it, increase in RTT due to queueing of packets is >>>> the main feedback mechanism for BBR. So dropping packets, which I >>>> already consider harmful, is really harmful with BBR because >>>> you're not telling the sender to slow down. Actually, BBR considers mainly a measurement of =E2=80=9Cdelivery = rate=E2=80=9D, and paces its sending to match that. It does *not* = primarily rely on a congestion window as most TCPs do; one is provided = only as a safety net of last resort. Measurements of RTT are mostly used for two purposes: to size the = congestion window so that it doesn=E2=80=99t interfere with normal = operation; and to estimate when =E2=80=9Cqueue draining=E2=80=9D is = complete after a bandwidth probe cycle. >>> If BBR does not slow down when packets are dropped, it's too >>> hostile to use on a public network. The only way for a public >>> network to respond to a flood of traffic higher than what it can >>> handle is to drop packets (with a possible warning via ECN shortly >>> before packets get dropped). If BBR doesn't slow down, it's just >>> going to be wasting bandwidth. >> No it isn't. Packet loss does not equal conguestion - it never did. = Dropping packets to signal congestion is an ugly hack for = implementations that are too dumb to understand any proper congestion >> control mechanism. >=20 > Hmm, I bet a lot of carrier links are policed rather than smart queue. Policing should theoretically produce a consistent delivery rate, which = is what BBR needs to work effectively. A wrinkle here is that most = policers and shapers to date rely on a token-bucket algorithm which = permits bursts at rates well above the policy, and BBR has to attempt to = infer the policy rate from the medium-term behaviour. > It also seems (OK one quick possibly flawed test), that bbr ignores = ECN > as well as drops in the sense that marked is just as high as dropped. Yes, BBR ignores ECN, which I consider to be an unfortunate feature; it = could quite reasonably be used to terminate bandwidth probes early, = before they build up a significant queue (which then needs to be = drained). Cake works very well with BBR, provided it is deployed at the upstream = end of the bottleneck link. In this position, Cake happily absorbs the = temporary standing queue caused by bandwidth probes, and the = deficit-mode shaper means that BBR tends to see a consistent delivery = rate, which it considers ideal. In practice it matters little whether = the BBR sender negotiates ECN or not, in this case. When deployed at the downstream end of the bottleneck link, Cake works = less well with BBR - but that=E2=80=99s true to some extent of all TCPs. = In ingress mode, at least, dropping packets effectively causes a = reduction in the delivery rate, which should influence BBR more strongly = to correct itself. But if ECN is negotiated, these packet drops do not = occur. In both cases, the temporary standing queue collects in the = upstream dumb queue, unless Cake is configured to a conservative enough = margin below the bottleneck rate. Cake does everything it reasonably = can here, but the topology is fundamentally unfavourable. - Jonathan Morton