From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 DA3D23B29E for ; Tue, 27 Nov 2018 03:55:02 -0500 (EST) Received: by mail-wm1-x330.google.com with SMTP id y139so20814280wmc.5 for ; Tue, 27 Nov 2018 00:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lE2teHBjSXbJQcurcQ4WBVNBAtiYtiL3+MxWgsCTah0=; b=ZtepoHzXwfvs1By7dQF1TgKgT6TtuVG6bvDtRHQGr621/kVkOw+JQRU3aYE9FxMuNs YwIBpEQtOcnWGNHIS/Grm1HZiMr/GpkRCzo9HZ/kfE4ZPs9IMfxXU6AYZ/ce5rb96dgO iES5Dto3WT8sdSR5EdVbSLa2hJ9INaySAQHjmogXbmW91JFP47jAkfvPnotpXrFZhont 9Khg8nlJ4FlTTtE+gi+oyvE0EFucUWzdPGnbK7/TEc+gEug4Uv/FD1AvXzo6YJ8bO+d7 bR5+10mntDcWy0QAV5Fi2ZyyzqXWgIGlRlLJ3gLAfeZjfz/xgyKv0LzBXtaK+LZQbr1z O/1w== 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=lE2teHBjSXbJQcurcQ4WBVNBAtiYtiL3+MxWgsCTah0=; b=cWE28rpK2yDpe4PRVnNv6LpHnXSnMCR8I4PdjhjU8qpGLZL/7HFhmETB40j2ZhKN73 CN6EeR17wuJorxSF99h+6jLm2bqt9Yq5ObyB415gOHWdsamgQChPIchXkJ1ZoMd9AsF9 WJtp2XnWBwDakrG0JAWDj/qUKVGKQRX8l0nEJVlP0F+fPtd8Xs7wp72cVvKjn8MGUtJo ul6o2I5ZPJ/us4yQZ0txGKfgRjfbzKlGiYcWgp82hs/HeK4FVYmZ+navipqjOB6mah3K Nhc28x51+BIvrgrtQUn91+OsFmp3vtAIQ0/z+YlnPL7wkBOaf8SrpvQmcM7bgdeHdj2u 12DQ== X-Gm-Message-State: AA+aEWaMVXKiXMo6hB5mjPnHhGuVOakJzqimbWK+EMvkDj4AjxOg4v3K kQga8LYWVnTK44bGQHZ6ESQXGNUFQ50= X-Google-Smtp-Source: AFSGD/Uce+kqu8BWVKcfl8/cg8FgqKp7IuracguOltkxB5XskSGa67baHSpcj0qiPrSaqGZjVIdqlw== X-Received: by 2002:a1c:93ca:: with SMTP id v193mr12123936wmd.82.1543308901854; Tue, 27 Nov 2018 00:55:01 -0800 (PST) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id p74sm5224070wmd.29.2018.11.27.00.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 00:55:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Pete Heist In-Reply-To: <87a7lvwkr7.fsf@toke.dk> Date: Tue, 27 Nov 2018 09:54:59 +0100 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: <6F5EB690-3D7E-4112-8890-CF727FF59EFE@heistp.net> References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87a7lvwkr7.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= 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 08:55:03 -0000 Thank you all for the responses! I was asked a related question by my local WISP, who wanted to know if = there would be any reason that fq_codel or Cake would be an improvement = over sfq specifically for some "noisy links=E2=80=9D (loose translation = from Czech) in a backhaul that have some loss but also experience = saturation. I conservatively answered no, but that may not be correct, = in case the reduced TCP RTT could help with loss recovery or other = behaviors, as Jon pointed out. I suspect more research would be needed = to quantify this. Neal=E2=80=99s/Dave's point about =E2=80=9Cnon-flow" = traffic is well taken also. > On Nov 26, 2018, at 11:13 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Michael Welzl writes: >=20 >> However, I would like to point out that thesis defense conversations >> are meant to be provocative, by design - when I said that CoDel >> doesn=E2=80=99t usually help and long queues would be the right thing = for all >> applications, I certainly didn=E2=80=99t REALLY REALLY mean that. >=20 > Just as I don't REALLY REALLY mean that bigger buffers are always = better > as you so sneakily tricked me into blurting out ;) I think most of us knew that =E2=80=9Cyeah=E2=80=9D wasn=E2=80=99t a = confirmation. Yeah can be used in a dozen different ways depending on = context and intonation, but it did give some comic relief. :) >> BTW, Anna Brunstrom was also very quick to also give me the HTTP/2.0 >> example in the break after the defense. >=20 > Yup, was thinking of HTTP/2 when I said "control data on the same > connection as the payload". Can see from Pete's transcript that it > didn't come across terribly clearly, though :P Ah, sorry for missing that part! I thought there was more there but = didn=E2=80=99t want to write something unless I was sure I heard it. >> I=E2=80=99ll use the opportunity to tell folks that I was also pretty >> impressed with Toke=E2=80=99s thesis as well as his performance at = the >> defense. I=E2=80=99ll second that. I=E2=80=99m enjoying digesting the thesis, as = well as the results of airtime fairness in a real world deployment. :)=