New Liaison Statement, "Response to questions about QUIC network level troubleshooting capabilities"

Liaison Statement Management Tool <statements@ietf.org> Wed, 06 November 2019 09:53 UTC

Return-Path: <statements@ietf.org>
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07156120810; Wed, 6 Nov 2019 01:53:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool <statements@ietf.org>
To: <georg.mayer.huawei@gmx.com>, <3GPPLiaison@etsi.org>
Cc: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>, Mark Nottingham <mnot@mnot.net>, QUIC Discussion List <quic@ietf.org>, Lars Eggert <lars@eggert.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: New Liaison Statement, "Response to questions about QUIC network level troubleshooting capabilities"
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157303403695.27429.14590132790034125800.idtracker@ietfa.amsl.com>
Date: Wed, 06 Nov 2019 01:53:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_L4FrhBwN8Snuo0xRK-5LCj84WI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 09:53:57 -0000

Title: Response to questions about QUIC network level troubleshooting capabilities
Submission Date: 2019-11-05
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1661/

From: Mark Nottingham <mnot@mnot.net>;
To: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org
Cc: Mark Nottingham <mnot@mnot.net>,QUIC Discussion List <quic@ietf.org>,Mirja K├╝hlewind <ietf@kuehlewind.net>,Lars Eggert <lars@eggert.org>,Magnus Westerlund <magnus.westerlund@ericsson.com>,Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>;
Response Contacts: Lars Eggert <lars@eggert.org>,Mark Nottingham <mnot@mnot.net>;
Technical Contacts: 
Purpose: In response

Referenced liaison: LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities (https://datatracker.ietf.org/liaison/1655/)

Body: Thank you for your input to our specifications.

Regarding the encryption of headers in addition to payload, this was a conscious design decision by the Working Group. Transport header encryption prevents modification by middleboxes, thereby avoiding ossification of the protocol, and also makes traffic analysis more difficult. The impact upon network operators was discussed extensively as part of that decision.

Regarding the spin bit, we believe that your characterisation is correct.

Regarding packet loss measurements, QUIC does support them, but only by the endpoints of communication -- not by third parties observing it. Keys may be exported by one of the endpoints to allow decoding of packet traces (e.g., with Wireshark), but that is not part of the QUIC standard.

Regarding performance analysis, it would be helpful if you described your use case in more detail. However, it's important to know that the Working Group decided early on that QUICv1 would focus on the use case of HTTP/3.

In turn, HTTP standardisation focuses primarily on the Web browsing use case; while we acknowledge that there are other uses of the protocol, and we accommodate them where possible, we cannot change the protocol in ways that harms that use. Exposing transport metadata would likely do so.

Kind regards,

Mark Nottingham and Lars Eggert, QUIC Working Group chairs
Attachments:

No document has been attached