From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 DF43D3B29E for ; Tue, 27 Nov 2018 06:06:09 -0500 (EST) Received: by mail-lf1-x12c.google.com with SMTP id i26so16091577lfc.0 for ; Tue, 27 Nov 2018 03:06:09 -0800 (PST) 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=0rS2IeHmZoMOEK7Zzp1yLDm4UbU9wSW8oK+Rp63rCbo=; b=VYl6VrnpLkWsVvK/w7dxJGggx4RlgFhAZUrFO2Fr6St/0RrlgX7spF13I0i2bbx1+i wJdH4sRr/FmN6Iv18nnGoUXMzk1y/6EP7iQm7u3aD94dLWe/OOmls0n/KelqzCCCNk1q RKFwcpXcfwoeRrPQ6DNTHI+L8eb+Yr7IPA/h/s7FwKS84C22M8eajWGG9sQSQjVAUBEL dhPDiUfIHMLbtm/NIZHUuBo3BzfagaEMs+pjZ5mj9y0au1F3N9v/NvVUes2eBYQIT47b yfF4dIY6vJ2iQdTTItg+xnmmAG7OhJYKyJBNBmJAi0KtGBqjn93HGjm48gW6UF8HLjiu Y8yw== 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=0rS2IeHmZoMOEK7Zzp1yLDm4UbU9wSW8oK+Rp63rCbo=; b=XDEOlWtIAEhsW+yXOaZgLJgCFM1BboG7yAaqQhSuMffVprt44cuJ85lO7a2pDncaPa H0FDctLQAN9Wh94D1P6tUirTeQm+Bipvk3GPccb44VcSUIHy216rmKx3ZR9MzJFCUqDl LWIxEzVfGRPi4f4vRaSTDIxNhyvtaLHc2shgfU7NOny2YsYC/mjkctxt8gmPnR5FDomq 2MAtReCwGOKcgrxu+PdnOfg/sR0AMjSyUQRrt06UblbTpmb2ZFenghGMKsHKgTvUrHAp PezaWcrTs7bgRZr9dlgX7jRevY/klvgv/DwgT27Jek+sR8Hq8LtkiwLY9p3pF7XpLt55 smYw== X-Gm-Message-State: AGRZ1gICnVj/8KjCiTiwQqiHoK7BJNUNnwry6wMpvY+vywVLEuczo0zj qgQaq99JhYgabVQVkf3VGLk= X-Google-Smtp-Source: AJdET5eZ11JJ4b7BjVDO/OdReYl2ZxPVN7+H3GgfOVlGi5Z3w5BgyR//Rrwz77sPcGr3urjNI2SIrQ== X-Received: by 2002:a19:6514:: with SMTP id z20mr17928257lfb.31.1543316768659; Tue, 27 Nov 2018 03:06:08 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-236-220-nat-p.elisa-mobile.fi. [83.245.236.220]) by smtp.gmail.com with ESMTPSA id s3-v6sm504801lje.73.2018.11.27.03.06.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 03:06:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Tue, 27 Nov 2018 13:06:06 +0200 Cc: Luca Muscariello , "Bless, Roland (TM)" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <192CE9E9-FFA9-4FC0-9642-B9D767E4673F@gmail.com> References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <86b16a95-e47d-896b-9d43-69c65c52afc7@kit.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] when does the CoDel part of fq_codel help in the real world? 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, 27 Nov 2018 11:06:10 -0000 > On 27 Nov, 2018, at 12:50 pm, Mikael Abrahamsson = wrote: >=20 > Could someone perhaps comment on the thinking in the transport = protocol design "crowd" when it comes to this? BBR purports to aim for the optimum of maximum throughput at minimum = latency; there is a sharp knee in the throughput-latency graph, at least = in an idealised scenario. In practice it's more complicated, hence the = gradual evolution of BBR. Previously, there has been a dichotomy between loss-based TCPs which aim = for maximum throughput regardless of latency, and delay-based TCPs which = aim for minimum latency with little regard for throughput. Pretty much = nobody uses the latter in the real world, because they get outcompeted = by loss-based traffic when they meekly back down at the first sign of a = queuing delay. Everyone uses loss-based TCPs, generally NewReno, CUBIC, = or Compound. CUBIC is specifically designed to spend most of its time = near queue saturation, by growing more slowly when near the cwnd at = which loss was last experienced than when distant from it. Compound is actually an interesting special case. It's a very = straightforward combination of a loss-based TCP and a delay-based one, = such that it spends a lot of time at or near the optimum operating point = - at least in theory. However, it will always eventually transition = into a NewReno-like mode, and fill the queue until loss is experienced. LEDBAT is a delay-based algorithm that can be applied to protocols other = than TCP. It's often used in BitTorrent clients as part of =C2=B5TP. = However, the sheer weight of flows employed by BT clients tends to = overwhelm the algorithm, as remote senders often collectively flood the = queue with near-simultaneous bursts in response to changes in collective = swarm state. BT client authors seem to be ill-equipped to address this = problem adequately. - Jonathan Morton