rfc9937v1.txt   rfc9937.txt 
Internet Engineering Task Force (IETF) M. Mathis Internet Engineering Task Force (IETF) M. Mathis
Request for Comments: 9937 Request for Comments: 9937
Obsoletes: 6937 N. Cardwell Obsoletes: 6937 N. Cardwell
Category: Standards Track Y. Cheng Category: Standards Track Y. Cheng
ISSN: 2070-1721 N. Dukkipati ISSN: 2070-1721 N. Dukkipati
Google, Inc. Google, Inc.
November 2025 December 2025
Proportional Rate Reduction Proportional Rate Reduction (PRR)
Abstract Abstract
This document specifies a Standards Track version of the Proportional This document specifies a Standards Track version of the Proportional
Rate Reduction (PRR) algorithm that obsoletes the Experimental Rate Reduction (PRR) algorithm that obsoletes the Experimental
version described in RFC 6937. PRR regulates the amount of data sent version described in RFC 6937. PRR regulates the amount of data sent
by TCP or other transport protocols during fast recovery. PRR by TCP or other transport protocols during fast recovery. PRR
accurately regulates the actual flight size through recovery such accurately regulates the actual flight size through recovery such
that at the end of recovery it will be as close as possible to the that at the end of recovery it will be as close as possible to the
slow start threshold (ssthresh), as determined by the congestion slow start threshold (ssthresh), as determined by the congestion
skipping to change at line 143 skipping to change at line 143
When inflight is above ssthresh, PRR reduces inflight smoothly toward When inflight is above ssthresh, PRR reduces inflight smoothly toward
ssthresh by clocking out transmissions at a rate that is in ssthresh by clocking out transmissions at a rate that is in
proportion to both the delivered data and ssthresh. proportion to both the delivered data and ssthresh.
When inflight is less than ssthresh, PRR adaptively chooses between When inflight is less than ssthresh, PRR adaptively chooses between
one of two Reduction Bounds to limit the total window reduction due one of two Reduction Bounds to limit the total window reduction due
to all mechanisms, including transient application stalls and the to all mechanisms, including transient application stalls and the
losses themselves. As a baseline, to be cautious when there may be losses themselves. As a baseline, to be cautious when there may be
considerable congestion, PRR uses its Conservative Reduction Bound considerable congestion, PRR uses its Conservative Reduction Bound
(PRR-CRB), which is strictly packet conserving. When recovery seems (CRB), which is strictly packet conserving. When recovery seems to
to be progressing well, PRR uses its Slow Start Reduction Bound (PRR- be progressing well, PRR uses its Slow Start Reduction Bound (SSRB),
SSRB), which is more aggressive than PRR-CRB by at most one segment which is more aggressive than PRR-CRB by at most one segment per ACK.
per ACK. PRR-CRB meets the Strong Packet Conservation Bound PRR-CRB meets the Strong Packet Conservation Bound described in
described in Appendix A; however, when used in real networks as the Appendix A; however, when used in real networks as the sole approach,
sole approach, it does not perform as well as the algorithm described it does not perform as well as the algorithm described in [RFC6675],
in [RFC6675], which proves to be more aggressive in a significant which proves to be more aggressive in a significant number of cases.
number of cases. PRR-SSRB offers a compromise by allowing a PRR-SSRB offers a compromise by allowing a connection to send one
connection to send one additional segment per ACK, relative to PRR- additional segment per ACK, relative to PRR-CRB, in some situations.
CRB, in some situations. Although PRR-SSRB is less aggressive than Although PRR-SSRB is less aggressive than [RFC6675] (transmitting
[RFC6675] (transmitting fewer segments or taking more time to fewer segments or taking more time to transmit them), it outperforms
transmit them), it outperforms due to the lower probability of due to the lower probability of additional losses during recovery.
additional losses during recovery.
The original definition of the packet conservation principle The original definition of the packet conservation principle
[Jacobson88] treated packets that are presumed to be lost (e.g., [Jacobson88] treated packets that are presumed to be lost (e.g.,
marked as candidates for retransmission) as having left the network. marked as candidates for retransmission) as having left the network.
This idea is reflected in the inflight estimator used by PRR, but it This idea is reflected in the inflight estimator used by PRR, but it
is distinct from the Strong Packet Conservation Bound as described in is distinct from the Strong Packet Conservation Bound as described in
Appendix A, which is defined solely on the basis of data arriving at Appendix A, which is defined solely on the basis of data arriving at
the receiver. the receiver.
This document specifies several main changes from the earlier version This document specifies several main changes from the earlier version
skipping to change at line 353 skipping to change at line 352
well below ssthresh, leading to bad performance. The performance well below ssthresh, leading to bad performance. The performance
could, in some cases, be worse than [RFC6675] recovery, which simply could, in some cases, be worse than [RFC6675] recovery, which simply
sets cwnd to ssthresh at the start of recovery. This behavior of sets cwnd to ssthresh at the start of recovery. This behavior of
setting cwnd to ssthresh at the end of recovery has been implemented setting cwnd to ssthresh at the end of recovery has been implemented
since the first widely deployed TCP PRR implementation in 2011 since the first widely deployed TCP PRR implementation in 2011
[First_TCP_PRR] and is similar to [RFC6675], which specifies setting [First_TCP_PRR] and is similar to [RFC6675], which specifies setting
cwnd to ssthresh at the start of recovery. cwnd to ssthresh at the start of recovery.
Since [RFC6937] was written, PRR has also been adapted to perform Since [RFC6937] was written, PRR has also been adapted to perform
multiplicative window reduction for non-loss-based congestion control multiplicative window reduction for non-loss-based congestion control
algorithms, such as for [RFC3168] style Explicit Congestion algorithms, such as for Explicit Congestion Notification (ECN) as
Notification (ECN). This can be done by using some parts of the loss described in [RFC3168]. This can be done by using some parts of the
recovery state machine (in particular, the RecoveryPoint from loss recovery state machine (in particular, the RecoveryPoint from
[RFC6675]) to invoke the PRR ACK processing for exactly one round [RFC6675]) to invoke the PRR ACK processing for exactly one round
trip worth of ACKs. However, note that using PRR for cwnd reductions trip worth of ACKs. However, note that using PRR for cwnd reductions
for ECN [RFC3168] has been observed, with some approaches to Active for the [RFC3168] variant of ECN has been observed, with some
Queue Management (AQM), to cause an excess cwnd reduction during ECN- approaches to Active Queue Management (AQM), to cause an excess cwnd
triggered congestion episodes, as noted in [VCC]. reduction during ECN-triggered congestion episodes, as noted in
[VCC].
5. Relationships to Other Standards 5. Relationships to Other Standards
PRR MAY be used in conjunction with any congestion control algorithm PRR MAY be used in conjunction with any congestion control algorithm
that intends to make a multiplicative decrease in its sending rate that intends to make a multiplicative decrease in its sending rate
over approximately the time scale of one round-trip time, as long as over approximately the time scale of one round-trip time, as long as
the current volume of in-flight data is limited by a congestion the current volume of in-flight data is limited by a congestion
window (cwnd) and the target volume of in-flight data during that window (cwnd) and the target volume of in-flight data during that
reduction is a fixed value given by ssthresh. In particular, PRR is reduction is a fixed value given by ssthresh. In particular, PRR is
applicable to both Reno [RFC5681] and CUBIC [RFC9438] congestion applicable to both Reno [RFC5681] and CUBIC [RFC9438] congestion
skipping to change at line 456 skipping to change at line 456
6.2. Per-ACK Steps 6.2. Per-ACK Steps
On every ACK starting or during fast recovery, excluding the ACK that On every ACK starting or during fast recovery, excluding the ACK that
concludes a PRR episode, PRR executes the following steps. concludes a PRR episode, PRR executes the following steps.
First, the sender computes DeliveredData, the data sender's best First, the sender computes DeliveredData, the data sender's best
estimate of the total number of bytes that the current ACK indicates estimate of the total number of bytes that the current ACK indicates
have been delivered to the receiver since the previously received have been delivered to the receiver since the previously received
ACK. With SACK, DeliveredData can be computed precisely as the ACK. With SACK, DeliveredData can be computed precisely as the
change in SND.UNA, plus the (signed) change in SACK. Thus, in the change in SND.UNA, plus the signed change in quantity of data marked
special case when there are no SACKed sequence ranges in the SACKed in the scoreboard. Thus, in the special case when there are
scoreboard before or after the ACK, DeliveredData is the change in no SACKed sequence ranges in the scoreboard before or after the ACK,
SND.UNA. In recovery without SACK, DeliveredData is estimated to be DeliveredData is the change in SND.UNA. In recovery without SACK,
1 SMSS on receiving a duplicate ACK, and on a subsequent partial or DeliveredData is estimated to be 1 SMSS on each received duplicate
full ACK DeliveredData is the change in SND.UNA, minus 1 SMSS for ACK (i.e., SND.UNA did not change). When SND.UNA advances (i.e., a
each preceding duplicate ACK. Note that without SACK, a poorly full or partial ACK), DeliveredData is the change in SND.UNA, minus 1
behaved receiver that returns extraneous duplicate ACKs (as described SMSS for each preceding duplicate ACK. Note that without SACK, a
in [Savage99]) could attempt to artificially inflate DeliveredData. poorly behaved receiver that returns extraneous duplicate ACKs (as
As a mitigation, if not using SACK, then PRR disallows incrementing described in [Savage99]) could attempt to artificially inflate
DeliveredData when the total bytes delivered in a PRR episode would DeliveredData. As a mitigation, if not using SACK, then PRR
exceed the estimated data outstanding upon entering recovery disallows incrementing DeliveredData when the total bytes delivered
(RecoverFS). in a PRR episode would exceed the estimated data outstanding upon
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 496
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)
SafeACK = (SND.UNA advances and no further loss indicated) SafeACK = (SND.UNA advances and no further loss indicated)
skipping to change at line 650 skipping to change at line 651
Although the Strong Packet Conservation Bound is very appealing for a Although the Strong Packet Conservation Bound is very appealing for a
number of reasons, earlier measurements (in Section 6 of [RFC6675]) number of reasons, earlier measurements (in Section 6 of [RFC6675])
demonstrate that it is less aggressive and does not perform as well demonstrate that it is less aggressive and does not perform as well
as [RFC6675], which permits bursts of data when there are bursts of as [RFC6675], which permits bursts of data when there are bursts of
losses. PRR-SSRB is a compromise that permits a sender to send one losses. PRR-SSRB is a compromise that permits a sender to send one
extra segment per ACK as compared to the Packet Conserving Bound when extra segment per ACK as compared to the Packet Conserving Bound when
the ACK indicates the recovery is in good progress without further the ACK indicates the recovery is in good progress without further
losses. From the perspective of a strict Packet Conserving Bound, losses. From the perspective of a strict Packet Conserving Bound,
PRR-SSRB does indeed open the window during recovery; however, it is PRR-SSRB does indeed open the window during recovery; however, it is
significantly less aggressive than [RFC6675] in the presence of burst significantly less aggressive than [RFC6675] in the presence of burst
losses. The [RFC6675] "half window of silence" may temporarily losses.
reduce queue pressure when congestion control does not reduce the
congestion window entering recovery to avoid further losses. The
goal of PRR is to minimize the opportunities to lose the self clock
by smoothly controlling inflight toward the target set by the
congestion control. It is the congestion control's responsibility to
avoid a full queue, not PRR.
8. Examples 8. Examples
This section illustrates the PRR and [RFC6675] algorithm by showing This section illustrates the PRR and [RFC6675] algorithms by showing
their different behaviors for two example scenarios: a connection their different behaviors for two example scenarios: a connection
experiencing either a single loss or a burst of 15 consecutive experiencing either a single loss or a burst of 15 consecutive
losses. All cases use bulk data transfers (no application pauses), losses. All cases use bulk data transfers (no application pauses),
Reno congestion control [RFC5681], and cwnd = FlightSize = inflight = Reno congestion control [RFC5681], and cwnd = FlightSize = inflight =
20 segments, so ssthresh will be set to 10 at the beginning of 20 segments, so ssthresh will be set to 10 at the beginning of
recovery. The scenarios use standard Fast Retransmit [RFC5681] and recovery. The scenarios use standard Fast Retransmit [RFC5681] and
Limited Transmit [RFC3042], so the sender will send two new segments Limited Transmit [RFC3042], so the sender will send two new segments
followed by one retransmit in response to the first three duplicate followed by one retransmit in response to the first three duplicate
ACKs following the losses. ACKs following the losses.
skipping to change at line 737 skipping to change at line 732
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 807 skipping to change at line 802
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
skipping to change at line 918 skipping to change at line 913
<https://www.rfc-editor.org/info/rfc9293>. <https://www.rfc-editor.org/info/rfc9293>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed., [RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438, "CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023, DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>. <https://www.rfc-editor.org/info/rfc9438>.
14.2. Informative References 14.2. Informative References
[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment: [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment:
Refining TCP Congestion Control", ACM SIGCOMM Computer Refining TCP Congestion Control", SIGCOMM '96: Conference
Communication Review, vol. 26, no. 4, pp. 281-291, Proceedings on Applications, Technologies, Architectures,
DOI 10.1145/248157.248181, August 1996, and Protocols for Computer Communications, pp. 281-291,
<https://dl.acm.org/doi/pdf/10.1145/248157.248181>. DOI 10.1145/248156.248181, August 1996,
<https://dl.acm.org/doi/10.1145/248156.248181>.
[First_TCP_PRR] [First_TCP_PRR]
"Proportional Rate Reduction for TCP.", commit "Proportional Rate Reduction for TCP.", commit
a262f0cdf1f2916ea918dc329492abb5323d9a6c, August 2011, a262f0cdf1f2916ea918dc329492abb5323d9a6c, August 2011,
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/ linux.git/
commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>. commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>.
[Flach2016policing] [Flach2016policing]
Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng, Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng,
skipping to change at line 943 skipping to change at line 939
Internet-Wide Analysis of Traffic Policing", SIGCOMM '16: Internet-Wide Analysis of Traffic Policing", SIGCOMM '16:
Proceedings of the 2016 ACM SIGCOMM Conference, pp. Proceedings of the 2016 ACM SIGCOMM Conference, pp.
468-482, DOI 10.1145/2934872.2934873, August 2016, 468-482, DOI 10.1145/2934872.2934873, August 2016,
<https://doi.org/10.1145/2934872.2934873>. <https://doi.org/10.1145/2934872.2934873>.
[Hoe96Startup] [Hoe96Startup]
Hoe, J., "Improving the Start-up Behavior of a Congestion Hoe, J., "Improving the Start-up Behavior of a Congestion
Control Scheme for TCP", SIGCOMM '96: Conference Control Scheme for TCP", SIGCOMM '96: Conference
Proceedings on Applications, Technologies, Architectures, Proceedings on Applications, Technologies, Architectures,
and Protocols for Computer Communications, pp. 270-280, and Protocols for Computer Communications, pp. 270-280,
DOI 10.1145/248157.248180, August 1996, DOI 10.1145/248156.248180, August 1996,
<https://doi.org/10.1145/248157.248180>. <https://doi.org/10.1145/248156.248180>.
[IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi, [IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi,
"Proportional Rate Reduction for TCP", IMC '11: "Proportional Rate Reduction for TCP", IMC '11:
Proceedings of the 2011 ACM SIGCOMM Conference on Internet Proceedings of the 2011 ACM SIGCOMM Conference on Internet
Measurement Conference, pp. 155-170, Measurement Conference, pp. 155-170,
DOI 10.1145/2068816.2068832, November 2011, DOI 10.1145/2068816.2068832, November 2011,
<https://doi.org/10.1145/2068816.2068832>. <https://doi.org/10.1145/2068816.2068832>.
[Jacobson88] [Jacobson88]
Jacobson, V., "Congestion Avoidance and Control", Jacobson, V., "Congestion Avoidance and Control",
skipping to change at line 1081 skipping to change at line 1077
Monia Ghobadi and Sivasankar Radhakrishnan helped analyze the Monia Ghobadi and Sivasankar Radhakrishnan helped analyze the
experiments. Ilpo Jarvinen reviewed the initial implementation. experiments. Ilpo Jarvinen reviewed the initial implementation.
Mark Allman, Richard Scheffenegger, Markku Kojo, Mirja Kuehlewind, Mark Allman, Richard Scheffenegger, Markku Kojo, Mirja Kuehlewind,
Gorry Fairhurst, Russ Housley, Paul Aitken, Daniele Ceccarelli, and Gorry Fairhurst, Russ Housley, Paul Aitken, Daniele Ceccarelli, and
Mohamed Boucadair improved the document through their insightful Mohamed Boucadair improved the document through their insightful
reviews and suggestions. reviews and suggestions.
Authors' Addresses Authors' Addresses
Matt Mathis Matt Mathis
Email: ietf@mattmathis.net Email: matt.mathis@gmail.com
Neal Cardwell Neal Cardwell
Google, Inc. Google, Inc.
Email: ncardwell@google.com Email: ncardwell@google.com
Yuchung Cheng Yuchung Cheng
Google, Inc. Google, Inc.
Email: ycheng@google.com Email: ycheng@google.com
Nandita Dukkipati Nandita Dukkipati
 End of changes. 15 change blocks. 
65 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.48.