Packet Loss Signaling for Encrypted Protocols
draft-ferrieuxhamchaoui-tsvwg-lossbits-02
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2019-11-04
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
htmlized
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
TSVWG A. Ferrieux
Internet-Draft I. Hamchaoui
Intended status: Informational Orange Labs
Expires: May 6, 2020 I. Lubashev
Akamai Technologies
November 3, 2019
Packet Loss Signaling for Encrypted Protocols
draft-ferrieuxhamchaoui-tsvwg-lossbits-02
Abstract
This document describes a protocol-independent method that employs
two bits to allow endpoints to signal packet loss in a way that can
be used by network devices to measure and locate the source of the
loss. The signaling method applies to all protocols with a protocol-
specific way to identify packet loss. The method is especially
valuable when applied to protocols that encrypt transport header and
do not allow an alternative method for loss detection.
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 https://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 May 6, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://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
Ferrieux, et al. Expires May 6, 2020 [Page 1]
Internet-Draft loss-bits November 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Loss Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Setting the sQuare Bit on Outgoing Packets . . . . . . . 4
3.1.1. Q Period Selection . . . . . . . . . . . . . . . . . 4
3.2. Setting the Loss Event Bit on Outgoing Packets . . . . . 4
4. Using the Loss Bits for Passive Loss Measurement . . . . . . 5
4.1. End-To-End Loss . . . . . . . . . . . . . . . . . . . . . 5
4.2. Upstream Loss . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Correlating End-to-End and Upstream Loss . . . . . . . . 6
4.4. Downstream Loss . . . . . . . . . . . . . . . . . . . . . 7
4.5. Observer Loss . . . . . . . . . . . . . . . . . . . . . . 7
5. ECN-Echo Event Bit . . . . . . . . . . . . . . . . . . . . . 7
5.1. Setting the ECN-Echo Event Bit on Outgoing Packets . . . 8
5.2. Using E Bit for Passive ECN-Reported Congestion
Measurement . . . . . . . . . . . . . . . . . . . . . . . 8
6. Protocol Ossification Considerations . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Since version 01 . . . . . . . . . . . . . . . . . . . . 9
10.2. Since version 00 . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Packet loss is a pervasive problem of day-to-day network operation,
and proactively detecting, measuring, and locating it is crucial to
maintaining high QoS and timely resolution of crippling end-to-end
throughput issues. To this effect, in a TCP-dominated world, network
operators have been heavily relying on information present in the
clear in TCP headers: sequence and acknowledgment numbers and SACKs
when enabled (see [RFC8517]). These allow for quantitative
estimation of packet loss by passive on-path observation, and the
lossy segment (upstream or downstream from the observation point) can
be quickly identified by moving the passive observer around.
Ferrieux, et al. Expires May 6, 2020 [Page 2]
Internet-Draft loss-bits November 2019
With encrypted protocols, the equivalent transport headers are
encrypted and passive packet loss observation is not possible, as
described in [TRANSPORT-ENCRYPT].
Since encrypted protocols could be routed by the network differently,
and the fraction of Internet traffic delivered using encrypted
protocols is increasing every year, it is imperative to measure
packet loss experienced by encrypted protocol users directly instead
of relying on measuring TCP loss between similar endpoints.
Following the recommendation in [RFC8558] of making path signals
explicit, this document proposes adding two explicit loss bits to the
clear portion of the protocol headers to restore network operators'
ability to maintain high QoS for users of encrypted protocols. These
bits can be added to an unencrypted portion of a header belonging to
any protocol layer, e.g. IP (see [IP]) and IPv6 (see [IPv6]) headers
or extensions, UDP surplus space (see [UDP-OPTIONS] and
[UDP-SURPLUS]), reserved bits in a QUIC v1 header (see
[QUIC-TRANSPORT]).
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Loss Bits
The proposal introduces two bits that are to be present in every
packet capable of loss reporting. These are packets that include
protocol headers with the loss bits. Only loss of packets capable of
loss reporting is reported using loss bits.
Whenever this specification refers to packets, it is referring only
to packets capable of loss reporting.
- Q: The "sQuare signal" bit is toggled every N outgoing packets as
explained below in Section 3.1.
- L: The "Loss event" bit is set to 0 or 1 according to the
Unreported Loss counter, as explained below in Section 3.2.
Each endpoint maintains appropriate counters independently and
separately for each connection (each subflow for multipath
connections).
Ferrieux, et al. Expires May 6, 2020 [Page 3]
Internet-Draft loss-bits November 2019
3.1. Setting the sQuare Bit on Outgoing Packets
The sQuare Value is initialized to the Initial Q Value (0 or 1) and
is reflected in the Q bit of every outgoing packet. The sQuare value
is inverted after sending every N packets (Q Period is 2*N). The Q
bit represents "packet color" as defined by [RFC8321].
The choice of the Initial Q Value and Q Period is determined by the
protocol containing Q and L bits. For example, the values can be
protocol constants (e.g. "Initial Q Value" is 0, and "Q Period" is
128), or they can be set explicitly for each connection (e.g.
"Initial Q Value" is whatever value the initial packet has, and "Q
Period" is set per a dedicated TCP option on SYN and SYN/ACK), or
they can be included with every packet (e.g. ConEx IPv6 Destination
Option of [ConEx-IPv6]).
Observation points can estimate the upstream losses by counting the
number of packets during a half period of the square signal, as
described in Section 4.
3.1.1. Q Period Selection
A protocol containing Q and L bits can allow the sender to choose Q
Period based on the expected amount of loss and reordering on the
path (see Section 4.2). If the explicit value of the Q Period is not
explicitly signaled by the protocol, the Q Period value MUST be at
least 128 and be a power of 2. This requirement allows an Observer
to infer the Q Period by obsering one period of the square signal.
It also allows the Observer to identify flows that set the loss bits
to arbitrary values (see Section 6).
3.2. Setting the Loss Event Bit on Outgoing Packets
The Unreported Loss counter is initialized to 0, and L bit of every
outgoing packet indicates whether the Unreported Loss counter is
positive (L=1 if the counter is positive, and L=0 otherwise). The
value of the Unreported Loss counter is decremented every time a
packet with L=1 is sent.
The value of the Unreported Loss counter is incremented for every
packet that the protocol declares lost, using whatever loss detection
machinery the protocol employs. If the protocol is able to rescind
the loss determination later, the Unreported Loss counter SHOULD NOT
be decremented due to the rescission.
This loss signaling is similar to loss signaling in [ConEx], except
the Loss Event bit is reporting the exact number of lost packets,
Ferrieux, et al. Expires May 6, 2020 [Page 4]
Internet-Draft loss-bits November 2019
whereas Echo Loss bit in [ConEx] is reporting an approximate number
of lost bytes.
For protocols, such as TCP ([TCP]), that allow network devices to
change data segmentation, it is possible that only a part of the
packet is lost. In these cases, the sender MUST increment Unreported
Loss counter by the fraction of the packet data lost (so Unreported
Loss counter may become negative when a packet with L=1 is sent after
a partial packet has been lost).
Observation points can estimate the end-to-end loss, as determined by
the upstream endpoint's loss detection machinery, by counting packets
in this direction with a L bit equal to 1, as described in Section 4.
4. Using the Loss Bits for Passive Loss Measurement
There are three sources of observable loss:
- _upstream loss_ - loss between the sender and the observation
point (Section 4.2)
- _downstream loss_ - loss between the observation point and the
destination (Section 4.4)
- _observer loss_ - loss by the observer itself that does not cause
downstream loss (Section 4.5)
The upstream and downstream loss together constitute _end-to-end
loss_ (Section 4.1).
The Q and L bits allow detection and measurement of the types of loss
listed above.
4.1. End-To-End Loss
The Loss Event bit allows an observer to calculate the end-to-end
loss rate by counting packets with L bit value of 0 and 1 for a given
connection. The end-to-end loss rate is the fraction of packets with
L=1.
The simplifying assumption here is that upstream loss affects packets
with L=0 and L=1 equally. This may be a simplification, if some loss
is caused by tail-drop in a network device. If the sender congestion
controller reduces the packet send rate after loss, there may be a
sufficient delay before sending packets with L=1 that they have a
greater chance of arriving at the observer.
Ferrieux, et al. Expires May 6, 2020 [Page 5]
Internet-Draft loss-bits November 2019
4.2. Upstream Loss
Blocks of N (half of Q Period) consecutive packets are sent with the
same value of the Q bit, followed by another block of N packets with
inverted value of the Q bit. Hence, knowing the value of N, an on-
path observer can estimate the amount of upstream loss after
observing at least N packets. If "p" is the average number of
packets in a block of packets with the same Q value, then the
upstream loss is "1-p/N".
The observer needs to be able to tolerate packet reordering that can
blur the edges of the square signal.
The Q Period needs to be chosen carefully, since the observation
could become too unreliable in case of packet reordering and loss if
Q Period is too small. However, when Q Period is too large,
connections that send fewer than half Q Period packets do not yield a
useful upstream loss measurement.
The observer needs to differentiate packets as belonging to different
connections, since they use independent counters.
4.3. Correlating End-to-End and Upstream Loss
Upstream loss is calculated by observing the actual packets that did
not suffer the upstream loss. End-to-end loss, however, is
calculated by observing subsequent packets after the sender's
protocol detected the loss. Hence, end-to-end loss is generally
observed with a delay of between 1 RTT (loss declared due to multiple
duplicate acknowledgments) and 1 RTO (loss declared due to a timeout)
relative to the upstream loss.
The connection RTT can sometimes be estimated by timing protocol
handshake messages. This RTT estimate can be greatly improved by
observing a dedicated protocol mechanism for conveying RTT
information, such as the Latency Spin bit of [QUIC-TRANSPORT].
Whenever the observer needs to perform a computation that uses both
upstream and end-to-end loss rate measurements, it SHOULD use
upstream loss rate leading the end-to-end loss rate by approximately
1 RTT. If the observer is unable to estimate RTT of the connection,
it should accumulate loss measurements over time periods of at least
4 times the typical RTT for the observed connections.
If the calculated upstream loss rate exceeds the end-to-end loss rate
calculated in Section 4.1, then either the Q Period is too short for
the amount of packet reordering or there is observer loss, described
Ferrieux, et al. Expires May 6, 2020 [Page 6]
Internet-Draft loss-bits November 2019
in Section 4.5. If this happens, the observer SHOULD adjust the
calculated upstream loss rate to match end-to-end loss rate.
4.4. Downstream Loss
Because downstream loss affects only those packets that did not
suffer upstream loss, the end-to-end loss rate ("e") relates to the
upstream loss rate ("u") and downstream loss rate ("d") as
"(1-u)(1-d)=1-e". Hence, "d=(e-u)/(1-u)".
4.5. Observer Loss
A typical deployment of a passive observation system includes a
network tap device that mirrors network packets of interest to a
device that performs analysis and measurement on the mirrored
packets. The observer loss is the loss that occurs on the mirror
path.
Observer loss affects upstream loss rate measurement since it causes
the observer to account for fewer packets in a block of identical Q
bit values (see {{upstreamloss)}). The end-to-end loss rate
measurement, however, is unaffected by the observer loss, since it is
a measurement of the fraction of packets with the set L bit value,
and the observer loss would affect all packets equally (see
Section 4.1).
The need to adjust the upstream loss rate down to match end-to-end
loss rate as described in Section 4.3 is a strong indication of the
observer loss, whose magnitude is between the amount of such
adjustment and the entirety of the upstream loss measured in
Section 4.2.
5. ECN-Echo Event Bit
While the primary focus of the draft is on exposing packet loss,
modern networks can report congestion before they are forced to drop
packets, as described in [ECN]. When transport protocols keep ECN-
Echo feedback under encryption, this signal cannot be observed by the
network operators. When tasked with diagnosing network performance
problems, knowledge of a congestion downstream of an observation
point can be intrumental.
If downstream congestion information is desired, this information can
be signaled with an additinal bit.
- E: The "ECN-Echo Event" bit is set to 0 or 1 according to the
Unreported ECN Echo counter, as explained below in Section 5.1.
Ferrieux, et al. Expires May 6, 2020 [Page 7]
Internet-Draft loss-bits November 2019
5.1. Setting the ECN-Echo Event Bit on Outgoing Packets
The Unreported ECN-Echo counter operates identicaly to Unreported
Loss counter (Section 3.2), except it counts packets delivered by the
network with CE markings, according to the ECN-Echo feedback from the
receiver.
This ECN-Echo signaling is similar to ECN signaling in [ConEx]. ECN-
Echo mechanism in QUIC provides the number of packets received with
CE marks. For protocols like TCP, the method described in
[ConEx-TCP] can be employed. As stated in [ConEx-TCP], such feedback
can be further improved using a method described in [ACCURATE].
5.2. Using E Bit for Passive ECN-Reported Congestion Measurement
A network observer can count packets with CE codepoint and determine
the upstream CE-marking rate directly.
Observation points can also estimate ECN-reported end-to-end
congestion by counting packets in this direction with a E bit equal
to 1.
The upstream CE-marking rate and end-to-end ECN-reported congestion
can provide information about downstream CE-marking rate. Presence
of E bits along with L bits, however, can somewhat confound precise
estimates of upstream and downstream CE-markings in case the flow
contains packets that are not ECN-capable.
6. Protocol Ossification Considerations
Accurate loss information is not critical to the operation of any
protocol, though its presence for a sufficient number of connections
is important for the operation of the networks.
The loss bits are amenable to "greasing" described in [GREASE], if
the protocol designers are not ready to dedicate (and ossify) bits
used for loss reporting to this function. The greasing could be
accomplished similarly to the Latency Spin bit greasing in
[QUIC-TRANSPORT]. Namely, implementations could decide that a
fraction of connections should not encode loss information in the
loss bits and, instead, the bits would be set to arbitrary values.
The observers would need to be ready to ignore connections with loss
information more resembling noise than the expected signal.
Ferrieux, et al. Expires May 6, 2020 [Page 8]
Internet-Draft loss-bits November 2019
7. Security Considerations
Passive loss observation has been a part of the network operations
for a long time, so exposing loss information to the network does not
add new security concerns.
8. Privacy Considerations
Guarding user's privacy is an important goal for modern protocols and
protocol extensions per [RFC7258]. While an explicit loss signal - a
preferred way to share loss information per [RFC8558] - helps to
minimize unintentional exposure of additional information,
implementations of loss reporting must ensure that loss information
does not compromise protocol's privacy goals.
For example, [QUIC-TRANSPORT] allows changing Connection IDs in the
middle of a connection to reduce the likelihood of a passive observer
linking old and new subflows to the same device. A QUIC
implementation would need to reset all counters when it changes the
destination (IP address or UDP port) or the Connection ID used for
outgoing packets. It would also need to avoid incrementing
Unreported Loss counter for loss of packets sent to a different
destinatoin or with a different Connection ID.
9. IANA Considerations
This document makes no request of IANA.
10. Change Log
10.1. Since version 01
- Clarified Q Period selection
- Added an optional E (ECN-Echo Event) bit
- Clarified L bit calculation for protocols that allow partial data
loss due to a change in segmentation (such as TCP)
10.2. Since version 00
- Addressed review comments
- Improved guidelines for privacy protections for QIUC
Ferrieux, et al. Expires May 6, 2020 [Page 9]
Internet-Draft loss-bits November 2019
11. Acknowledgments
The sQuare bit was originally suggested by Kazuho Oku in early
proposals for loss measurement and is an instance of the "alternate
marking" as defined in [RFC8321].
12. References
12.1. Normative References
[ConEx] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>.
[ConEx-IPv6]
Krishnan, S., Kuehlewind, M., Briscoe, B., and C. Ralli,
"IPv6 Destination Option for Congestion Exposure (ConEx)",
RFC 7837, DOI 10.17487/RFC7837, May 2016,
<https://www.rfc-editor.org/info/rfc7837>.
[ConEx-TCP]
Kuehlewind, M., Ed. and R. Scheffenegger, "TCP
Modifications for Congestion Exposure (ConEx)", RFC 7786,
DOI 10.17487/RFC7786, May 2016,
<https://www.rfc-editor.org/info/rfc7786>.
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Ferrieux, et al. Expires May 6, 2020 [Page 10]
Internet-Draft loss-bits November 2019
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
12.2. Informative References
[ACCURATE]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-09 (work in progress), July 2019.
[GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility",
draft-ietf-tls-grease-04 (work in progress), August 2019.
[QUIC-TRANSPORT]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-24 (work
in progress), September 2019.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/info/rfc8517>.
[TRANSPORT-ENCRYPT]
Fairhurst, G. and C. Perkins, "The Impact of Transport
Header Confidentiality on Network Operation and Evolution
of the Internet", draft-ietf-tsvwg-transport-encrypt-09
(work in progress), August 2019.
[UDP-OPTIONS]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-08 (work in progress), September 2019.
Ferrieux, et al. Expires May 6, 2020 [Page 11]
Internet-Draft loss-bits November 2019
[UDP-SURPLUS]
Herbert, T., "UDP Surplus Header", draft-herbert-udp-
space-hdr-01 (work in progress), July 2019.
Authors' Addresses
Alexandre Ferrieux
Orange Labs
EMail: alexandre.ferrieux@orange.com
Isabelle Hamchaoui
Orange Labs
EMail: isabelle.hamchaoui@orange.com
Igor Lubashev
Akamai Technologies
150 Broadway
Cambridge, MA 1122
USA
EMail: ilubashe@akamai.com
Ferrieux, et al. Expires May 6, 2020 [Page 12]