Re: [PANRG] IETF/IRTF huddle about Performance Implications of PATH Characteristics (PIPC)

Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> Tue, 23 July 2019 20:34 UTC

Return-Path: <Nicolas.Kuhn@cnes.fr>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7804D120973 for <panrg@ietfa.amsl.com>; Tue, 23 Jul 2019 13:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 RjS7EcuPwHoI for <panrg@ietfa.amsl.com>; Tue, 23 Jul 2019 13:34:49 -0700 (PDT)
Received: from mx2.cnes.fr (mx2.cnes.fr [194.199.174.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF14120904 for <panrg@irtf.org>; Tue, 23 Jul 2019 13:34:48 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.64,300,1559520000"; d="scan'208,217"; a="28153140"
X-IPAS-Result: A2GVBwCfbjdd/wIBeApmHgEGBwaBZ4EVgVsUgS4KhBOUJZJ7hheBZwkBAQEBAQEBAQE3AQGBS4J1AheCWzgTAQMBAQEEAQEBAQQBAQIChU5FhUwCAQMjClwCAQgNFSACAgIwJQIEARIIgxuBHawKgTIaiiOBNIFjjBKBEUaCTD6EAAw6gwkygiYEjnSEfpZxBwKBMmmCH5IIc4E6hyWDeQOKPI01mV9MgS4zGieDOIJ5jg1yjkWBIQEB
X-URL-LookUp-ScanningError: 1
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
To: 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>, "panrg@irtf.org" <panrg@irtf.org>
Thread-Topic: [PANRG] IETF/IRTF huddle about Performance Implications of PATH Characteristics (PIPC)
Thread-Index: AQHVQZRzB7SnjGH0M02QgNp4noj9SKbYpt3Q
Date: Tue, 23 Jul 2019 20:33:45 +0000
Deferred-Delivery: Tue, 23 Jul 2019 20:34:44 +0000
Message-ID: <F3B0A07CFD358240926B78A680E166FF1EC24E5E@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <CAKKJt-cBqzBJQnfSdvgn6LikQ6x+8stnSwnpheW12K4hdTkiEg@mail.gmail.com>
In-Reply-To: <CAKKJt-cBqzBJQnfSdvgn6LikQ6x+8stnSwnpheW12K4hdTkiEg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24790.001
x-tm-as-result: No--26.301700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F3B0A07CFD358240926B78A680E166FF1EC24E5ETWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/PlWVAWbzl36iWRGI3hAQ-T9PXFE>
Subject: Re: [PANRG] IETF/IRTF huddle about Performance Implications of PATH Characteristics (PIPC)
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 20:34:53 -0000

Hi,

I can hardly make it tomorrow morning but I can confirm that IETF104’s session was very interesting.

>>“I believe it's time to revisit this topic, and to focus on PATH characteristics, rather than first-hop link characteristics.”
+1

Moreover, we have slot at PANRG where we present some ‘QUIC 4 SATCOM’ aspects where we focus on the use of in-sequence paths that have (very) different characteristics (typically in sequence use of SATCOM and Wi-Fi or SATCOM for backhauling cellular networks).
Please find here an extract of the introduction of the related document.

   Satellite systems has long been used to support point-to-
   point links and specialised networks.  The predominate current use is
   as a link-layer for Internet Protocols.  Typical example applications
   include: use as an access technology for remote locations, backup and
   rapid deployment of new services, transit networks, and backhaul of
   various types of IP networks, and provision to mobile (maritime,
   aircraft, etc).  The satellite IP network segment usually only forms
   one part of the end-to-end path.  This means user traffic can
   experience a path that includes satellites satellite capacity together
   with a wide variety of other network technologies (Ethernet, cable
   modems, WiFi, cellular, radio links, etc).  Although a user can
   sometimes the presence of the satellite service, a typical user does
   not deploy special software or applications because they expect a
   satellite network is being used.  Often a user is unaware of the
   technologies underpinning the links forming the network path.

Cheers,

Nico

De : Panrg <panrg-bounces@irtf.org> De la part de Spencer Dawkins at IETF
Envoyé : mardi 23 juillet 2019 22:22
À : panrg@irtf.org
Objet : [PANRG] IETF/IRTF huddle about Performance Implications of PATH Characteristics (PIPC)

Dear PANRG,

The PILC ("Performance Implications of Link Characteristics") working group produced a number of BCPs providing guidance for protocol designers working with links that were slow, error-prone, and asymmetric, for subnetwork designers, and for Performance Enhancing Proxies (PEPs), between 1999 and 2004.

Networks and protocols have changed significantly since 2004.

I believe it's time to revisit this topic, and to focus on PATH characteristics, rather than first-hop link characteristics.

We had a side meeting about this at IETF 104, and there was significant interest, so we are ready to move forward.

I'll be hosting a side meeting in the IETF Code Lounge at 8:30-9:30AM on WEDNESDAY (moved from Tuesday to accommodate attendance at Technology Deep Dive on NICs), to talk about next steps. Any recommendations will come out of the IETF, but I'm inviting IRTF people to help us separate what's research, and what's close enough to engineering to be used as the basis for IETF recommendations.

Thanks - andplease come if you should be there.

Spencer