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>
- [LOOPS] IETF106: LOOPS side meeting on Tuesday 08… Carsten Bormann
- Re: [LOOPS] IETF106: LOOPS side meeting on Tuesda… Morten V. Pedersen
- Re: [LOOPS] IETF106: LOOPS side meeting on Tuesda… Carsten Bormann
- Re: [LOOPS] IETF106: LOOPS side meeting on Tuesda… Carsten Bormann
- Re: [LOOPS] IETF106: LOOPS side meeting on Tuesda… Carsten Bormann
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Carsten Bormann
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Liyizhou
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Michael Welzl
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Colin Perkins
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Zhouxingwang (Joe)
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Colin Perkins
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Zhouxingwang (Joe)
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Stuart William Card
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Carsten Bormann
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Stuart William Card
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Zhouxingwang (Joe)
- Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting o… Michael Welzl