idnits 2.17.1 draft-ferrieuxhamchaoui-quic-lossbits-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 9, 2019) is 1843 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- No information found for draft-ietf-quic-transport-latest - is the name correct? Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC A. Ferrieux, Ed. 3 Internet-Draft I. Hamchaoui, Ed. 4 Intended status: Experimental Orange Labs 5 Expires: October 11, 2019 April 9, 2019 7 The QUIC Loss Bits 8 draft-ferrieuxhamchaoui-quic-lossbits-00 10 Abstract 12 This document specifies the addition of loss bits to the QUIC 13 transport protocol and describes how to use them to measure and 14 locate packet loss. 16 Note to Readers 18 This document specifies an experimental delta to the QUIC transport 19 protocol. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 11, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Passive Loss measurement . . . . . . . . . . . . . . . . . . 3 57 2.1. Proposed Short Header Format Including Loss Bits . . . . 3 58 2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2.1. Setting the sQuare Bit on Outgoing Packets . . . . . 3 60 2.2.2. Setting the Retransmit Bit on Outgoing Packets . . . 3 61 2.2.3. Resetting state on CID change . . . . . . . . . . . . 4 62 3. Using the loss bits for Passive Loss Measurement . . . . . . 4 63 3.1. End-to-end loss . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Upstream loss . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Downstream loss . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Bidirectional flows . . . . . . . . . . . . . . . . . . . 5 67 4. Security and Privacy Considerations . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Packet loss is a hard and pervasive problem of day-to-day network 76 operation, and locating them is crucial to timely resolution of 77 crippling end-to-end throughput issues. To this effect, in a TCP- 78 dominated world, network operators have been heavily relying on 79 information present in clear in TCP headers: sequence and 80 acknowledgement numbers, and SACK when enabled. By passive on-path 81 observation, these allow for quantitative estimation of packet loss. 82 Additionally, the lossy segment (upstream or downstream from the 83 observation point) is unambiguous; this is crucial as it gives the 84 ability to quickly home in on the offending segment, by moving the 85 passive observer around. 87 In the QUIC context, the equivalent transport headers being 88 encrypted, such observation is not possible. To restore network 89 operators' ability to maintain QUIC clients experience, this document 90 adds two explicit loss bits to the QUIC short header, named "Q" 91 (sQuare signal) and "R" (Retransmit). Together, these bits allow the 92 observer to estimate upstream and downstream loss, enabling the same 93 dichotomic search as with TCP. 95 2. Passive Loss measurement 97 The proposed mechanisms enable loss measurement from observation 98 points on the network path throughout the lifetime of a connection. 99 End-to end loss as well as segmental loss (upstream or downstream 100 from the observation point) are measurable thanks to two dedicated 101 bits in short packet headers, named loss bits. The loss bits 102 therefore appear only after version negotiation and connection 103 establishment are completed. 105 2.1. Proposed Short Header Format Including Loss Bits 107 As of the current editor's version of [QUIC-TRANSPORT], two bits are 108 "reserved" in the first byte of short headers. This proposal 109 naturally fits in there, allocating these two bits as Q and R. Of 110 course, the very purpose of Q and R being to enable on-path 111 observation, the current restrictions about their encryption and zero 112 value should be lifted in QUIC versions supporting this proposal. 114 2.2. Semantics 116 The semantics of these bits are as follows: 118 Q: The sQuare bit is toggled every N outgoing packets as explained 119 below in Section 2.2.1. 121 R: The Retransmit bit is set to 0 or 1 according to the not-yet- 122 disclosed-lost-packets counter, as explained below in Section 2.2.2. 124 2.2.1. Setting the sQuare Bit on Outgoing Packets 126 Each endpoint independently maintains a sQuare value, 0 or 1, during 127 a block of N outgoing packets (e.g. N=64), and sets the sQuare bit 128 in the short header to the currently stored value when a packet with 129 a short header is sent out. The sQuare value is initiated to 0 at 130 each endpoint, client and server, at connection start. This 131 mechanism thus delineates slots of N packets with the same marking. 132 Observation points can estimate the upstream losses by simply 133 counting the number of packets during a half period of the square 134 signal, as described in Section 3. 136 2.2.2. Setting the Retransmit Bit on Outgoing Packets 138 Each endpoint, client and server, independently maintains a not-yet- 139 disclosed-lost-packets counter and sets the Retransmit bit of short 140 header packets to 0 or 1 accordingly. The not-yet-disclosed-lost- 141 packets counter is initialized to 0 at each endpoint, client and 142 server, at connection start, and reflects packets considered lost by 143 the QUIC machinery, the content of which is pending for 144 retransmission. When a packet is declared lost by the QUIC 145 retransmission machinery (see [QUIC-RECOVERY]) the not-yet-disclosed- 146 lost-packets counter is incremented by 1. When a packet with a short 147 header is sent out by an end-point, its retransmit bit is set to 0 148 when the not-yet-disclosed-lost-packets counter is equal to 0. 149 Otherwise, the packet is sent out with a retransmit bit set to 1 and 150 the not-yet-disclosed-lost-packets counter is decremented by 1. 151 Thus, the retransmit bit performs unary encoding of the amount of 152 loss: observation points can estimate the number of packets 153 considered lost by the QUIC transmission machinery in a given 154 direction by counting packets in this direction with a retransmit bit 155 equal to 1. 157 2.2.3. Resetting state on CID change 159 When sending the first packet of a given connection with a new 160 connection ID, each endpoint resets its sQuare value and not-yet- 161 disclosed-lost-packets counter to zero. This eliminates the 162 possibility for transient sQuare or Retransmit bit state to be used 163 to link flows across connection migration or ID change. 165 3. Using the loss bits for Passive Loss Measurement 167 3.1. End-to-end loss 169 The Retransmit bit mechanism merely reflects the number of packets 170 considered lost by the sender QUIC stack with a slight delay. In 171 case of fast retransmit due to repeted acknowlegments of a packet, 172 this delay is at least equal to the one way delay in the reverse 173 direction. It is larger otherwise (eg RTO). The retransmit 174 mechanism alone suffices to estimate the end-to-end losses; similar 175 to TCP passive loss measurement, its accuracy depends on the loss 176 affecting the retransmit-bit-marked packets, which are in themselves 177 proof of previous loss. 179 3.2. Upstream loss 181 During a QUIC connection lifetime, the sQuare bit mechanism 182 delineates slots of N packets with the same marking. When focusing 183 on the sQuare bit of consecutive packets in a direction, this 184 mechanism sketches a periodic square signal which toggles every N 185 packets. On-path observers can then estimate the upstream losses by 186 simply counting the number of packets during a half period (level 0 187 or level 1) of the square signal. Packets with a long header are not 188 marked, but yet taken into account by the sender when counting the N 189 outgoing packets before its next toggle. Observers should assign 190 long header packets to the pending slot if possible (i.e. up to N 191 packets counted in this slot), to the next one otherwise. Thus, 192 slots with less than N packets, whatever their header length, 193 generally denote upstream loss. As with TCP passive detection based 194 on missing sequence numbers, this estimation may become inaccurate in 195 case of packet reordering which blurs the edges of the square signal 196 ; heuristics may be proposed to filter out this noise in the 197 observation points. 199 The slot size N should be carefully chosen : too short, it becomes 200 very sensitive to packet reordering and loss. Too large, short 201 connections may end before completion of the first square slot, 202 ruining any loss estimation. Slots of 64 packets are suggested as a 203 reasonable trade-off. 205 3.3. Downstream loss 207 The Retransmit bit mechanism can be coupled with the sQuare bit 208 mechanism to estimate downstream losses. Indeed, passive observers 209 can infer downstream losses by difference between end-to-end and 210 upstream losses. 212 The sQuare bit mechanism allows for observers to compute loss 213 measurement at the end of every half square signal period (level 0 or 214 level 1). 216 The Retransmit bit mechanism provides for the end-to-end loss after 217 reaction of the sender stack. 219 On-path observers can estimate upstream and downstream loss at 220 various scales, from the square slot level to the connection lifetime 221 level. 223 Note that observers should perform a loose synchronisation between 224 the sQuare and the Retransmit measurements when accurate evolution of 225 segmental loss over connection lifetime is sought, so as to compare 226 the same portion of the packet stream. 228 3.4. Bidirectional flows 230 The Q and R bits sent by one endpoint cover loss of packets sent by 231 the same endpoint, allowing a midpoint observer to estimate loss in 232 that direction; no specific cooperation is needed between the 233 endpoints beyond negotiating a QUIC version that supports this 234 proposal. Hence, the server will be enabling troubleshooting of the 235 download path, and the client will work for the upload path. This 236 allows to be confident about getting a useful signal in asymmetric 237 situations: clients may for example implement Q and R improperly, the 238 download path will still be debuggable as long as servers do it 239 right. 241 It should also be noted that the method does not suffer from the 242 natural asymmetry in packet rate of a typical download or upload 243 scenario. Indeed, although there are often fewer acknowledgements 244 than payload-bearing packets, the unary encoding by R of payload loss 245 is borne by the payload stream itself. This allows to report loss in 246 the important direction in both a timely and accurate fashion without 247 sampling or quantization. 249 4. Security and Privacy Considerations 251 The loss bits are intended to expose loss to observers along the 252 path, so the privacy considerations for the loss bits are essentially 253 the same as those for passive loss measurement in general. Loss 254 gives no hint on customer geolocalisation; moreover, reset of loss 255 accounting state on CID changes prevents linkability. 257 5. IANA Considerations 259 An IANA registry has been suggested for QUIC versions. In support of 260 the fully negotiated status of the proposed extension, a natural way 261 of deploying this feature would be through such a registered version. 263 6. Acknowledgments 265 The sQuare Bit was originally specified by Kazuho Oku in early 266 proposals for loss measurement. 268 7. Normative References 270 [QUIC-RECOVERY] 271 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 272 and Congestion Control". 274 [QUIC-TRANSPORT] 275 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 276 Multiplexed and Secure Transport", draft-ietf-quic- 277 transport-latest (work in progress). 279 Authors' Addresses 281 Alexandre Ferrieux (editor) 282 Orange Labs 284 Email: alexandre.ferrieux@orange.com 285 Isabelle Hamchaoui (editor) 286 Orange Labs 288 Email: isabelle.hamchaoui@orange.com