RE: LS from 3GPP on QUIC network level troubleshooting capabilities

"Lubashev, Igor" <ilubashe@akamai.com> Sun, 27 October 2019 22:14 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86791200DF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 27 Oct 2019 15:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MAILING_LIST_MULTI=-1, 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 rRcWYp5YfUGX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 27 Oct 2019 15:14:13 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 25AE91200BA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 27 Oct 2019 15:14:13 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iOqm0-0003K3-CL for ietf-http-wg-dist@listhub.w3.org; Sun, 27 Oct 2019 22:12:32 +0000
Resent-Message-Id: <E1iOqm0-0003K3-CL@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1iOqly-0003I7-Go for ietf-http-wg@listhub.w3.org; Sun, 27 Oct 2019 22:12:30 +0000
Received: from raoul.w3.org ([128.30.52.128]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ylafon@w3.org>) id 1iOqlw-0003sc-RX for ietf-http-wg@w3.org; Sun, 27 Oct 2019 22:12:30 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.129]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1iOqlw-0002qM-CV for ietf-http-wg@w3.org; Sun, 27 Oct 2019 22:12:28 +0000
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_673283C4-63E5-42FA-8C31-1E2324CFFC19"
From: "Lubashev, Igor" <ilubashe@akamai.com>
In-Reply-To: <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Mon, 14 Oct 2019 12:09:14 +0000
Cc: "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "allison.mankin@gmail.com" <allison.mankin@gmail.com>, "quic-chairs@ietf.org" <quic-chairs@ietf.org>, "wes@mti-systems.com" <wes@mti-systems.com>, "Gorry (erg)" <gorry@erg.abdn.ac.uk>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "Black, David" <David.Black@dell.com>, "httpbis-ads@ietf.org" <httpbis-ads@ietf.org>, "quic-ads@ietf.org" <quic-ads@ietf.org>
Resent-Date: Sun, 27 Oct 2019 23:12:27 +0100
Message-Id: <f083b00a0b374ab28c0db505ea61eaee@ustx2ex-dag1mb6.msg.corp.akamai.com>
Resent-To: HTTP Working Group <ietf-http-wg@w3.org>
References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
To: Christian Huitema <huitema@huitema.net>, "lionel.morand@orange.com" <lionel.morand@orange.com>, "quic@ietf.org" <quic@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-W3C-Hub-Spam-Status: No, score=-0.6
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1iOqlw-0003sc-RX 9604b1b3d64d4b80536192dd6054f8e6
X-Original-To: ietf-http-wg@w3.org
Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilities
Archived-At: <https://www.w3.org/mid/f083b00a0b374ab28c0db505ea61eaee@ustx2ex-dag1mb6.msg.corp.akamai.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37075
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Christian, do you believe that the outcome of the tsvwg discussion and the contents of draft-ietf-Ztsvwg-transport-encrypt will be timely enough to affect QUIC v1?  If not, a discussion in QUIC WG would have a better chance of being timely for QUIC v1.
 
3GPP consists of Internet players who are mostly absent from QUIC WG, and their concerns should be taken seriously, since their networks carry a large portion of QUIC traffic.  It would require everyone’s efforts to ensure that QUIC can grow from a single-digit percentage to the majority of Internet traffic with QUIC v1.
 
Igor
 
From: Christian Huitema <huitema@huitema.net <mailto:huitema@huitema.net>> 
Sent: Saturday, October 12, 2019 11:41 PM
This topic, troubleshooting capabilities supported by QUIC compared to the ones available with TCP, is currently being debated in the transport area working group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Dtransport-2Dencrypt_&d=DwMD-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=Lnp-EOYUknzse809dTMZYzMs55FSJEDbEYvz9ZPWGuo&s=DRWGiEADVTxFXLm2BWHCFSJQKLTHtSdQ4d2frGEGouI&e=>) is a general discussion of "The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet".

It might be a good idea for the IETF to have that discussion at just one place.

-- Christian huitema

On 10/12/2019 1:24 AM, lionel.morand@orange.com <mailto:lionel.morand@orange.com> wrote:
Hi,
 
Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4).
This WG is actually studying the introduction of QUIC as transport protocol instead of HTTP/2 in the 5G core network.
The WG has some questions regarding the troubleshooting capabilities supported by QUIC compared to the ones available with TCP.
 
The LS is officially addressed to the QUIC WG. However, it was highlighted that httpbis WG could also be interested in. I will let you decide if only QUIC or both are relevant in the discussion.
 
Next CT4 WG meetings:
3GPP TSG CT4#95           11th – 15th November 2019       Reno, US
3GPP TSG CT4#96           24th – 28th February 2020          Sophia Antipolis, FR
 
It would be good to receive an official feedback at the latest for the February meeting, where the study will be concluded (at least for this release).
 
Regards,
 

Lionel Morand 
Chair of 3GPP TSG CT
3GPP Liaison Person to IETF
Chair of IETF Dime and Radext WGs 
Core Network Senior Architect and Diameter expert 
Cell. +33 6 07 75 89 36  <https://urldefense.proofpoint.com/v2/url?u=https-3A__monsi.sso.francetelecom.fr_index.asp-3Ftarget-3Dhttp-253A-252F-252Fclicvoice.sso.francetelecom.fr-252FClicvoiceV2-252FToolBar.do-253Faction-253Ddefault-2526rootService-253DSIGNATURE-2526to-253D0607758936&d=DwMD-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=Lnp-EOYUknzse809dTMZYzMs55FSJEDbEYvz9ZPWGuo&s=F2f6eijakCDMZfPDciLaCuzHubXGQ1onCA7xdxhrcMs&e=>
lionel.morand@orange.com <mailto:lionel.morand@orange.com>