| rfc9506v1.txt | rfc9506.txt | |||
|---|---|---|---|---|
| skipping to change at line 102 ¶ | skipping to change at line 102 ¶ | |||
| 3.2.3. Identifying Q Block Boundaries | 3.2.3. Identifying Q Block Boundaries | |||
| 3.2.3.1. Improved Resilience to Burst Losses | 3.2.3.1. Improved Resilience to Burst Losses | |||
| 3.3. L Bit -- Loss Event Bit | 3.3. L Bit -- Loss Event Bit | |||
| 3.3.1. End-To-End Loss | 3.3.1. End-To-End Loss | |||
| 3.3.1.1. Loss Profile Characterization | 3.3.1.1. Loss Profile Characterization | |||
| 3.3.2. L+Q Bits -- Loss Measurement Using L and Q Bits | 3.3.2. L+Q Bits -- Loss Measurement Using L and Q Bits | |||
| 3.3.2.1. Correlating End-to-End and Upstream Loss | 3.3.2.1. Correlating End-to-End and Upstream Loss | |||
| 3.3.2.2. Downstream Loss | 3.3.2.2. Downstream Loss | |||
| 3.3.2.3. Observer Loss | 3.3.2.3. Observer Loss | |||
| 3.4. R Bit -- Reflection Square Bit | 3.4. R Bit -- Reflection Square Bit | |||
| 3.4.1. Enhancement of R Block Length Computation | 3.4.1. Enhancement of Reflection Block Length Computation | |||
| 3.4.2. Improved Resilience to Packet Reordering | 3.4.2. Improved Resilience to Packet Reordering | |||
| 3.4.2.1. Improved Resilience to Burst Losses | 3.4.2.1. Improved Resilience to Burst Losses | |||
| 3.4.3. R+Q Bits -- Loss Measurement Using R and Q Bits | 3.4.3. R+Q Bits -- Loss Measurement Using R and Q Bits | |||
| 3.4.3.1. Three-Quarters Connection Loss | 3.4.3.1. Three-Quarters Connection Loss | |||
| 3.4.3.2. End-To-End Loss in the Opposite Direction | 3.4.3.2. End-To-End Loss in the Opposite Direction | |||
| 3.4.3.3. Half Round-Trip Loss | 3.4.3.3. Half Round-Trip Loss | |||
| 3.4.3.4. Downstream Loss | 3.4.3.4. Downstream Loss | |||
| 3.5. E Bit -- ECN-Echo Event Bit | 3.5. E Bit -- ECN-Echo Event Bit | |||
| 3.5.1. Setting the ECN-Echo Event Bit on Outgoing Packets | 3.5.1. Setting the ECN-Echo Event Bit on Outgoing Packets | |||
| 3.5.2. Using E Bit for Passive ECN-Reported Congestion | 3.5.2. Using E Bit for Passive ECN-Reported Congestion | |||
| skipping to change at line 144 ¶ | skipping to change at line 144 ¶ | |||
| network operation. Proactively detecting, measuring, and locating | network operation. Proactively detecting, measuring, and locating | |||
| them is crucial to maintaining high QoS and timely resolution of end- | them is crucial to maintaining high QoS and timely resolution of end- | |||
| to-end throughput issues. | to-end throughput issues. | |||
| Detecting and measuring packet loss and delay allows network | Detecting and measuring packet loss and delay allows network | |||
| operators to independently confirm trouble reports and, ideally, be | operators to independently confirm trouble reports and, ideally, be | |||
| proactively notified of developing problems on the network. Locating | proactively notified of developing problems on the network. Locating | |||
| the cause of packet loss or excessive delay is the first step to | the cause of packet loss or excessive delay is the first step to | |||
| resolving problems and restoring QoS. | resolving problems and restoring QoS. | |||
| Traditionally, network operators wishing to perform quantitative | Network operators wishing to perform quantitative measurement of | |||
| measurement of packet loss and delay have been heavily relying on | packet loss and delay have been heavily relying on information | |||
| information present in the clear in transport-layer headers (e.g., | present in the clear in transport-layer headers (e.g., TCP sequence | |||
| TCP sequence and acknowledgment numbers). By passively observing a | and acknowledgment numbers). By passively observing a network path | |||
| network path at multiple points within one's network, operators have | at multiple points within one's network, operators have been able to | |||
| been able to either quickly locate the source the problem within | either quickly locate the source the problem within their network or | |||
| their network or reliably attribute it to an upstream or downstream | reliably attribute it to an upstream or downstream network. | |||
| network. | ||||
| With encrypted protocols, the transport-layer headers are encrypted | With encrypted protocols, the transport-layer headers are encrypted | |||
| and passive packet loss and delay observations are not possible, as | and passive packet loss and delay observations are not possible, as | |||
| also noted in [TRANSPORT-ENCRYPT]. Nevertheless, accurate | also noted in [TRANSPORT-ENCRYPT]. Nevertheless, accurate | |||
| measurement of packet loss and delay experienced by encrypted | measurement of packet loss and delay experienced by encrypted | |||
| transport-layer protocols is highly desired, especially by network | transport-layer protocols is highly desired, especially by network | |||
| operators who own or control the infrastructure between the client | operators who own or control the infrastructure between the client | |||
| and server. | and server. | |||
| The measurement of loss and delay experienced by connections using an | The measurement of loss and delay experienced by connections using an | |||
| skipping to change at line 256 ¶ | skipping to change at line 255 ¶ | |||
| [QUIC-MANAGEABILITY]. | [QUIC-MANAGEABILITY]. | |||
| The Spin bit is a signal generated by Alternate-Marking [AltMark], | The Spin bit is a signal generated by Alternate-Marking [AltMark], | |||
| where the size of the alternation changes with the flight size each | where the size of the alternation changes with the flight size each | |||
| RTT. | RTT. | |||
| The latency Spin bit is a single-bit signal that toggles once per | The latency Spin bit is a single-bit signal that toggles once per | |||
| RTT, enabling latency monitoring of a connection-oriented | RTT, enabling latency monitoring of a connection-oriented | |||
| communication from intermediate observation points. | communication from intermediate observation points. | |||
| A "spin period" is a set of packets with the same Spin bit value sent | A "Spin bit period" is a set of packets with the same Spin bit value | |||
| during one RTT time interval. A "spin period value" is the value of | sent during one RTT time interval. A "Spin bit period value" is the | |||
| the Spin bit shared by all packets in a spin period. | value of the Spin bit shared by all packets in a Spin bit period. | |||
| The client and server maintain an internal per-connection spin value | The client and server maintain an internal per-connection spin value | |||
| (i.e., 0 or 1) used to set the Spin bit on outgoing packets. Both | (i.e., 0 or 1) used to set the Spin bit on outgoing packets. Both | |||
| endpoints initialize the spin value to 0 when a new connection | endpoints initialize the spin value to 0 when a new connection | |||
| starts. Then: | starts. Then: | |||
| * when the client receives a packet with the packet number larger | * when the client receives a packet with the packet number larger | |||
| than any number seen so far, it sets the connection spin value to | than any number seen so far, it sets the connection spin value to | |||
| the opposite value contained in the received packet; and | the opposite value contained in the received packet; and | |||
| skipping to change at line 295 ¶ | skipping to change at line 294 ¶ | |||
| as network impairments arise as explained in Section 2.2. | as network impairments arise as explained in Section 2.2. | |||
| 2.2. Delay Bit | 2.2. Delay Bit | |||
| The Delay bit has been designed to overcome accuracy limitations | The Delay bit has been designed to overcome accuracy limitations | |||
| experienced by the Spin bit under difficult network conditions: | experienced by the Spin bit under difficult network conditions: | |||
| * packet reordering leads to generation of spurious edges and errors | * packet reordering leads to generation of spurious edges and errors | |||
| in delay estimation; | in delay estimation; | |||
| * loss of edges causes wrong estimation of spin periods and | * loss of edges causes wrong estimation of Spin bit periods and | |||
| therefore wrong RTT measurements; and | therefore wrong RTT measurements; and | |||
| * application-limited senders cause the Spin bit to measure the | * application-limited senders cause the Spin bit to measure the | |||
| application delays instead of network delays. | application delays instead of network delays. | |||
| Unlike the Spin bit, which is set in every packet transmitted on the | Unlike the Spin bit, which is set in every packet transmitted on the | |||
| network, the Delay bit is set only once per round trip. | network, the Delay bit is set only once per round trip. | |||
| When the Delay bit is used, a single packet with a marked bit (the | When the Delay bit is used, a single packet with a marked bit (the | |||
| Delay bit) bounces between a client and a server during the entire | Delay bit) bounces between a client and a server during the entire | |||
| skipping to change at line 367 ¶ | skipping to change at line 366 ¶ | |||
| | | <----------- | | | | | <----------- | | | |||
| +--------+ 0 0 0 1 0 +--------+ | +--------+ 0 0 0 1 0 +--------+ | |||
| (e) The Server reflects the delay sample | (e) The Server reflects the delay sample | |||
| and so on. | and so on. | |||
| Figure 1: Delay Bit Mechanism | Figure 1: Delay Bit Mechanism | |||
| 2.2.1. Generation Phase | 2.2.1. Generation Phase | |||
| Only the client is actively involved in the generation phase. It | Only the client is actively involved in the Generation Phase. It | |||
| maintains an internal per-flow timestamp variable (ds_time) updated | maintains an internal per-flow timestamp variable (ds_time) updated | |||
| every time a delay sample is transmitted. | every time a delay sample is transmitted. | |||
| When connection starts, the client generates a new delay sample | When connection starts, the client generates a new delay sample | |||
| initializing the Delay bit of the first outgoing packet to 1. Then | initializing the Delay bit of the first outgoing packet to 1. Then | |||
| it updates the ds_time variable with the timestamp of its | it updates the ds_time variable with the timestamp of its | |||
| transmission. | transmission. | |||
| The server initializes the Delay bit to 0 at the beginning of the | The server initializes the Delay bit to 0 at the beginning of the | |||
| connection, and its only task during the connection is described in | connection, and its only task during the connection is described in | |||
| skipping to change at line 576 ¶ | skipping to change at line 575 ¶ | |||
| subtraction of the above RTT components | subtraction of the above RTT components | |||
| Figure 4: Intra-domain Round-Trip Time (Client-Observer: Upstream) | Figure 4: Intra-domain Round-Trip Time (Client-Observer: Upstream) | |||
| 2.2.5. Observer's Algorithm | 2.2.5. Observer's Algorithm | |||
| An on-path observer maintains an internal per-flow variable to keep | An on-path observer maintains an internal per-flow variable to keep | |||
| track of the time at which the last delay sample has been observed. | track of the time at which the last delay sample has been observed. | |||
| The flow characterization should be part of the protocol. | The flow characterization should be part of the protocol. | |||
| A unidirectional observer or in case of asymmetric routing, upon | If the observer is unidirectional or in case of asymmetric routing, | |||
| detecting a delay sample: | then upon detecting a delay sample: | |||
| * if a delay sample was also detected previously in the same | * if a delay sample was also detected previously in the same | |||
| direction and the distance in time between them is less than T_Max | direction and the distance in time between them is less than T_Max | |||
| - K, then the two delay samples can be used to calculate RTT | - K, then the two delay samples can be used to calculate RTT | |||
| measurement. K is a protection threshold to absorb differences in | measurement. K is a protection threshold to absorb differences in | |||
| T_Max computation and delay variations between two consecutive | T_Max computation and delay variations between two consecutive | |||
| delay samples (e.g., K = 10% T_Max). | delay samples (e.g., K = 10% T_Max). | |||
| If the observer can observe both forward and return traffic flows, | If the observer can observe both forward and return traffic flows, | |||
| and it is able to determine which direction contains the client and | and it is able to determine which direction contains the client and | |||
| skipping to change at line 623 ¶ | skipping to change at line 622 ¶ | |||
| 3. Loss Bits | 3. Loss Bits | |||
| This section introduces bits that can be used for loss measurements. | This section introduces bits that can be used for loss measurements. | |||
| Whenever this section of the specification refers to packets, it is | Whenever this section of the specification refers to packets, it is | |||
| referring only to packets with protocol headers that include the loss | referring only to packets with protocol headers that include the loss | |||
| bits -- the only packets whose loss can be measured. | bits -- the only packets whose loss can be measured. | |||
| T: The "round-Trip loss" bit is used in combination with the Spin | T: The "round-Trip loss" bit is used in combination with the Spin | |||
| bit to measure round-trip loss. See Section 3.1. | bit to measure round-trip loss. See Section 3.1. | |||
| Q: The "sQuare signal" bit is used to measure upstream loss. See | Q: The "sQuare" bit is used to measure upstream loss. See | |||
| Section 3.2. | Section 3.2. | |||
| L: The "Loss event" bit is used to measure end-to-end loss. See | L: The "Loss Event" bit is used to measure end-to-end loss. See | |||
| Section 3.3. | Section 3.3. | |||
| R: The "Reflection square signal" bit is used in combination with | R: The "Reflection square" bit is used in combination with the Q bit | |||
| the Q bit to measure end-to-end loss. See Section 3.4. | to measure end-to-end loss. See Section 3.4. | |||
| Loss measurements enabled by T, Q, and L bits can be implemented by | Loss measurements enabled by T, Q, and L bits can be implemented by | |||
| those loss bits alone (T bit requires a working Spin bit). Two-bit | those loss bits alone (T bit requires a working Spin bit). Two-bit | |||
| combinations Q+L and Q+R enable additional measurement opportunities | combinations Q+L and Q+R enable additional measurement opportunities | |||
| discussed below. | discussed below. | |||
| Each endpoint maintains appropriate counters independently and | Each endpoint maintains appropriate counters independently and | |||
| separately for each separately identifiable flow (each sub-flow for | separately for each identifiable flow (or each sub-flow for multipath | |||
| multipath connections). | connections). | |||
| Since loss is reported independently for each flow, all bits (except | Since loss is reported independently for each flow, all bits (except | |||
| for the L bit) require a certain minimum number of packets to be | for the L bit) require a certain minimum number of packets to be | |||
| exchanged per flow before any signal can be measured. Therefore, | exchanged per flow before any signal can be measured. Therefore, | |||
| loss measurements work best for flows that transfer more than a | loss measurements work best for flows that transfer more than a | |||
| minimal amount of data. | minimal amount of data. | |||
| 3.1. T Bit -- Round-Trip Loss Bit | 3.1. T Bit -- Round-Trip Loss Bit | |||
| The round-Trip loss bit is used to mark a variable number of packets | The round-Trip loss bit is used to mark a variable number of packets | |||
| exchanged twice between the endpoints realizing a two round-trip | exchanged twice between the endpoints realizing a two round-trip | |||
| reflection. A passive on-path observer, observing either direction, | reflection. A passive on-path observer, observing either direction, | |||
| can count and compare the number of marked packets seen during the | can count and compare the number of marked packets seen during the | |||
| two reflections, estimating the loss rate experienced by the | two reflections, estimating the loss rate experienced by the | |||
| connection. The overall exchange comprises: | connection. The overall exchange comprises: | |||
| * the client selects and consequently sets the T bit to 1 in order | * the client selects and consequently sets the T bit to 1 in order | |||
| to identify a first train of packets; | to identify a first train of packets; | |||
| * the server, upon receiving each packet included in the first | * upon receiving each packet included in the first train, the server | |||
| train, reflects to the client a respective second train of packets | sets the T bit to 1 and reflects to the client a respective second | |||
| of the same size as the first train received, by setting the T bit | train of packets of the same size as the first train received; | |||
| to 1; | ||||
| * the client, upon receiving each packet included in the second | * upon receiving each packet included in the second train, the | |||
| train, reflects to the server a respective third train of packets | client sets the T bit to 1 and reflects to the server a respective | |||
| of the same size as the second train received, by setting the T | third train of packets of the same size as the second train | |||
| bit to 1; and | received; and | |||
| * the server, upon receiving each packet included in the third | * upon receiving each packet included in the third train, the server | |||
| train, finally reflects to the client a respective fourth train of | sets the T bit to 1 and finally reflects to the client a | |||
| packets of the same size as the third train received, by setting | respective fourth train of packets of the same size as the third | |||
| the T bit to 1. | train received. | |||
| Packets belonging to the first round trip (first and second train) | Packets belonging to the first round trip (first and second train) | |||
| represent the Generation Phase, while those belonging to the second | represent the Generation Phase, while those belonging to the second | |||
| round trip (third and fourth train) represent the Reflection Phase. | round trip (third and fourth train) represent the Reflection Phase. | |||
| A passive on-path observer can count and compare the number of marked | A passive on-path observer can count and compare the number of marked | |||
| packets seen during the two round trips (i.e., the first and third or | packets seen during the two round trips (i.e., the first and third or | |||
| the second and the fourth trains of packets, depending on which | the second and the fourth trains of packets, depending on which | |||
| direction is observed) and estimate the loss rate experienced by the | direction is observed) and estimate the loss rate experienced by the | |||
| connection. This process is repeated continuously to obtain more | connection. This process is repeated continuously to obtain more | |||
| skipping to change at line 763 ¶ | skipping to change at line 761 ¶ | |||
| (b) the intra-domain RTPL resulting from the | (b) the intra-domain RTPL resulting from the | |||
| subtraction of the above RTPL components | subtraction of the above RTPL components | |||
| Figure 7: Intra-domain Round-Trip Packet Loss (Observer-Server) | Figure 7: Intra-domain Round-Trip Packet Loss (Observer-Server) | |||
| 3.1.2. Setting the Round-Trip Loss Bit on Outgoing Packets | 3.1.2. Setting the Round-Trip Loss Bit on Outgoing Packets | |||
| The round-Trip loss signal requires a working Spin bit signal to | The round-Trip loss signal requires a working Spin bit signal to | |||
| separate trains of marked packets (packets with T bit set to 1). A | separate trains of marked packets (packets with T bit set to 1). A | |||
| "pause" of at least one empty spin-bit period between each phase of | "pause" of at least one empty Spin bit period between each phase of | |||
| the algorithm serves as such a separator for the on-path observer. | the algorithm serves as such a separator for the on-path observer. | |||
| The connection between T bit and Spin bit helps the correlations on | The connection between T bit and Spin bit helps the observer | |||
| the observer. | correlate packet trains. | |||
| The client maintains a "generation token" count that is set to zero | The client maintains a "generation token" count that is set to zero | |||
| at the beginning of the session and is incremented every time a | at the beginning of the session and is incremented every time a | |||
| packet is received (marked or unmarked). The client also maintains a | packet is received (marked or unmarked). The client also maintains a | |||
| "reflection counter" that starts at zero at the beginning of the | "reflection counter" that starts at zero at the beginning of the | |||
| session. | session. | |||
| The client is in charge of launching trains of marked packets and | The client is in charge of launching trains of marked packets and | |||
| does so according to the algorithm: | does so according to the algorithm: | |||
| 1. Generation Phase. The client starts generating marked packets | 1. Generation Phase. The client starts generating marked packets | |||
| for two consecutive spin-bit periods. When the client transmits | for two consecutive Spin bit periods. When the client transmits | |||
| a packet and a "generation token" is available, the client marks | a packet and a "generation token" is available, the client marks | |||
| the packet and retires a "generation token". If no token is | the packet and retires a "generation token". If no token is | |||
| available, the outgoing packet is transmitted unmarked. At the | available, the outgoing packet is transmitted unmarked. At the | |||
| end of the first spin-bit period spent in generation, the | end of the first Spin bit period spent in generation, the | |||
| reflection counter is unlocked to start counting incoming marked | reflection counter is unlocked to start counting incoming marked | |||
| packets that will be reflected later. | packets that will be reflected later. | |||
| 2. Pause Phase. When the generation is completed, the client pauses | 2. Pause Phase. When the generation is completed, the client pauses | |||
| till it has observed one entire Spin bit period with no marked | till it has observed one entire Spin bit period with no marked | |||
| packets. That Spin bit period is used by the observer as a | packets. That Spin bit period is used by the observer as a | |||
| separator between generated and reflected packets. During this | separator between generated and reflected packets. During this | |||
| marking pause, all the outgoing packets are transmitted with T | marking pause, all the outgoing packets are transmitted with T | |||
| bit set to 0. The reflection counter is still incremented every | bit set to 0. The reflection counter is still incremented every | |||
| time a marked packet arrives. | time a marked packet arrives. | |||
| 3. Reflection Phase. The client starts transmitting marked packets, | 3. Reflection Phase. The client starts transmitting marked packets, | |||
| decrementing the reflection counter for each transmitted marked | decrementing the reflection counter for each transmitted marked | |||
| packet until the reflection counter has reached zero. The | packet until the reflection counter has reached zero. The | |||
| "generation token" method from the generation phase is used | "generation token" method from the Generation Phase is used | |||
| during this phase as well. At the end of the first spin period | during this phase as well. At the end of the first Spin bit | |||
| spent in reflection, the reflection counter is locked to avoid | period spent in reflection, the reflection counter is locked to | |||
| incoming reflected packets incrementing it. | avoid incoming reflected packets incrementing it. | |||
| 4. Pause Phase 2. The pause phase is repeated after the reflection | 4. Pause Phase 2. The Pause Phase is repeated after the Reflection | |||
| phase and serves as a separator between the reflected packet | Phase and serves as a separator between the reflected packet | |||
| train and a new packet train. | train and a new packet train. | |||
| The generation token counter should be capped to limit the effects of | The generation token counter should be capped to limit the effects of | |||
| a subsequent sudden reduction in the other endpoint's packet rate | a subsequent sudden reduction in the other endpoint's packet rate | |||
| that could prevent that endpoint from reflecting collected packets. | that could prevent that endpoint from reflecting collected packets. | |||
| A cap value of 1 is recommended. | A cap value of 1 is recommended. | |||
| A server maintains a "marking counter" that starts at zero and is | A server maintains a "marking counter" that starts at zero and is | |||
| incremented every time a marked packet arrives. When the server | incremented every time a marked packet arrives. When the server | |||
| transmits a packet and the "marking counter" is positive, the server | transmits a packet and the "marking counter" is positive, the server | |||
| marks the packet and decrements the "marking counter". If the | marks the packet and decrements the "marking counter". If the | |||
| "marking counter" is zero, the outgoing packet is transmitted | "marking counter" is zero, the outgoing packet is transmitted | |||
| unmarked. | unmarked. | |||
| Note that a choice of 2-RTT (two spin periods) for the generation | Note that a choice of 2 RTT (two Spin bit periods) for the Generation | |||
| phase is a trade-off between the percentage of marked packets (i.e., | Phase is a trade-off between the percentage of marked packets (i.e., | |||
| the percentage of traffic monitored) and the measurement delay. | the percentage of traffic monitored) and the measurement delay. | |||
| Using this value, the algorithm produces a measurement approximately | Using this value, the algorithm produces a measurement approximately | |||
| every 6-RTT (2 generations, ~2 reflections, 2 pauses), marking ~1/3 | every 6 RTT (2 generations, ~2 reflections, 2 pauses), marking ~1/3 | |||
| of packets exchanged in the slower direction (see Section 3.1.4). | of packets exchanged in the slower direction (see Section 3.1.4). | |||
| Choosing a generation phase of 1-RTT, we would produce measurements | Choosing a Generation Phase of 1 RTT, we would produce measurements | |||
| every 4-RTT, monitoring just ~1/4 of packets in the slower direction. | every 4 RTT, monitoring ~1/4 of packets in the slower direction. | |||
| It is worth mentioning that problems can happen in some cases, | It is worth mentioning that problems can happen in some cases, | |||
| especially if the rate suddenly changes, but the mechanism described | especially if the rate suddenly changes, but the mechanism described | |||
| here worked well with normal traffic conditions in the | here worked well with normal traffic conditions in the | |||
| implementation. | implementation. | |||
| 3.1.3. Observer's Logic for Round-Trip Loss Signal | 3.1.3. Observer's Logic for Round-Trip Loss Signal | |||
| The on-path observer counts marked packets and separates different | The on-path observer counts marked packets and separates different | |||
| trains by detecting spin-bit periods (at least one) with no marked | trains by detecting Spin bit periods (at least one) with no marked | |||
| packets. The Round-Trip Packet Loss (RTPL) is the difference between | packets. The Round-Trip Packet Loss (RTPL) is the difference between | |||
| the size of the Generation train and the Reflection train. | the size of the Generation train and the Reflection train. | |||
| In the following example, packets are represented by two bits (first | In the following example, packets are represented by two bits (first | |||
| one is the Spin bit, second one is the round-Trip loss bit): | one is the Spin bit, second one is the round-Trip loss bit): | |||
| Generation Pause Reflection Pause | Generation Pause Reflection Pause | |||
| ____________________ ______________ ____________________ ________ | ____________________ ______________ ____________________ ________ | |||
| | | | | | | | | | | | | |||
| 01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10 | 01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10 | |||
| Figure 8: Round-Trip Loss Signal Example | Figure 8: Round-Trip Loss Signal Example | |||
| Note that 5 marked packets have been generated, of which 4 have been | Note that 5 marked packets have been generated, of which 4 have been | |||
| reflected. | reflected. | |||
| 3.1.4. Loss Coverage and Signal Timing | 3.1.4. Loss Coverage and Signal Timing | |||
| A cycle of the round-Trip loss signaling algorithm contains 2 RTTs of | A cycle of the round-Trip loss signaling algorithm contains 2 RTTs of | |||
| Generation phase, 2 RTTs of Reflection phase, and 2 Pause phases at | Generation phase, 2 RTTs of Reflection Phase, and 2 Pause Phases at | |||
| least 1 RTT in duration each. Hence, the loss signal is delayed by | least 1 RTT in duration each. Hence, the loss signal is delayed by | |||
| about 6 RTTs since the loss events. | about 6 RTTs since the loss events. | |||
| The observer can only detect the loss of marked packets that occurs | The observer can only detect the loss of marked packets that occurs | |||
| after its initial observation of the Generation phase and before its | after its initial observation of the Generation Phase and before its | |||
| subsequent observation of the Reflection phase. Hence, if the loss | subsequent observation of the Reflection Phase. Hence, if the loss | |||
| occurs on the path that sends packets at a lower rate (typically ACKs | occurs on the path that sends packets at a lower rate (typically ACKs | |||
| in such asymmetric scenarios), 2/6 (1/3) of the packets will be | in such asymmetric scenarios), 2/6 (1/3) of the packets will be | |||
| sampled for loss detection. | sampled for loss detection. | |||
| If the loss occurs on the path that sends packets at a higher rate, | If the loss occurs on the path that sends packets at a higher rate, | |||
| lowPacketRate/(3*highPacketRate) of the packets will be sampled for | lowPacketRate/(3*highPacketRate) of the packets will be sampled for | |||
| loss detection. For protocols that use ACKs, the portion of packets | loss detection. For protocols that use ACKs, the portion of packets | |||
| sampled for loss in the higher rate direction during unidirectional | sampled for loss in the higher rate direction during unidirectional | |||
| data transfer is 1/(3*packetsPerAck), where the value of | data transfer is 1/(3*packetsPerAck), where the value of | |||
| packetsPerAck can vary by protocol, by implementation, and by network | packetsPerAck can vary by protocol, by implementation, and by network | |||
| conditions. | conditions. | |||
| 3.2. Q Bit -- sQuare Bit | 3.2. Q Bit -- sQuare Bit | |||
| The sQuare bit (Q bit) takes its name from the square wave generated | The sQuare bit (Q bit) takes its name from the square wave generated | |||
| by its signal. This method is based on the Alternate-Marking method | by its signal. This method is based on the Alternate-Marking method | |||
| [AltMark], and the Q bit represents the "packet color" that allows to | [AltMark], and the Q bit represents the "packet color" that can be | |||
| mark consecutive blocks of packets with different colors. This | switched between 0 and 1 in order to mark consecutive blocks of | |||
| method does not require cooperation from both endpoints. | packets with different colors. This method does not require | |||
| cooperation from both endpoints. | ||||
| [AltMark] introduces two variations of the Alternate-Marking method | [AltMark] introduces two variations of the Alternate-Marking method | |||
| depending on whether the color is switched according to a fixed timer | depending on whether the color is switched according to a fixed timer | |||
| or after a fixed number of packets. The method based on a fixed | or after a fixed number of packets. Cooperating and synchronized | |||
| timer can measure packet loss on a network segment by cooperating and | observers on either end of a network segment can use the fixed-timer | |||
| synchronized observers on both ends of the segment comparing packets | method to measure packet loss on the segment by comparing packet | |||
| counters for the same packet blocks. The time length of the blocks | counters for the same packet blocks. The time length of the blocks | |||
| can be chosen depending on the desired measurement frequency, but it | can be chosen depending on the desired measurement frequency, but it | |||
| must be long enough to guarantee the proper operation with respect to | must be long enough to guarantee the proper operation with respect to | |||
| clock errors and network delay issues. | clock errors and network delay issues. | |||
| The Q bit method described in this document chooses the color- | The Q bit method described in this document chooses the color- | |||
| switching method based on a fixed number of packets for each block. | switching method based on a fixed number of packets for each block. | |||
| This approach has the advantage that it does not require cooperating | This approach has the advantage that it does not require cooperating | |||
| or synchronized observers or network elements. Each probe can | or synchronized observers or network elements. Each probe can | |||
| measure packet loss autonomously without relying on an external NMS. | measure packet loss autonomously without relying on an external NMS. | |||
| skipping to change at line 1029 ¶ | skipping to change at line 1028 ¶ | |||
| The value of the Unreported Loss counter is incremented for every | The value of the Unreported Loss counter is incremented for every | |||
| packet that the protocol declares lost, using whatever loss detection | packet that the protocol declares lost, using whatever loss detection | |||
| machinery the protocol employs. If the protocol is able to rescind | machinery the protocol employs. If the protocol is able to rescind | |||
| the loss determination later, a positive Unreported Loss counter may | the loss determination later, a positive Unreported Loss counter may | |||
| be decremented due to the rescission. In general, it should not | be decremented due to the rescission. In general, it should not | |||
| become negative due to the rescission, but it can happen in few | become negative due to the rescission, but it can happen in few | |||
| cases. | cases. | |||
| This loss signaling is similar to loss signaling in [ConEx], except | This loss signaling is similar to loss signaling in [ConEx], except | |||
| the Loss Event bit is reporting the exact number of lost packets, | that the Loss Event bit is reporting the exact number of lost | |||
| whereas Echo Loss bit in [ConEx] is reporting an approximate number | packets, whereas the signal mechanism in in [ConEx] is reporting an | |||
| of lost bytes. | approximate number of lost bytes. | |||
| For protocols, such as TCP [TCP], that allow network devices to | For protocols, such as TCP [TCP], that allow network devices to | |||
| change data segmentation, it is possible that only a part of the | change data segmentation, it is possible that only a part of the | |||
| packet is lost. In these cases, the sender must increment the | packet is lost. In these cases, the sender must increment the | |||
| Unreported Loss counter by the fraction of the packet data lost (so | Unreported Loss counter by the fraction of the packet data lost (so | |||
| the Unreported Loss counter may become negative when a packet with | the Unreported Loss counter may become negative when a packet with | |||
| L=1 is sent after a partial packet has been lost). | L=1 is sent after a partial packet has been lost). | |||
| Observation points can estimate the end-to-end loss, as determined by | Observation points can estimate the end-to-end loss, as determined by | |||
| the upstream endpoint, by counting packets in this direction with the | the upstream endpoint, by counting packets in this direction with the | |||
| skipping to change at line 1098 ¶ | skipping to change at line 1097 ¶ | |||
| duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) | duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) | |||
| relative to the upstream loss. | relative to the upstream loss. | |||
| The flow RTT can sometimes be estimated by timing the protocol | The flow RTT can sometimes be estimated by timing the protocol | |||
| handshake messages. This RTT estimate can be greatly improved by | handshake messages. This RTT estimate can be greatly improved by | |||
| observing a dedicated protocol mechanism for conveying RTT | observing a dedicated protocol mechanism for conveying RTT | |||
| information, such as the Spin bit (see Section 2.1) or Delay bit (see | information, such as the Spin bit (see Section 2.1) or Delay bit (see | |||
| Section 2.2). | Section 2.2). | |||
| Whenever the observer needs to perform a computation that uses both | Whenever the observer needs to perform a computation that uses both | |||
| upstream and end-to-end loss rate measurements, it should use | upstream and end-to-end loss rate measurements, it should consider | |||
| upstream loss rate leading the end-to-end loss rate by approximately | the upstream loss rate leading the end-to-end loss rate by | |||
| 1 RTT. If the observer is unable to estimate RTT of the flow, it | approximately 1 RTT. If the observer is unable to estimate RTT of | |||
| should accumulate loss measurements over time periods of at least 4 | the flow, it should accumulate loss measurements over time periods of | |||
| times the typical RTT for the observed flows. | at least 4 times the typical RTT for the observed flows. | |||
| If the calculated upstream loss rate exceeds the end-to-end loss rate | If the calculated upstream loss rate exceeds the end-to-end loss rate | |||
| calculated in Section 3.3.1, then either the Q Period is too short | calculated in Section 3.3.1, then either the Q Period is too short | |||
| for the amount of packet reordering or there is observer loss, | for the amount of packet reordering or there is observer loss, | |||
| described in Section 3.3.2.3. If this happens, the observer should | described in Section 3.3.2.3. If this happens, the observer should | |||
| adjust the calculated upstream loss rate to match end-to-end loss | adjust the calculated upstream loss rate to match end-to-end loss | |||
| rate, unless the following applies. | rate, unless the following applies. | |||
| In case of a protocol, such as TCP or SCTP, that does not track | In case of a protocol, such as TCP or SCTP, that does not track | |||
| losses of pure ACK packets, observing a direction of traffic | losses of pure ACK packets, observing a direction of traffic | |||
| skipping to change at line 1156 ¶ | skipping to change at line 1155 ¶ | |||
| adjustment and the entirety of the upstream loss measured in | adjustment and the entirety of the upstream loss measured in | |||
| Section 3.2.2. Alternatively, a high apparent upstream loss rate | Section 3.2.2. Alternatively, a high apparent upstream loss rate | |||
| could be an indication of significant packet reordering, possibly due | could be an indication of significant packet reordering, possibly due | |||
| to packets belonging to a single flow being multiplexed over several | to packets belonging to a single flow being multiplexed over several | |||
| upstream paths with different latency characteristics. | upstream paths with different latency characteristics. | |||
| 3.4. R Bit -- Reflection Square Bit | 3.4. R Bit -- Reflection Square Bit | |||
| R bit requires a deployment alongside Q bit. Unlike the square | R bit requires a deployment alongside Q bit. Unlike the square | |||
| signal for which packets are transmitted in blocks of fixed size, the | signal for which packets are transmitted in blocks of fixed size, the | |||
| number of packets in Reflection square signal blocks (also an | number of packets in Reflection square blocks (also an Alternate- | |||
| Alternate-Marking signal) varies according to these rules: | Marking signal) varies according to these rules: | |||
| * when the transmission of a new block starts, its size is set equal | * when the transmission of a new block starts, its size is set equal | |||
| to the size of the last Q Block whose reception has been | to the size of the last Q Block whose reception has been | |||
| completed; and | completed; and | |||
| * if the reception of at least one further Q Block is completed | * if the reception of at least one further Q Block is completed | |||
| before transmission of the block is terminated, the size of the | before transmission of the block is terminated, the size of the | |||
| block is updated to be the average size of the further received Q | block is updated to be the average size of the further received Q | |||
| Blocks. | Blocks. | |||
| The Reflection square value is initialized to 0 and is applied to the | The Reflection square value is initialized to 0 and is applied to the | |||
| R bit of every outgoing packet. The Reflection square value is | R bit of every outgoing packet. The Reflection square value is | |||
| toggled for the first time when the completion of a Q Block is | toggled for the first time when the completion of a Q Block is | |||
| detected in the incoming square signal (produced by the other | detected in the incoming square signal (produced by the other | |||
| endpoint using the Q bit). The number of packets detected within | endpoint using the Q bit). The number of packets detected within | |||
| this first Q Block (p), is used to generate a reflection square | this first Q Block (p), is used to generate a reflection square | |||
| signal that toggles every M=p packets (at first). This new signal | signal that toggles every M=p packets (at first). This new signal | |||
| produces blocks of M packets (marked using the R bit) and each of | produces blocks of M packets (marked using the R bit) and each of | |||
| them is called "Reflection Block" (R Block). | them is called "Reflection Block" (Reflection Block). | |||
| The M value is then updated every time a completed Q Block in the | The M value is then updated every time a completed Q Block in the | |||
| incoming square signal is received, following this formula: | incoming square signal is received, following this formula: | |||
| M=round(avg(p)). | M=round(avg(p)). | |||
| The parameter avg(p), the average number of packets in a marking | The parameter avg(p), the average number of packets in a marking | |||
| period, is computed based on all the Q Blocks received since the | period, is computed based on all the Q Blocks received since the | |||
| beginning of the current R Block. | beginning of the current Reflection Block. | |||
| The transmission of an R Block is considered complete (and the signal | The transmission of an Reflection Block is considered complete (and | |||
| toggled) when the number of packets transmitted in that block is at | the signal toggled) when the number of packets transmitted in that | |||
| least the latest computed M value. | block is at least the latest computed M value. | |||
| To ensure a proper computation of the M value, endpoints implementing | To ensure a proper computation of the M value, endpoints implementing | |||
| the R bit must identify the boundaries of incoming Q Blocks. The | the R bit must identify the boundaries of incoming Q Blocks. The | |||
| same approach described in Section 3.2.3 should be used. | same approach described in Section 3.2.3 should be used. | |||
| By looking at the R bit, unidirectional observation points have an | By looking at the R bit, unidirectional observation points have an | |||
| indication of loss experienced by the entire unobserved channel plus | indication of loss experienced by the entire unobserved channel plus | |||
| the loss on the path from the sender to them. | the loss on the path from the sender to them. | |||
| Since the Q Block is sent in one direction, and the corresponding | Since the Q Block is sent in one direction, and the corresponding | |||
| reflected R Block is sent in the opposite direction, the reflected R | reflected R Block is sent in the opposite direction, the reflected R | |||
| signal is transmitted with the packet rate of the slowest direction. | signal is transmitted with the packet rate of the slowest direction. | |||
| Namely, if the observed direction is the slowest, there can be | Namely, if the observed direction is the slowest, there can be | |||
| multiple Q Blocks transmitted in the unobserved direction before a | multiple Q Blocks transmitted in the unobserved direction before a | |||
| complete R Block is transmitted in the observed direction. If the | complete Reflection Block is transmitted in the observed direction. | |||
| unobserved direction is the slowest, the observed direction can be | If the unobserved direction is the slowest, the observed direction | |||
| sending R Blocks of the same size repeatedly before it can update the | can be sending R Blocks of the same size repeatedly before it can | |||
| signal to account for a newly completed Q Block. | update the signal to account for a newly completed Q Block. | |||
| 3.4.1. Enhancement of R Block Length Computation | 3.4.1. Enhancement of Reflection Block Length Computation | |||
| The use of the rounding function used in the M computation introduces | The use of the rounding function used in the M computation introduces | |||
| errors that can be minimized by storing the rounding applied each | errors that can be minimized by storing the rounding applied each | |||
| time M is computed and using it during the computation of the M value | time M is computed and using it during the computation of the M value | |||
| in the following R Block. | in the following Reflection Block. | |||
| This can be achieved by introducing the new r_avg parameter in the | This can be achieved by introducing the new r_avg parameter in the | |||
| computation of M. The new formula is Mr=avg(p)+r_avg; M=round(Mr); | computation of M. The new formula is Mr=avg(p)+r_avg; M=round(Mr); | |||
| r_avg=Mr-M where the initial value of r_avg is equal to 0. | r_avg=Mr-M where the initial value of r_avg is equal to 0. | |||
| 3.4.2. Improved Resilience to Packet Reordering | 3.4.2. Improved Resilience to Packet Reordering | |||
| When a protocol implementing the marking mechanism is able to detect | When a protocol implementing the marking mechanism is able to detect | |||
| when packets are received out of order, it can improve resilience to | when packets are received out of order, it can improve resilience to | |||
| packet reordering beyond what is possible by using methods described | packet reordering beyond what is possible by using methods described | |||
| in Section 3.2.3. | in Section 3.2.3. | |||
| This can be achieved by updating the size of the current R Block | This can be achieved by updating the size of the current Reflection | |||
| while it is being transmitted. The reflection block size is then | Block while it is being transmitted. The Reflection Block size is | |||
| updated every time an incoming reordered packet of the previous Q | then updated every time an incoming reordered packet of the previous | |||
| Block is detected. This can be done if and only if the transmission | Q Block is detected. This can be done if and only if the | |||
| of the current reflection block is in progress and no packets of the | transmission of the current Reflection Block is in progress and no | |||
| following Q Block have been received. | packets of the following Q Block have been received. | |||
| 3.4.2.1. Improved Resilience to Burst Losses | 3.4.2.1. Improved Resilience to Burst Losses | |||
| Burst losses can affect the accuracy of R measurements similar to how | Burst losses can affect the accuracy of R measurements similar to how | |||
| they affect accuracy of Q measurements. Therefore, recommendations | they affect accuracy of Q measurements. Therefore, recommendations | |||
| in Section 3.2.3.1 apply equally to improving burst loss resilience | in Section 3.2.3.1 apply equally to improving burst loss resilience | |||
| for R measurements. | for R measurements. | |||
| 3.4.3. R+Q Bits -- Loss Measurement Using R and Q Bits | 3.4.3. R+Q Bits -- Loss Measurement Using R and Q Bits | |||
| skipping to change at line 1507 ¶ | skipping to change at line 1506 ¶ | |||
| | Q: sQuare | 1 | Upstream | x2 | * |Rate over |N pkts| | | Q: sQuare | 1 | Upstream | x2 | * |Rate over |N pkts| | |||
| | Bit | | | | |N pkts |(e.g.,| | | Bit | | | | |N pkts |(e.g.,| | |||
| | | | | | |(e.g., |64) | | | | | | | |(e.g., |64) | | |||
| | | | | | |64) | | | | | | | | |64) | | | |||
| +------------+----+------------+-------------+----+----------+------+ | +------------+----+------------+-------------+----+----------+------+ | |||
| | L: Loss | 1 | E2E | x2 | # |Loss |Min: | | | L: Loss | 1 | E2E | x2 | # |Loss |Min: | | |||
| | Event Bit | | | | |shape |RTT, | | | Event Bit | | | | |shape |RTT, | | |||
| | | | | | |(and |Max: | | | | | | | |(and |Max: | | |||
| | | | | | |rate) |RTO | | | | | | | |rate) |RTO | | |||
| +------------+----+------------+-------------+----+----------+------+ | +------------+----+------------+-------------+----+----------+------+ | |||
| | QL: sQuare | 2 | Upstream | x2 | # |-> see Q |see Q | | | QL: sQuare | 2 | Upstream | x2 | # |see Q |see Q | | |||
| | + Loss Ev. | +------------+-------------+----+----------+------+ | | + Loss Ev. | +------------+-------------+----+----------+------+ | |||
| | Bits | | Downstream | x2 | # |-> see |see L | | | Bits | | Downstream | x2 | # |see Q|L |see L | | |||
| | | | | | |Q|L | | | ||||
| | | +------------+-------------+----+----------+------+ | | | +------------+-------------+----+----------+------+ | |||
| | | | E2E | x2 | # |-> see L |see L | | | | | E2E | x2 | # |see L |see L | | |||
| +------------+----+------------+-------------+----+----------+------+ | +------------+----+------------+-------------+----+----------+------+ | |||
| | QR: sQuare | 2 | Upstream | x2 | * |Rate over |see Q | | | QR: sQuare | 2 | Upstream | x2 | * |Rate over |see Q | | |||
| | + Ref. Sq. | +------------+-------------+----+N*ppa +------+ | | + Ref. Sq. | +------------+-------------+----+N*ppa +------+ | |||
| | Bits | | 3/4 RT | x2 | * |pkts (see |N*ppa | | | Bits | | 3/4 RT | x2 | * |pkts (see |N*ppa | | |||
| | | +------------+-------------+----+Q bit for |pk | | | | +------------+-------------+----+Q bit for |pkts | | |||
| | | | !E2E | E2E, | * |N) |(see Q| | | | | !E2E | E2E, | * |N) |(see Q| | |||
| | | | | Downstream, | | |bit | | | | | | Downstream, | | |bit | | |||
| | | | | Half RT | | |for N)| | | | | | Half RT | | |for N)| | |||
| +------------+----+------------+-------------+----+----------+------+ | +------------+----+------------+-------------+----+----------+------+ | |||
| Table 2: Loss Comparison | Table 2: Loss Comparison | |||
| * All protocols | * All protocols | |||
| # Protocols employing loss detection (with or without pure ACK | # Protocols employing loss detection (with or without pure ACK | |||
| skipping to change at line 1626 ¶ | skipping to change at line 1624 ¶ | |||
| In the absence of packet loss, Q and R bits signals do not provide | In the absence of packet loss, Q and R bits signals do not provide | |||
| any information that cannot be observed by simply counting packets | any information that cannot be observed by simply counting packets | |||
| transiting a network path. In the presence of packet loss, Q and R | transiting a network path. In the presence of packet loss, Q and R | |||
| bits will disclose the loss, but this is information about the | bits will disclose the loss, but this is information about the | |||
| environment and not the endpoint state. The L bit signal discloses | environment and not the endpoint state. The L bit signal discloses | |||
| internal state of the protocol's loss-detection machinery, but this | internal state of the protocol's loss-detection machinery, but this | |||
| state can often be gleaned by timing packets and observing the | state can often be gleaned by timing packets and observing the | |||
| congestion controller response. | congestion controller response. | |||
| The measurements described in this document do not imply new packets | The measurements described in this document do not imply that new | |||
| injected into the network causing potential harm to the network | packets injected into the network can cause potential harm to the | |||
| itself and to data traffic. The measurements could be harmed by an | network itself and to data traffic. The measurements could be harmed | |||
| attacker altering the marking of the packets or injecting artificial | by an attacker altering the marking of the packets or injecting | |||
| traffic. Authentication techniques may be used where appropriate to | artificial traffic. Authentication techniques may be used where | |||
| guard against these traffic attacks. | appropriate to guard against these traffic attacks. | |||
| Hence, loss bits do not provide a viable new mechanism to attack data | Hence, loss bits do not provide a viable new mechanism to attack data | |||
| integrity and secrecy. | integrity and secrecy. | |||
| The measurement fields introduced in this document are intended to be | The measurement fields introduced in this document are intended to be | |||
| included in the packets. However, it is worth mentioning that it may | included in the packets. However, it is worth mentioning that it may | |||
| be possible to use this information as a covert channel. | be possible to use this information as a covert channel. | |||
| This document does not define a specific application, and the | This document does not define a specific application, and the | |||
| described techniques can generally apply to different communication | described techniques can generally apply to different communication | |||
| skipping to change at line 1670 ¶ | skipping to change at line 1668 ¶ | |||
| least an entire Q Block of packets, which renders the attack | least an entire Q Block of packets, which renders the attack | |||
| ineffective against a delay-sensitive congestion controller. | ineffective against a delay-sensitive congestion controller. | |||
| A protocol that is more susceptible to an optimistic ACK attack with | A protocol that is more susceptible to an optimistic ACK attack with | |||
| the loss signal provided by the Q bit and that uses a loss-based | the loss signal provided by the Q bit and that uses a loss-based | |||
| congestion controller should shorten the current Q Block by the | congestion controller should shorten the current Q Block by the | |||
| number of skipped packets numbers. For example, skipping a single | number of skipped packets numbers. For example, skipping a single | |||
| packet number will invert the square signal one outgoing packet | packet number will invert the square signal one outgoing packet | |||
| sooner. | sooner. | |||
| Similar considerations apply to the R bit, although a shortened R | Similar considerations apply to the R bit, although a shortened | |||
| Block along with a matching skip in packet numbers does not | Reflection Block along with a matching skip in packet numbers does | |||
| necessarily imply a lost packet, since it could be due to a lost | not necessarily imply a lost packet, since it could be due to a lost | |||
| packet on the reverse path along with a deliberately skipped packet | packet on the reverse path along with a deliberately skipped packet | |||
| by the sender. | by the sender. | |||
| 7.2. Delay Bit with RTT Obfuscation | 7.2. Delay Bit with RTT Obfuscation | |||
| Theoretically, delay measurements can be used to roughly evaluate the | Theoretically, delay measurements can be used to roughly evaluate the | |||
| distance of the client from the server (using the RTT) or from any | distance of the client from the server (using the RTT) or from any | |||
| intermediate observer (using the client-observer half-RTT). As | intermediate observer (using the client-observer half-RTT). As | |||
| described in [RTT-PRIVACY], connection RTT measurements for | described in [RTT-PRIVACY], connection RTT measurements for | |||
| geolocating endpoints are usually inferior to even the most basic IP | geolocating endpoints are usually inferior to even the most basic IP | |||
| End of changes. 43 change blocks. | ||||
| 101 lines changed or deleted | 99 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||