-
Notifications
You must be signed in to change notification settings - Fork 14
RFC 8311 updates sender's response to CE / ECE #84
Comments
@markkukojo CUBIC follows RFC 3168's below requirement,
Sure, it doesn't half the congestion window but the response to classic ECN is to behave same as loss. |
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:
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:
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:
Finally, even if RFC8311 were relevant, when it updates §5 of RFC3168 (quoted above) by adding:
...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. |
@markkukojo do you agree to close with no action based on the above? |
@markkukojo ping? |
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): RFC 8174: |
@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. |
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. |
No answer from @markkukojo, closing. |
Markku Kojo said,
The text was updated successfully, but these errors were encountered: