From 5a9ee3a3937be3a8315b9649e8127b7a65ae8963 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 1 Nov 2018 15:11:44 +1100 Subject: [PATCH 1/2] Use varints for transport parameter values This is a partial change related to #1608. It builds on the renumbering of transport parameters so as to avoid churn. --- draft-ietf-quic-transport.md | 76 ++++++++++++++++++------------------ 1 file changed, 39 insertions(+), 37 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 6580bce376..515cdafa4c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3873,6 +3873,13 @@ included in the cryptographic handshake. ## Transport Parameter Definitions {#transport-parameter-definitions} +This section details the transport parameters defined in this document. + +Many transport parameters listed here have integer values. Those transport +parameters that are identified as integers use a variable-length integer +encoding (see {{integer-encoding}}) and have a default value of 0 if the +transport parameter is absent, unless otherwise stated. + The following transport parameters are defined: original_connection_id (0x0000): @@ -3884,38 +3891,34 @@ original_connection_id (0x0000): idle_timeout (0x0001): -: The idle timeout is a value in seconds that is encoded as an unsigned 16-bit - integer. If this parameter is absent or zero then the idle timeout is - disabled. +: The idle timeout is a value in seconds that is encoded as an integer. If this + parameter is absent or zero then the idle timeout is disabled. stateless_reset_token (0x0002): -: The Stateless Reset Token is used in verifying a stateless reset, see +: A stateless reset token is used in verifying a stateless reset, see {{stateless-reset}}. This parameter is a sequence of 16 bytes. This transport parameter is only sent by a server. max_packet_size (0x0003): -: The maximum packet size parameter places a limit on the size of packets that - the endpoint is willing to receive, encoded as an unsigned 16-bit integer. - This indicates that packets larger than this limit will be dropped. The - default for this parameter is the maximum permitted UDP payload of 65527. - Values below 1200 are invalid. This limit only applies to protected packets - ({{packet-protected}}). +: The maximum packet size parameter is an integer value that limits the size of + packets that the endpoint is willing to receive. This indicates that packets + larger than this limit will be dropped. The default for this parameter is the + maximum permitted UDP payload of 65527. Values below 1200 are invalid. This + limit only applies to protected packets ({{packet-protected}}). initial_max_data (0x0004): -: The initial maximum data parameter contains the initial value for the maximum - amount of data that can be sent on the connection. This parameter is encoded - as an unsigned 32-bit integer in units of bytes. This is equivalent to - sending a MAX_DATA ({{frame-max-data}}) for the connection immediately after - completing the handshake. If the transport parameter is absent, the connection - starts with a flow control limit of 0. +: The initial maximum data parameter is an integer value that contains the + initial value for the maximum amount of data that can be sent on the + connection. This is equivalent to sending a MAX_DATA ({{frame-max-data}}) for + the connection immediately after completing the handshake. initial_max_stream_data_bidi_local (0x0005): : The initial stream maximum data for bidirectional, locally-initiated streams - parameter is a 32-bit integer that contains the initial flow control limit for + parameter is an integer value that contains the initial flow control limit for newly created bidirectional streams opened by the endpoint that sets the transport parameter. In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x0; in server @@ -3925,7 +3928,7 @@ initial_max_stream_data_bidi_local (0x0005): initial_max_stream_data_bidi_remote (0x0006): : The initial stream maximum data for bidirectional, peer-initiated streams - parameter is a 32-bit integer that contains the initial flow control limit for + parameter is an integer value that contains the initial flow control limit for newly created bidirectional streams opened by the endpoint that receives the transport parameter. In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x1; in server @@ -3934,8 +3937,8 @@ initial_max_stream_data_bidi_remote (0x0006): initial_max_stream_data_uni (0x0007): -: The initial stream maximum data for unidirectional streams parameter is a - 32-bit integer that contains the initial flow control limit for newly created +: The initial stream maximum data for unidirectional streams parameter is an + integer value that contains the initial flow control limit for newly created unidirectional streams opened by the endpoint that receives the transport parameter. In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x3; in server transport @@ -3944,36 +3947,35 @@ initial_max_stream_data_uni (0x0007): initial_max_streams_bidi (0x0008): -: The initial maximum bidirectional streams parameter contains the initial - maximum number of bidirectional streams the peer may initiate, encoded as an - unsigned 16-bit integer. If this parameter is absent or zero, the peer cannot - open bidirectional streams until a MAX_STREAMS frame is sent. Setting this +: The initial maximum bidirectional streams parameter is an integer value that + contains the initial maximum number of bidirectional streams the peer may + initiate. If this parameter is absent or zero, the peer cannot open + bidirectional streams until a MAX_STREAMS frame is sent. Setting this parameter is equivalent to sending a MAX_STREAMS ({{frame-max-streams}}) of the corresponding type with the same value. initial_max_streams_uni (0x0009): -: The initial maximum unidirectional streams parameter contains the initial - maximum number of unidirectional streams the peer may initiate, encoded as an - unsigned 16-bit integer. If this parameter is absent or zero, the peer cannot - open unidirectional streams until a MAX_STREAMS frame is sent. Setting this +: The initial maximum unidirectional streams parameter is an integer value that + contains the initial maximum number of unidirectional streams the peer may + initiate. If this parameter is absent or zero, the peer cannot open + unidirectional streams until a MAX_STREAMS frame is sent. Setting this parameter is equivalent to sending a MAX_STREAMS ({{frame-max-streams}}) of the corresponding type with the same value. ack_delay_exponent (0x000a): -: The ACK delay exponent is an 8-bit unsigned integer value indicating an - exponent used to decode the ACK Delay field in the ACK frame, see - {{frame-ack}}. If this value is absent, a default value of 3 is assumed - (indicating a multiplier of 8). The default value is also used for ACK frames - that are sent in Initial and Handshake packets. Values above 20 are invalid. +: The ACK delay exponent is an integer value indicating an exponent used to + decode the ACK Delay field in the ACK frame, see {{frame-ack}}. If this value + is absent, a default value of 3 is assumed (indicating a multiplier of 8). + This default value is also used for ACK frames that are sent in Initial and + Handshake packets. Values above 20 are invalid. max_ack_delay (0x000b): -: The maximum ACK delay is an 8 bit unsigned integer value indicating the - maximum amount of time in milliseconds by which the endpoint will delay - sending acknowledgments. If this value is absent, a default of 25 - milliseconds is assumed. +: The maximum ACK delay is an integer value indicating the maximum amount of + time in milliseconds by which the endpoint will delay sending acknowledgments. + If this value is absent, a default of 25 milliseconds is assumed. disable_migration (0x000c): From 435b309e8c93f7ee956d475c8f51fe3487e69c03 Mon Sep 17 00:00:00 2001 From: ianswett Date: Fri, 2 Nov 2018 22:31:39 -0400 Subject: [PATCH 2/2] What packet information to track and send (#1939) * What to track and send First pass at #765 and some of #1724 * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Reference transport * Update draft-ietf-quic-recovery.md Co-Authored-By: ianswett * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 85 ++++++++++++++++++++++++------------- 1 file changed, 55 insertions(+), 30 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 93a918c146..50169790fc 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -509,6 +509,57 @@ frames containing them could be lost. In this case, the loss recovery algorithm may cause spurious retransmits, but the sender will continue making forward progress. +## Tracking Sent Packets {#tracking-sent-packets} + +QUIC stores information about every packet sent. It's expected implementations +will index this information by packet number and crypto context and store the +per-packet fields detailed below for loss recovery and congestion control. +Additionally, implementations MUST ensure that any retransmittable frames +being transmitted are tracked in case of loss. + +If a packet containing retransmittable frames is lost, the QUIC transport +needs to recover from that loss, such as by retransmitting the data, +sending an updated frame, or abandoning the frame. For more information, +see Section 13.2 of {{QUIC-TRANSPORT}}. + +Packets MUST be tracked until acknowledged or lost. After a packet is lost, +it SHOULD be tracked for an amount of time comparable to the maximum +expected packet reordering, such as 1 RTT. This allows detection of +spurious retransmissions and MAY avoid extra retransmissions if the frames +contained within the packet were retransmitted and lost again. + +Sent packets are tracked for each packet number space, and ACK +processing only applies to a single space. + +### Sent Packet Fields {#sent-packets-fields} + +packet_number: +: The packet number of the sent packet. + +retransmittable: +: A boolean that indicates whether a packet is retransmittable. + If true, it is expected that an acknowledgement will be received, + though the peer could delay sending the ACK frame containing it + by up to the MaxAckDelay. + +in_flight: +: A boolean that indicates whether the packet counts towards bytes in + flight. + +is_crypto_packet: +: A boolean that indicates whether the packet contains + cryptographic handshake messages critical to the completion of the QUIC + handshake. In this version of QUIC, this includes any packet with the long + header that includes a CRYPTO frame. + +sent_bytes: +: The number of bytes sent in the packet, not including UDP or IP + overhead, but including QUIC framing overhead. + +time: +: The time the packet was sent. + + ## Pseudocode ### Constants of interest @@ -615,15 +666,8 @@ loss_time: transmit or exceeding the reordering window in time. sent_packets: - -: An association of packet numbers to information about them, including a number - field indicating the packet number, a time field indicating the time a packet - was sent, a boolean indicating whether the packet is retransmittable, - a boolean indicating whether it counts towards bytes in flight, and a size - field indicating the packet's size in bytes. sent_packets is ordered and - indexed by packet number. Packets remain in sent_packets until acknowledged - or lost. A sent_packets data structure is maintained per packet number space, - and processing of an ACK frame only applies to a single space. +: An association of packet numbers to information about them. Described + in detail above in {{tracking-sent-packets}}. ### Initialization @@ -653,27 +697,8 @@ follows: ### On Sending a Packet -After any packet is sent, be it a new transmission or a rebundled transmission, -the following OnPacketSent function is called. The parameters to OnPacketSent -are as follows: - -* packet_number: The packet number of the sent packet. - -* retransmittable: A boolean that indicates whether a packet is - retransmittable. If true, it is expected that an acknowledgement will - be received, though the peer could delay sending the ACK frame containing - it by up to the MaxAckDelay. - -* in_flight: A boolean that indicates whether the packet counts towards bytes in - flight. - -* is_crypto_packet: A boolean that indicates whether the packet contains - cryptographic handshake messages critical to the completion of the QUIC - handshake. In this version of QUIC, this includes any packet with the long - header that includes a CRYPTO frame. - -* sent_bytes: The number of bytes sent in the packet, not including UDP or IP - overhead, but including QUIC framing overhead. +After any packet is sent. The parameters to OnPacketSent are described in +detail above in {{sent-packets-fields}}. Pseudocode for OnPacketSent follows: