[tsvwg] TR: New Liaison Statement, "LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities"

<emile.stephan@orange.com> Wed, 16 October 2019 10:58 UTC

Return-Path: <emile.stephan@orange.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881901200CE; Wed, 16 Oct 2019 03:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dRA5mu5u5fqk; Wed, 16 Oct 2019 03:58:23 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670DD1200C4; Wed, 16 Oct 2019 03:58:23 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 46tTmY5qdhz5w5d; Wed, 16 Oct 2019 12:58:21 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 46tTmY4qc9zDq7r; Wed, 16 Oct 2019 12:58:21 +0200 (CEST)
Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 16 Oct 2019 12:58:21 +0200
From: <emile.stephan@orange.com>
To: "etosat@ietf.org" <etosat@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: New Liaison Statement, "LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities"
Thread-Index: AQHVgrIHFeWMHsj7FEWM/Op/T9/9oKddFXBA
Date: Wed, 16 Oct 2019 10:58:21 +0000
Message-ID: <23548_1571223501_5DA6F7CD_23548_322_3_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931EFD3A1@OPEXCAUBM44.corporate.adroot.infra.ftgroup>
References: <157107290622.24688.13746109096420368827.idtracker@ietfa.amsl.com>
In-Reply-To: <157107290622.24688.13746109096420368827.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931EFD3A1OPEXCAUBM44corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xVjXweL9rZ7hNttKGEefVW-o9G4>
Subject: [tsvwg] TR: New Liaison Statement, "LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities"
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 10:58:27 -0000

Hi,

Below the text of a LS from  3GPP CT WG4 on QUIC network level troubleshooting capabilities.
TL,NR: the 3GPP CT WG 4 (CT4) is currently studying the introduction of QUIC as transport protocol instead of HTTP/2 in the 5G core network.
It has some questions regarding the troubleshooting capabilities supported by QUIC compared to the ones available with TCP.
It focuses on the lack of  support for on-path packet loss measurements.



Regards

Emile



-----Message d'origine-----
De : QUIC [mailto:quic-bounces@ietf.org] De la part de Liaison Statement Management Tool
Envoyé : lundi 14 octobre 2019 19:08
À : Lars Eggert; Mark Nottingham
Cc : Magnus Westerlund; 3GPPLiaison@etsi.org; georg.mayer.huawei@gmx.com; Mark Nottingham; Mirja Kühlewind; Lars Eggert; QUIC Discussion List
Objet : New Liaison Statement, "LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities"



Title: LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities

Submission Date: 2019-10-14

URL of the IETF Web page: https://datatracker.ietf.org/liaison/1655/

Please reply by 2020-02-14

From: Susanna Kooistra <3GPPLiaison@etsi.org>

To: Lars Eggert <lars@eggert.org>,Mark Nottingham <mnot@mnot.net>

Cc: Mirja Kühlewind <ietf@kuehlewind.net>,QUIC Discussion List <quic@ietf.org>,Lars Eggert <lars@eggert.org>,Magnus Westerlund <magnus.westerlund@ericsson.com>,Mark Nottingham <mnot@mnot.net>

Response Contacts: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org

Technical Contacts:

Purpose: For action



Body: 1. Overall Description:

3GPP CT WG4 is performing a feasibility study on the potential usage of QUIC protocol for the 3GPP 5G Core Network in 3GPP°TR°29.893 (last version available via the following link: https://www.3gpp.org/ftp/Specs/archive/29_series/29.893/29893-120.zip ). 3GPP CT WG4 is currently waiting for the release of the first official version of QUIC RFC in order to resume and conclude this study.



3GPP CT4 WG hence reviewed the IETF draft-ietf-quic-transport-19 and would like to provide the following feedback on network level troubleshooting capabilities of QUIC as compared to TCP (cf. clause°9.6.3 of 3GPP TR°29.893 for more details):



-           QUIC replaces both TLS and TCP. One of the main differences indeed is that QUIC encrypts the transport headers in addition to the payload, which is highly relevant for the network level troubleshooting matters. The existing Network OAM (Operation And Maintenance) solutions which are designed to make use and act on TCP headers would hence not be able to troubleshoot QUIC traffic and even less be easily adaptable to perform this task.

-           QUIC includes an optional measurement bit, named spinbit, which allows in-path probes to measure both the round trip delay and the decomposition of the delay on both sides of symmetrical path.

-           As of version 19, QUIC specifications do not support packet loss measurements.

-           To enable an in depth analysis of the performance (e.g. flow control, etc.) between a consumer 3GPP 5G core Network Function (NF) and a producer NF, the decryption of the entire QUIC message is often required in order to read the transport parameters of the QUIC packet header. Contrary to HTTP/2 over TLS, this has the side effect of decrypting and revealing application layer information to network probes.



2. Actions:

To IETF QUIC group

ACTION:           3GPP CT WG4 kindly asks IETF QUIC WG to take the above feedback into consideration in QUIC version 1 specification and provide a feedback (especially on the highlighted points).



3. Date of Next CT4 Meetings:

3GPP TSG CT4#95       11th – 15th November 2019       Reno, US

3GPP TSG CT4#96       24th – 28th February 2020         Sophia Antipolis, FR

Attachments:



    Liaison Statement on QUIC network level troubleshooting capabilities

    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2019-10-14-3gpp-tsgct-ct4-quic-ls-on-3gpp-ct-wg4-feedback-on-quic-network-level-troubleshooting-capabilities-attachment-1.docx



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.