New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Second set of editorial nits #3770
Conversation
@gorryfair had some useful feedback in #3735. This doesn't address the following items as numbered in the issue: (2) Because the fix to (1) seems adequate by my reckoning. That addresses the question of considering the impact on other network users. (6) This doesn't appear to be a problem. It might be a formatting issue, with the URL not appearing. (7) This is addressed in the recent draft by adding [Section 10.2.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-deferring-idle-timeout) (9) and (11) I can't find the rendering glitch mentioned. The rest of these are good. Closes #3735.
draft-ietf-quic-transport.md
Outdated
@@ -3551,7 +3553,7 @@ too large. A receiver can discard unacknowledged ACK Ranges to limit ACK frame | |||
size, at the cost of increased retransmissions from the sender. This is | |||
necessary if an ACK frame would be too large to fit in a packet, however | |||
receivers MAY also limit ACK frame size further to preserve space for other | |||
frames. | |||
frames or to limit the bandwidth that acknowledgments consume. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is /bandwidth/capacity/ ?
Fine and thanks for looking to these. I do think something more needs to be said about the need to avoid collateral impact on the forward traffic of this and other traffic sharing a path. To me this really important in an IETF Transport specification, especially one that might displace TCP. To me, a note to make sure this isn't ignored would seem enough, but I'd be happy to take this up as a separate WGLC comment if that seems better. |
Let's take that up separately. I don't object to the language, but I just didn't know what to say. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get these in and deal with more specific issues separately.
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
@gorryfair had some useful feedback in #3735.
This doesn't address the following items as numbered in the issue:
(2) Because the fix to (1) seems adequate by my reckoning. That
addresses the question of considering the impact on other network users.
(6) This doesn't appear to be a problem. It might be a formatting
issue, with the URL not appearing.
(7) This is addressed in the recent draft by adding Section
10.2.2
(9) and (11) I can't find the rendering glitch mentioned.
The rest of these are good.
Closes #3735.