From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 5241B3B2A0 for ; Fri, 20 May 2016 12:37:38 -0400 (EDT) Received: by mail-oi0-x236.google.com with SMTP id x201so187693582oif.3 for ; Fri, 20 May 2016 09:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitamins-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=xNlWeyn7yw1+1pQJnKPacabOLuAHPA6MkgqjFlJYQjo=; b=OCBSfK5OOLpBeoeW3rmAfaoFoIIdNhWpqPDw6971xPO+632UzU3v0EcYBRVkjnRZtE 17RCzgkPOSri2KXiOFl/V7JNh19HGxklL2JXYXi/txHLN3YGHr/4I7tiek+iNBiiJQj7 0MIgpQ9ikzkddpegPDURtJU91NW1uoi4a9fjVVf7WtHzIcBEqERskrA8LmIP4/KIeW78 5uz8AWlYqqmROFgUrmHG+tAlOYwrITMrkHLXSSy2gYB9bZCeHtsswRL4uiVMu+iWaFGt 3hxP+NcsgorDoflLk+FRgrF9J3YrFJmSYJhQAIZDVR39fCECDosAta0t+0ZuLCRFq6uu vGHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=xNlWeyn7yw1+1pQJnKPacabOLuAHPA6MkgqjFlJYQjo=; b=fKhyShu/gqFYz0rnWc7EXTgO1dz/0p4VhLiluUrgO1yBZcx0Z4EZViVy5ZM41Zuola S/EfHFnE8lr5ev8reenIV4ZMqZNE0eh0VRWgf0c7XTDRedUo8A1DaeHCD7ta7A9U0926 Rz0fJh1EIfEW4nu03Bh2BksEPjQoeZpT//DU8fEbqGS0mUdgor2GgCVy94Dv5ZhkQH1g hMrko9wEzlg8vX4J815oSiY9pdcV403Hl6umGTJkQx4hI+Mmj9SFtx0o2KeWJsArew59 6fDk/RCcItdYClFViUqAugKoPPQLXYBDdx5iU2m+kAubyX+FHUq0dwBXbPrglcszbVm4 A0LQ== X-Gm-Message-State: AOPr4FUWWpjasm6855aA3rBzf2kNZ8ANJdtkDFm0y60hxseU+PXRIjEqCVGvXm3f3fJnOT/OaFLhXb8pZZgKeQ== MIME-Version: 1.0 X-Received: by 10.157.43.85 with SMTP id f21mr2758356otd.116.1463762257622; Fri, 20 May 2016 09:37:37 -0700 (PDT) Received: by 10.157.17.7 with HTTP; Fri, 20 May 2016 09:37:37 -0700 (PDT) X-Originating-IP: [206.108.31.35] In-Reply-To: <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> Date: Fri, 20 May 2016 10:37:37 -0600 Message-ID: From: "Luis E. Garcia" To: cake@lists.bufferbloat.net, codel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113d0c6c66d41a053348b5f4 Subject: Re: [Cake] Proposing COBALT 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: Fri, 20 May 2016 16:37:38 -0000 --001a113d0c6c66d41a053348b5f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jonathan, I think this would be a great idea to implement and test. Can COBALT's behavior be easily implemented to test it using the OpenWRT or LEVE ? Regards, Luis On Fri, May 20, 2016 at 8:36 AM, Jonathan Morton wrote: > >> If the relative load from the flow decreases, BLUE=E2=80=99s action wi= ll begin > to leave the subqueue empty when serviced, causing BLUE=E2=80=99s drop pr= obability > to fall off gradually, potentially until it reaches zero. At this point > the subqueue is naturally reset and will react normally to subsequent > traffic using it. > > > > But if we reach a queue length of codel=E2=80=99s target (for some smal= l amount > of time), would that not be the best point in time to hand back to codel? > Otherwise we push the queue to zero only to have codel come in and let it > grow back to target (well approximately). > > No, because at that moment we can only assume that it is the heavy > pressure of BLUE that is keeping the queue under control. Again, this is > an aspect of Codel=E2=80=99s behaviour which should not be duplicated in = its > alternate, because it depends on assumptions which have been demonstrated > not to hold. > > BLUE doesn=E2=80=99t even start backing off until it sees the queue empty= , so for > the simple and common case of an isochronous flow (or a steady flood > limited by some upstream capacity), BLUE will rapidly increase its drop > rate until the queue stops being continuously full. In all likelihood th= e > queue will now slowly and steadily drain until it is empty. But the load > is still there, so if BLUE stopped dropping entirely at that point, the > queue would almost instantly be full again and it would have to ramp up > from scratch. > > Instead, BLUE backs off slightly and waits to see if the queue *remains* > empty during its timeout. If so, it backs off some more. As long as the > queue is still serviced while BLUE=E2=80=99s drop probability is nonzero,= it will > back down all the way to zero *if* the traffic has really gone away or > become responsive enough for Codel to deal with. > > Hence BLUE will hand control back to Codel only when it is sure its extra > effort is not required. > > - Jonathan Morton > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --001a113d0c6c66d41a053348b5f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jonathan,
I think this would be a great idea to implem= ent and test.
Can COBALT's behavior be easily implemented to = test it using the OpenWRT or LEVE ?

Regards,
=
Luis

On Fri, May 20, 2016 at 8:36 AM, Jonathan Morton <= chromatix99@gmai= l.com> wrote:
>> If the relative load from the flow decreases, BLUE=E2=80=99s= action will begin to leave the subqueue empty when serviced, causing BLUE= =E2=80=99s drop probability to fall off gradually, potentially until it rea= ches zero.=C2=A0 At this point the subqueue is naturally reset and will rea= ct normally to subsequent traffic using it.
>
> But if we reach a queue length of codel=E2=80=99s target (for some sma= ll amount of time), would that not be the best point in time to hand back t= o codel? Otherwise we push the queue to zero only to have codel come in and= let it grow back to target (well approximately).

No, because at that moment we can only assume that it is the heavy p= ressure of BLUE that is keeping the queue under control.=C2=A0 Again, this = is an aspect of Codel=E2=80=99s behaviour which should not be duplicated in= its alternate, because it depends on assumptions which have been demonstra= ted not to hold.

BLUE doesn=E2=80=99t even start backing off until it sees the queue empty, = so for the simple and common case of an isochronous flow (or a steady flood= limited by some upstream capacity), BLUE will rapidly increase its drop ra= te until the queue stops being continuously full.=C2=A0 In all likelihood t= he queue will now slowly and steadily drain until it is empty.=C2=A0 But th= e load is still there, so if BLUE stopped dropping entirely at that point, = the queue would almost instantly be full again and it would have to ramp up= from scratch.

Instead, BLUE backs off slightly and waits to see if the queue *remains* em= pty during its timeout.=C2=A0 If so, it backs off some more.=C2=A0 As long = as the queue is still serviced while BLUE=E2=80=99s drop probability is non= zero, it will back down all the way to zero *if* the traffic has really gon= e away or become responsive enough for Codel to deal with.

Hence BLUE will hand control back to Codel only when it is sure its extra e= ffort is not required.

=C2=A0- Jonathan Morton

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

--001a113d0c6c66d41a053348b5f4--