Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix congestion control permissiveness #3248

Merged
merged 6 commits into from
Jan 17, 2020
Merged

Fix congestion control permissiveness #3248

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
d97c226
Fix congestion control permissiveness
janaiyengar Nov 17, 2019
df57eff
remove pointless sentences
janaiyengar Nov 17, 2019
1de8eb4
gorry comment
janaiyengar Nov 20, 2019
d8ad745
Update draft-ietf-quic-recovery.md
janaiyengar Nov 18, 2019
dc62871
specify section 3.1
janaiyengar Nov 28, 2019
19063e4
Ted's suggestion
janaiyengar Dec 10, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 17 additions & 17 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -633,20 +633,22 @@ sooner, as soon as handshake keys are available (see Section 4.9.1 of

# Congestion Control {#congestion-control}

QUIC's congestion control is based on TCP NewReno {{?RFC6582}}. NewReno is a
congestion window based congestion control. QUIC specifies the congestion
window in bytes rather than packets due to finer control and the ease of
appropriate byte counting {{?RFC3465}}.
This document specifies a Reno congestion controller for QUIC {{?RFC6582}}.

QUIC hosts MUST NOT send packets if they would increase bytes_in_flight (defined
in {{vars-of-interest}}) beyond the available congestion window, unless the
packet is a probe packet sent after a PTO timer expires, as described in
{{pto}}.
The signals QUIC provides for congestion control are generic and are designed to
support different algorithms. Endpoints can unilaterally choose a different
algorithm to use, such as Cubic {{?RFC8312}}.

Implementations MAY use other congestion control algorithms, such as
Cubic {{?RFC8312}}, and endpoints MAY use different algorithms from one another.
The signals QUIC provides for congestion control are generic and are designed
to support different algorithms.
If an endpoint uses a different controller than that specified in this document,
the chosen controller MUST conform to the congestion control guidelines
specified in Section 3.1 of {{!RFC8085}}.

The algorithm in this document specifies and uses the controller's congestion
window in bytes.

An endpoint MUST NOT send a packet if it would cause bytes_in_flight (see
{{vars-of-interest}}) to be larger than the congestion window, unless the packet
is sent on a PTO timer expiration (see {{pto}}).

## Explicit Congestion Notification {#congestion-ecn}

Expand Down Expand Up @@ -888,8 +890,7 @@ time_sent:
## Constants of interest {#ld-consts-of-interest}

Constants used in loss recovery are based on a combination of RFCs, papers, and
common practice. Some may need to be changed or negotiated in order to better
suit a variety of environments.
common practice.

kPacketThreshold:
: Maximum reordering in packets before packet threshold loss detection
Expand Down Expand Up @@ -1249,9 +1250,8 @@ in {{congestion-control}}.

## Constants of interest {#cc-consts-of-interest}

Constants used in congestion control are based on a combination of RFCs,
papers, and common practice. Some may need to be changed or negotiated
in order to better suit a variety of environments.
Constants used in congestion control are based on a combination of RFCs, papers,
and common practice.

kInitialWindow:
: Default limit on the initial amount of data in flight, in bytes. Taken from
Expand Down