Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

"Stuart William Card" <stu.card@critical.com> Mon, 06 January 2020 01:46 UTC

Return-Path: <stu.card@critical.com>
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 F22E2120058; Sun, 5 Jan 2020 17:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 biPEcu59lh0E; Sun, 5 Jan 2020 17:46:26 -0800 (PST)
Received: from mail.critical.com (mail.critical.com [209.217.211.166]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8C120045; Sun, 5 Jan 2020 17:46:26 -0800 (PST)
Received: by mail.critical.com (Postfix, from userid 99) id DC75F3801D; Sun, 5 Jan 2020 20:32:40 -0500 (EST)
Received: from www.critical.com (unknown [192.168.6.38]) by mail.critical.com (Postfix) with ESMTP id 9240F1854D; Sun, 5 Jan 2020 20:32:38 -0500 (EST)
Received: from 74.78.200.230 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Sun, 5 Jan 2020 20:46:22 -0500
Message-ID: <266cb00cb46ed971f3055a086b421312.squirrel@www.critical.com>
In-Reply-To: <A5F38E44-F83A-41EC-AFF6-90EDFFFDF057@tzi.org>
References: <AAF1E19E-37C1-4A9D-B92A-621054B06AF6@tzi.org> <c172b80c-04ee-9786-153f-9e1dda57fdd8@steinwurf.com> <3D026CEF-AF7D-4CDE-8A5B-8CE5DCF749D1@tzi.org> <163A8040-9B13-43AA-8917-F75D984B0EBF@tzi.org> <26708398-5DEB-478E-8CB8-D406A8B874FF@tzi.org> <7DC0B005-8BA2-4D80-8CDF-4E2AE7EA96F3@tzi.org> <24526f0dbdcbdb65951d16cb5770fcbe.squirrel@www.critical.com> <A5F38E44-F83A-41EC-AFF6-90EDFFFDF057@tzi.org>
Date: Sun, 05 Jan 2020 20:46:22 -0500
From: Stuart William Card <stu.card@critical.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: loops@ietf.org, nwcrg@irtf.org, dtn@ietf.org
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/EArgGfZHd5XZyzYhsM8vTbNyMro>
Subject: Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
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: Mon, 06 Jan 2020 01:46:29 -0000

Carsten --

Thanks for your thoughtful response. I'll try to focus my inputs. :-)

> ...
> (1) ... more intricate (and timely) knowledge of the critical path
segment...
> (2) techniques such as TCP splitting allowed mitigating some...
> of the latency induced performance issues end-to-end protocols exhibited...
> With increasing use of encryption... (2) is going away...
> (1) will stay relevant... where that knowledge can be provided...
> What LOOPS is trying to do is providing a protocol that can help even in
> the absence of both (1) and (2)...
> recovering packets can lead to reordering...
> applications will need to be part of the picture...
> LOOPS itself will need to focus on a more narrow
> set of problems and opportunities, and this is the time to discuss whether
> we got that narrowing right in the current charter proposal...

Agreed. Further, not only transport but also network layer encryption
kills simple approaches to (2), leaving AFAIK only multipath or trading
increased mean latency to reduce latency variance.

Many of us have suffered from suboptimal and sometimes unanticipated
interactions between link and transport layer behaviors (retransmission in
both, flow control in the data link, congestion control in the transport).
Application layer adaptive behaviors (e.g. video streaming that switches
dynamically during a session among different source coding rates based
upon end to end performance as it varies) further complicate this. LOOPS
will be yet another interacting control loop. In the worst case, a
non-congestion loss of a link layer frame could lead to:
- data link retransmission
- LOOPS retransmission
- transport retransmission
- transport backoff
- application rate downshift
All at once! Presumably we can't prevent this altogether but want to
minimize its occurrence.

The charter looks good. I suggest broadening its scope of consideration of
cross-layer interactions: not just w/transport congestion control, but
also w/retransmission, misordering & resequencing at all layers.

-- 
Stuart W. Card, VP & Chief Scientist
Critical Technologies Inc. (CTI)
<stu.card@critical.com>