Re: [arch-d] A Public Option for the Core

Toerless Eckert <> Mon, 17 August 2020 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 017DE3A0D47 for <>; Mon, 17 Aug 2020 09:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vzKDt4TrSzAn for <>; Mon, 17 Aug 2020 09:43:01 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF8083A0D42 for <>; Mon, 17 Aug 2020 09:43:00 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 3ECBD54802F; Mon, 17 Aug 2020 18:42:56 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 370A5440059; Mon, 17 Aug 2020 18:42:56 +0200 (CEST)
Date: Mon, 17 Aug 2020 18:42:56 +0200
From: Toerless Eckert <>
To: Christian Huitema <>
Cc: Joseph Touch <>,
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [arch-d] A Public Option for the Core
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2020 16:43:06 -0000

On Mon, Aug 17, 2020 at 08:19:59AM -0700, Christian Huitema wrote:
> Given the knowledge and trust issue,
> one-size-fits-all looks actually very practical. That does mean a
> compromise, because the network should allow those applications that
> want low latency to get it, but should not limit the bandwidth that
> applications can use if it is available. That probably requires more
> research and development in active queue management, and in congestion
> control algorithms that can cooperate with active queue management and
> deliver the profile that fits the application.

Thats again the look for networks we currently call "the Internet",
and quite valid there. But certainly not the only type of networks
IETF should be interested in.

When you look at managing traffic flows in e.g.: networks of an airplane,
you will see every individual flow being designed, and planned for before
the plane is built. And those parameters ar then embodied into the network
during plane building. I would call this the other end of the spectrum.

Instead of just talking about some of the tools (CC, ACM), it would be
nice to try to set goals first, to see if we could get agreement there:

-> I would like traffic to get the same throughput under congestion
   whatever its RTT is.

-> I would like for traffic to get bandwidth share indpendent of the
   number of 5 tuple flows it utilizes (no gaming the system). But
   rather fair per subscriber (weighted by how much the subscriber pays).

-> I would like to be able for traffic to indicate preferences for
   lower latency or higher throughput... If you ask for lower latency,
   you get less throughput.

-> Goodput always > 95%

That would be a start for the most simple "one-size-fits" all i could
imagine. But there is a lot more things i would like to factor in beyond


> -- Christian Huitema