Clarify congestion and rate control #134
Conversation
I don't think normative SHOULD's are useful for describing API considerations. This also clarifies the datagram/stream acknowledgement mappings. Additionally, I removed the API write functions section. I think resetting streams is a core feature of QUIC and it shouldn't be necessary to be listed explicitly. And congestion control configuration is not something that needs an API at runtime. The updates to the congestion control section in #134 should also make this more clear.
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| sender and receiver. | ||
| : A mechanism that adjusts the sending rate of an application in order to | ||
| maximize the amount of information that is sent to a receiver without causing | ||
| queues to build beyond a reasonable amount, causing *buffer bloat* and *jitter*. |
There was a problem hiding this comment.
This sentence ^^ reads as if building queues are the only cause of jitter. I'd suggest phrasing this as
maximize the amount of information that is sent to a receiver without causing buffer bloat, when
queues build beyond a reasonable amount, or jitter, when interpacket arrival times fluctuate due to queuing delays.
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| : A mechanism that adjusts the sending rate of an application in order to | ||
| maximize the amount of information that is sent to a receiver without causing | ||
| queues to build beyond a reasonable amount, causing *buffer bloat* and *jitter*. | ||
| Rate adaptation is one way to respond to send rate limitations imposed by |
There was a problem hiding this comment.
I'd suggest
Rate adaptation is one way to respond to sending rate limitations imposed by
draft-ietf-avtcore-rtp-over-quic.md
Outdated
|
|
||
| {{shared-connections}} discusses congestion control implications of using shared | ||
| or multiple separate QUIC connections to send and receive multiple independent | ||
| data streams. |
There was a problem hiding this comment.
Just for readability - the previous paragraphs have pointed to document sections at the end of each sentence, but this paragraph starts with the pointer to a document section. Perhaps
This document also discusses congestion control implications of using shared
or multiple separate QUIC connections to send and receive multiple independent
data streams in {{shared-connections}}.
or perhaps just flip the previous paragraphs to match this one? Your call, of course.
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| described in {{rate-adaptation-application-layer}}. | ||
|
|
||
| It is assumed that the congestion controller in use provides a pacing mechanism | ||
| to determine when a packet can be sent to avoid bursts. The currently proposed |
There was a problem hiding this comment.
I'd suggest
to avoid bursts and minimize variation in inter-packet arrival times.
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| If the application transmits media that does not saturate path bandwidth and | ||
| paces its transmission, more heavy-handed congestion control mechanisms (drastic | ||
| reductions in the sending rate when loss is detected, with much slower increases | ||
| when losses are no longer detected) should rarely come into play. If the |
There was a problem hiding this comment.
I'd suggest
when losses are no longer being detected)
The main points have been integrated into the previous subsection.
mengelbart
force-pushed
the
fix/128-congestion-and-rate-control
branch
from
5f37e1f
to
7a03e8f
Compare
I don't think normative SHOULD's are useful for describing API considerations. This also clarifies the datagram/stream acknowledgement mappings. Additionally, I removed the API write functions section. I think resetting streams is a core feature of QUIC and it shouldn't be necessary to be listed explicitly. And congestion control configuration is not something that needs an API at runtime. The updates to the congestion control section in #134 should also make this more clear.
I don't think normative SHOULD's are useful for describing API considerations. This also clarifies the datagram/stream acknowledgement mappings. Additionally, I removed the API write functions section. I think resetting streams is a core feature of QUIC and it shouldn't be necessary to be listed explicitly. And congestion control configuration is not something that needs an API at runtime. The updates to the congestion control section in #134 should also make this more clear.
close #128