From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 3689A3CB35 for ; Fri, 20 Jul 2018 02:01:07 -0400 (EDT) Received: by mail-pg1-x536.google.com with SMTP id s7-v6so2455263pgv.3 for ; Thu, 19 Jul 2018 23:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZE+OdQ9Lc5jvqb1k2/MNSrL2IwkAgd8Z/PmGGJuexCw=; b=A7Wrqjc+V8tzqK8844VxHmuKEivILr+8XTNElkGLqSyQv7KXQpMB2UW7R9SZScUXDW cQTmCJYxXYt/b/MyEhWHYDVqFAvh5ImH6KgqCkSyQ+ZemE0aYcmf3OPJlVrquCyrva0C UVnVVAMvu36XirNyqgbBvo05iV8gf4Is09LW+wojSfZvG/tItrGtKayj6cecjk8zU36U AsUDzxyGbxNNdOLLeB2oAYxWzLtwbXcu5QWqBaAPE6QUttmxFYHJ/bZfyLXUm+f9SV+o dQrDysbEnvtEVfbWDwBXfcdmZjWF+ILRTQBabJreOHsmhucxJQX5jm8yHYeLCWymCsrN ngEw== 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=ZE+OdQ9Lc5jvqb1k2/MNSrL2IwkAgd8Z/PmGGJuexCw=; b=igVfJGcF0PNhRupXUqlgTrjoVEpCbIWxChVv0RH6jollZHoOCAw6bAS35zfZAY5Wgn J7vIXet/77oKgCqrF+HCoVrtOlkvVijvru50u+35DGWOEdVEqaaJtenZXyOTQJBpG2Dr Q0gORr0w/YmCuZIVNYYsUAN+lUO0EbDmcsIeQCHUCMZH4VkcnDnxZtds9aNWLdQLj8DA lC5a88/ssW6yZel4odjTJmpvC45oEa/68j/pbXf62mQKRjDaNbqaOqThwRexMjJCAO9l 0oZNDlOXy+aM53TVW3JSmjmkMxMv8B3LHVNmF1iyLnYQabxJaxThKc4UmuhI+pm2Lsxu nb8w== X-Gm-Message-State: AOUpUlFvb75pBEGzipYu3v2Z/wyanP7Erh757Q+reAvyPypnkDogPUKa 8MdPd+YtRDU/1bRcbJdqg0xtDdIUIvW2AbFD7tQ= X-Google-Smtp-Source: AAOMgpfajaZgxX4efR5oIy15SfDN83fEJfIrl5RquePK2bzhPeAQCLKIIm0NQqwHd7X8mk21VyrFbv1ImWdCB1d3Hb0= X-Received: by 2002:a63:bd51:: with SMTP id d17-v6mr795134pgp.42.1532066466366; Thu, 19 Jul 2018 23:01:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew McGregor Date: Fri, 20 Jul 2018 16:00:56 +1000 Message-ID: To: Dave Taht Cc: codel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000800a8b05716805e6" Subject: Re: [Codel] self tuning codel X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 06:01:07 -0000 --000000000000800a8b05716805e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, it has a core assumption: that a stable arrangement of links with small persistent delays is something that both can and should exist. It's kind of like a fluid model, in many ways. Thing is, I don't think it's desirable that persistent delays exist anywhere. Now, autotuning codel is probably a good idea... but the implementation should be local. If you're a bottleneck, you may as well behave as if you're the only bottleneck, even if that isn't the case, because if you're in a distributed bottleneck situation your actions will help anyway. A global distributed solver like is proposed here could possibly work in a private network, but I can't see that solution flying in precisely the place you really need it: peering. One way to do this locally would be to identify the impulse response of the stochastic DE describing the aggregate running through the link using something like https://arxiv.org/abs/1309.7857 and then tune to optimal behaviour for the resulting DE, along the lines of https://arxiv.org/abs/1510.08439. On Thu, Jul 19, 2018 at 8:42 AM Dave Taht wrote: > there's so much math in this that I cannot make heads or tails of it. > > > https://www.eee.hku.hk/~kcleung/papers/conferences/bufferbloat_multi-bott= leneck:INFOCOM_2018/PID5170809.pdf > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > --000000000000800a8b05716805e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, it has a core assumption: that a stable arrangement of= links with small persistent delays is something that both can and should e= xist.

It's kind of like a fluid model, in many ways.=

Thing is, I don't think it's desirable th= at persistent delays exist anywhere.

Now, autotuni= ng codel is probably a good idea... but the implementation should be local.= If you're a bottleneck, you may as well behave as if you're the on= ly bottleneck, even if that isn't the case, because if you're in a = distributed bottleneck situation your actions will help anyway. A global di= stributed solver like is proposed here could possibly work in a private net= work, but I can't see that solution flying in precisely the place you r= eally need it: peering.

One way to do this locally= would be to identify the impulse response of the stochastic DE describing = the aggregate running through the link using something like=C2=A0https://arxiv.org/abs/1309.7857 and t= hen tune to optimal behaviour for the resulting DE, along the lines of=C2= =A0https://arxiv.org/abs/1510.= 08439.


On Thu, Jul 19, 2018 at 8:42 AM Dave Taht <dave.taht@gmail.com> wrote:
there's so much math in this that I cannot make hea= ds or tails of it.

https://www.eee.hku.hk/~kcleung/papers/conferences/bufferbloat_multi= -bottleneck:INFOCOM_2018/PID5170809.pdf

--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Codel mailing list
Codel@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
--000000000000800a8b05716805e6--