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

Joseph Touch <touch@strayalpha.com> Mon, 17 August 2020 18:59 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75F93A09D9 for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 11:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 t3fOiknwOqIw for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 11:59:15 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 29E3D3A09CC for <architecture-discuss@ietf.org>; Mon, 17 Aug 2020 11:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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 cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61993 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) 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.120.23.2.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de>
Date: Mon, 17 Aug 2020 11:59:09 -0700
Cc: Christian Huitema <huitema@huitema.net>, architecture-discuss@ietf.org
Message-Id: <F232EFB9-F671-45DA-B7FB-97DE5C883545@strayalpha.com>
References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <FB381338-A278-45B2-A40B-3A065E3A3ED1@strayalpha.com> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/f-DslMzpd7T-RNRNsymv0_7wueI>
Subject: Re: [arch-d] A Public Option for the Core
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 18:59:22 -0000


> On Aug 17, 2020, at 9:42 AM, Toerless Eckert <tte@cs.fau.de> 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.

Joe