From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 4C88E3B25E; Tue, 24 May 2016 10:07:05 -0400 (EDT) Received: by mail-lb0-x22e.google.com with SMTP id k7so5827320lbm.0; Tue, 24 May 2016 07:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q8xGj9Tiuc+Czhx2gFaTDvNDRiRgT7I9a0VXfmheY4s=; b=KU3s+MUl1UfypisSf2N1CqeSL3Pa7b6pyWgGvD8P2FCjGUVzMxzBVy6MdBmbVX5IfD 9WvXXMFxCe9V7dx21AKCzI3PuWxbANA8IREjcj6ENZnyhYDbauiD8PF9qHjEAwndbUEZ HQF/adK8eiaCtb8/QTzIfB6MowkZNq1S5mK4g+vznJexqv3qGQ3I2FNu45Mzfb74PBwV fLFmgsyBNuDaijmDtxVZmlolscsCvdW0NfWmNUY3EKi4WVk9M/TX+NG7Li9xDId25V4m Ah+CQEDAOjgguewSXsBmzQeKqFTN/9Kw0Fvc464IBnknARPOYiDW3mYdYFVfG/JZIy3X nr4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q8xGj9Tiuc+Czhx2gFaTDvNDRiRgT7I9a0VXfmheY4s=; b=Jl98Zb5P3570htOT/tpk22Z7cl8/TD6zsNeGiV386nBGerF96n7kB0levJhWq0KAqm hMbmr5EW5hJl8gmvVzQHCqmeNkN7RoNxajqZlhFsbSMH8/iW8lm1hhYFi3KC9a+v/stR ctQ0pp3nVAYMXAyEQMa6fnvy5T5MIo7ldc4blU31gBTfyMqh/HyGduHKG6N9yjFXUiI9 w/C4+vBYirO/OPAUSV7nnvUhgrW2Hbhe0OCjj9KssZ4jS0vtPGjlNat0hALoH6AVjHop /5YcoIdRVuEfWKb9ez0b7seRxzgQncERtT+RXsf0oYbjeqELyHmHegApax3gR9MUMJ7o wXOA== X-Gm-Message-State: AOPr4FW2HbgCqr8NTB8TFgX2W7kvTdrt7zySAckNTWAk2BPO6/F7Go9HFbiEmgtC4VsSLA== X-Received: by 10.112.141.135 with SMTP id ro7mr7916687lbb.0.1464098824126; Tue, 24 May 2016 07:07:04 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-138-144.bb.dnainternet.fi. [188.67.138.144]) by smtp.gmail.com with ESMTPSA id rf7sm544048lbb.11.2016.05.24.07.07.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 07:07:03 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <274D3A0FA900FD47AA6B56991AAA32FDC5529FC8@wtl-exchp-1.sandvine.com> Date: Tue, 24 May 2016 17:07:00 +0300 Cc: "Luis E. Garcia" , "cake@lists.bufferbloat.net" , "codel@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> <8AB0D25D-C1CA-45F1-889E-2F73CF8C44F7@gmail.com> <323AFC22-A092-4F59-8197-AF21EF73FD58@gmail.com> <274D3A0FA900FD47AA6B56991AAA32FDC5529FC8@wtl-exchp-1.sandvine.com> To: Jeff Weeks X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] [Cake] Proposing COBALT 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: Tue, 24 May 2016 14:07:05 -0000 > On 24 May, 2016, at 16:47, Jeff Weeks wrote: >=20 >> In COBALT, I keep the drop-scheduler running in this phase, but = without actually dropping packets, and *decrementing* count instead of = incrementing it; the backoff phase then=20 >> naturally ends when count returns to zero, instead of after an = arbitrary hard timeout. The loop simply ensures that count will reduce = by the correct amount, even if traffic=20 >> temporarily ceases on the queue. Ideally, this should cause Codel=92s = count value to stabilise where 50% of the time is spent above target = sojourn time, and 50% below. (Actual=20 >> behaviour won=92t quite be ideal, but it should be closer than = before.) >=20 > I tried this as well, at one point, but can't remember, off-hand, why = I didn't stick with it; will have to see if I can find mention of it in = my notes. > What trigger are you using to decrement count? I initially did a = crude decrement of count every interval, but then you end up with a = ramp-down time which is considerably slower then the ramp-up (and the = ramp up is slow to begin with). > I assume you're actually re-calculating the next drop, using the = 1/sqrt(count) but instead of dropping and increasing count, you're = simply decreasing count, so the time to get from 1->N is the same as the = time to get to N->1? That=92s basically right. In retrospect, it seems like a very obvious = approach to the backoff problem. :-) Of course, due to the =93priming=94 delay and the possibility of the = signalling frequency exceeding the packet rate, it=92s likely to take = *less* time to ramp down than to ramp up; this is why the ramping down = is guarded by a while loop. >> As another simplification, I eliminated the =93primed=94 state = (waiting for interval to expire) as an explicit entity, by simply = scheduling the first drop event to be at now+interval when=20 >> entering the dropping state. This also eliminates the = first_above_time variable. Any packets with sojourn times below target = will bump Codel out of the dropping state anyway. >=20 > How do you handle the case where you're scheduled a drop event 100ms = in the future, and we immediately see low latency; is the event = descheduled? > If not, what if we then see high latency again; can the = still-scheduled-event cause us to start dropping packets earlier than = 100ms? The first drop event is scheduled by setting the =93dropping=94 flag, = ensuring that =93count=94 is nonzero, and setting the =93drop_next=94 = timestamp to now+interval. Any packet below the target sojourn time = clears the =93dropping=94 flag, which prevents marking or dropping from = occurring - which is why the explicit =93primed=94 state is eliminated. Since the timestamp is set in this way whenever the =93dropping=94 flag = transitions from cleared to set, there are no spurious drop events. The code is in the sch_cake repo if you want to examine the details. I = promise it=92s a lot easier to read than the original Codel code. - Jonathan Morton