Re: [homenet] homenet: what now? ... next?

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 15 March 2019 08:24 UTC

Return-Path: <swmike@swm.pp.se>
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 1E9101311F9 for <homenet@ietfa.amsl.com>; Fri, 15 Mar 2019 01:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 neMJSs0pPPKO for <homenet@ietfa.amsl.com>; Fri, 15 Mar 2019 01:24:17 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 B9B2D1311F2 for <homenet@ietf.org>; Fri, 15 Mar 2019 01:24:17 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 75187B3; Fri, 15 Mar 2019 09:24:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1552638254; bh=fTQQdPfPn1SFcFyTuNhoUIqcZsxiZhq221jg9gy4TLI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bVtzF/+uzCnXQKw7EegRhjo1BWQQxhnqZB+wdGvkMSo3PHfQA98OZ9zGOlCxgMiO4 w2WPTKkl/pqpSJxTxvmuYmsGYyF3e57sDC4nvDyHeHJtNZqE98GETwF7azrpufJSXa ElfIRAVkuoDOgXfBBI13eCNKOjWprvnotP3i+8zs=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7350AAF; Fri, 15 Mar 2019 09:24:14 +0100 (CET)
Date: Fri, 15 Mar 2019 09:24:14 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Juliusz Chroboczek <jch@irif.fr>
cc: Toke Høiland-Jørgensen <toke@toke.dk>, homenet@ietf.org
In-Reply-To: <87bm2dt17d.wl-jch@irif.fr>
Message-ID: <alpine.DEB.2.20.1903150912470.3161@uplift.swm.pp.se>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/9swAIU4PHKSkHAUkUzaMIU4HgmI>
Subject: Re: [homenet] homenet: what now? ... next?
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 08:24:21 -0000

On Fri, 15 Mar 2019, Juliusz Chroboczek wrote:

>> PIE [...] lends itself better for implementation in existing hardware,
>> or hardware with small modification.
>
> Could one of you please explain why?

Packet accelerators work either by completely autonomously forwarding 
packet without CPU involvement, or it works by flow offload. This 
basically means that on this kind of hardware if you tcpdump packets 
you'll see the first TCP handshake packets and then kernel sees nothing. 
It's now offloaded to the packet forwarding hardware, including all 
queueing decisions.

I am not an expert on exact implementations, but WRED is available on a 
lot of platforms. PIE seems to be taking a stance in WRED and adding a bit 
of control logic on top of it, and that's that. It means PIE has a 
possibility to be retrofitted onto older hardware.

FQ part of FQ_CODEL means you need to have a lot of queues, and you need 
to L4 hash onto these different queues. That's just not possible on a lot 
of HW.

I don't know if CODEL can be retrofitted onto WRED style HW, but I don't 
think so.

My observation has been that the bufferbloat movement has focused on 
academic excellence and making this work on the platforms they have 
available to them. Nothing wrong with that and the results are great, it's 
just not applicable to a lot of equipment out there that it should be 
applicable to.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se