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

Marie-Jose Montpetit <marie@mjmontpetit.com> Tue, 18 August 2020 21:30 UTC

Return-Path: <marie@mjmontpetit.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 82D433A0E0B for <architecture-discuss@ietfa.amsl.com>; Tue, 18 Aug 2020 14:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.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 UYbwmZaCmTKa for <architecture-discuss@ietfa.amsl.com>; Tue, 18 Aug 2020 14:30:44 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 10BEF3A0DDB for <architecture-discuss@ietf.org>; Tue, 18 Aug 2020 14:30:43 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id t23so23096518ljc.3 for <architecture-discuss@ietf.org>; Tue, 18 Aug 2020 14:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 gmailapi.google.com with HTTPREST; Tue, 18 Aug 2020 14:30:41 -0700
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <6998f7af-7834-3aa3-300d-410036cd2466@gmail.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> <b3044f47-d2a0-7ef3-4a0e-4e6b9e3023ba@gmail.com> <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de> <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com>
MIME-Version: 1.0
Date: Tue, 18 Aug 2020 14:30:41 -0700
Message-ID: <CAPjWiCTToT=2dvOFhjVydZnMj91mFuHgBbxxxzUSFo8Hcv94kQ@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Toerless Eckert <tte@cs.fau.de>
Cc: architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006242c905ad2d99cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/ejlJgeqHLPHqQU0RBTvN2qTQtF8>
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: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.
marie@mjmontpetit.com



On August 18, 2020 at 5:23:50 PM, Brian E Carpenter (
brian.e.carpenter@gmail.com) 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.

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
>

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss