Internet DRAFT - draft-kazuho-quic-perf-metrics
draft-kazuho-quic-perf-metrics
Network Working Group K. Oku
Internet-Draft Fastly
Intended status: Standards Track February 12, 2018
Expires: August 16, 2018
Performance Metrics Subprotocol for QUIC
draft-kazuho-quic-perf-metrics-00
Abstract
This memo proposes a subprotocol that can be used to query the
performance metrics of a QUIC path.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Oku Expires August 16, 2018 [Page 1]
Internet-Draft quic-perf-metrics February 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. METRICS Packet . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. REQUEST Subtype . . . . . . . . . . . . . . . . . . . . . 5
3.2. RESPONSE Subtype . . . . . . . . . . . . . . . . . . . . 6
3.3. DENY Subtype . . . . . . . . . . . . . . . . . . . . . . 7
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Server State . . . . . . . . . . . . . . . . . . . . . . 8
5. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Observation of upstream loss, reorder, and round-trip time is crucial
to diagnosing issues on the network. With TCP, it is possible for an
on-path device to make estimation of such metrics by observing the
sequence number and the ACK packets being sent in clear. But with
QUIC, packet number is never used twice and ACK is encrypted, hence
such on-path observation has become difficult. There is also an
ongoing discussion about encrypting the packet numbers to avoid
ossification and also to miminize privacy concern. Such change will
make observation even more challenging.
There have been proposals to include signals in each QUIC packet that
conveys enough information for diagnosis but does not cause
ossification nor privary issues. However, it is difficult if not
impossible to figure out an approach that will work well for the
lifetime of a transport protocol.
This memo proposes an alternative solution. In the proposal, an on-
path device willing to obtain the performance metrics of a QUIC path
sends a query to the server, and the server responds with the
necessary information to calculate such metrics.
There are three primary benefits in the approach:
o Observation becomes an active action rather than passive, giving
the endpoints a chance to record observation attempts as well as
rejecting undesirable ones.
o Observation becomes accurate due to the endpoints' knowledge of
what is being exchanged encypted.
o Flexibility against issues (both performance- and privacy-related)
that might arise in the future, since bits for observation no
Oku Expires August 16, 2018 [Page 2]
Internet-Draft quic-perf-metrics February 2018
longer exists hard-coded in each packet. The metrics protocol can
evolve indenpendently to the QUIC transport protocol.
2. Overview
An on-path device that is willing to query the performance metrics of
a QUIC path sends a METRICS packet of subtype REQUEST to the server-
side endpoint of the path.
When receiving the request packet, A QUIC server sends a response to
the client (not to the observer). The response can be either a
METRICS packet of subtype RESPONSE that contains the performance
metrics, or a METRICS packet of subtype DENY that indicates the
servers unwillingness to provide such information. An on-path device
that sent the request will witness the METRICS packet containing the
response and extract the necessary values.
3. METRICS Packet
A METRICS packet is used by a QUIC server and the on-path devices to
communicate the performance metrics of a QUIC path.
Oku Expires August 16, 2018 [Page 3]
Internet-Draft quic-perf-metrics February 2018
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|0|C|K| Type(5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ [Connection ID (64)] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Preamble (160) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Request UUID (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: METRICS packet format
The packet mimics a QUIC packet using the short packet header. But
instead of the encrypted packet number and the payload, Preamble
field directly follows the Connection ID field.
A Preamble field consisting of twenty (20) octets of zero indicates a
METRICS packet.
Subtype field is used to identify the role of the METRICS packet.
This document defines three subtypes: REQUEST, RESPONSE, REJECT.
Request UUID field contains an identifier that is used for
correlating a performance metrics request and the response.
Oku Expires August 16, 2018 [Page 4]
Internet-Draft quic-perf-metrics February 2018
Omit Connection ID flag indicates if the Connection ID field is
omitted.
Key Phase Bit and Type field is not used and SHOULD be set to the
same value as those found in the ordinary QUIC packets being
exchanged on the same path during the same time.
3.1. REQUEST Subtype
A METRICS packet of subtype REQUEST (0x0) is sent from an on-path
observer to the QUIC server to query the performance metrics of a
QUIC path that conveyed the packets it has observed.
The sender of the packet MUST fill the Request UUID field with a
sequence of random octets so that the request and the packets sent in
response can be correlated.
Figure 2 shows the payload format of the REQUEST subtype.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client IP Address (32/128) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Fingerprints (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: REQUEST subtype payload format
Client IP Address field and Client Port field contain the client-side
tuple of a QUIC path.
Packet Fingerprints field contains a list of the packets for which
the on-path device wants to obtain the metrics. Each element of the
list is thirty-six (36) octets long, containing the first thirty-six
(36) octets of the observed packets immediately following the
Connection ID field (or the Type field if Connection ID is omitted).
The list MUST contain two or more entries.
The length of each element (thirty-six (36) octets) has been chosen
so that an endpoint in posession of the key used for encrypting the
packet number can decrypt the packet number from the fingerprint,
when a symmetric cipher that requires an initialization vector
shorter than 33 octets is being used.
Oku Expires August 16, 2018 [Page 5]
Internet-Draft quic-perf-metrics February 2018
3.2. RESPONSE Subtype
A METRICS packet of subtype RESPONSE (0x1) is sent by a QUIC server
to indicate the performance metrics of the QUIC path related to the
packets that have been specified by the METRICS packet of subtype
REQUEST.
The packet MUST echo the value of the Request UUID found in the
METRICS packet of subtype REQUEST so that the on-path observer that
sent the request can determine the response.
Figure 3 shows the payload format of the METRICS subtype.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets Sent (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets Lost (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRTT (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTTVAR (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distances (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: METRICS subtype payload format
Number of Packets Sent field contains the cumulative number of
packets being sent on the path. Number of Packets Lost field
contains the cumulative number of packets sent on the path but were
deemed to be lost. The values are encoded using Variable-Length
Integer Encoding defined in [QUIC-TRANSPORT].
SRTT field and RTTVAR field indicates the smoothed round-trip time
and the RTT variant, in the unit of microseconds, encoded as 32-bit
unsigned integers.
Distances field contains a sequence of integers representing the
distances between the packets specified by the request.
The field contains one less elements than the corresonponding Packet
Fingerprint field. Nth element of the Distances field corresponds to
the distance between the Nth element and the N+1th element of the
Packet Fingerprint field.
Distance between two packets (A and B) is defined as following:
Oku Expires August 16, 2018 [Page 6]
Internet-Draft quic-perf-metrics February 2018
o the integral part represents number of packets being sent between
the two, incremented by one
o the sign part is "+" if A was sent before B, else "-"
As an example, if packet B was sent right after A, the distance
between A and B is one "1". If packet B was sent two packets after
A, the distance is "2". If packet B was sent right before A, the
distance is "-1".
Each distance is converted to unsigned values using the following
formula, then encoded into variable length using Variable-Length
Integer Encoding defined in [QUIC-TRANSPORT].
uint_distance = abs(distance * 2) + (distance < 0 ? 1 : 0)
By observing the packet, the on-path device that sent the request can
determine the losses or reorders between the packets it specified in
the request.
3.3. DENY Subtype
A METRICS packet of subtype DENY (0x2) is sent by a QUIC server to
inidicate its unwillingness to provide performance metrics.
There is no payload for the subtype.
4. Server Behavior
A QUIC server MUST ignore a METRICS packet of subtype REQUEST if any
of the following requirements is not being met.
o the destination IP address and port number match the server-side
tuple of the QUIC path
o values of Client IP Address field and Client Port field match the
client-side tuple of the QUIC path
o (unless omitted and permitted to be omitted during QUIC handshake)
value of the Connection ID field matches that of the QUIC path
o Packet Fingerprint field contains two or more entries
o all the packet numbers being recovered from the entries of Packet
Fingerprint field belong to the QUIC path
Oku Expires August 16, 2018 [Page 7]
Internet-Draft quic-perf-metrics February 2018
Once all the checks succeed, the server can send a METRICS packet of
subtype RESPONSE, or notify the rejection the request by sending a
packet of subtype DENY.
4.1. Server State
A QUIC server willing to let the on-path devices observe upstream
loss and / or reorder ratio needs to calculate the distances of the
packets being specified in the request.
A server can easily calculate the distances if it records the packet
numbers of all the packets it has sent over a given path.
On the other hand, a server can calculate the distances by retaining
very little state if it is implemented following the criteria shown
below.
o record the packet number of the first packet sent after switching
to the current path
o use a deterministic function (such as a keyed hash function) to
determine when to skip a packet number as a mitigitation against
opportunistic ACK attacks
o record the packet numbers of packets that were exchanged on a
prepared path (i.e. packet numbers of PATH_CHALLENGE and
PATH_RESPONSE)
The distance can be calculated as a subtraction of two packet
numbers, further subtracted by the number of skips and the number of
packets used for preparing new paths.
5. Normative References
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic-
transport-latest (work in progress).
Author's Address
Kazuho Oku
Fastly
Email: kazuhooku@gmail.com
Oku Expires August 16, 2018 [Page 8]