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

Brian E Carpenter <> Tue, 18 August 2020 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BA793A0D01 for <>; Tue, 18 Aug 2020 14:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Status: No, score=-3.047 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-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 qd6OKb0a2_7K for <>; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF35A3A0CFC for <>; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
Received: by with SMTP id y206so10572931pfb.10 for <>; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rm7Gy22Ni6nHgVDs5CwvgZ6OWaJunp4ElB0hWT9S3kk=; b=pDh519tbDCvOejtiiK9O0KLi+9+Sm+PX+qNsEcNtTsZvkxAqBc8NbWcPa40ICOfCxg 01EX4bT+Vb5V6Z+uGKE8FEVY6eXRXlxHsU+xdU6ziVktwxh9sh5tvFqxRmyT7ygVhIUu h0V6kZPXUVqkaw/kANh1M81mTslnekJtn3pfu4bN4YY3xKlJuG/9xqNeb832z29Qjfy6 cFyiCLMnxT3pWz0Eawsa8FwIDxx541QgOPzmM2Knfx35S4v2vHSRw5TinH5B8cv9iX2q F2Owkoymle93/P3BBx8VERjqPNsImjikvulzEAOp77seweqtzvduN3OPA0SFDChQpvtw 1nOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rm7Gy22Ni6nHgVDs5CwvgZ6OWaJunp4ElB0hWT9S3kk=; b=DIAQk84L6YoIRdE1dUBXufleWPoV+4mkXgLZ3efNTB4QoDoIZvrtD8hopLCcPUtIZI fQefku4C2btMAviW8Njm+RvbzpbX50TLVb9sfVjJrwPxEkF+4wdXY1jvxukebTGVKwJb mzp7ABRELCyJsoECL+fjff2CLn3aNWPlrMzzTu55/knRTdbPTRQCrxJqWDZdLhc2mCBQ jacx5JqsD7k9cg2EJoj9KmuIqgLE9TNd5uZ0hrllmduOuByR3D0CmOOBwJVXr45Jrodo rutUdG8e+2Dow7ps/GkOyG7v2GjdLjuSEY60dE57dxOcOEBjEsH3GTBZ5SyuJhcYYDkj cRwQ==
X-Gm-Message-State: AOAM5330fnWwKL2fwXT/xUZGRrVbEifmOj1176Yed1Xvrjq9Sxeni4Ys Dmu+uHdcTmyb0KHkHrFiwG1mZkEa/dgk6Q==
X-Google-Smtp-Source: ABdhPJyilqOpT+wkyJ+VstwCcq1zlQN6Hj4624rxkAINBFkaV1lg3YcqCLbjyLOAKGOJfA0cfoVbZg==
X-Received: by 2002:a62:164a:: with SMTP id 71mr16826833pfw.266.1597785816001; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id v2sm783238pjd.18.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 14:23:35 -0700 (PDT)
To: Toerless Eckert <>
References: <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 19 Aug 2020 09:23:31 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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:23:38 -0000

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 in RFC8406, 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