Liaison statement
Response to questions about QUIC network level troubleshooting capabilities

State Posted
Submitted Date 2019-11-05
From Group quic
From Contact Mark Nottingham
To Group 3GPP
To Contacts georg.mayer.huawei@gmx.com
3GPPLiaison@etsi.org
CcMark Nottingham
QUIC Discussion List
Mirja K├╝hlewind
Lars Eggert
Magnus Westerlund
Gonzalo Camarillo
Response Contact Lars Eggert
Mark Nottingham
Purpose In response
Attachments (None)
Liaisons referred by this one LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities
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