From 112e1f7aae4dd0b493e4fe55a318c5957fe6efc7 Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Thu, 8 Jun 2017 09:34:22 +0200 Subject: [PATCH 1/7] Adding description of the latency spin bit This is the result of the discussion of latency monitoring during the Paris interim meeting. --- draft-ietf-quic-transport.md | 49 ++++++++++++++++++++++++++++++------ 1 file changed, 42 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 34ca18eef4..12da8fa363 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -198,6 +198,8 @@ strengths of QUIC include: * Version negotiation +* Support for monitoring + ## Low-Latency Connection Establishment @@ -294,6 +296,15 @@ QUIC version negotiation allows for multiple versions of the protocol to be deployed and used concurrently. Version negotiation is described in {{version-negotiation}}. +## Support for Monitoring + +Network administrators often find difficult to monitor the behavior +of encrypted protocols. Bandwidth can be monitored by observing the +flow of encrypted packets, but the usal tools for monitoring +latency require observing packet numbers and acknowledgements, which +in QUIC are encrypted. +QUIC packets include a clear text latency spin bit that enables +monitoring of latency by observing packets in transit. # Versions {#versions} @@ -355,7 +366,7 @@ version negotiation and 1-RTT keys are established. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ -|1| Type (7) | +|1|S| Type (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID (64) + @@ -383,10 +394,15 @@ Header Form: : The most significant bit (0x80) of the first octet is set to 1 for long headers and 0 for short headers. +Latency Spin Bit: + +: The second most significant bit (0x40) of the first octet carries + the latency spin bit used for latency monitoring. + Long Packet Type: -: The remaining seven bits of first octet of a long packet is the packet type. - This field can indicate one of 128 packet types. The types specified for this +: The remaining six bits of first octet of a long packet is the packet type. + This field can indicate one of 64 packet types. The types specified for this version are listed in {{long-packet-types}}. Connection ID: @@ -443,7 +459,7 @@ following sections. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ -|0|C|K| Type (5)| +|0|S|C|K|Type(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + [Connection ID (64)] + @@ -464,21 +480,26 @@ Header Form: : The most significant bit (0x80) of the first octet of a packet is the header form. This bit is set to 0 for the short header. +Latency Spin Bit: + +: The second most significant bit (0x40) of the first octet carries + the latency spin bit used for latency monitoring. + Connection ID Flag: -: The second bit (0x40) of the first octet indicates whether the Connection ID +: The third bit (0x20) of the first octet indicates whether the Connection ID field is present. If set to 1, then the Connection ID field is present; if set to 0, the Connection ID field is omitted. Key Phase Bit: -: The third bit (0x20) of the first octet indicates the key phase, which allows +: The fourth bit (0x10) of the first octet indicates the key phase, which allows a recipient of a packet to identify the packet protection keys that are used to protect the packet. See {{QUIC-TLS}} for details. Short Packet Type: -: The remaining 5 bits of the first octet include one of 32 packet types. +: The remaining 4 bits of the first octet include one of 16 packet types. {{short-packet-types}} lists the types that are defined for short packets. Connection ID: @@ -827,6 +848,20 @@ Implementations MUST assume that an unsupported version uses an unknown packet format. All other fields MUST be ignored when processing a packet that contains an unsupported version. +## Latency Spin Bit + +The latency spin bit enables latency monitoring from observation points on +the network path. This bit is set as follow: + +* The connection responder sets the spin bit value to the value of the + spin bit in the last packet received from the connection initiator. + +* The connection initiator sets the spin bit value to the opposite + of the last value received from the connection responder, or to 0 + if no packet as been received yet. + +Observation points can estimate the network latency by monitoring the +changes in the latency spin bit. # Frames and Frame Types {#frames} From f57f7f4198b8f012b2cc05ca6189ccf3bd273067 Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Thu, 8 Jun 2017 09:40:43 +0200 Subject: [PATCH 2/7] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 12da8fa363..0d0550d47e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -198,7 +198,7 @@ strengths of QUIC include: * Version negotiation -* Support for monitoring +* Support for monitoring ## Low-Latency Connection Establishment From 18434c77ca9fda6fc0cd8d454147edb3cb854c44 Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Thu, 8 Jun 2017 10:09:37 +0200 Subject: [PATCH 3/7] Rename the section to "support latency monitoring" --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0d0550d47e..cc1920285c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -198,7 +198,7 @@ strengths of QUIC include: * Version negotiation -* Support for monitoring +* Support for latency monitoring ## Low-Latency Connection Establishment @@ -296,7 +296,7 @@ QUIC version negotiation allows for multiple versions of the protocol to be deployed and used concurrently. Version negotiation is described in {{version-negotiation}}. -## Support for Monitoring +## Support for Latency Monitoring Network administrators often find difficult to monitor the behavior of encrypted protocols. Bandwidth can be monitored by observing the From ab881a929395d315fca2c66ec363534efdf27a88 Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Thu, 8 Jun 2017 10:34:34 +0200 Subject: [PATCH 4/7] Adding reference to IPPM draft Adding a reference to draft-ietf-ippm-alt-mark, as Brian suggested in his review. --- draft-ietf-quic-transport.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cc1920285c..3558a390f7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -863,6 +863,10 @@ the network path. This bit is set as follow: Observation points can estimate the network latency by monitoring the changes in the latency spin bit. +The latency spin bit handling is similar to the +"Alternate Marking method for passive performance monitoring" +described in [@?I-D.draft-ietf-ippm-alt-mark]. + # Frames and Frame Types {#frames} The payload of cleartext packets and the plaintext after decryption of protected From 0afcbb994812c647ecc7e6ec8606e63eb493757c Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Mon, 12 Jun 2017 20:08:01 -0700 Subject: [PATCH 5/7] Editorial fixes Fixes suggested in Ian's review. --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3558a390f7..e532b392b6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -298,13 +298,13 @@ deployed and used concurrently. Version negotiation is described in ## Support for Latency Monitoring -Network administrators often find difficult to monitor the behavior +Network administrators have difficulties monitoring the behavior of encrypted protocols. Bandwidth can be monitored by observing the -flow of encrypted packets, but the usal tools for monitoring +flow of encrypted packets, but the usual tools for monitoring latency require observing packet numbers and acknowledgements, which in QUIC are encrypted. -QUIC packets include a clear text latency spin bit that enables -monitoring of latency by observing packets in transit. +QUIC packets enable monitoring of latency by including a clear text +latency spin bit that is reflected between peers. # Versions {#versions} From 981d9e2c7aa2b4d38710616f44174f552c313116 Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Sun, 18 Jun 2017 18:31:33 -0700 Subject: [PATCH 6/7] Changes suggested by Martin and Ian Replacing initiator/responder by client and server for consistency with the rest of the document. Adding some minimal explanation of the expected behavior. --- draft-ietf-quic-transport.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e532b392b6..ee3972d466 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -304,7 +304,7 @@ flow of encrypted packets, but the usual tools for monitoring latency require observing packet numbers and acknowledgements, which in QUIC are encrypted. QUIC packets enable monitoring of latency by including a clear text -latency spin bit that is reflected between peers. +latency spin bit that is reflected between client and server. # Versions {#versions} @@ -853,15 +853,19 @@ an unsupported version. The latency spin bit enables latency monitoring from observation points on the network path. This bit is set as follow: -* The connection responder sets the spin bit value to the value of the - spin bit in the last packet received from the connection initiator. +* The server sets the spin bit value to the value of the + spin bit in the last packet received from the client. -* The connection initiator sets the spin bit value to the opposite - of the last value received from the connection responder, or to 0 +* The client sets the spin bit value to the opposite + of the last value received from the server, or to 0 if no packet as been received yet. -Observation points can estimate the network latency by monitoring the +Observation points can estimate the network latency by monitoring these changes in the latency spin bit. +If packets are delivered in sequence, this procedure will cause the spin +bit to change value in each direction once per round trip. Out of +sequence deliveries can cause some spurious transitions, which +monitoring agents may have to filter. The latency spin bit handling is similar to the "Alternate Marking method for passive performance monitoring" From 47b685c7f071a10170b70a0dc816315353688bdb Mon Sep 17 00:00:00 2001 From: Christian Huitema Date: Mon, 26 Jun 2017 16:42:47 -0700 Subject: [PATCH 7/7] Largest sequence number The phrase is a bit clumsy, but this solves the issues of flipping the bit when packets are received out of order. --- draft-ietf-quic-transport.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ee3972d466..64effff224 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -854,10 +854,12 @@ The latency spin bit enables latency monitoring from observation points on the network path. This bit is set as follow: * The server sets the spin bit value to the value of the - spin bit in the last packet received from the client. + spin bit in the packet received from the client with + the largest sequence number. * The client sets the spin bit value to the opposite - of the last value received from the server, or to 0 + of the value set in the packet received from the server with the + largest sequence number, or to 0 if no packet as been received yet. Observation points can estimate the network latency by monitoring these