rfc9937v2.txt   rfc9937.txt 
skipping to change at line 472 skipping to change at line 472
SMSS for each preceding duplicate ACK. Note that without SACK, a SMSS for each preceding duplicate ACK. Note that without SACK, a
poorly behaved receiver that returns extraneous duplicate ACKs (as poorly behaved receiver that returns extraneous duplicate ACKs (as
described in [Savage99]) could attempt to artificially inflate described in [Savage99]) could attempt to artificially inflate
DeliveredData. As a mitigation, if not using SACK, then PRR DeliveredData. As a mitigation, if not using SACK, then PRR
disallows incrementing DeliveredData when the total bytes delivered disallows incrementing DeliveredData when the total bytes delivered
in a PRR episode would exceed the estimated data outstanding upon in a PRR episode would exceed the estimated data outstanding upon
entering recovery (RecoverFS). entering recovery (RecoverFS).
Next, the sender computes inflight, the data sender's best estimate Next, the sender computes inflight, the data sender's best estimate
of the number of bytes that are in flight in the network. To of the number of bytes that are in flight in the network. To
calculate inflight, connections with SACK enabled and using loss calculate inflight, connections with SACK enabled and using [RFC6675]
detection [RFC6675] MAY use the "pipe" algorithm as specified in loss detection MAY use the "pipe" algorithm as specified in
[RFC6675]. SACK-enabled connections using RACK-TLP loss detection [RFC6675]. SACK-enabled connections using RACK-TLP loss detection
[RFC8985] or other loss detection algorithms MUST calculate inflight [RFC8985] or other loss detection algorithms MUST calculate inflight
by starting with SND.NXT - SND.UNA, subtracting out bytes SACKed in by starting with SND.NXT - SND.UNA, subtracting out bytes SACKed in
the scoreboard, subtracting out bytes marked lost in the scoreboard, the scoreboard, subtracting out bytes marked lost in the scoreboard,
and adding bytes in the scoreboard that have been retransmitted since and adding bytes in the scoreboard that have been retransmitted since
they were last marked lost. For non-SACK-enabled connections, they were last marked lost. For non-SACK-enabled connections,
instead of subtracting out bytes SACKed in the SACK scoreboard, instead of subtracting out bytes SACKed in the SACK scoreboard,
senders MUST subtract out: min(RecoverFS, 1 SMSS for each preceding senders MUST subtract out: min(RecoverFS, 1 SMSS for each preceding
duplicate ACK in the fast recovery episode); the min() with RecoverFS duplicate ACK in the fast recovery episode); the min() with RecoverFS
is to protect against misbehaving receivers [Savage99]. is to protect against misbehaving receivers [Savage99].
skipping to change at line 495 skipping to change at line 495
Next, the sender computes SafeACK, a local boolean variable Next, the sender computes SafeACK, a local boolean variable
indicating that the current ACK reported good progress. SafeACK is indicating that the current ACK reported good progress. SafeACK is
true only when the ACK has cumulatively acknowledged new data and the true only when the ACK has cumulatively acknowledged new data and the
ACK does not indicate further losses. For example, an ACK triggering ACK does not indicate further losses. For example, an ACK triggering
"rescue" retransmission (Section 4 of [RFC6675], NextSeg() condition "rescue" retransmission (Section 4 of [RFC6675], NextSeg() condition
4) may indicate further losses. Both conditions indicate the 4) may indicate further losses. Both conditions indicate the
recovery is making good progress and the sender can send more recovery is making good progress and the sender can send more
aggressively, increasing inflight, if appropriate. aggressively, increasing inflight, if appropriate.
Finally, the sender uses DeliveredData, inflight, SafeACK, and other Finally, the sender uses DeliveredData, inflight, SafeACK, and other
PRR states to compute SndCnt, a local variable indicating exactly how PRR state to compute SndCnt, a local variable indicating exactly how
many bytes should be sent in response to each ACK and then uses many bytes should be sent in response to each ACK and then uses
SndCnt to update cwnd. SndCnt to update cwnd.
The full sequence of per-ACK PRR algorithm steps is as follows: The full sequence of per-ACK PRR algorithm steps is as follows:
if (DeliveredData is 0) if (DeliveredData is 0)
Return Return
prr_delivered += DeliveredData prr_delivered += DeliveredData
inflight = (estimated volume of in-flight data) inflight = (estimated volume of in-flight data)
skipping to change at line 731 skipping to change at line 731
s N N R R R s N N R R R
a: ack#; c: cwnd; i: inflight; s: sent a: ack#; c: cwnd; i: inflight; s: sent
Figure 2 Figure 2
In this specific situation, [RFC6675] is more aggressive because once In this specific situation, [RFC6675] is more aggressive because once
Fast Retransmit is triggered (on the ACK for segment 17), the sender Fast Retransmit is triggered (on the ACK for segment 17), the sender
immediately retransmits sufficient data to bring inflight up to cwnd. immediately retransmits sufficient data to bring inflight up to cwnd.
Earlier measurements (in Section 6 of [RFC6675]) indicate that Earlier measurements (in Section 6 of [RFC6675]) indicate that
[RFC6675] significantly outperforms PRR [RFC6937] using only PRR-CRB [RFC6675] significantly outperforms the [RFC6937] version of PRR
and some other similarly conservative algorithms that were tested, using only PRR-CRB and some other similarly conservative algorithms
showing that it is significantly common for the actual losses to that were tested, showing that it is significantly common for the
exceed the cwnd reduction determined by the congestion control actual losses to exceed the cwnd reduction determined by the
algorithm. congestion control algorithm.
Under such heavy losses, during the first round trip of fast Under such heavy losses, during the first round trip of fast
recovery, PRR uses the PRR-CRB to follow the packet conservation recovery, PRR uses the PRR-CRB to follow the packet conservation
principle. Since the total losses bring inflight below ssthresh, principle. Since the total losses bring inflight below ssthresh,
data is sent such that the total data transmitted, prr_out, follows data is sent such that the total data transmitted, prr_out, follows
the total data delivered to the receiver as reported by returning the total data delivered to the receiver as reported by returning
ACKs. Transmission is controlled by the sending limit, which is set ACKs. Transmission is controlled by the sending limit, which is set
to prr_delivered - prr_out. to prr_delivered - prr_out.
While not shown in the figure above, once the fast retransmits sent While not shown in the figure above, once the fast retransmits sent
skipping to change at line 801 skipping to change at line 801
require any changes at data receivers or in networks. This allows require any changes at data receivers or in networks. This allows
data senders using PRR to work correctly with any existing data data senders using PRR to work correctly with any existing data
receivers or networks. PRR does not require any changes to or receivers or networks. PRR does not require any changes to or
assistance from routers, switches, or other devices in the network. assistance from routers, switches, or other devices in the network.
11.2. Fairness 11.2. Fairness
PRR is designed to maintain the fairness properties of the congestion PRR is designed to maintain the fairness properties of the congestion
control algorithm with which it is deployed. PRR only operates control algorithm with which it is deployed. PRR only operates
during a congestion control response episode, such as fast recovery during a congestion control response episode, such as fast recovery
or response to ECN [RFC3168], and only makes short-term, per- or response to the [RFC3168] variant of ECN, and only makes short-
acknowledgment decisions to smoothly regulate the volume of in-flight term, per-acknowledgment decisions to smoothly regulate the volume of
data during an episode such that at the end of the episode it will be in-flight data during an episode such that at the end of the episode
as close as possible to the slow start threshold (ssthresh), as it will be as close as possible to the slow start threshold
determined by the congestion control algorithm. PRR does not modify (ssthresh), as determined by the congestion control algorithm. PRR
the congestion control cwnd increase or decrease mechanisms outside does not modify the congestion control cwnd increase or decrease
of congestion control response episodes. mechanisms outside of congestion control response episodes.
11.3. Protecting the Network Against Excessive Queuing and Packet Loss 11.3. Protecting the Network Against Excessive Queuing and Packet Loss
Over long time scales, PRR is designed to maintain the queuing and Over long time scales, PRR is designed to maintain the queuing and
packet loss properties of the congestion control algorithm with which packet loss properties of the congestion control algorithm with which
it is deployed. As noted above, PRR only operates during a it is deployed. As noted above, PRR only operates during a
congestion control response episode, such as fast recovery or congestion control response episode, such as fast recovery or
response to ECN, and only makes short-term, per-acknowledgment response to ECN, and only makes short-term, per-acknowledgment
decisions to smoothly regulate the volume of in-flight data during an decisions to smoothly regulate the volume of in-flight data during an
episode such that at the end of the episode it will be as close as episode such that at the end of the episode it will be as close as
 End of changes. 4 change blocks. 
15 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.48.