Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases.

Carsten Bormann <cabo@tzi.org> Thu, 30 July 2020 15:16 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07453A08FF for <loops@ietfa.amsl.com>; Thu, 30 Jul 2020 08:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0qTqpACNtbP1 for <loops@ietfa.amsl.com>; Thu, 30 Jul 2020 08:16:41 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB923A091B for <loops@ietf.org>; Thu, 30 Jul 2020 08:16:41 -0700 (PDT)
Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BHYsg5xyfzyT6; Thu, 30 Jul 2020 17:16:39 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <faf62c9a-3380-7d72-f39e-2153c9d13680@wizmail.org>
Date: Thu, 30 Jul 2020 17:16:39 +0200
Cc: loops@ietf.org
X-Mao-Original-Outgoing-Id: 617814999.241396-87601213d0ba5be0e4db5dc2f890595f
Content-Transfer-Encoding: quoted-printable
Message-Id: <19B91FED-B5BC-41E0-8B7B-F3F164ACAF03@tzi.org>
References: <fb709277-50a8-26ad-b925-38f153805d70@erg.abdn.ac.uk> <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> <faf62c9a-3380-7d72-f39e-2153c9d13680@wizmail.org>
To: Jeremy Harris <jgh@wizmail.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/ziJGlyeoI9TbjwLavOjOSfkj0Rs>
Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases.
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 15:16:45 -0000

Hi Jeremy,


> On 2020-07-30, at 15:50, Jeremy Harris <jgh@wizmail.org> wrote:
> 
> On 29/07/2020 22:52, Carsten Bormann wrote:
>>> (2) I will argue there is not a satellite-specific use case really, there is a use case for any reliable long-haul path (large RTT) that is concatenated with another segment with a lossy segment with lower RTT.
>> 
>> Yes!
>> (For a definition of “reliable”.)
> 
> Seems you'd do well, for that scenario, to have a separate LOOPS-like
> reliability segment for the lower-RTT but lossy segment - to better
> respond given the segment RTT being lower than the full path RTT?

Yes.

> But we're regressing to the 1950's era of separate link-reliability
> mechanisms, and a sequence of such links.  Something the e2e principle
> discarded very successfully.  Are we really better off, provably?

I do not think there is a conflict with the e2e argument here (*).
LOOPS is not replacing TCP/QUIC/etc., it is assisting the e2e protocol.
All links that do not have ridiculous signal/noise budgets have some form of error recovery; that may just not very visible or well known (e.g., Trellis Coding for Gigabit Ethernet).  In theory, that would always be working well and be enough so the rest can be done in the e2e protocol.  In practice, there is a difference between theory and practice.

Grüße, Carsten

(*) Please see Section 2.3 of https://dl.acm.org/doi/10.1145/357401.357402 if you need an appeal to the original reference.