Proposed congestion control requirement to recharter

[LPardue]

I received an offlist comment about whether congestion control should be explicitly called out in the charter.

As an individual my response to the question is:

I don't think the reliable bidirectional stream itself needs to provide congestion control (e.g. TLS does not provide that itself, nor does it require it itself, but it does work on TCP which provides it). That said, in the prior work on draft-kazuho-quic-quic-on-streams @kazuho and I stated that it was designed to work on a transport that is congestion controlled when using a shared network. The rationale being that we can have a simple design and remain Internet congestion safe by delegating the congestion control requrements to the substrate.

This PR proposes an additional sentence to the charter to capture that we expect congestion control on shared networks.

This might be too broad brush for folks that were thinking of using RDMA, so pinging @nibanks .

I'd like to keep any text in this realm succinct.

One alternative to the "congestion control" phrase could to talk about the outcome we want to avoid:

"Deployments on a shared network must use a substrate that can avoid congesting the network."

[kazuho]

Thank you for doing this!

[kazuho]

How about something like below?

• I share the concern that "congestion control" might refer to an end-to-end approach and exclude hop-by-hop, flow-control-based congestion avoidance techniques. By switching to "congestion-management capabilities," we can be vague enough to have them in scope.
• Start the sentence with "when," for consistency with the previous sentence.

Suggested change

	communication without a security provider. Deployments on a shared
	network must use a substrate that provides congestion control.
	communication without a security provider. When operating over a shared path, the chosen substrate must provide congestion-management capabilities.

[LPardue]

Thanks for the suggestions, I think they make the text more broadly applicable while keeping the intent of avoiding damage in places we (the IETF) strongly care

[mjoras]

I think we should avoid the words "congestion control" if we can because it both overly specifies the requirement while also opening us up to debates about what congestion control even is. I like "congestion management" since it conveys the spirit of not running it over a totally dumb channel.

[nibanks]

I think this general direction is fine, whether you go with the text here or Kazuho's suggestion. I think the RDMA work will be fine regardless.

[wtarreau]

I think we shouldn't even start to enumerate cases (like "when substrate is shared ..."), instead we should probably say something along "any congestion management that may be required over the path is the sole responsibility of the chosen substrate".

For example, even when not shared, congestion management might be required to avoid excess queuing and buffer bloat on networks with different speeds at different points.

Another approach could be instead to just mention indicate the need for a lossless substrate, which indirectly implies that it is connection-managed as needed. Or even a "lossless, non-congestioned bidirectional stream".

[guhetier]

Both versions seems good to me.
I like kazuho suggestion as a way to clarify that any type of congestion avoidance is valid for the substrate.

[LPardue]

I think we shouldn't even start to enumerate cases (like "when substrate is shared ..."), instead we should probably say something along "any congestion management that may be required over the path is the sole responsibility of the chosen substrate".

For example, even when not shared, congestion management might be required to avoid excess queuing and buffer bloat on networks with different speeds at different points.

Another approach could be instead to just mention indicate the need for a lossless substrate, which indirectly implies that it is connection-managed as needed. Or even a "lossless, non-congestioned bidirectional stream".

I think I'm understanding the rationale here but I'm struggling with the concrete suggestions a little. We need the charter to be concise and clear enough that is obvious what the WG is agreeing to work on. The first suggestion - ""any congestion management that may be required over the path is the sole responsibility of the chosen substrate"" reads a bit to vague/wooly to me. The second suggestion - "lossless, non-congestioned bidirectional stream" - makes me nervous of inciting some pedantry about where congestion can happen (or where it can be detected to have happened), which could be a disctration.

However, I agree enumerating cases that are not critically relevant sounds good. So how about we take Kazuho's text but tweak it a bit to

"Substrates must provide congestion-management capabilities applicable to their deployment environments."

[wtarreau]

Yeah sounds good like this! thanks!

[LPardue]

Thanks for the feedback folks, I've merged this into the main charter proposal.