From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 5749E3CB36 for ; Thu, 4 Jan 2018 10:23:08 -0500 (EST) Received: by mail-qt0-x234.google.com with SMTP id a16so2248056qtj.3 for ; Thu, 04 Jan 2018 07:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fWR2y3zaHTH1VoMXJi65e6gLjTMbWD4eS9wFgmbCOI0=; b=u3xLe/tx6WA0ZeCrBG2mjNnFqavf9kWNTIBSoSVm2A+ezBDJxZGAHb4tSccPUjDpjG TYOx4smUvxzR7zQ3BjEdlyt5DfJGCOmuv7s12ZQ9xJHEAleCTNqpdJtLaLrpNTVJkroP aL0TJJHdVi2W0pCVtUcq46IuhvlFb95dNeVoa9YayVqJxwMblNbP0TkMs5g65iYtdLnL Z7yRuSIvoF7Ht9vraeUTY3yJCs0wfZsTuvBZWY6WL1noPFc8WhIyxoy/Si7sKFUNgZcG 6H4d8BbGEMi8HYUBV0Ye317DY/fOlhajGWw91dMWgowgbS07wNJ2FsPCAFtcvQCM+aWD DQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fWR2y3zaHTH1VoMXJi65e6gLjTMbWD4eS9wFgmbCOI0=; b=H3yopjVCoyTgxhlQHNSjgtvzHxKN4dOyN5EqRbsmZ/uJQhW0+ro+xRjf3ePGh1T0rx P35c4T4M+CeRrC76SOIg2M3gTS+gNIfbPriK0tVGePBjX6TT3n9rCfqd8s9FNgV7mI5t Q455v6SWNqY+npAQaJU+F5OaD56IPaPGLxfRUq3yNHgJOBJOSehWVUe2i/7Zjn5lBj+W mcdlB84++5I/7SaZiPkzaDH7wVksRAGeaucU5h+n7gzcvPbYLrOQhv6UVZ4us9G8qUbT h4uFa4bPe9CTan2O67qwJfyiuLVciOccATS5qZ6ESoOKa5RbL/Rx0PSsAECy8KxjNWD5 Lc3A== X-Gm-Message-State: AKGB3mKxFHXAxQKHX7qKKE9pMN+mAqiUiMikohJ31oVUmlK7O59kU6s+ 3OEyjI1K57tDRj0XHpPM/9aOytn+1EPZguZO+GY= X-Google-Smtp-Source: ACJfBouGObzhfdFSIIeTo2WFW1VW+fuAajj5PkHo1YfrsNxYdkDMGvOmTNpj6pBY/CIpQV/NsshhQCQZMq7IXOLdwQk= X-Received: by 10.237.37.85 with SMTP id w21mr6825972qtc.268.1515079387816; Thu, 04 Jan 2018 07:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Thu, 4 Jan 2018 07:23:07 -0800 (PST) In-Reply-To: References: <87bmi97l3w.fsf@toke.dk> From: Luca Muscariello Date: Thu, 4 Jan 2018 16:23:07 +0100 Message-ID: To: Jonathan Morton Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="001a1141fd72b7a85e0561f4e8fc" Subject: Re: [Cake] Modification of DRR with deficit saving 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: Thu, 04 Jan 2018 15:23:08 -0000 --001a1141fd72b7a85e0561f4e8fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the closest scheduler to Cake is this one, if I have to compare: https://team.inria.fr/rap/files/2013/12/KOR05.pdf J. Roberts et al. Implicit Service Differentiation using Deficit Round Robin, In Proc of ITC 2005. Luca On Thu, Jan 4, 2018 at 4:01 PM, Jonathan Morton wrote: > > On 4 Jan, 2018, at 4:29 pm, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > This popped up in my Google Scholar notifications: > > > > https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18b.pdf > > > > Basically, they are proposing to permit a queue to accumulate a larger > > deficit while empty to allow light users to achieve the same throughput > > as heavy users (users being an endpoint with potentially multiple > > flows). > > > > Not sure how useful this really is, but it's somewhat related to Cake's > > src/dst user fairness feature, so may be of interest. > > They're trying to solve the same problem as DRR++ does, not the same one > as Triple Isolation does. > > As a result, they've basically proposed a bugfix to the original DRR (ie. > you should keep replenishing the deficit until it saturates, even if the > queue is temporarily empty), without gaining the full benefit of DRR++. > > Not interesting at all. > > - Jonathan Morton > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --001a1141fd72b7a85e0561f4e8fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the closest scheduler to Cake is this one, if I ha= ve to compare:

https://team.inria.fr/rap/files/2013/12/KOR05.pdf<= /div>

J. Roberts et al. Implicit Service Differentiation= using Deficit Round Robin, In Proc of ITC 2005.

L= uca


On Thu, Jan 4, 2018 at 4:01 PM, Jonathan Morton <chromatix99@gmail.co= m> wrote:
> On 4 Jan, 2018, at 4:29 pm, Toke H=C3=B8iland= -J=C3=B8rgensen <toke@toke.dk> wr= ote:
>
> This popped up in my Google Scholar notifications:
>
> https://atlas.informatik.un= i-tuebingen.de/~menth/papers/Menth18b.pdf
>
> Basically, they are proposing to permit a queue to accumulate a larger=
> deficit while empty to allow light users to achieve the same throughpu= t
> as heavy users (users being an endpoint with potentially multiple
> flows).
>
> Not sure how useful this really is, but it's somewhat related to C= ake's
> src/dst user fairness feature, so may be of interest.

They're trying to solve the same problem as DRR++ does, not the = same one as Triple Isolation does.

As a result, they've basically proposed a bugfix to the original DRR (i= e. you should keep replenishing the deficit until it saturates, even if the= queue is temporarily empty), without gaining the full benefit of DRR++.
Not interesting at all.

=C2=A0- Jonathan Morton

_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

--001a1141fd72b7a85e0561f4e8fc--