Make the ECN requirements match the the discussion in #2156. Fixes #2156 #2201
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
quicwg#2156 1. Implementations are free to enable sending or not. 2, Implementations MAY read the ECN code points if they can and send ECN ACKs. 3. Implementations MUST accept the 0x03 ACK type and if they are sending ECN SHOULD use the ECN section. I recognize that some people want to have stronger language here, based on this discussion I think this is where we are. I'll defer to the chairs to judge whether more is needed here and can change the PR as required.
martinthomson
approved these changes
Dec 18, 2018
draft-ietf-quic-transport.md
Outdated
| other peer. Even if ECN is not used on the path to the peer, the endpoint MUST | ||
| provide feedback about ECN markings received (if accessible). | ||
| other peer. Even if not setting ECN codepoints on packets it transmits, the | ||
| endpoint MAY provide feedback about ECN markings received (if accessible). |
There was a problem hiding this comment.
SHOULD SGTM.
Also, can you remove the parens around if accessible?
|
I took the discussion to be "MAY" but obviously this is easily changed if
the chairs judge consensus otherwise.
…On Mon, Dec 17, 2018 at 8:19 PM Martin Thomson ***@***.***> wrote:
***@***.**** approved this pull request.
------------------------------
In draft-ietf-quic-transport.md
<#2201 (comment)>:
> @@ -3014,11 +3016,11 @@ the 1-RTT packet number space will be increased by two.
Each endpoint independently verifies and enables use of ECN by setting the IP
header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the
-other peer. Even if ECN is not used on the path to the peer, the endpoint MUST
-provide feedback about ECN markings received (if accessible).
+other peer. Even if not setting ECN codepoints on packets it transmits, the
+endpoint MAY provide feedback about ECN markings received (if accessible).
SHOULD?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2201 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABD1oRt2EbSqbfKSyUhZ6ug38oB5aX__ks5u6Gy7gaJpZM4ZW1UG>
.
|
ianswett
reviewed
Dec 18, 2018
draft-ietf-quic-transport.md
Outdated
| other peer. Even if ECN is not used on the path to the peer, the endpoint MUST | ||
| provide feedback about ECN markings received (if accessible). | ||
| other peer. Even if not setting ECN codepoints on packets it transmits, the | ||
| endpoint MAY provide feedback about ECN markings received (if accessible). |
There was a problem hiding this comment.
SHOULD SGTM.
Also, can you remove the parens around if accessible?
janaiyengar
reviewed
Dec 18, 2018
draft-ietf-quic-transport.md
Outdated
| @@ -4133,7 +4135,9 @@ Receivers send ACK frames (types 0x02 and 0x03) to inform senders of packets | |||
| they have received and processed. The ACK frame contains one or more ACK Blocks. | |||
| ACK Blocks are ranges of acknowledged packets. If the frame type is 0x03, ACK | |||
| frames also contain the sum of QUIC packets with associated ECN marks received | |||
| on the connection up until this point. | |||
| on the connection up until this point. QUIC implementations MUST properly handle | |||
| both types 0x02 and 0x03 and if they have enabled ECN for packets they send, | |||
There was a problem hiding this comment.
Suggested change
| both types 0x02 and 0x03 and if they have enabled ECN for packets they send, | |
| both types 0x02 and 0x03, and if they have enabled ECN for packets they send, |
ianswett
approved these changes
Dec 18, 2018
martinthomson
added
editorial
martinthomson
added
design
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
2, Implementations MAY read the ECN code points if they
can and send ECN ACKs.
sending ECN SHOULD use the ECN section.
I recognize that some people want to have stronger language here, based
on this discussion I think this is where we are. I'll defer to the
chairs to judge whether more is needed here and can change the PR as
required.