Add some MUSTs to congestion control

[ianswett]

Fixes #3944

Includes some changes suggested in #3992(see below)

ISSUE:
/When a loss or ECN-CE marking is detected, NewReno halves the
congestion window, sets the slow start threshold to the new congestion
window, and then enters the recovery period./

• The requirement is that TCP needs to reduce after CE, The RFC series
  does not now say it needs to halve, it could for example follow the
  reduction method specified in RFC8511. e.g. /When a loss or ECN-CE
  marking is detected, the sender must reduce the cwnd. NewReno halves the
  congestion window, sets the slow start threshold to the new congestion
  window, and then enters the recovery period. [RFC8511] specifies an
  alternate cwnd reduction./

ISSUE:
Similar comment in 8.3:
/Though congestion controllers generally treat reports of ECN-CE
markings as equivalent to loss [RFC8311], the exact response for each
controller could be different. /

• This does not seem correct. Could I suggest:
  /Congestion controllers respond to reports of ECN-CE by reducing their
  rate. Markings can be treated as equivalent to loss [RFC3168], but other
  responses can be specified (e.g. [RFC8511]) [RFC8311]. /

[janaiyengar]

one nit, but LGTM

[janaiyengar]

Suggested change

	Congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD)
	approach that MUST increase the congestion window by one maximum packet size
	per congestion window acknowledged. When a loss or ECN-CE marking is
	Congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD)
	approach and MUST increase the congestion window by one maximum packet size
	per congestion window acknowledged. When a loss or ECN-CE marking is

[martinthomson]

This is a weird MUST to add. It just does this.

[ianswett]

Agreed, we can just drop this part of the change.

[janaiyengar]

What are we dropping? My suggestion or the MUST increase entirely? Dropping my suggestion is fine, but I would keep the MUST increase -- that's just the definition of Reno.

[martinthomson]

The removal of the first sentence is fine. (Though we need a definition of congestion avoidance, this isn't it.)

The original text here is fine without a MUST: "Congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD) approach that increases the congestion window by one maximum packet size per congestion window". You don't need normative language, because it is definitional. If you use "MUST" you do so by identifying an actor and an action. This is saying what "congestion avoidance" is.

[janaiyengar]

That's not the reason we stick with Reno -- we have RFC 8312 (Cubic) as well. Reno is simple, which is why we went with it. To be clear, this is not a default requirement for QUIC. It's stated that some congestion controller is necessary, and we specify one, but implementations can use others (Section 7.)

[MikeBishop]

We're chartered to use a Standard congestion controller, and RFC 8312 is Informational. But as you say, people are perfectly able to plug in other congestion controllers instead; this is merely "a default scheme," in the language of the charter.

[mirjak]

I still don't understand what the problem of referring RFC5681 normatively is?

[ianswett]

Early in the QUIC process, the preference of the working group was to have the recovery document be complete enough that one can implement from it, and to only reference TCP RFCs informationally. I think that was the right decision both because there are some differences between QUIC and TCP and because not all the text in TCP RFCs is relevant here. As such, if there are important requirements, they should be specified in this document.

[mirjak]

Thanks for trying to make that clearer. However, the normative language for reduction is most less strict (MUST reduce) and not specifying a concrete algorithm. I think that would be also the better approach for the increase behaviour. However, it's probably less clear what this minimum requirement is. So I would still prefer to just not use normative language here and just say NewReno does increase by one maximum packet size per congestion window acknowledged.

[mirjak]

I actually don't really understand the intention of the last sentence. This is also true for lost base congestion control or even controller which are not based on loss at all.

[ianswett]

This text is pre-existing, but I agree it doesn't say anything important and probably could be removed.

[pravb]

Yes I think we should remove it because it almost sounds like an incentive to deviate which we don't want to encourage.

[ianswett]

SG, sentence removed.

[mirjak]

This MUST NOT kind of already says that QUICv1 cannot implement Cubic. Is that what we want?

[janaiyengar]

It does not, since this document allows an endpoint to implement a different controller than the one specified here. See Section 7:

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].

[mirjak]

Then I don't see why this need to be a normative requirement.

[mirjak]

Similar as we don't require normatively in the next part that the congestion needs be halved on loss/CE mark.

[ianswett]

I don't have a strong opinion on this, but I see @mirjak point. If we're going to keep this, I think we should be clear that this MUST NOT only applies to NewReno.

[ianswett]

Updated to start the sentence with NewReno to make it a bit clearer.

[mirjak]

This still say that you have to set the cwnd to ssthresh when entering recovery. Saying that you have to do this when entering recovery and then saying that you may do it it later seems confusing.

[janaiyengar]

Good point - fixed

[ianswett]

Thanks for updating this while I was gone, looks like a good resolution.