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

Joseph Touch <> Mon, 17 August 2020 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B75F93A09D9 for <>; Mon, 17 Aug 2020 11:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t3fOiknwOqIw for <>; Mon, 17 Aug 2020 11:59:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29E3D3A09CC for <>; Mon, 17 Aug 2020 11:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r2B1ij3HOkKboNP1dUSCAhXQyD8QCClxkLe/dRDA20U=; b=KeWi02Z/Ri2iplsxh7pZ/hahO XVQpvLUJDhppmP2QZD5WJWD1ruQ1AnSygb8thiim4vhpZo7HwyonKs/rbtpPh8j8CwUg/jyjyKZ19 6i/4of926ShYzUD6WnplGM1Agww1WhSt3TpwXDD9PoftElGMYso8z9giu8GRbZk/QEi3y30iamTls pE8BTRflvl5JVpEksaq1VmROpOHttjhD80is5QJBWh23CaFDwHN/rK0GyyNR5QUqgYUB50PD2lx83 9mQRmMX87mYiGWPMyvKV5OtqBfnmzhVijSQqb7MCE1/xzzl7frM0jiLlMxxhp1cik1Cpn15Ei5x1u JWY9TNQyw==;
Received: from ([]:61993 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1k7kLe-003KaV-2l; Mon, 17 Aug 2020 14:59:14 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A31397B-9855-4713-9CB7-DAFFFF911E16"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Mon, 17 Aug 2020 11:59:09 -0700
Cc: Christian Huitema <>,
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Toerless Eckert <>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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 18:59:22 -0000

> On Aug 17, 2020, at 9:42 AM, Toerless Eckert <> wrote:
> 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.

Yes, as long as the issue isn’t that the ISP does something differently based on RTT>

If they run feedback loops whose recovery depends on RTT, then it’s their fault if they don’t get a fair share. It’s not the ISPs job to compensate for that.

> -> 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).

That’s 1 class of service. There can be more than one (or are you just treating that as ‘different subscribers’?).

> -> 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.

Three network decisions:
	- go now
	- take up space and go later
	- drop

It seems like there ought to be three service classes (at least):
	- low latency and low loss (go now)
	- low loss with increased latency (go later)
	- everything else (drop if you can’t handle it)

That roughly maps to a few of the DSCPs. The rest are there largely to ensure that “some pigs are more equal than others”, i.e., that network management/control protocols can bump others. That sort of priority - with a single ‘reserved’ level - may be important to operations, but shouldn’t be sold out to users.

> -> Goodput always > 95%

I have no idea what goodput is. Nothing ensures that a packet that ‘wins’ on a link now won’t be dropped downstream when competing for other resources. If you want goodput to be high, then load has to be low (vs. capacity), i.e., under 50-60%-ish.