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

Marie-Jose Montpetit <> Tue, 18 August 2020 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82D433A0E0B for <>; Tue, 18 Aug 2020 14:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, 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 UYbwmZaCmTKa for <>; Tue, 18 Aug 2020 14:30:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10BEF3A0DDB for <>; Tue, 18 Aug 2020 14:30:43 -0700 (PDT)
Received: by with SMTP id t23so23096518ljc.3 for <>; Tue, 18 Aug 2020 14:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=5foLxCpdG0szEiglsjXW5MT9fo/HO+1L1megaxFIhEo=; b=ZMEca2dvnxFXYMafp8zfiGN/kofyM9dMuxI/oAq36VXqRqRvGwmVWskVAZ2mEL2qYZ +wDb5h/quF6pQ/n7OQ3NnMysHFulyJoQ31t5Joc5zL6HpiDh5/w4t+9j1iUUTxz/GCZ9 rT6Oexl2j7ff30LTBpheuSqbKHn56W6mwGhpTqF3eEx9CEN5MwTlVk3+cgw1qtNtvr2d TJ0GRiuP5XU7a30Qo0IlVh0ByFnRcJ8cddRzvtmMEYalYvWiDPoYCdir+Dl1ty3RR4vB UiWmHszG5lmBTvirt2NzY1fqODflyY+QpBKyylsl8xsTFKbnf01lpz6b5nQLAB/4QLvz /P0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5foLxCpdG0szEiglsjXW5MT9fo/HO+1L1megaxFIhEo=; b=QeCVCQZQiqmGSxx5Q04PWBmWAOacU6hLH3g0ILoOXLPKt59LZciFnIft1HyIVfKzzW lqLnmAP6otevYAZX2jKUYl67C4J13G22RzQCnlvYRan58/c8YNyimP4v5pjswkGCQnZV tF8m6+vgYucwfiSqZWrN05MoWhq/MAsBXKbiq3LZOutFmvXjtNmQ6vBbw/cVo69D/Lg9 bFkUYAm97RoXQN/v8XlDvZ7TQEA6hFY8umOepZ5HemGk04LW5ufaM05J0J0KYWAPdoIc 9G+6lUWrIcgKQYoEfyCZb/3BU081kD4HsZQoR1Z5gVg22CRGByYcLxxLytmSIcX6ijtS HkWQ==
X-Gm-Message-State: AOAM5301SU9javsiFuXECUaUd5M7pCNJ65RUOTH4rjuLg2nVEifiT16u dgH0cY8J3gO4FpXjNX0r9zRdtmtcaQVDbvJfCxPphY+KusM1og==
X-Google-Smtp-Source: ABdhPJwfx6s24YtuL7s1U1qXjR/97tc2bvfUrCt674LGjGpbmbb9G0wmRpD2STMM68rIbi97WSpm6LVpSCeQhn5bxVw=
X-Received: by 2002:a2e:a497:: with SMTP id h23mr10145205lji.154.1597786242034; Tue, 18 Aug 2020 14:30:42 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 18 Aug 2020 14:30:41 -0700
From: Marie-Jose Montpetit <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Date: Tue, 18 Aug 2020 14:30:41 -0700
Message-ID: <>
To: Brian E Carpenter <>, Toerless Eckert <>
Content-Type: multipart/alternative; boundary="0000000000006242c905ad2d99cd"
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: Tue, 18 Aug 2020 21:30:47 -0000

Just a note: while in nwcrg we have not addressed coding and storage there
is indeed a large amount of work in the area.

Marie-José Montpetit, Ph.D.

On August 18, 2020 at 5:23:50 PM, Brian E Carpenter ( wrote:

On 18-Aug-20 17:26, Toerless Eckert wrote:
> Multiple parallel TCP connections to overcome TCP issues with high
> capacity high loss paths even in the absence of congestion was always
> a bad workaround.

It's certainly a workaround, but why was it particularly bad? The
context where GridFTP was developed and used was the world of very
high capacity links between major Big Data sites; it's actually a
good example for RFC8799 that we overlooked.

If you really want maximum throughput on such links, which also have
very low bit error rates, you can use a non-windowing, rate-controlled
transport protocol with simplified error handling. But that's not an
IETF problem, really.

> Digital Fountain was already selling software 15 years
> ago with scatter storage and network coding gather retrieval. Still
> network coding researchers seem to claim this stuff is new today.

The network coding literature goes back to at least 2000**.
The network coding people I know are aiming at a different problem
area today: poor quality wireless and/or overloaded satellite links.
Exactly the opposite of the Big Data scenario. (However, I am not
tracking the NWCRG. I am rather amazed by the lack of references
to the extensive literature insurance, but draft-irtf-nwcrg-nwc-ccn-reqs
does better.)

> A lot of of the network side problems of this are the result of the
> traditional, uncontrolled transit SP paths, aka: the classical Internet
> model.



** R. Ahlswede, N. Cai, S.-Y.R. Li and R.W. Yeung, “Network
Information Flow”, IEEE-IT, vol. 46, pp. 1204-1216, 2000.
> Cheers
> Toerless
> On Tue, Aug 18, 2020 at 11:54:34AM +1200, Brian E Carpenter wrote:
>> On 18-Aug-20 04:42, Toerless Eckert wrote:
>> ...
>>> -> 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).
>> You just broke GridFTP, used in Big Science to move terabyte datasets
>> around the world efficiently. It's not gaming, it's achieving throughput
>> despite defects in TCP. But the topic is very much alive there, since
>> GridFTP is now unsupported.
>> For further reading:
>> Brian

Architecture-discuss mailing list