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

Toerless Eckert <tte@cs.fau.de> Mon, 17 August 2020 22:50 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 7E1203A13F8 for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 15:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XMxLHuAg6XBB for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 15:50:31 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474863A13F7 for <architecture-discuss@ietf.org>; Mon, 17 Aug 2020 15:50:30 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 37311548621; Tue, 18 Aug 2020 00:50:26 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 30ABE440059; Tue, 18 Aug 2020 00:50:26 +0200 (CEST)
Date: Tue, 18 Aug 2020 00:50:26 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Joseph Touch <touch@strayalpha.com>
Cc: Christian Huitema <huitema@huitema.net>, architecture-discuss@ietf.org
Message-ID: <20200817225026.GD62842@faui48f.informatik.uni-erlangen.de>
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> <F232EFB9-F671-45DA-B7FB-97DE5C883545@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F232EFB9-F671-45DA-B7FB-97DE5C883545@strayalpha.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/Go5yAlcF9ZTNAnapQ6V5qLIqtp0>
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 22:50:34 -0000

On Mon, Aug 17, 2020 at 11:59:09AM -0700, Joseph Touch wrote:
> 
> 
> > 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.

Thats a matter of opinion. many transportation services have elements
of equalization in them. postal charges within countries for example
(for most parts equal cost even when you live far away). Financial
market information needs to get more and more latency equalized for
market fairness.

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

Yes, i was talking about granularity of fairness.

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

Yes. There is IMHO the not well explored opportunity to take up space
in already provisioned but unused buffers - for example for equalization
of latency where that is desirable.

But when you want lower latency you might want to get into one of the
fewer buffers served faster. And there would be fewer of those than
when you have more time to hang around. What impact would that have
on relative throughput ?

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

We understand how to manage classical diffserv/intserv solutions.
And how managing them is limited by scale and cost of management vs.
incremental sales revenue. The interesting question is what different
services you can reasonably multiplex so different apps get different
benefits but it doesn't end up simply every app wanting to game the
system by picking the one "winner" service.

For example, theoretically something like scavenger sounds like a
nice option. But applications would only use it if the non-scavenger
traffic was more expensive. Eg.: go beyond your monthly volume limit
with scavenger. Likewise the use of best-effort vs. low latency would
self regulate if the throughput loss of low-latency was making it
only worth for traffic that really needed lower latency.

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

True, goodput is ambiguous as fairness. I was primarily thinking
of retransmissions to be below 5% (of course for non-low-latency traffic
only).

Cheers
   Toerless
> 
> Joe
> 

-- 
---
tte@cs.fau.de