Skip to content

Commit

Permalink
Congestion window reduced on ACK
Browse files Browse the repository at this point in the history
  • Loading branch information
janaiyengar committed Jan 4, 2019
1 parent d403d8d commit 182ebee
Showing 1 changed file with 12 additions and 11 deletions.
23 changes: 12 additions & 11 deletions draft-ietf-quic-recovery.md
Expand Up @@ -955,10 +955,14 @@ packets might cause the sender's bytes in flight to exceed the congestion window
until an acknowledgement is received that establishes loss or delivery of
packets.

If a threshold number of consecutive PTOs have occurred (pto_count is more than
kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
considered to be experiencing persistent congestion, and the sender's congestion
window MUST be reduced to the minimum congestion window.
When an ACK frame is received that establishes loss after a threshold number of
consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see
{{cc-consts-of-interest}}), the network is considered to be experiencing
persistent congestion, and the sender's congestion window MUST be reduced to the
minimum congestion window (kMinimumWindow). This response of collapsing the
congestion window on persistent congestion is functionally similar to a sender's
response on a Retransmission Timeout (RTO) in TCP {{RFC5681}}.


## Pacing

Expand Down Expand Up @@ -1030,15 +1034,12 @@ kLossReductionFactor:
The RECOMMENDED value is 0.5.

kPersistentCongestionThreshold:
: Number of consecutive PTOs after which network is considered to be
: Number of consecutive PTOs after which network might be considered to be
experiencing persistent congestion. The rationale for this threshold is to
enable a sender to use initial PTOs for aggressive probing, similar to Tail
Loss Probe (TLP) in TCP {{TLP}} {{RACK}}. Once the number of consecutive PTOs
reaches this threshold - that is, persistent congestion is established - the
sender responds by collapsing its congestion window to kMinimumWindow, similar
to a Retransmission Timeout (RTO) in TCP {{RFC5681}}. The RECOMMENDED value
for kPersistentCongestionThreshold is 2, which is equivalent to having two
TLPs before an RTO in TCP.
Loss Probe (TLP) in TCP {{TLP}} {{RACK}}. The RECOMMENDED value for
kPersistentCongestionThreshold is 2, which is equivalent to having two TLPs
before an RTO in TCP.

### Variables of interest {#vars-of-interest}

Expand Down

0 comments on commit 182ebee

Please sign in to comment.