< draft-stephan-quic-interdomain-troubleshooting-02.txt   draft-stephan-quic-interdomain-troubleshooting-03.txt >
QUIC WG E. Stephan QUIC WG E. Stephan
Internet Draft M. Cayla Internet Draft M. Cayla
Intended status: Informational A. Braud Intended status: Informational A. Braud
Expires: November 2019 F. Fieau Expires: January 2020 F. Fieau
A. Ferrieux A. Ferrieux
Orange Orange
M. Ihlar M. Ihlar
Ericsson Ericsson
May 20, 2019 July 8, 2019
QUIC Interdomain Troubleshooting QUIC Interdomain Troubleshooting
draft-stephan-quic-interdomain-troubleshooting-02.txt draft-stephan-quic-interdomain-troubleshooting-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 21,20, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
expensive to deploy and to maintain. This draft motivates the expensive to deploy and to maintain. This draft motivates the
exposure of QUIC header fields for on-path network measurements and exposure of QUIC header fields for on-path network measurements and
their specification in the QUIC core protocol as a solution to avoid their specification in the QUIC core protocol as a solution to avoid
on-path network performance measurements to ossify the IP stack in on-path network performance measurements to ossify the IP stack in
the future. the future.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
2. Conventions used in this document............................ 3 2. Conventions used in this document............................ 3
3. Interdomain UX troubleshooting............................... 3 3. Interdomain UX troubleshooting .............................. 3
4. Reference of Network Performance............................. 4 4. Reference of Network Performance ............................ 4
5. Explicit measurement signals................................. 5 5. Explicit measurement signals ................................ 5
5.1. Spinbit, measuring the delay............................... 5
5.2. Squarebit, measuring packet losses ........................ 6
6. QUIC Fallback ............................................... 6 6. QUIC Fallback ............................................... 6
6.1. Flapping .................................................. 6 6.1. Flapping .................................................. 6
7. Versioning and Implementations............................... 7 7. Versioning and Implementations............................... 7
8. Security Considerations...................................... 7 8. Tools ....................................................... 7
9. IANA Considerations ......................................... 7 8.1. Spindump .................................................. 7
10. Discussions ................................................ 8 9. Security Considerations...................................... 8
10.1. Fallback ................................................. 8 10. IANA Considerations......................................... 8
10.2. On-path Measurement....................................... 8 11. Discussions ................................................ 8
11. References ................................................. 9 11.1. Fallback ................................................. 8
11.1. Normative References...................................... 9 11.2. On-path Measurement....................................... 9
11.2. Informative References.................................... 9 12. References ................................................. 9
12. Acknowledgments ............................................ 9 12.1. Normative References...................................... 9
12.2. Informative References................................... 10
13. Acknowledgments ........................................... 10
1. Introduction 1. Introduction
The IP layer does not include the material for measuring the delay The IP layer does not include the material for measuring the delay
and packet losses of segments of a path. The network performance is and packet losses of segments of a path. The network performance is
currently measured by points of presence of the path [SPATIAL], currently measured by points of presence of the path [SPATIAL],
[COMPO] using transport fields of the upper layers: TCP transport [COMPO] using transport fields of the upper layers: TCP transport
layer, RTP application layer... layer, RTP application layer...
The evolution of the Internet stack toward end-to-end integrity The evolution of the Internet stack toward end-to-end integrity
skipping to change at page 5, line 33 skipping to change at page 5, line 35
Additionally, charging may require the differentiation of the Additionally, charging may require the differentiation of the
goodput from the throughput. goodput from the throughput.
Continuous network performance monitoring requires packet losses and Continuous network performance monitoring requires packet losses and
delay measurements to allow operators to manage properly their delay measurements to allow operators to manage properly their
networks and to provides them with a reference of performance of networks and to provides them with a reference of performance of
their network for interdomain troubleshooting. their network for interdomain troubleshooting.
5. Explicit measurement signals 5. Explicit measurement signals
5.1. Spinbit, measuring the delay
An alternative to exposing raw transport protocol data to the path An alternative to exposing raw transport protocol data to the path
is to have explicitly designed signals with the purpose of is to have explicitly designed signals with the purpose of
facilitating on-path measurements. To facilitate troubleshooting, facilitating on-path measurements. To facilitate troubleshooting,
such a signal should enable passive measurement of RTT, packet-loss such a signal should enable passive measurement of RTT, packet-loss
and other congestion indicators such as ECN. An example of how a and other congestion indicators such as ECN. An example of how a
transport protocol could expose measurement information to the path transport protocol could expose measurement information to the path
would be three flag bits available in a public header. The first bit would be three flag bits available in a public header. The first bit
would be used for passive RTT measurement, bit 2 would indicate would be used for passive RTT measurement, bit 2 would indicate
whether the packet contains retransmitted data and bit 3 would whether the packet contains retransmitted data and bit 3 would
indicate whether the packet contains an ECN echo. An explicit signal indicate whether the packet contains an ECN echo. An explicit signal
is unambiguous and simpler for a middlebox to interpret, than parsed is unambiguous and simpler for a middlebox to interpret, than parsed
transport headers. Furthermore, it could be invariant between transport headers. Furthermore, it could be invariant between
revisions of the transport protocol that exposes it, which minimizes revisions of the transport protocol that exposes it, which minimizes
the risk of network ossification. the risk of network ossification.
At this step the WG specified a signal to measure the round trip At this step the WG specified a signal to measure the round trip
delay delay [SPINBIT]. delay delay [SPINBIT].
QUIC packets numbering) are available in QUIC but encrypted an 5.2. Squarebit, measuring packet losses
additional signal like described in [SQUAREBIT] is needed to measure
and locate packet losses. QUIC packets numbering is available in QUIC but encrypted. By
consequence an additional signal like described in [SQUAREBIT] is
needed to measure packet losses on the path.
[TODO: add other proposals]
6. QUIC Fallback 6. QUIC Fallback
Fallback is necessary to address cases where a QUIC connection Fallback is necessary to address cases where a QUIC connection
establishment fails [QUICAPP] (A device of the path blocks UDP, the establishment fails [QUICAPP] (A device of the path blocks UDP, the
stack blocks 0-RTT...). stack blocks 0-RTT...).
Fallback may occur additionally when an active QUIC connection drops Fallback may occur additionally when an active QUIC connection drops
and tries to reconnect. As an example, the steps of the fallback and tries to reconnect. As an example, the steps of the fallback
could be: could be:
skipping to change at page 7, line 24 skipping to change at page 7, line 35
performance measurement must not depend on the version. performance measurement must not depend on the version.
There might be numerous implementations of the QUIC protocol in the There might be numerous implementations of the QUIC protocol in the
future. An important part of them will implement the congestion future. An important part of them will implement the congestion
control at application level. There will be unfair behaviors like control at application level. There will be unfair behaviors like
abnormal retransmission rate which will impact the fairness of the abnormal retransmission rate which will impact the fairness of the
repartition of the bandwidth amongst the customers of the network. repartition of the bandwidth amongst the customers of the network.
By consequence the network needs to be able to detect connections By consequence the network needs to be able to detect connections
which have abnormal throughput/goodput. which have abnormal throughput/goodput.
8. Security Considerations 8. Tools
8.1. Spindump
The "Spindump" tool [SPINDUMP] is a Unix command-line utility that can
be used for latency monitoring in traffic passing through an interface.
The tool performs passive, in-network monitoring. It is not a tool to
monitor traffic content or metadata of individual connections, and
indeed that is not possible in the Internet as most connections are
encrypted.
The tool looks at the characteristics of transport protocols, such as
the QUIC Spinbit, and attempts to derive information about round-trip
times for individual connections or for the aggregate or average
values. The tool supports TCP, QUIC, COAP, DNS, and ICMP traffic.
There's also an easy way to anonymize connection information so that
the resulting statistics cannot be used to infer anything about
specific connections or users.
Spindump can both generate and read JSON formatted measurement events.
Measurements from several collection points can be aggregated at a
central point. Having multiple Spindump instances along a path allows
for further segmentation of measurements than having a single
measurement point, which is useful for both inter- and intra-domain
troubleshooting.
The Spindump command-line utility is based on the Spindump library
which can be integrated with other measurement or troubleshooting
software.
9. Security Considerations
The integrity of the parameters exposed for measuring on-path delay The integrity of the parameters exposed for measuring on-path delay
and losses can be end-to-end protected to increase the security of and losses can be end-to-end protected to increase the security of
the connection. the connection.
Flapping from QUIC to a fallback protocol might overload on-path Flapping from QUIC to a fallback protocol might overload on-path
devices and end-points and by consequence affect the stability of devices and end-points and by consequence affect the stability of
the connections and introduces weaknesses. the connections and introduces weaknesses.
The fallback from encrypted headers to clear headers transport The fallback from encrypted headers to clear headers transport
protocols might open the door to new types of active attacks. protocols might open the door to new types of active attacks.
It is not clear yet whether a network can distinguish numerous QUIC It is not clear yet whether a network can distinguish numerous QUIC
fallback flappings from an active attack: fallback flappings from an active attack:
o What is the expected behavior from the network? o What is the expected behavior from the network?
o Will networks detect QUIC flapping as an active attack? o Will networks detect QUIC flapping as an active attack?
9. IANA Considerations 10. IANA Considerations
This draft does not request any IANA actions. This draft does not request any IANA actions.
10. Discussions 11. Discussions
10.1. Fallback 11.1. Fallback
Troubleshooting QUIC traffic and its fallbacks requires measuring Troubleshooting QUIC traffic and its fallbacks requires measuring
similar metrics. One suggestion is to use the integrity mechanism of similar metrics. One suggestion is to use the integrity mechanism of
the TCPinc WG [TCPINC] to protect and keep visible the fields used the TCPinc WG [TCPINC] to protect and keep visible the fields used
for on-path measurement. for on-path measurement.
Fallback must be precisely specified in the core specification of Fallback must be precisely specified in the core specification of
QUIC [QUICCORE]. QUIC [QUICCORE].
To avoid unnecessary flapping [QUICCORE] might clarify the usage of To avoid unnecessary flapping [QUICCORE] might clarify the usage of
the advertisement of QUIC support in HTTP protocols [ALTSVC]. the advertisement of QUIC support in HTTP protocols [ALTSVC].
[QUICMAN] should propose guidance for the management of QUIC [QUICMAN] should propose guidance for the management of QUIC
fallback in a way to avoid flapping situations. fallback in a way to avoid flapping situations.
10.2. On-path Measurement 11.2. On-path Measurement
QUIC is designed to carry other traffic than HTTP such as DNS and QUIC is designed to carry other traffic than HTTP such as DNS and
Web. End-to-end encryption of the transport headers prevents the use Web. End-to-end encryption of the transport headers prevents the use
of models [E-MODEL] and heuristics to estimate UX on a path segment. of models [E-MODEL] and heuristics to estimate UX on a path segment.
To maintain a high level of UX, QUIC capabilities should support the To maintain a high level of UX, QUIC capabilities should support the
measurement of the delay and the losses of a segment of a source to measurement of the delay and the losses of a segment of a source to
destination path. destination path.
On-path measurement techniques are currently ad hoc. Adding the On-path measurement techniques are currently ad hoc. Adding the
exposure of the fields for on-path packet delay and losses in the exposure of the fields for on-path packet delay and losses in the
core specification of the QUIC protocol creates a stable network core specification of the QUIC protocol creates a stable network
performance measurement framework. It will be a real incentive for performance measurement framework. It will be a real incentive for
networks to support QUIC rapidly and to support the numerous QUIC networks to support QUIC rapidly and to support the numerous QUIC
versions in the future. This will reduce network impacts on the versions in the future. This will reduce network impacts on the
ossification of the IP stack in the future. ossification of the IP stack in the future.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[QUICCORE] https://tools.ietf.org/html/draft-ietf-quic-transport [QUICCORE] https://tools.ietf.org/html/draft-ietf-quic-transport
[FALLBACK] https://github.com/quicwg/base-drafts/issues/166 [FALLBACK] https://github.com/quicwg/base-drafts/issues/166
[IABSEC] https://www.iab.org/2014/11/14/iab-statement-on-internet- [IABSEC] https://www.iab.org/2014/11/14/iab-statement-on-internet-
confidentiality/ confidentiality/
[SPINBIT] https://tools.ietf.org/html/draft-ietf-quic-transport- [SPINBIT] https://tools.ietf.org/html/draft-ietf-quic-transport-
20#section-17.3.1 20#section-17.3.1
[SQUAREBIT] https://tools.ietf.org/html/draft-ferrieux-hamchaoui- [SQUAREBIT] https://tools.ietf.org/html/draft-ferrieux-hamchaoui-
quic-lossbits-00 quic-lossbits-00
11.2. Informative References 12.2. Informative References
[E-MODEL] https://www.itu.int/rec/T-REC-G.107-199812-S/en [E-MODEL] https://www.itu.int/rec/T-REC-G.107-199812-S/en
[SPATIAL] https://tools.ietf.org/html/rfc5644 [SPATIAL] https://tools.ietf.org/html/rfc5644
[COMPO] https://tools.ietf.org/html/rfc6049 [COMPO] https://tools.ietf.org/html/rfc6049
[QUICAPP] https://tools.ietf.org/wg/quic/draft-ietf-quic- [QUICAPP] https://tools.ietf.org/wg/quic/draft-ietf-quic-
applicability/ applicability/
[QUICMAN] https://tools.ietf.org/wg/quic/draft-ietf-quic- [QUICMAN] https://tools.ietf.org/wg/quic/draft-ietf-quic-
manageability/ manageability/
[TCPINC] https://tools.ietf.org/wg/tcpinc/ [TCPINC] https://tools.ietf.org/wg/tcpinc/
[ALTSVC] https://tools.ietf.org/html/rfc7838 [ALTSVC] https://tools.ietf.org/html/rfc7838
12. Acknowledgments [SPINDUMP] https://github.com/EricssonResearch/spindump
13. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Emile Stephan Emile Stephan
Orange Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22300 Lannion 22300
France France
 End of changes. 17 change blocks. 
28 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/