From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 02D673B2A4 for ; Sat, 24 Aug 2019 05:16:09 -0400 (EDT) Received: by mail-wm1-x32f.google.com with SMTP id m125so11237649wmm.3 for ; Sat, 24 Aug 2019 02:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DQXft1UoL+ye3jVaHfIxhfBzAzOUq5FnnHom0ih1Bk4=; b=As61XiQOZkPZSdGLGhUJHghujKEhJtp/KzxE/gA+WlilzKffDv3uRtilxFbycRskyx DyOp+UceWmxxAA/W4lNa38GqfoOzBdIJj0fH9OHNN85QH81aAixVZmbF7cG7mbLxlhWz O3AMGpdEJC5bAmBDkt9OKQ9mIm+JhP+CJnFxk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DQXft1UoL+ye3jVaHfIxhfBzAzOUq5FnnHom0ih1Bk4=; b=UV4GETz0re/iM3FunS9zmM0W6hvSIkdCUt7zG6Orh1bfsJEIkSf1i8V3RXZqyq3pTr L72NqFLJhPdxAN08tmfk3rTN3JZmqe3CfjhOuCiiDjlol76J+7f6Go0MVaGnVwDmq57W DNEpMEnoZQfhKiVOxyJa+OU8jHlLxplPfVBuVA1UN/RQWP7jrB70qkL+Vi3MCECG6VVt SFA2EHpkkH25l2rh3Io+L8YbPYyVdWPdUPTZEVAVH69IUST4L9F7KUdM/y+m430VBKmk CbYHRq4gs1aH6uRelpjeaOxpwMkKXiTgU9dvRjNDi9UewTiKciX8A50UjEGMnAw8cXMP 7vSQ== X-Gm-Message-State: APjAAAWi5Ue6q9ff1qkO22ZB585pjZmAc1XyyFt7LRz4wEReAsMhN82j fjaLYT6+67EwjBEBEaUQqz/Nm5GQivPh0k/3VBNGzg== X-Google-Smtp-Source: APXvYqx6szMRG8WPFE/0w3pwNYcc0z2Gjiq9+enxnoYRRIwanYdL3oJWqZXI64amRKL4uwvy8V6Gs1UGOEnCG3FGAbk= X-Received: by 2002:a1c:18a:: with SMTP id 132mr10084832wmb.15.1566638169042; Sat, 24 Aug 2019 02:16:09 -0700 (PDT) MIME-Version: 1.0 References: <42B8EB6B-5540-46EB-8BB3-81D6239A4D58@superduper.net> <20190824095453.1a15ca5a@carbon> <36973E7C-0B93-4512-AB0B-917C807E9684@gmx.de> In-Reply-To: <36973E7C-0B93-4512-AB0B-917C807E9684@gmx.de> From: Luca Muscariello Date: Sat, 24 Aug 2019 11:15:57 +0200 Message-ID: To: Sebastian Moeller Cc: Jesper Dangaard Brouer , bloat Content-Type: multipart/alternative; boundary="0000000000008ed1c90590d95fb2" Subject: Re: [Bloat] buffer sizing meeting notes 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: Sat, 24 Aug 2019 09:16:10 -0000 --0000000000008ed1c90590d95fb2 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 24, 2019 at 9:59 AM Sebastian Moeller wrote: > Another nugget from the notes ( > http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/): > > This looks like an argument for fq_codel/cake's use of time instead of > queue length, OR an argument for fq, because in a non-overwhelmed fq_system > the local bucket's queue length should be somewhat stronger correlated with > the sojurn times, than the sojurn time of a packet though a shared queue, > no? > I believe that using fq there are good implications in terms of buffer sizing rules. The focus is only on backlogged flows. The sparse flow queue can be sized purely based on queue load. Which is trivial queuing theory formulas with non-TCP traffic. For backlogged flows, sizing is just like sizing a buffer for a single TCP flow. So the computation can be done based on estimations of the number of backlogged flows and by setting the cut-off BDP based on the largest (maximum) min RTT one want to serve optimally. So AQM is really needed to get optimality. The number of backlogged flows could be estimated as a max value or an avg value, and this of course changes depending on the network segment (DC, residential, campus, access, backhaul etc.). Nick McKeown has done quite a lot of research on the topic (reported in the slide deck), so I find hilarious the following in his slide deck "Personal confession: I have no idea what the general answer is" about sizing buffers! --0000000000008ed1c90590d95fb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 24, 2019 at 9:59 AM Sebastian Moeller <moeller0@gmx.de> wrote:
Another = nugget from the notes (http://yuba.stan= ford.edu/~bspang/buffer-sizing-meeting/notes/):

This looks like an argument for fq_codel/cake's use of time instead of = queue length, OR an argument for fq, because in a non-overwhelmed fq_system= the local bucket's queue length should be somewhat stronger correlated= with the sojurn times, than the sojurn time of a packet though a shared qu= eue, no?

I believe that using fq there = are good implications in terms of buffer sizing rules.
The focus = is only on backlogged flows. The sparse flow queue can be sized purely base= d on queue load.
Which is trivial queuing theory formulas with no= n-TCP traffic.

For backlogged flows, sizing is jus= t like sizing a buffer for a single TCP flow. So the computation
= can be done based on estimations of the number of backlogged flows and by s= etting the cut-off BDP based on the=C2=A0
largest (maximum) min R= TT one want to serve optimally.=C2=A0 So AQM is really needed to get optima= lity.
The number of backlogged flows could be estimated as a max = value or an avg value, and this of course=C2=A0
changes depending= on the network segment (DC, residential, campus, access, backhaul etc.).

Nick McKeown has done quite a lot of research on th= e topic (reported in the slide deck), so I find hilarious the following in = his slide deck
"Personal confession: I have no idea what= the general answer is" about sizing buffers!
<= /div>
--0000000000008ed1c90590d95fb2--