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

"Stuart William Card" <stu.card@critical.com> Mon, 23 December 2019 00:02 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 151E3120013; Sun, 22 Dec 2019 16:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 ftUNxIwK2W-4; Sun, 22 Dec 2019 16:02:25 -0800 (PST)
Received: from mail.critical.com (mail.critical.com [209.217.211.166]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7A120047; Sun, 22 Dec 2019 16:02:24 -0800 (PST)
Received: by mail.critical.com (Postfix, from userid 99) id 98A5F3801D; Sun, 22 Dec 2019 18:49:37 -0500 (EST)
Received: from www.critical.com (unknown [192.168.6.38]) by mail.critical.com (Postfix) with ESMTP id 55D66191BF; Sun, 22 Dec 2019 18:49:34 -0500 (EST)
Received: from 72.10.213.204 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Sun, 22 Dec 2019 19:02:21 -0500
Message-ID: <24526f0dbdcbdb65951d16cb5770fcbe.squirrel@www.critical.com>
In-Reply-To: <7DC0B005-8BA2-4D80-8CDF-4E2AE7EA96F3@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>
Date: Sun, 22 Dec 2019 19:02:21 -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/QGZv6QEu_nlBpoqZfUlADm6Aw70>
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, 23 Dec 2019 00:02:28 -0000

Carsten et al --

There has been interesting discussion since this thread-starter, but as I
am not responding specifically to any of the points in those subsequent
messages, I'll reply to this one.

Over 15 years ago, for an enterprise with global air mobile operations, I
was deeply involved in enabling IP networking among LANs aboard aircraft
and WANs on the ground.

Then there were few air-ground links available, and they were mostly:
 - high error (or packet loss) rate
 - low data rate
 - long latency
 - half-duplex (with long transmit-receive turn-around times)
 - asymmetric
 - rapidly and widely varying in all the above characteristics

So we used store-and-forward Delay/Disruption Tolerant Networking (DTN)
techniques were we could, but also had to support TCP/IP applications.

To take advantage of all of the different narrow-band links to/from the
aircraft, we integrated what we called Concurrent Multipath Routing (CMR).
This was not just flow by flow but also packet by packet load balancing
and failover, as often we had only a single application flow demanding a
higher data rate than we could achieve over a single air-ground link, as
well as the need for multi-homing for smooth make-before-break mobility
handoffs. Of course, this resulted in frequent Out Of Order Delivery
(OOOD), utterly trashing performance of basic TCP. Each different
air-ground link was just a single hop, near the aircraft end, of a
multi-hop path, with each ground segment run by a different organization
with different QoS etc. policies. Further, some links had reliable link
layer protocols that used ARQ, causing further RTT variation, so TCP
retransmissions were often needlessly triggered, redundant with (and
slower than) link layer retransmissions.

So we integrated symmetric transparent TCP Performance Enhancing Proxies
(PEPs) based on the Space Communications Protocol Specifications -
Transport Protocol (SCPS-TP), an interoperable TCP variant with additional
(IANA listed) options, especially Selective Negative ACKnowledgment
(SNACK). We implemented and got CCSDS to standardize "Lazy SNACK", where
the transport layer receiver does not immediately SNACK a hole in the
sequence and/or the transport layer sender does not immediately retransmit
in response to getting a SNACK; this more patient strategy dramatically
improved response to CMR's OOOD and the reliable link layer's ARQ.

I relate all this because I wish to suggest that LOOPS participants brush
up on SCPS-TP (the protocol, its testing and its uses), to avoid
unnecessarily re-inventing wheels. I recognize that LOOPS is for path
_segments_: we used SCPS-TP only on a portion of our end-to-end multipath
route, so that is the same; but our TCP<->SCPS-TP PEPs were transparent,
which is largely infeasible today as it looks like a Man In The Middle
attack and is defeated by end-to-end encryption (whether IPsec or TLS).
However, it certainly is possible to tunnel IP in TCP (or SCPS-TP), albeit
with substantial overhead. I'm not suggesting an IP in SCPS-TP tunnel as a
LOOPS technique, but something _like_ that might make some sense. Anyway,
check out the CCSDS standard for SCPS-TP for good ideas on dealing with
lousy path segments. Here are some getting-started references --

https://en.wikipedia.org/wiki/Space_Communications_Protocol_Specifications
https://public.ccsds.org/publications/scps.aspx
https://public.ccsds.org/Pubs/714x0b2.pdf

Although few are aware of SCPS-TP (even those who are using it, as it is
typically embedded in their SATCOM gateways), it is required for all U.S.
military TCP over SATCOM, and there has been recent work outside DoD --

http://www.ittc.ku.edu/resilinets/papers/Nguyen-Sterbenz-wns3-2017.pdf

I can provide lots of other references for anyone interested. We are also
planning to launch a new [secure] reliable [multicast] transport mailing
list to replace the old SCPS and NACK Oriented Reliable Multicast (NORM)
lists (we have the NORM list archives).

Note I added the DTN working group to distribution on this message; you
may or may not want to keep them on distribution of replies.

Thanks all!

-- Stu

> Thanks again everyone for the participation at the LOOPS side meeting and
> in our slot at the NWCRG meeting.
>
> I have compiled more detailed notes, with links to/copies of the meeting
> materials, at
>
> https://github.com/loops-wg/ietf106
>
> Please do have a look at the notes, specifically [1] and [2], and send
> corrections and additions.  Also, there were a few items in the NWCRG
> discussion where there may be results that we already can point to; as
> Marie-Jose said, please send them to both mailing lists.
>
> Grüße, Carsten
>
> [1]:
> https://github.com/loops-wg/ietf106/blob/master/ietf106-loops-side-meeting.md
> [2]:
> https://github.com/loops-wg/ietf106/blob/master/ietf106-nwcrg-loops.md
>
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg

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