Skip to content
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

Merged
merged 4 commits into from Jun 19, 2020
Merged

Second set of editorial nits #3770

merged 4 commits into from Jun 19, 2020

Conversation

martinthomson
Copy link
Member

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

@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.
@martinthomson martinthomson added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Jun 17, 2020
@@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is /bandwidth/capacity/ ?

@gorryfair
Copy link
Contributor

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.
/It can also improve connection throughput on severely asymmetric links; see Section 3 of {{?RFC3449}}./

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.

@martinthomson
Copy link
Member Author

Let's take that up separately. I don't object to the language, but I just didn't know what to say.

Copy link
Contributor

@janaiyengar janaiyengar left a 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.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
martinthomson and others added 2 commits June 19, 2020 13:59
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
@martinthomson martinthomson merged commit 72b0f37 into master Jun 19, 2020
@martinthomson martinthomson deleted the gorry-nits-2 branch June 19, 2020 04:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

QUIC transport Reading NiTs part 2 of 2
3 participants