From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 D28C43B2A3 for ; Fri, 28 Apr 2017 18:02:40 -0400 (EDT) Received: by mail-wr0-x22a.google.com with SMTP id l9so40206067wre.1 for ; Fri, 28 Apr 2017 15:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=9xDPPR0p7Bp4fnajMxY31hpOTm+1jHvXE6HZ3ODbhnQ=; b=KxYjI366bfdAUj/KaTfmn6w74b1ddBUJ0LTiOGrl7pfpAIY1ncXu65zluaU3JMNTAf 3VqZy2oXWZGrA6878HCCM/1pAN9IGX8WdXQ5Fd+ptTWlA1KGg/IF1hDrXF9stGj+STmG 9bWQmrFy0o0vG764BeDL8NSEIIiDIEf5oXWegib2O4cfPe/FrTJf8BzLg2s4Zh86S/oY jvgZgW2arv+ZeOnEeoQ6gUcOQQt9WsiCqeO7/ZWwWmF0RhfCu6XlIjU1QFYLoEfzU8lw CYJfo6AsEQOJrUF3U9qx3TACvcfqXpeMIe4ijdFt8k6uInF37C7murtaM/KAL/eNirxS Tq7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=9xDPPR0p7Bp4fnajMxY31hpOTm+1jHvXE6HZ3ODbhnQ=; b=ZDxVgKERFYy/BjGF931T1XbGhxWtV4pLwpRLtkp01WGUoXcDUJqb3C3d8CfcmXeoc8 Wvm+hMk6Nv6Px6ej/bcQYH1MnTRpUyn9CNXDJbCdpUlHpmAMk5jKGb9pz3AR1QqbOvIb jw3aIYVhFgzCgGiPbUARxF6we1r/7V/ZBxI7D9cWcwljM96aSonKuajf0J4i+BEUv0qR u00jwojrdcyhX/yY2JP62rKr7x26tGjFznJxQ5vOfzBJTb45xBszFjUZNd3OsOHvbEda 1EBHqZiuyPy5vQznJpBQrNkSUAfOvnFd1pqVbCewrGl5OizfJo4QHAIgwEmnEF3HbUAz 48og== X-Gm-Message-State: AN3rC/73E1TxziKgBrHBBjyAUYP1wpz3LHh5U9+PKxYFThZwcF+BtPN2 4Xmr0EoRYWY7G8AySUQ= X-Received: by 10.223.172.48 with SMTP id v45mr9907700wrc.112.1493416959841; Fri, 28 Apr 2017 15:02:39 -0700 (PDT) Received: from [192.168.1.116] (cm149-53.liwest.at. [81.10.149.53]) by smtp.gmail.com with ESMTPSA id y190sm878415wmy.15.2017.04.28.15.02.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 15:02:39 -0700 (PDT) From: xnor To: "David Lang" Cc: Cake@lists.bufferbloat.net Date: Fri, 28 Apr 2017 22:02:38 +0000 Message-Id: In-Reply-To: References: Reply-To: xnor User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 28 Apr 2017 22:02:41 -0000 >On Fri, 28 Apr 2017, xnor wrote: > >>As I understand it, increase in RTT due to queueing of packets is the=20 >>main feedback mechanism for BBR. >>So dropping packets, which I already consider harmful, is really=20 >>harmful with BBR because you're not telling the sender to slow down. > >If BBR does not slow down when packets are dropped, it's too hostile to= =20 >use on a public network. The only way for a public network to respond=20 >to a flood of traffic higher than what it can handle is to drop packets= =20 >(with a possible warning via ECN shortly before packets get dropped).=20 >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.=20 Dropping packets to signal congestion is an ugly hack for=20 implementations that are too dumb to understand any proper congestion=20 control mechanism. Dropping due to queues being full normally doesn't happen before the RTT= =20 has significantly increased. BBR fixes both of these problems: a) it ignores packet loss on unreliable links and therefore achieves=20 much higher throughput than conventional congestion control algorithms=20 (that wrongly assume congestion on packet loss) An experiment with 10 Gbps bottleneck, 100 ms RTT and 1% packet loss (as= =20 described in the net-next commit) showed ~3000x higher throughput with=20 BBR compared to cubic. b) it reacts to increase in RTT. An experiment with 10 Mbps bottleneck, 40 ms RTT and a typical 1000=20 packet buffer, increase in RTT with BBR is ~3 ms while with cubic it is=20 over 1000 ms. > >>Instead, with a controlled delay qdisc like cake or codel, you're=20 >>telling the sender to keep sending the data faster because the qdisc=20 >>keeps the increase in RTT minimal. To make things worse, you're=20 >>throwing away perfectly good packets with no effect other than wasting= =20 >>bandwidth. > >you are mistaking how cake and codel work. They are working at the link= =20 >endpoint adjacent to where the bandwidth is most limited. They drop=20 >packets before they get send over the most contrained link. The fact=20 >that the packets eat up some bandwidth on the non-constrained link=20 >prior to the bottleneck doesn't matter, the bandwidth is available by=20 >definition (otherwise it would be a constrained link to the endpoint=20 >before it) No, my ISP isn't using either cake or codel and neither is Andy's. We're talking about ingress traffic "shaping" of downloads here, so=20 we're not working at the point in front of the most constrained link.=20 Instead we work behind the most contrained link. That's why dropping packets is counterproductive, but as I've mentioned=20 before it should be avoided anyway (except for the broken parts of the=20 Internet where it still is a necessary evil).