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. |