Re: [nwcrg] [LOOPS] 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: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC14120071 for <nwcrg@ietfa.amsl.com>; 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=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 uFNgGJoFdcYW for <nwcrg@ietfa.amsl.com>; 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 95454120058 for <nwcrg@irtf.org>; 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/nwcrg/kpRFGIDuMTSqCfnM_xRnMbBxeHg>
Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 01:46:28 -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>
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Carsten Bormann
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Carsten Bormann
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Liyizhou
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Michael Welzl
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Colin Perkins
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Zhouxingwang (Joe)
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Colin Perkins
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Zhouxingwang (Joe)
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Stuart William Card
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Carsten Bormann
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Stuart William Card
- Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting o… Zhouxingwang (Joe)