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.

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

fix typos on the flowcontrol page #56

Merged
merged 3 commits into from
May 7, 2024
Merged
Changes from all commits
Commits
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
6 changes: 3 additions & 3 deletions content/docs/quic/flowcontrol.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,13 @@ toc: true
weight: 7
---

This page outlines the flow control algorithms used by QUIC. Flow control ensures that a sender doesn't overwhem the receiver with too much data (and too many new streams), if the receiver is not able to keep up with the sender's rate. This is essential to control the resource consumption of a QUIC connection. On the other hand, misconfiguration of flow control limits often is the reason for suboptimal performance (see the [BDP section](#bdp)).
This page outlines the flow control algorithms used by QUIC. Flow control ensures that a sender doesn't overwhelm the receiver with too much data (and too many new streams), if the receiver is not able to keep up with the sender's rate. This is essential to control the resource consumption of a QUIC connection. On the other hand, misconfiguration of flow control limits often is the reason for suboptimal performance (see the [BDP section](#bdp)).


## Flow Control for Data sent on Streams

Flow control for data sent on streams is described in [Section 4.1 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-4.1). QUIC imposes two separate limits:
1. A per-stream limit, definining the maximum amount of data that can be sent on any stream.
1. A per-stream limit, defining the maximum amount of data that can be sent on any stream.
2. A per-connection limit, specifying the total amount of data that can sent across all streams.

The per-connection limit makes it possible to use relatively high per-stream limits, while avoiding to commit a large amount of memory. For example, a QUIC stack might configure a per-stream window of 5 MB and a per-connection limit of 10 MB. Even if the peer opens 100 streams at the same time, the maximum memory commitment is limit to 10 MB (and not 500 MB).
Expand Down Expand Up @@ -75,7 +75,7 @@ quic.Config{
}
```

The QUIC protocols allows adjusting this number during the lifetime of the connection, similar to how it is possible to [adjust the receive window](#auto-tuning). Currently quic-go doesn't expose an API for that.
The QUIC protocol allows adjusting this number during the lifetime of the connection, similar to how it is possible to [adjust the receive window](#auto-tuning). Currently, quic-go doesn't expose an API for that.

These configuration flags determine the number of concurrent streams and not the total number of streams over the lifetime of a QUIC connection. Once a stream is closed and / or reset (in both directions, in the case of bidirectional streams), and all frames have been delivered to the peer, the peer is allowed to open a new stream.

Expand Down