Re: [homenet] -CoDel

Toke Høiland-Jørgensen <toke@toke.dk> Fri, 15 March 2019 21:41 UTC

Return-Path: <toke@toke.dk>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A6130F62 for <homenet@ietfa.amsl.com>; Fri, 15 Mar 2019 14:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U36Oc7JRvag for <homenet@ietfa.amsl.com>; Fri, 15 Mar 2019 14:41:11 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A2C12785F for <homenet@ietf.org>; Fri, 15 Mar 2019 14:41:11 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1552686068; bh=5gJqcGvWMm/2Tzrlap76XK3J7trdlAubfI5NfjCXSn0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gp70gF7qR58rNbeS8mjP2KSHnnAdvmmiBcamiL6spwEls3V5c3VMmiTMr9/uU2IUP 9Wk6leockUFpVYMZiTyy1725fdRQ7MVbEZcN2MSwWFJRuLSHYZIB3pCzsz64FnVIoR rFcbD5Bpw5Slp60MRG7dlPHAnN75r3a8ru6je41XUXAfHSSgFIqb/JyXFy5jmaVnWk VcyhXELYszu14bCzPMJkRLVCvuCPnOeSYbunxv+IRwePfc0TEzg/KoAWbExG0Orxa3 vUeh76ClTq9olSnuR5fipKIDuMIblEGXYLZ8GbjA8A/EU8QeDwSqRgjBSwwaftgwh9 Th1JhtVNSQ+Nw==
To: "David R. Oran" <daveoran@orandom.net>
Cc: Juliusz Chroboczek <jch@irif.fr>, Mikael Abrahamsson <swmike@swm.pp.se>, homenet@ietf.org
In-Reply-To: <5CFA14C1-5332-450B-AE50-5459C4745B8A@orandom.net>
References: <894b4181-c4ca-5cf1-adba-1c5fcab0d355@cs.tcd.ie> <90A48EC1-C13D-4B9B-9F04-252C0CC87084@fugue.com> <dbe6e19f-84c2-f2eb-b9ab-d085de7c299c@mtcc.com> <4803.1551485670@localhost> <alpine.DEB.2.20.1903132150430.3161@uplift.swm.pp.se> <87d0mu1nrm.fsf@toke.dk> <alpine.DEB.2.20.1903140759060.3161@uplift.swm.pp.se> <87pnqtzqls.fsf@toke.dk> <alpine.DEB.2.20.1903141318260.3161@uplift.swm.pp.se> <87bm2dt17d.wl-jch@irif.fr> <875zskxqmr.fsf@toke.dk> <5CFA14C1-5332-450B-AE50-5459C4745B8A@orandom.net>
Date: Fri, 15 Mar 2019 22:41:07 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87lg1fx1cc.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/2n_uLrB1Trk9ggLQ-9la7zbrVJE>
Subject: Re: [homenet] -CoDel
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2019 21:41:14 -0000

"David R. Oran" <daveoran@orandom.net> writes:

> On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote:
>
>> Juliusz Chroboczek <jch@irif.fr> writes:
>>
>>>> PIE [...] lends itself better for implementation in existing 
>>>> hardware,
>>>> or hardware with small modification.
>>>
>>> Could one of you please explain why?
>>
>> With the caveat that I have never worked with any of this hardware, 
>> this
>> is my understanding:
>>
>> Basically, you can re-use the drop mechanism from RED and use the PIE
>> algorithm as a (better) way to control the setpoints. This makes it
>> possible to retrofit it in existing hardware. In fact I believe you 
>> can
>> implement PIE entirely in the (software) control plane on (a lot of)
>> gear that already knows how to do RED.
>>
> Another factor, which as I recall was perhaps the strongest of the
> original motivations for PIE, is that PIE does nearly all its work on
> enqueue, whereas CoDel does most of its work on dequeue. In many
> hardware interfaces, especially at a head end where there are lots of
> queues and a simple hardware FIFO feeding the link, it turns out to be
> difficult/expensive to insert the computations CoDel does on each
> dequeue operation.

Ah, I see. I guess that makes sense. Although I have also seen someone
implement CoDel in a "virtual queueing" setting where all computation is
done on enqueue and the sojourn time is simulated ahead of time. You
can't do this in all scenarios, but probably in more than one might
think... Obviously it would require a bit of work to go from the spec
(or reference implementation) to that, but it's definitely possible.

-Toke