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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 18 August 2020 21:23 UTC

Return-Path: <brian.e.carpenter@gmail.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 0BA793A0D01 for <architecture-discuss@ietfa.amsl.com>; Tue, 18 Aug 2020 14:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qd6OKb0a2_7K for <architecture-discuss@ietfa.amsl.com>; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF35A3A0CFC for <architecture-discuss@ietf.org>; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
Received: by mail-pf1-x444.google.com with SMTP id y206so10572931pfb.10 for <architecture-discuss@ietf.org>; Tue, 18 Aug 2020 14:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id v2sm783238pjd.18.2020.08.18.14.23.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 14:23:35 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: architecture-discuss@ietf.org
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> <b3044f47-d2a0-7ef3-4a0e-4e6b9e3023ba@gmail.com> <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com>
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: <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/jMiqi37weooV2Be9nRyYFdkg-Ls>
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: 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. 

Indeed. 

Regards
    Brian

** 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:
>> https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy
>>
>>     Brian
>