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

"Stuart William Card" <> Mon, 06 January 2020 01:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FC14120071 for <>; Sun, 5 Jan 2020 17:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uFNgGJoFdcYW for <>; Sun, 5 Jan 2020 17:46:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 95454120058 for <>; Sun, 5 Jan 2020 17:46:26 -0800 (PST)
Received: by (Postfix, from userid 99) id DC75F3801D; Sun, 5 Jan 2020 20:32:40 -0500 (EST)
Received: from (unknown []) by (Postfix) with ESMTP id 9240F1854D; Sun, 5 Jan 2020 20:32:38 -0500 (EST)
Received: from (SquirrelMail authenticated user cardsw) by with HTTP; Sun, 5 Jan 2020 20:46:22 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Sun, 5 Jan 2020 20:46:22 -0500
From: "Stuart William Card" <>
To: "Carsten Bormann" <>
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: <>
Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> (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)