4.1.  Data Flow Control

* senders MUST NOT send data in excess of either limit. -> already chech with max_data etc

4.3.  Flow Control Performance	
		 		
If an endpoint cannot ensure that its peer always has available flow	
control credit that is greater than the peer's bandwidth-delay	
product on this connection, its receive throughput will be limited by	
flow control.	
		 		
Packet loss can cause gaps in the receive buffer, preventing the	
application from consuming data and freeing up receive buffer space.	
		 		
Sending timely updates of flow control limits can improve	
performance.  Sending packets only to provide flow control updates	
can increase network load and adversely affect performance.  Sending	
flow control updates along with other frames, such as ACK frames,	
reduces the cost of those updates.

4.6.  Controlling Concurrency

If a max_streams transport parameter or a MAX_STREAMS frame is	
received with a value greater than 2^60, this would allow a maximum	
stream ID that cannot be expressed as a variable-length integer; see	
Section 16.  If either is received, the connection MUST be closed	
immediately with a connection error of type TRANSPORT_PARAMETER_ERROR	
if the offending value was received in a transport parameter or of	
type FRAME_ENCODING_ERROR if it was received in a frame; see	
Section 10.2. -> OK (+- need test for the TP)

5.  Connections	 <-> before: 	5.3.  Life of a QUIC Connection
		 		
A QUIC connection is shared state between a client and a server.	

Each connection starts with a handshake phase, during which the two	
endpoints establish a shared secret using the cryptographic handshake	
protocol [QUIC-TLS] and negotiate the application protocol.  The	
handshake (Section 7) confirms that both endpoints are willing to	
communicate (Section 8.1) and establishes parameters for the	
connection (Section 7.4).	
		 		
An application protocol can use the connection during the handshake	
phase with some limitations.  0-RTT allows application data to be	
sent by a client before receiving a response from the server.	
However, 0-RTT provides no protection against replay attacks; see	
Section 9.2 of [QUIC-TLS].  A server can also send application data	
to a client before it receives the final cryptographic handshake	
messages that allow it to confirm the identity and liveness of the	
client.  These capabilities allow an application protocol to offer	
the option of trading some security guarantees for reduced latency.	
		 		
The use of connection IDs (Section 5.1) allows connections to migrate	
to a new network path, both as a direct choice of an endpoint and	
when forced by a change in a middlebox.  Section 9 describes	
mitigations for the security and privacy issues associated with	
migration.	
		 		
For connections that are no longer needed or desired, there are	
several ways for a client and server to terminate a connection, as	
described in Section 10.	
		 	
5.1.  Connection ID

Multiple connection IDs are used so that endpoints can send packets	
that cannot be identified by an observer as being for the same	
connection without cooperation from an endpoint; see Section 9.5.

...

A Version Negotiation (Section 17.2.1) packet echoes the connection	
IDs selected by the client, both to ensure correct routing toward the	
client and to demonstrate that the packet is in response to a packet	
sent by the client. -> OK

5.1.1.  Issuing Connection IDs

An endpoint that initiates migration and requires non-zero-length	     An endpoint that initiates migration and requires non-zero-length	
connection IDs SHOULD ensure that the pool of connection IDs	        connection IDs SHOULD ensure that the pool of connection IDs	
available to its peer allows the peer to use a new connection ID on	  available to its peer allows the peer to use a new connection ID on	
migration, as the peer will close the connection if the pool is	     migration, as the peer will be **unable** to respond if the pool is	
exhausted.	                                                           exhausted.

An endpoint that selects a zero-length connection ID during the	-> OK
handshake cannot issue a new connection ID.  A zero-length	
Destination Connection ID field is used in all packets sent toward	
such an endpoint over any network path.

5.2.  Matching Packets to Connections

Invalid packets without packet protection, such as Initial, Retry, or	 	   Invalid packets that lack strong integrity protection, such as	
Version Negotiation, MAY be discarded.  An endpoint MUST generate a	 	       Initial, Retry, or Version Negotiation, MAY be discarded.  An	
connection error if it commits changes to state before discovering an	 	   endpoint MUST generate a connection error if processing the contents	
error.	 	                                                                   of these packets prior to discovering an error, or fully revert any	
                                                                               changes made during that processing.	-> TODO tests/scenario

5.2.1.  Client Packet Handling

If a client receives a packet that has an **unsupported version**, it	 	  If a client receives a packet that uses a **different version** than it	
MUST discard that packet.	 	                                               initially selected, it MUST discard that packet. -> internal state ? check if packet eventually acked at the end ?

6.  Version Negotiation	
		 		
Version negotiation ensures that client and server agree to a QUIC	 	    Version negotiation allows a server to indicate that it does not	
version that is mutually supported.  A server sends a Version	 	          support the version the client used.  A server sends a Version	
Negotiation packet in response to each packet that might initiate a	 	    Negotiation packet in response to each packet that might initiate a	
new connection; see Section 5.2 for details.	 	                            new connection; see Section 5.2 for details.	
		 		
The size of the first packet sent by a client will determine whether	 	    The size of the first packet sent by a client will determine whether	
a server sends a Version Negotiation packet.  Clients that support	 	    a server sends a Version Negotiation packet.  Clients that support	
multiple QUIC versions SHOULD pad the first packet they send to the	 	    multiple QUIC versions SHOULD ensure that the first UDP datagram they	
largest of the minimum packet sizes across all versions they support.  	    send is sized to the largest of the minimum datagram sizes from all	
This ensures that the server responds if there is a mutually	 	          versions they support, using PADDING frames (Section 19.1) as	
supported version.	 	                                                    necessary.  This ensures that the server responds if there is a	
                                                                            mutually supported version.  A server might not send a Version	
                                                                            Negotiation packet if the datagram it receives is smaller than the	-> OK

7.3.  Authenticating Connection IDs

The values provided by a peer for these transport parameters MUST	     The values provided by a peer for these transport parameters (cid related) MUST	
match the values that an endpoint used in the Destination and Source	  match the values that an endpoint used in the Destination and Source	
Connection ID fields of Initial packets that it sent.  Including	     Connection ID fields of Initial packets that it sent (and received,	
connection ID values in transport parameters and verifying them	     for servers).  Endpoints MUST validate that received transport	-> OK
ensures that that an attacker cannot influence the choice of	        parameters match received connection ID values.  Including connection	
connection ID for a successful connection by injecting packets	        ID values in transport parameters and verifying them ensures that an	
carrying attacker-chosen connection IDs during the handshake.	        attacker cannot influence the choice of connection ID for a	
                                                                       successful connection by injecting packets carrying attacker-chosen	
                                                                       connection IDs during the handshake.

7.4.1.  Values of Transport Parameters for 0-RTT

Both endpoints store the value of the server transport parameters	 	   Using 0-RTT depends on both client and server using protocol	
from a connection and apply them to any 0-RTT packets that are sent	   parameters that were negotiated from a previous connection.  To	
in subsequent connections to that peer, except for transport	         enable 0-RTT, endpoints store the values of the server transport	
parameters that are explicitly excluded.  Remembered transport	         parameters with any session tickets it receives on the connection.	
parameters apply to the new connection until the handshake completes	   Endpoints also store any information required by the application	
and the client starts sending 1-RTT packets.  Once the handshake	      protocol or cryptographic handshake; see Section 4.6 of [QUIC-TLS].	
completes, the client uses the transport parameters established in	   The values of stored transport parameters are used when attempting	
the handshake.	                                                         0-RTT using the session tickets.	

The definition of new transport parameters (Section 7.4.2) MUST	      Remembered transport parameters apply to the new connection until the	
specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A 	   handshake completes and the client starts sending 1-RTT packets.	
client need not store a transport parameter it cannot process.	         Once the handshake completes, the client uses the transport	
                                                                        parameters established in the handshake.  Not all transport	
                                                                        parameters are remembered, as some do not apply to future connections	
                                                                        or they have no effect on the use of 0-RTT.	
		                                                                       	
                                                                        The definition of a new transport parameter (Section 7.4.2) MUST	
                                                                        specify whether storing the transport parameter for 0-RTT is	
                                                                        mandatory, optional, or prohibited.  A client need not store a	
                                                                        transport parameter it cannot process.

A server might provide larger initial stream flow control limits for
streams than the remembered values that a client applies when sending	
0-RTT.  Once the handshake completes, the client updates the flow	
control limits on all sending streams using the updated values of	
initial_max_stream_data_bidi_remote and initial_max_stream_data_uni.	
		 		
A server MAY store and recover the previously sent values of the	
max_idle_timeout, max_udp_payload_size, and disable_active_migration	
parameters and reject 0-RTT if it selects smaller values.  Lowering	
the values of these parameters while also accepting 0-RTT data could	
degrade the performance of the connection.  Specifically, lowering	
the max_udp_payload_size could result in dropped packets, leading to	      -> liveness
worse performance compared to rejecting 0-RTT data outright.	
		 		
A server MUST either reject 0-RTT data **or** abort a handshake if the      A server MUST reject 0-RTT data if the **restored** values for transport	
implied values for transport parameters cannot be supported.                parameters cannot be supported.	-> TODO: no ack for 0rtt packet ? but not ground truth, cannot have access to internal state

QUESITON: is reject 0-rtt data same than reject 0rtt ?
   -> 0rtt is rejected when 'A server rejects 0-RTT by sending the EncryptedExtensions without an early_data extension.'

7.4.2.  New Transport Parameters

A client that does not understand a transport parameter can discard	
it and attempt 0-RTT on subsequent connections.  However, if the	
client adds support for a discarded transport parameter, it risks	
violating the constraints that the transport parameter establishes if	
it attempts 0-RTT.  New transport parameters can avoid this problem	
by setting a default of the most conservative value.  Clients can	
avoid this problem by remembering all parameters, even those not	
currently supported.

8.  Address Validation

The primary defense against amplification attack is verifying that an	    The primary defense against amplification attacks is verifying that a	
endpoint is able to receive packets at the transport address that it	       peer is able to receive packets at the transport address that it	
claims.  Address validation is performed both during connection claims.     Therefore, after receiving packets from an address that is	
establishment (see Section 8.1) and during connection migration (see	       not yet validated, an endpoint MUST limit the amount of data it sends	
Section 8.2).	                                                             to the unvalidated address to three times the amount of data received	
                                                                            from that address.  This limit on the size of responses is known as	
                                                                            the anti-amplification limit. -> impossible to verify if is really limited

                                                                            Address validation is performed both during connection establishment	
                                                                            (see Section 8.1) and during connection migration (see Section 8.2).	

8.1.  Address Validation during Connection Establishment

Additionally, an endpoint MAY consider the peer address validated if	
the peer uses a connection ID chosen by the endpoint and the	
connection ID contains at least 64 bits of entropy.	+
		 		
For the client, the value of the Destination Connection ID field in	
its first Initial packet allows it to validate the server address as	
a part of successfully processing any packet.  Initial packets from	
the server are protected with keys that are derived from this value	
(see Section 5.2 of [QUIC-TLS]).  Alternatively, the value is echoed	
by the server in Version Negotiation packets (Section 6) or included	
in the Integrity Tag in Retry packets (Section 5.8 of [QUIC-TLS]).

8.1.2.  Address Validation Using Retry Packets

In response to processing an Initial packet containing a token that	
was provided in a Retry packet, a server **cannot send another Retry**	
packet; it can only refuse the connection or permit it to proceed -> OK

8.1.4.  Address Validation Token Integrity

An address validation token MUST be difficult to guess.  Including a	   An address validation token MUST be difficult to guess.  Including a	
large enough random value in the token would be sufficient, but this	   random value with at least **128 bits of entropy** in the token would be	
depends on the server remembering the value it sends to clients.	 	   sufficient, but this depends on the server remembering the value it	
		 	                                                               sends to clients. ->> is it that now 128 bits is minimum size ?? "would be"

Servers MUST ensure that replay of tokens is prevented or limited.	 	   Attackers could replay tokens to use servers as amplifiers in DDoS	
For instance, servers might limit the time over which a token is	 	      attacks.  To protect against such attacks, servers MUST ensure that	
accepted.  Tokens provided in NEW_TOKEN frames might need to allow	 	   replay of tokens is prevented or limited.  Servers SHOULD ensure that	
longer validity periods.  Tokens MAY include additional information	 	   tokens sent in Retry packets are only accepted for a short time, as	
about clients to further narrow applicability or reuse.	 	               they are returned immediately by clients.  Tokens that are provided	
                                                                           in NEW_TOKEN frames (Section 19.7) need to be valid for longer but	
                                                                           SHOULD NOT be accepted multiple times.  Servers are encouraged to	
                                                                           allow tokens to be used only once, if possible; tokens MAY include	
                                                                           additional information about clients to further narrow applicability	
                                                                           or reuse.


8.2.  Path Validation

Path validation does not validate that a peer can send in the return	
direction.  Acknowledgments cannot be used for return path validation	
because they contain insufficient entropy and might be spoofed.	
Endpoints independently determine reachability on each direction of a	
path, and therefore return reachability can only be established by	
the peer

When probing a new path, an endpoint might want to ensure that its	 	   An endpoint uses a new connection ID for probes sent from a new local	
peer has an unused connection ID available for responses.  The	 	         address; see Section 9.5.  When probing a new path, an endpoint can	
endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the	      ensure that its peer has an unused connection ID available for	
same packet.  This ensures that an unused connection ID will be	 	      responses.  Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in	
available to the peer when sending a response.	 	                        the same packet, if the peer's active_connection_id_limit permits,	
                                                                           ensures that an unused connection ID will be available to the peer	
                                                                           when sending a response.	-> ok
                                                                                
                                                                           An endpoint can choose to simultaneously probe multiple paths.  The	
                                                                           number of simultaneous paths used for probes is limited by the number	
                                                                           of extra connection IDs its peer has previously supplied, since each	
                                                                           new local address used for a probe requires a previously unused	
                                                                           connection ID


8.2.1.  Initiating Path Validation

An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame	
to at least the smallest allowed maximum datagram size of 1200 bytes,	
**unless the anti-amplification limit for the path** does not permit	 -> impossible to know ?
sending a datagram of this size.  Sending UDP datagrams of this size	
ensures that the network path from the endpoint to the peer can be	
used for QUIC; see Section 14.	
		 		
When an endpoint is unable to expand the datagram size to 1200 bytes	
due to the anti-amplification limit, the path MTU will not be	
validated.  To ensure that the path MTU is large enough, the endpoint	
MUST perform a second path validation by sending a PATH_CHALLENGE	
frame in a datagram of at least 1200 bytes.  This additional	
validation can be performed after a PATH_RESPONSE is successfully	
received or when enough bytes have been received on the path that	
sending the larger datagram will not result in exceeding the anti-	
amplification limit.	
		 		
Unlike other cases where datagrams are expanded, endpoints MUST NOT	
discard datagrams that appear to be too small when they contain	
PATH_CHALLENGE or PATH_RESPONSE.

8.2.2.  Path Validation Responses

On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by	
echoing the data contained in the PATH_CHALLENGE frame in a	
PATH_RESPONSE frame.  -> OK
An endpoint MUST NOT delay transmission of a	
packet containing a PATH_RESPONSE frame unless constrained by	
congestion control.	-> Impossible to know
		 		
A PATH_RESPONSE frame MUST be sent on the network path where the	
PATH_CHALLENGE frame was received.  -> TO CHECK
This ensures that path validation	
by a peer only succeeds if the path is functional in both directions.	
This requirement MUST NOT be enforced by the endpoint that initiates	
path validation, as that would enable an attack on migration; see	
Section 9.3.3.	
		 		
An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame	
to at least the smallest allowed maximum datagram size of 1200 bytes.	
This verifies that the path is able to carry datagrams of this size	 -> TODO
in both directions.  However, an endpoint MUST NOT expand the	
datagram containing the PATH_RESPONSE if the resulting data exceeds	
the anti-amplification limit.  This is expected to only occur if the	
received PATH_CHALLENGE was not sent in an expanded datagram.	

8.2.3.  Successful Path Validation

A new address is considered valid when a PATH_RESPONSE frame is	       Path validation succeeds when a PATH_RESPONSE frame is received that	
received that contains the data that was sent in a previous	             contains the data that was sent in a previous PATH_CHALLENGE frame.	
PATH_CHALLENGE.  Receipt of an acknowledgment for a packet containing	 A PATH_RESPONSE frame received on any network path validates the path	
a PATH_CHALLENGE frame is not adequate validation, since the	          on which the PATH_CHALLENGE was sent.	
acknowledgment can be spoofed by a malicious peer.	 		
		 		
Note that receipt on a different local address does not result in	       If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not	
path validation failure, as it might be a result of a forwarded	       expanded to at least 1200 bytes and if the response to it validates	
packet (see Section 9.3.3) or misrouting.  It is possible that a	       the peer address, the path is validated but not the path MTU.  As a	
valid PATH_RESPONSE might be received in the future.	                   result, the endpoint can now send more than three times the amount of	
                                                                         data that has been received.  However, the endpoint MUST initiate	
                                                                         another path validation with an expanded datagram to verify that the	
                                                                         path supports the required MTU.	
                                                                                
                                                                         Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE	
                                                                         frame is not adequate validation, since the acknowledgment can be	
                                                                         spoofed by a malicious peer.

8.2.4.  Failed Path Validation

This timeout allows for multiple PTOs to expire prior to failing path	
validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE	
frame does not cause path validation failure.

An endpoint	 that has no valid network path to its peer MAY signal this using the	
NO_VIABLE_PATH connection error, noting that this is only possible if	
the network path exists but does not support the required MTU	
(Section 14). ->> TODO tests

9.2.  Initiating Connection Migration

To establish reachability on the new path, an endpoint initiates path	
validation (Section 8.2) on the new path.  An endpoint MAY defer path	
validation until after a peer sends the next non-probing frame to its	
new address.

9.3.  Responding to Connection Migration

If the recipient permits the migration, it MUST send subsequent	
packets to the new peer address and MUST initiate path validation	
(Section 8.2) to verify the peer's ownership of the address if	
validation is not already underway.  If the recipient has no unused	
connection IDs from the peer, it will not be able to send anything on	
the new path until the peer provides one; see Section 9.5.	
		 		
An endpoint only changes the address to which it sends packets in	
response to the highest-numbered non-probing packet.  This ensures	
that an endpoint does not send packets to an old peer address in the	
case that it receives reordered packets.

9.6.2.  Migration to a Preferred Address

A client that migrates to a preferred address MUST validate the	
address it chooses before migrating; see Section 21.5.3

10.1.  Idle Timeout

To avoid excessively small idle timeout periods, endpoints MUST	
increase the idle timeout period to be at least three times the	
current Probe Timeout (PTO).  This allows for multiple PTOs to	
expire, and therefore multiple probes to be sent and lost, prior to	
idle timeout.

10.2.  Immediate Close

After sending a CONNECTION_CLOSE frame, an endpoint immediately	 	   After sending a CONNECTION_CLOSE frame, an endpoint immediately	
enters the closing state.	                                             enters the closing state; see Section 10.2.1.  After receiving a	
                                                                        CONNECTION_CLOSE frame, endpoints enter the draining state; see	
                                                                        Section 10.2.2.	
		 		
During the closing period, an endpoint that sends a CONNECTION_CLOSE	 Violations of the protocol lead to an immediate close.	
frame SHOULD respond to any incoming packet that can be decrypted	 		
with another packet containing a CONNECTION_CLOSE frame.  Such an	     An immediate close can be used after an application protocol has	
endpoint SHOULD limit the number of packets it generates containing a	 arranged to close a connection.  This might be after the application	
CONNECTION_CLOSE frame.  For instance, an endpoint could wait for a	     protocol negotiates a graceful shutdown.  The application protocol	
...                                                                      can exchange messages that are needed for both application endpoints	
                                                                         to agree that the connection can be closed, after which the	
                                                                         application requests that QUIC close the connection.  When QUIC	
                                                                         consequently closes the connection, a CONNECTION_CLOSE frame with an	
                                                                         application-supplied error code will be used to signal closure to the	
                                                                         peer.	
                                                                            
                                                                         The closing and draining connection states exist to ensure that	
                                                                         connections close cleanly and that delayed or reordered packets are	
                                                                         properly discarded.  These states SHOULD persist for at least three	
                                                                         times the current PTO interval as defined in [QUIC-RECOVERY].	
                                                                            
                                                                         Disposing of connection state prior to exiting the closing or	
                                                                         draining state could result in an endpoint generating a Stateless	
                                                                         Reset unnecessarily when it receives a late-arriving packet.	
                                                                         Endpoints that have some alternative means to ensure that late-	
                                                                         arriving packets do not induce a response, such as those that are	
                                                                         able to close the UDP socket, MAY end these states earlier to allow	
                                                                         for faster resource recovery.  Servers that retain an open socket for	
                                                                         accepting new connections SHOULD NOT end the closing or draining	
                                                                         state early.	
                                                                            
                                                                        Once its closing or draining state ends, an endpoint SHOULD discard	
                                                                        all connection state.  The endpoint MAY send a Stateless Reset in	
                                                                        response to any further incoming packets belonging to this	
                                                                        connection.
	
10.2.1.  Closing Connection State

In the closing state, an endpoint retains only enough information to	
generate a packet containing a CONNECTION_CLOSE frame and to identify	
packets as belonging to the connection.  An endpoint in the closing	
state sends a packet containing a CONNECTION_CLOSE frame in response	
to any incoming packet that it attributes to the connection.	
		 	
An endpoint MAY drop packet protection keys when entering the closing	
state and send a packet containing a CONNECTION_CLOSE frame in	
response to any UDP datagram that is received.  However, an endpoint	
that discards packet protection keys cannot identify and discard	
invalid packets.  To avoid being used for an amplification attack,	
such endpoints MUST limit the cumulative size of packets it sends to	
three times the cumulative size of the packets that are received and	
attributed to the connection.  To minimize the state that an endpoint	
maintains for a closing connection, endpoints MAY send the exact same	
packet in response to any received packet.

10.3.  Stateless Reset

A stateless reset token is specific to a connection ID.  An endpoint	
issues a stateless reset token by including the value in the	
Stateless Reset Token field of a NEW_CONNECTION_ID frame.  Servers	
can also issue a stateless_reset_token transport parameter during the	
handshake that applies to the connection ID that it selected during	
the handshake.  These exchanges are protected by encryption, so only	
client and server know their value.  Note that clients cannot use the	
stateless_reset_token transport parameter because their transport	
parameters do not have confidentiality protection.	

11.1.  Connection Errors

Application protocols can signal application-specific protocol errors	 	   Application-specific protocol errors are signaled using the	
using the application-specific variant of the CONNECTION_CLOSE frame.	 	   CONNECTION_CLOSE frame with a frame type of 0x1d.  Errors that are	
Errors that are specific to the transport, including all those	 	            specific to the transport, including all those described in this	
described in this document, are carried in the QUIC-specific variant	 	      document, are carried in the CONNECTION_CLOSE frame with a frame type	
of the CONNECTION_CLOSE frame.	 	                                          of 0x1c.

...


As the AEAD for Initial packets does not provide strong	
authentication, an endpoint MAY discard an invalid Initial packet.	
Discarding an Initial packet is permitted even where this	
specification otherwise mandates a connection error.  An endpoint can	
only discard a packet if it does not process the frames in the packet	
or reverts the effects of any processing.  Discarding invalid Initial	
packets might be used to reduce exposure to denial of service; see	
Section 21.2.


12.4.  Frames and Frame Type

		 		
The payload of a packet that contains frames MUST contain at least	 	   The payload of a packet that contains frames MUST contain at least	
one frame, and MAY contain multiple frames and multiple frame types.	      one frame, and MAY contain multiple frames and multiple frame types.	
Frames always fit within a single QUIC packet and cannot span	 	         An endpoint MUST treat receipt of a packet containing no frames as a	
multiple packets.	 	                                                      connection error of type PROTOCOL_VIOLATION.  Frames always fit	
		 	                                                                  within a single QUIC packet and cannot span multiple packets.

       Table 3 lists and summarizes information about each frame type that	
 	   is defined in this specification.  A description of this summary is	
 	   included after the table.	
 		
 	    +============+======================+===============+======+======+	
 	    | Type Value | Frame Type Name      | Definition    | Pkts | Spec |	
 	    +============+======================+===============+======+======+	
 	    | 0x00       | PADDING              | Section 19.1  | IH01 | NP   |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x01       | PING                 | Section 19.2  | IH01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x02-0x03  | ACK                  | Section 19.3  | IH_1 | NC   |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x04       | RESET_STREAM         | Section 19.4  | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x05       | STOP_SENDING         | Section 19.5  | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x06       | CRYPTO               | Section 19.6  | IH_1 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x07       | NEW_TOKEN            | Section 19.7  | ___1 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x08-0x0f  | STREAM               | Section 19.8  | __01 | F    |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x10       | MAX_DATA             | Section 19.9  | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x11       | MAX_STREAM_DATA      | Section 19.10 | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x12-0x13  | MAX_STREAMS          | Section 19.11 | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x14       | DATA_BLOCKED         | Section 19.12 | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x15       | STREAM_DATA_BLOCKED  | Section 19.13 | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x16-0x17  | STREAMS_BLOCKED      | Section 19.14 | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x18       | NEW_CONNECTION_ID    | Section 19.15 | __01 | P    |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x19       | RETIRE_CONNECTION_ID | Section 19.16 | __01 |      |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x1a       | PATH_CHALLENGE       | Section 19.17 | __01 | P    |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x1b       | PATH_RESPONSE        | Section 19.18 | ___1 | P    |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x1c-0x1d  | CONNECTION_CLOSE     | Section 19.19 | ih01 | N    |	
 	    +------------+----------------------+---------------+------+------+	
 	    | 0x1e       | HANDSHAKE_DONE       | Section 19.20 | ___1 |      |	
 	    +------------+----------------------+---------------+------+------+	
 		
 	                            Table 3: Frame Types	
 		
 	   The format and semantics of each frame type are explained in more	
 	   detail in Section 19.  The remainder of this section provides a	
 	   summary of important and general information.

The "Spec" column in Table 3 summarizes any special rules governing	
the processing or generation of the frame type, as indicated by the	
following characters:	
 		
       N:   Packets containing only frames with this marking are not ack-	
             eliciting; see Section 13.2.	
 		
 	   C:   Packets containing only frames with this marking do not count	
 	        toward bytes in flight for congestion control purposes; see	
 	        [QUIC-RECOVERY].	
 		
 	   P:   Packets containing only frames with this marking can be used to	
 	        probe new network paths during connection migration; see	
 	        Section 9.1.	
 		
 	   F:   The contents of frames with this marking are flow controlled;	
 	        see Section 4.	
 		
 The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA	
 registry; see Section 22.4.

 12.5.  Frames and Number Spaces	
 		
Some frames are prohibited in different packet number spaces.  The	
rules here generalize those of TLS, in that frames associated with	
establishing the connection can usually appear in packets in any	
packet number space, whereas those associated with transferring data	
can only appear in the application data packet number space:	
 		
*  PADDING, PING, and CRYPTO frames MAY appear in any packet number	
   space.	
 		
*  CONNECTION_CLOSE frames signaling errors at the QUIC layer (type	
   0x1c) MAY appear in any packet number space.  CONNECTION_CLOSE	
   frames signaling application errors (type 0x1d) MUST only appear	
   in the application data packet number space.	
 		
*  ACK frames MAY appear in any packet number space but can only	
   acknowledge packets that appeared in that packet number space.	
   However, as noted below, 0-RTT packets cannot contain ACK frames.	
 		
*  All other frame types MUST only be sent in the application data	
   packet number space.	
 		
Note that it is not possible to send the following frames in 0-RTT	
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,	
PATH_RESPONSE, and RETIRE_CONNECTION_ID.  A server MAY treat receipt	
of these frames in 0-RTT packets as a connection error of type	
PROTOCOL_VIOLATION.	

13.2.1.  Sending ACK Frames

An endpoint MUST acknowledge all ack-eliciting Initial and Handshake	
packets immediately and all ack-eliciting 0-RTT and 1-RTT packets	
within its advertised max_ack_delay, with the following exception.	
Prior to handshake confirmation, an endpoint might not have packet	
protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets	
when they are received.  It might therefore buffer them and	
acknowledge them when the requisite keys become available.

An endpoint that is only sending ACK frames will not receive	
acknowledgments from its peer unless those acknowledgments are	
included in packets with ack-eliciting frames.  An endpoint SHOULD	
send an ACK frame with other frames when there are new ack-eliciting	
packets to acknowledge.  When only non-ack-eliciting packets need to	
be acknowledged, an endpoint MAY choose not to send an ACK frame with	
outgoing frames until an ack-eliciting packet has been received.	
 		
An endpoint that is only sending non-ack-eliciting packets might	
choose to occasionally add an ack-eliciting frame to those packets to	
ensure that it receives an acknowledgment; see Section 13.2.4.  In	
that case, an endpoint MUST NOT send an ack-eliciting frame in all	
packets that would otherwise be non-ack-eliciting, to avoid an	
infinite feedback loop of acknowledgments.	-> not possible to test

In order to assist loss detection at the sender, an endpoint SHOULD	 	   In order to assist loss detection at the sender, an endpoint SHOULD	
send an ACK frame immediately on receiving an ack-eliciting packet	 	   generate and send an ACK frame without delay when it receives an ack-	
that is out of order.  The endpoint SHOULD NOT continue sending ACK	 	   eliciting packet either:	
frames immediately unless more ack-eliciting packets are received out	 		
of order.  If every subsequent ack-eliciting packet arrives out of	 	    *  when the received packet has a packet number less than another	
order, then an ACK frame SHOULD be sent immediately for every	 	             ack-eliciting packet that has been received, or	
                                                                               received ack-eliciting packet.	 		
                                                                            *  when the packet has a packet number larger than the highest-	
                                                                               numbered ack-eliciting packet that has been received and there are	
                                                                               missing packets between that packet and this packet.

13.2.3.  Managing ACK Ranges

Senders can expect acknowledgments	
for most packets, but QUIC does not guarantee receipt of an	
acknowledgment for every packet that the receiver processes.

13.2.4.  Limiting Ranges by Tracking ACK Frames	
 		
When a packet containing an ACK frame is sent, the Largest	
Acknowledged field in that frame can be saved.  When a packet	
containing an ACK frame is acknowledged, the receiver can stop	
acknowledging packets less than or equal to the Largest Acknowledged	
field in the sent ACK frame.	
 	                                                                         	
A receiver that sends only non-ack-eliciting packets, such as ACK	
frames, might not receive an acknowledgment for a long period of	
time.  This could cause the receiver to maintain state for a large	
number of ACK frames for a long period of time, and ACK frames it	
sends could be unnecessarily large.  In such a case, a receiver could	
send a PING or other small ack-eliciting frame occasionally, such as	
once per round trip, to elicit an ACK from the peer.	
 		
In cases without ACK frame loss, this algorithm allows for a minimum	
of 1 RTT of reordering.  In cases with ACK frame loss and reordering,	
this approach does not guarantee that every acknowledgment is seen by	
the sender before it is no longer included in the ACK frame.  Packets	
could be received out of order, and all subsequent ACK frames	
containing them could be lost.  In this case, the loss recovery	
algorithm could cause spurious retransmissions, but the sender will	
continue making forward progress.

13.2.5.  Measuring and Reporting Host Delay

A packet might be held in the OS kernel or elsewhere on the host	
before being processed.  An endpoint MUST NOT include delays that it	
does not control when populating the ACK Delay field in an ACK frame.	
However, endpoints SHOULD include buffering delays caused by	
unavailability of decryption keys, since these delays can be large	
and are likely to be non-repeating.	
 		
When the measured acknowledgment delay is larger than its	
max_ack_delay, an endpoint SHOULD report the measured delay.  This	
information is especially useful during the handshake when delays	
might be large; see Section 13.2.1.

13.3.  Retransmission of Information

A sender SHOULD avoid retransmitting information from packets once	
they are acknowledged.  This includes packets that are acknowledged	
after being declared lost, which can happen in the presence of	
network reordering.  Doing so requires senders to retain information	
about packets after they are declared lost.  A sender can discard	
this information after a period of time elapses that adequately	
allows for reordering, such as a PTO (Section 6.2 of	
[QUIC-RECOVERY]), or based on other events, such as reaching a memory	
limit.	

13.4.  Explicit Congestion Notification -->> "lot" of modification

14.  Datagram Size	
 		
The QUIC packet size includes the QUIC header and protected payload,	 	    A UDP datagram can include one or more QUIC packets.  The datagram	
but not the UDP or IP headers.	 	                                        size refers to the total UDP payload size of a single UDP datagram	
                                                                            carrying QUIC packets.  The datagram size includes one or more QUIC	
                                                                            packet headers and protected payloads, but not the UDP or IP headers.	
                                                                                
QUIC depends upon a minimum IP packet size of at least 1280 bytes.	 	    The maximum datagram size is defined as the largest size of UDP	
This is the IPv6 minimum size [RFC8200] and is also supported by most	    payload that can be sent across a network path using a single UDP	
modern IPv4 networks.  Assuming the minimum IP header size, this	 	       datagram.  QUIC MUST NOT be used if the network path cannot support a	
results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252	 	 maximum datagram size of at least 1200 bytes.	
bytes for IPv4.	 		
 		
The QUIC maximum packet size is the largest size of QUIC packet that	 	QUIC assumes a minimum IP packet size of at least 1280 bytes.  This	
can be sent across a network path using a single packet.  Any maximum	 	is the IPv6 minimum size [IPv6] and is also supported by most modern	
packet size larger than 1200 bytes can be discovered using Path	 	        IPv4 networks.  Assuming the minimum IP header size of 40 bytes for	
Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or	       	IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this	
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see	 	            results in a maximum datagram size of 1232 bytes for IPv6 and 1252	
Section 14.3).	 	                                                        bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are	
                                                                            expected to be able to support QUIC.	
                                                                                
                                                                                |  Note: This requirement to support a UDP payload of 1200 bytes	
                                                                                |  limits the space available for IPv6 extension headers to 32	
                                                                                |  bytes or IPv4 options to 52 bytes if the path only supports the	
                                                                                |  IPv6 minimum MTU of 1280 bytes.  This affects Initial packets	
                                                                                |  and path validation.	
                                                                                                                                                        
                                                                            Any maximum datagram size larger than 1200 bytes can be discovered	
                                                                            using Path Maximum Transmission Unit Discovery (PMTUD) (see	
                                                                            Section 14.2.1) or Datagram Packetization Layer PMTU Discovery	
                                                                            (DPLPMTUD) (see Section 14.3

QUIC sometimes requires datagrams to be no smaller than a certain	
size; see Section 8.1 as an example.  However, the size of a datagram	
is not authenticated.  That is, if an endpoint receives a datagram of	
a certain size, it cannot know that the sender sent the datagram at	
the same size.  Therefore, an endpoint MUST NOT close a connection	
when it receives a datagram that does not meet size constraints; the	
endpoint MAY discard such datagrams.

14.1.  Initial Datagram Size

A client MUST expand the payload of all UDP datagrams carrying	 	        A client MUST expand the payload of all UDP datagrams carrying	
Initial packets to at least the smallest allowed maximum packet size	 	Initial packets to at least the smallest allowed maximum datagram	
(1200 bytes) by adding PADDING frames to the Initial packet or by	 	    size of 1200 bytes by adding PADDING frames to the Initial packet or	
coalescing the Initial packet; see Section 12.2.  Sending a UDP	 	        by coalescing the Initial packet; see Section 12.2.  Initial packets	
datagram of this size ensures that the network path from the client	 	    can even be coalesced with invalid packets, which a receiver will	
to the server supports a reasonable Path Maximum Transmission Unit	 	    discard.  Similarly, a server MUST expand the payload of all UDP	
(PMTU).  This also helps reduce the amplitude of amplification	 	        datagrams carrying ack-eliciting Initial packets to at least the	
attacks caused by server responses toward an unverified client	 	        smallest allowed maximum datagram size of 1200 bytes.	
address; see Section 8.	 		
                                                                            Sending UDP datagrams of this size ensures that the network path	
                                                                            supports a reasonable Path Maximum Transmission Unit (PMTU), in both	
                                                                            directions.  Additionally, a client that expands Initial packets	
                                                                            helps reduce the amplitude of amplification attacks caused by server	
                                                                            responses toward an unverified client address; see Section 8.	
 		
Datagrams containing Initial packets MAY exceed 1200 bytes if the	 	    Datagrams containing Initial packets MAY exceed 1200 bytes if the	
client believes that the network path and peer both support the size	 	sender believes that the network path and peer both support the size	
that it chooses.	 	                                                    that it chooses.

16.  Variable-Length Integer Encoding

Error codes (Section 20) and versions (Section 15) are described	    	Values do not need to be encoded on the minimum number of bytes	
using integers, but do not use this encoding.	 	                        necessary, with the sole exception of the Frame Type field; see	
                                                                            Section 12.4.	
                                                                                
                                                                            Versions (Section 15), packet numbers sent in the header	
                                                                            (Section 17.1), and the length of connection IDs in long header	
                                                                            packets (Section 17.2) are described using integers but do not use	
                                                                            this encoding.

17.1.  Packet Number Encoding and Decoding

The sender MUST use a packet number size able to represent more than	 	Prior to receiving an acknowledgment for a packet number space, the	
twice as large a range than the difference between the largest	 	        full packet number MUST be included; it is not to be truncated, as	
acknowledged packet and packet number being sent.  A peer receiving	 	    described below.	
the packet will then correctly decode the packet number, unless the	 		
packet is delayed in transit such that it arrives after many higher-	 	After an acknowledgment is received for a packet number space, the	
numbered packets have been received.  An endpoint SHOULD use a large	 	sender MUST use a packet number size able to represent more than	
enough packet number encoding to allow the packet number to be	 	        twice as large a range as the difference between the largest	
recovered even if the packet arrives after packets that are sent	 	    acknowledged packet number and the packet number being sent.  A peer	
afterwards.	 	                                                            receiving the packet will then correctly decode the packet number,	
                                                                            unless the packet is delayed in transit such that it arrives after	
                                                                            many higher-numbered packets have been received.  An endpoint SHOULD	
                                                                            use a large enough packet number encoding to allow the packet number	
                                                                            to be recovered even if the packet arrives after packets that are	
                                                                            sent afterwards.	
// due to mvfst i think

17.2.  Long Header Packets

Fixed Bit:  The next bit (0x40) of byte 0 is set to 1.                      Packets	 Fixed Bit:  The next bit (0x40) of byte 0 is set to 1, unless the	
        containing a zero value for this bit are not valid packets in this	                packet is a Version Negotiation packet.  Packets containing a zero	
            version and MUST be discarded.	                                                value for this bit are not valid packets in this version and MUST	
                                                                                            be discarded.  A value of 1 for this bit allows QUIC to coexist	
                                                                                            with other protocols; see [RFC7983].

17.2.1.  Version Negotiation Packet

The remainder of the Version Negotiation packet is a list of 32-bit	 	    The remainder of the Version Negotiation packet is a list of 32-bit	
versions which the server supports.	 	                                    versions that the server supports.	
 		
A Version Negotiation packet cannot be explicitly acknowledged in an	 	A Version Negotiation packet is not acknowledged.  It is only sent in	
ACK frame by a client.  Receiving another Initial packet implicitly	 	    response to a packet that indicates an unsupported version; see	
acknowledges a Version Negotiation packet.	 	                            Section 5.2.2.

17.2.3.  0-RTT

After a client receives a Retry packet, 0-RTT packets are likely to	 	    After a client receives a Retry packet, 0-RTT packets are likely to	
have been lost or discarded by the server.  A client SHOULD attempt	 	    have been lost or discarded by the server.  A client SHOULD attempt	
to resend data in 0-RTT packets after it sends a new Initial packet.	 	to resend data in 0-RTT packets after it sends a new Initial packet.	
                                                       	 	                New packet numbers MUST be used for any new packets that are sent; as	
A client MUST NOT reset the packet number it uses for 0-RTT packets,	 	described in Section 17.2.5.3, reusing packet numbers could	
since the keys used to protect 0-RTT packets will not change as a	 	    compromise packet protection.	
result of responding to a Retry packet.  Sending packets with the	 		
same packet number in that case is likely to compromise the packet	 		
protection for all 0-RTT packets because the same key and nonce could	 		
be used to protect different content.	 		
 		
A client only receives acknowledgments for its 0-RTT packets once the	 	A client only receives acknowledgments for its 0-RTT packets once the	
handshake is complete.  Consequently, a server might expect 0-RTT	 	    handshake is complete, as defined in Section 4.1.1 of [QUIC-TLS].	
packets to start with a packet number of 0.  Therefore, in	 		
determining the length of the packet number encoding for 0-RTT	 		
packets, a client MUST assume that all packets up to the current	 		
packet number are in flight, starting from a packet number of 0.	 		
Thus, 0-RTT packets could need to use a longer packet number	 		
encoding.

17.2.4.  Handshake Packet

The payload of this packet contains CRYPTO frames and could contain	 	   The payload of this packet contains CRYPTO frames and could contain	
PING, PADDING, or ACK frames.  Handshake packets MAY contain	 	       PING, PADDING, or ACK frames.  Handshake packets MAY contain	
CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt	 	   CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt	
of Handshake packets with other frames as a connection error.	 	       of Handshake packets with other frames as a connection error of type	
 	                                                                       PROTOCOL_VIOLATION.

17.2.5.3.  Continuing a Handshake after Retry	
 		
The next Initial packet from the client uses the connection ID and	 	    Subsequent Initial packets from the client include the connection ID	
token values from the Retry packet; see Section 7.2.  Aside from	 	    and token values from the Retry packet.  The client copies the Source	
this, the Initial packet sent by the client is subject to the same	 	    Connection ID field from the Retry packet to the Destination	
                                                                            Connection ID field and uses this value until an Initial packet with	
                                                                            an updated value is received; see Section 7.2.  The value of the	
                                                                            Token field is copied to all subsequent Initial packets; see	
                                                                            Section 8.1.2.	
                                                                                
                                                                            Other than updating the Destination Connection ID and Token fields,	
                                                                            the Initial packet sent by the client is subject to the same	
restrictions as the first Initial packet.  A client MUST use the same	 	restrictions as the first Initial packet.  A client MUST use the same	
cryptographic handshake message it includes in this packet.  A server	 	cryptographic handshake message it included in this packet.  A server	
MAY treat a packet that contains a different cryptographic handshake	 	MAY treat a packet that contains a different cryptographic handshake	
message as a connection error or discard it.	 	                        message as a connection error or discard it.  Note that including a	
                                                                            Token field reduces the available space for the cryptographic	
                                                                            handshake message, which might result in the client needing to send	
                                                                            multiple Initial packets.	
 		
A client MAY attempt 0-RTT after receiving a Retry packet by sending	 	A client MAY attempt 0-RTT after receiving a Retry packet by sending	
0-RTT packets to the connection ID provided by the server.  A client	 	0-RTT packets to the connection ID provided by the server.	
MUST NOT change the cryptographic handshake message it sends in	 		
response to receiving a Retry.	 		
 		
A client MUST NOT reset the packet number for any packet number space	 	A client MUST NOT reset the packet number for any packet number space	
after processing a Retry packet; Section 17.2.3 contains more	 	        after processing a Retry packet.  In particular, 0-RTT packets	
information on this.	 	                                                contain confidential information that will most likely be	
 	                                                                        retransmitted on receiving a Retry packet.  The keys used to protect	
A server acknowledges the use of a Retry packet for a connection	 	    these new 0-RTT packets will not change as a result of responding to	
using the retry_source_connection_id transport parameter; see	 	        a Retry packet.  However, the data sent in these packets could be	
Section 18.2.  If the server sends a Retry packet, it also	 	            different than what was sent earlier.  Sending these new packets with	
subsequently includes the value of the Source Connection ID field	 	    the same packet number is likely to compromise the packet protection	
from the Retry packet in its retry_source_connection_id transport	 	    for those packets because the same key and nonce could be used to	
parameter.	 	                                                            protect different content.  A server MAY abort the connection if it	
 	                                                                        detects that the client reset the packet number.	
 		
If the client received and processed a Retry packet, it MUST validate	 	The connection IDs used in Initial and Retry packets exchanged	
that the retry_source_connection_id transport parameter is present	 	    between client and server are copied to the transport parameters and	
and correct; otherwise, it MUST validate that the transport parameter	 	validated as described in Section 7.3.	
is absent.  A client MUST treat a failed validation as a connection	 		
error of type PROTOCOL_VIOLATION.

19.7.  NEW_TOKEN Frames

An endpoint might receive multiple NEW_TOKEN frames that contain the	 	   A client might receive multiple NEW_TOKEN frames that contain the

19.8.  STREAM Frames

   *  The FIN bit (0x01) of the frame type is set only on frames that	 	   *  The FIN bit (0x01) indicates that the frame marks the end of the	
      contain the final size of the stream.  Setting this bit indicates	 	      stream.  The final size of the stream is the sum of the offset and	
      that the frame marks the end of the stream.	 	                         the length of this frame.

19.11.  MAX_STREAMS Frames	
 	
An endpoint MUST NOT open more streams than permitted by the current	 	    An endpoint MUST NOT open more streams than permitted by the current	
stream limit set by its peer.  For instance, a server that receives a	 	    stream limit set by its peer.  For instance, a server that receives a	
unidirectional stream limit of 3 is permitted to open stream 3, 7,	 	        unidirectional stream limit of 3 is permitted to open streams 3, 7,	
and 11, but not stream 15.  An endpoint MUST terminate a connection	 	        and 11, but not stream 15.  An endpoint MUST terminate a connection	
with a STREAM_LIMIT_ERROR error if a peer opens more streams than was	 	    with an error of type STREAM_LIMIT_ERROR if a peer opens more streams	
permitted.	 	                                                                than was permitted.  This includes violations of remembered limits in	
 	                                                                            Early Data; see Section 7.4.1.
20.1.  Transport Error Codes

CRYPTO_ERROR (0x1XX):  The cryptographic handshake failed.  A range	 	        KEY_UPDATE_ERROR (0x0e):  An endpoint detected errors in performing	
of 256 values is reserved for carrying error codes specific to the	 	        key updates; see Section 6 of [QUIC-TLS].	
cryptographic handshake that is used.  Codes for errors occurring	 		
when TLS is used for the crypto handshake are described in	 		
Section 4.8 of [QUIC-TLS].	 		
 		
See Section 22.4 for details of registering new error codes.	 	            AEAD_LIMIT_REACHED (0x0f):  An endpoint has reached the	
                                                                                confidentiality or integrity limit for the AEAD algorithm used by	
                                                                                the given connection.	
                                                                                    
                                                                                NO_VIABLE_PATH (0x10):  An endpoint has determined that the network	
                                                                                path is incapable of supporting QUIC.  An endpoint is unlikely to	
                                                                                receive a CONNECTION_CLOSE frame carrying this code except when	
                                                                                the path does not support a large enough MTU.	
                                                                                    
                                                                                CRYPTO_ERROR (0x0100-0x01ff):  The cryptographic handshake failed.  A	
                                                                                range of 256 values is reserved for carrying error codes specific	
                                                                                to the cryptographic handshake that is used.  Codes for errors	
                                                                                occurring when TLS is used for the cryptographic handshake are	
                                                                                described in Section 4.8 of [QUIC-TLS].

A.2.  Sample Packet Number Encoding Algorithm	
 		
The pseudocode in Figure 46 shows how an implementation can select an	
appropriate size for packet number encodings.	
 		
The EncodePacketNumber function takes two arguments:	
 		
*  full_pn is the full packet number of the packet being sent.	
 		
*  largest_acked is the largest packet number that has been	
   acknowledged by the peer in the current packet number space, if	
   any.	
 		
EncodePacketNumber(full_pn, largest_acked):	
 		
  // The number of bits must be at least one more	
  // than the base-2 logarithm of the number of contiguous	
  // unacknowledged packet numbers, including the new packet.	
  if largest_acked is None:	
    num_unacked = full_pn + 1	
  else:	
    num_unacked = full_pn - largest_acked	
 		
  min_bits = log(num_unacked, 2) + 1	
  num_bytes = ceil(min_bits / 8)	
 		
  // Encode the integer value and truncate to	
  // the num_bytes least significant bytes.	
  return encode(full_pn, num_bytes)	
 		
          Figure 46: Sample Packet Number Encoding Algorithm	
 		
For example, if an endpoint has received an acknowledgment for packet	
0xabe8b3 and is sending a packet with a number of 0xac5c02, there are	
29,519 (0x734f) outstanding packet numbers.  In order to represent at	
least twice this range (59,038 packets, or 0xe69e), 16 bits are	
required.	
 		
In the same state, sending a packet with a number of 0xace8fe uses	
the 24-bit encoding, because at least 18 bits are required to	
represent twice the range (131,222 packets, or 0x020096).