RFC 8311 updates sender's response to CE / ECE

[goelvidhi]

Markku Kojo said,

RFC 8311 (sec 4.1) allows modifying the TCP-sender response to
ECE for experimental purposes only. Has there been any discussion
with tsvwg in that modifying the TCP-response to ECE in CUBIC is
conflict with RFC 8311 as CUBIC is currently intended to become
a Standards Track RFC?

[goelvidhi]

@markkukojo CUBIC follows RFC 3168's below requirement,

The indication
of congestion should be treated just as a congestion loss in non-
ECN-Capable TCP.

Sure, it doesn't half the congestion window but the response to classic ECN is to behave same as loss.
OTOH, RFC 8311 intends to allow experiments that treat CE markings different from loss by free'ing up the ECT(1) IP code-point. As CUBIC treats ECE flag and packet loss in the same way, it doesn't have anything to do with RFC 8311.

[bbriscoe]

I agree. The scope of RFC8311 is solely changes to ECN, whereas RFC8312bis changes the response to drop, and consequently also the response to ECN in order to continue to comply with stds track RFC3168 §5:

Upon the receipt by an ECN-Capable transport of a single CE packet,
the congestion control algorithms followed at the end-systems MUST be
essentially the same as the congestion control response to a single
dropped packet. For example, for ECN-Capable TCP the source TCP is
required to halve its congestion window for any window of data
containing either a packet drop or an ECN indication.

The first sentence gives the normative requirement. The second sentence isn't normative, because later RFC3168 says it assumes the standard congestion response is defined elsewhere; specifically §6.1 of RFC3168 says:

We assume that the source TCP uses the standard congestion
control algorithms of Slow-start, Fast Retransmit and Fast Recovery
[RFC2581].

Therefore, it would be compatible with RFC3168 for a sender to follow the congestion response of a different stds track RFC, such as the one RFC8312bis will define.

RFC3168 mentions the halving again later, and again doesn't make it normative, but does define a normative bound on the response (that it MUST not increase), see RFC3168 §6.1.2:

The indication
of congestion should be treated just as a congestion loss in non-
ECN-Capable TCP. That is, the TCP source halves the congestion window
"cwnd" and reduces the slow start threshold "ssthresh". The sending
TCP SHOULD NOT increase the congestion window in response to the
receipt of an ECN-Echo ACK packet.

Finally, even if RFC8311 were relevant, when it updates §5 of RFC3168 (quoted above) by adding:

unless otherwise
specified by an Experimental RFC in the IETF document stream

...that merely allows experimental RFCs to define different congestion responses without having to update RFC3168 (because an exp track RFC cannot update a stds track RFC). That is the stated purpose of RFC8311. It doesn't need to say that a stds track RFC can update RFC3168, because nothing prevents the IETF updating a stds track RFC with another stds track RFC.

Assuming I'm correct, I suggest this issue is just closed with no action.

[larseggert]

@markkukojo do you agree to close with no action based on the above?

[larseggert]

@markkukojo ping?

[markkukojo]

...that merely allows experimental RFCs to define different congestion responses without having to update RFC3168 (because an exp track RFC cannot update a stds track RFC). That is the stated purpose of RFC8311. It doesn't need to say that a stds track RFC can update RFC3168, because nothing prevents the IETF updating a stds track RFC with another stds track RFC.

Sure, a stds track RFC can update RFC3168. I might be wrong but my understanding was that TSVWG at this time is not ready to see other than experimental modifications to RFC 3168?

In particular, when there is little or no experimental results to support a stds track update; as Bob has recently testified that there has been hardly any ECN enabled routers in the Internet, the long deployment experience cannot include experience on modified ECN response. At the same time, RFC 8511 (ABE) documents findings saying that positive results with a larger MD factor were found only when the sender is in CA. This does not support using a larger MD factor when an ECN capable sender is in slow start.

I'd leave this for tcpm wg chairs to discuss with tsvwg chairs.

Nits on what is normative text.

RFC 2119 (the one that was valid at the time RFC 3186 was published):
These words are often capitalized.

RFC 8174:
These words can be used as defined here, but using them is not
required. Specifically, normative text does not require the use
of these key words. They are used for clarity and consistency
when that is what's wanted, but a lot of normative text does not
use them and is still normative.

[larseggert]

@markkukojo based on what you write, I still don't understand if we can close this issue with no action, or else, what changes you want to see in the document.

[goelvidhi]

In particular, when there is little or no experimental results to support a stds track update; as Bob has recently testified that there has been hardly any ECN enabled routers in the Internet, the long deployment experience cannot include experience on modified ECN response. At the same time, RFC 8511 (ABE) documents findings saying that positive results with a larger MD factor were found only when the sender is in CA. This does not support using a larger MD factor when an ECN capable sender is in slow start.

The second statement is a bit of a contradiction of the first. If we can't believe the long deployment experience of CUBIC for ECN, then how can we believe RFC 8511's findings about large MD factor during CA.

[larseggert]

No answer from @markkukojo, closing.