From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 18B6A3B2A4 for ; Thu, 4 Jan 2018 10:53:37 -0500 (EST) Received: by mail-qt0-x22d.google.com with SMTP id 33so2367588qtv.1 for ; Thu, 04 Jan 2018 07:53:37 -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=CrqZUY996w1WfvGBAMv3uy+k4QpuTj8t5jN15F+jZyQ=; b=Y3gH4Inl7GPUCCv2TEWNxI0DLoTsrQuHAoswMa/a9DAwwT8uwE1NSSTcjU2o91bzAT Kx0LYGtL14SteUOsecDON69QJBQzEXglz0mbH08zXJKsykJ+nfFTp/YsEnOVbmmPhupS LrzemYtUPsI89fxRL2QLP7R/gQm4/aMTXIgtyjAc41+khNOSivNmUTtLIT5rm50ws7f+ 91E6SzuUXJw76YXFA+3zymdVFU0FBMEmRt3+Rr2lwbd6stI0bi036r89fYB8CIO0QQT3 wAxjzG3lH9DOMQyGTQAOJ4/pyIVqnlQHlRx5Pmbc66gFkftWT249yU7s6M51QINFzBMW ecDQ== 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=CrqZUY996w1WfvGBAMv3uy+k4QpuTj8t5jN15F+jZyQ=; b=SBMAzztoo/As4y5FuRpynFfybr72WrKsw/hYFr9yzQTQybblcICNMbT/KJqGG2ZOrv fBsCBMU0yNVWf7HhfDuhcyeacdSe5eq5W/Xmm6Xb8SpddGV8mLPcW2PLL8I3+oO+AzNQ 58f72so9LmtRd88hDaolnWAW00MaYOnZF0hbWU/zkYAdStOoHh73AN3vkLOdPN+nyG1M JCo/5WgYNP6jWy0CLJQ8qlO7AqTzJ3TCZnISvppsrUYmtUoZ5Y5NTCCW/JBu926iDgie cMAqTCXJpB2ykwM3mJzO2/+5ezb49xdx0tXn4pyjYMlsY4QW9/ctjJBBzLdOP+T3UleD kMNg== X-Gm-Message-State: AKwxytdKN69XiJrpIJZ3hEzgSiuyGXzpHEZDCV6cUgF8vUDXLLEebUq8 GL0qZC/PkoZOaiH5NopZ+7x16Kl453G4GhiB6Ec= X-Google-Smtp-Source: ACJfBouO2ScYMb3oHzLD3iP14X6OeSGGI0N+boDIGkAxMkTdIJHxaPtTYrHLt6HoXlVQtJXSQoShfm86IgDlwYIdIsM= X-Received: by 10.237.42.163 with SMTP id t32mr1895qtd.238.1515081216496; Thu, 04 Jan 2018 07:53:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Thu, 4 Jan 2018 07:53:36 -0800 (PST) In-Reply-To: References: <87bmi97l3w.fsf@toke.dk> From: Luca Muscariello Date: Thu, 4 Jan 2018 16:53:36 +0100 Message-ID: To: Dave Taht Cc: Jonathan Morton , Cake List Content-Type: multipart/alternative; boundary="001a114d7940b7199e0561f5559d" 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:53:37 -0000 --001a114d7940b7199e0561f5559d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sanity check: the active flow list in Jim's work is very compact as it counts only the flows with a packet in the queue. So you need to read that paragraph with this in mind. Then you'll agree :) I have a reasonable proof that what cake is doing is truly sane. You just need to compare cake to Jim's monumental work and see that it fits in that class. Then you sleep well as I do. don't pay too much attention to admission control. Even if it makes sense to me. In case of overload, i.e. too many flows in the system for too long, nobody is happy. Accepting more flows is making no one happier. The new one included. So instead of dropping one random packet, dropping new SYN packets seems like the bouncer telling you "guys: there is no room left". And it works well in the home. On Thu, Jan 4, 2018 at 4:42 PM, Dave Taht wrote: > On Thu, Jan 4, 2018 at 7:23 AM, Luca Muscariello > wrote: > > 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 > > Try as I might, at workloads that I've been able to create (I did just > add 10GigE capability to my testbed), it's seemingly nearly impossible > to have more than a few hundred flows in memory (compared to > potentially thousands actually active), and it's unclear how to go > about thinking about it sanely.This tends to point to cake's 8 way set > associativity as being overkill, but haven't got around to trying > higher bandwidths, lower target RTTs, or, as I said, higher > bandwidths. > > 'course, while I disagree with this statement in the paper, and do > care a lot about handling overload sanely, > > "In overload, it is necessary to apply per-flow admission control in > order to preserve good performance for admitted flows. Note that no > scheduler can avoid drastic performance degradation when offered > traffic exceeds capacity. PDRR has the advantage of allowing" > > I wish I had reasonable proof that what we do in cake is truly sane, > or had some curve to apply to flows per the available bandwidth. > > > > > 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 larg= er > >> > 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 o= ne > >> 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 t= he > >> 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 > > > > > > > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > > > > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > --001a114d7940b7199e0561f5559d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sanity check: the active flow list in Jim's work is ve= ry compact=C2=A0
as it counts only the flows with a packet in the queue= .
So you need to read that paragraph with this in mind. Then you&= #39;ll agree :)

I have a reasonable proof that wha= t cake is doing is truly sane.=C2=A0
You just need to compare cak= e to Jim's monumental work and see that it fits in that class.
Then you sleep well as I do.

don't pay too m= uch attention to admission control.
Even if it makes sense to me.= In case of overload, i.e. too many flows in the system for too long,
=
nobody is happy.
Accepting more flows is making no one happi= er. The new one included.
So instead of dropping one random packe= t, dropping new SYN packets seems like the bouncer telling=C2=A0
= you "guys: there is no room left". And it works well in the home.=





=

On Th= u, Jan 4, 2018 at 4:42 PM, Dave Taht <dave.taht@gmail.com>= wrote:
On Thu, Jan 4, 2= 018 at 7:23 AM, Luca Muscariello
<luca.muscariello@gmail.co= m> wrote:
> I think the closest scheduler to Cake is this one, if I have to compar= e:
>
> https://team.inria.fr/rap/files/2013/12/K= OR05.pdf

Try as I might, at workloads that I've been able to create (I di= d just
add 10GigE capability to my testbed), it's seemingly nearly impossible<= br> to have more than a few hundred flows in memory (compared to
potentially thousands actually active), and it's unclear how to go
about thinking about it sanely.This tends to point to cake's 8 way set<= br> associativity as being overkill, but haven't got around to trying
higher bandwidths, lower target RTTs, or, as I said, higher
bandwidths.

'course, while I disagree with this statement in the paper, and do
care a lot about handling overload sanely,

"In overload, it is necessary to apply per-flow admission control in order to preserve good performance for admitted flows. Note that no
scheduler can avoid drastic performance degradation when offered
traffic exceeds capacity. PDRR has the advantage of allowing"

I wish I had reasonable proof that what we do in cake is truly sane,
or had some curve to apply to flows per the available bandwidth.

>
> 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 <chromatix99@gmail.com>
> wrote:
>>
>> > On 4 Jan, 2018, at 4:29 pm, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> wrote:
>> >
>> > This popped up in my Google Scholar notifications:
>> >
>> > https://atlas.info= rmatik.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 mult= iple
>> > flows).
>> >
>> > Not sure how useful this really is, but it's somewhat rel= ated 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 th= e same one
>> as Triple Isolation does.
>>
>> As a result, they've basically proposed a bugfix to the origin= al DRR (ie.
>> you should keep replenishing the deficit until it saturates, even = if the
>> queue is temporarily empty), without gaining the full benefit of D= RR++.
>>
>> Not interesting at all.
>>
>>=C2=A0 - Jonathan Morton
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferblo= at.net
>> https://lists.bufferbloat.net/listinfo/cake=
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.n= et
> https://lists.bufferbloat.net/listinfo/cake=
>



--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619

--001a114d7940b7199e0561f5559d--