Draft: draft-ietf-quic-transport

Commentary: Looks like this is good to go . 
 ( Broken out of . ) An endpoint can verify support for Explicit Congestion Notification Nearly - It can verify the endpoints support ECN and the current path could be used to transfer ECN - marked packets . That ’s not quite enough to complete verification that the path and endpoints have full ECN support . 
 This is the level of support that we rely upon . If the path does not provide ECN - CE marking , that 's OK , because the congestion controller responds to loss just as well as marking . If it does n't have L4S support , that 's not something we care about . 
 No . I think this is not the same understanding of what it means to say " verify support for ECN " . What I see as validation , is the act of setting a CE code point and seeing this echoed by the remote endpoint . To me this can be done at the sending endpoint and the resulting ECN feedback can safely ignored from a CC perspective when it refers to the packet was intentionally CE - marked . ( This does not confirm the devices on path observe or remark , simply that if a known CE - mark is inserted by the sender , this is in fact observed by the receiver and generates a response to the sender . I agree that knowledge whether the path updates ECT - marks is not a part of the spec . ) 
 So would a resolution be " An end point can verify support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counters " ? 
 Hmmmm , I recall that proposal .... That 's a different approach to what I said , and does n't check that CE is correctly interpreted , but I think there is only a slim chance that CE - only is not correctly reported ( I guess a server could in principle cheat and refuse to report CE - marks - but I have no evidence to suggest we currently need this ) . So ... I think my answer is " YES " ! Can we explain this out a little , and state that QUIC does this . I 'm assuming that this refers independently for each direction of transmission . 
 If you 'd like more text than what I proposed above , could you craft that text ? 
  and I believe I 'm fine with the current rev . 
 I the text above to . 
 ( Edited by on Aug 19 . ) says : current text has changed , to review says : address in PR says : addressed in PR says : I can no longer find this text in the draft , to check says : text has changed significantly in draft , to review says : I can no longer find this text in the draft , to check says : addressed in PR says : I am not aware of other IETF specs that require logging . says : already addressed see PR says : I can no longer find this text in the draft , to check says : current text has changed , to review says : I can no longer find this text in the draft , to check says : I can no longer find this text in the draft , to check says : see PR says : see PR says : see PR says : see PR says : I am not aware of other IETF specs that require logging . says : current text has changed , to review says : see PR , propose to remove the sentence says : see PR says : already addressed 
 Each of these two dozen or so nits requires its own GitHub issue . It will become unwieldy quickly were we to start discussing all of them in one place . This is likely there have been no comments since this issue was opened . 
 I 'll let the editors propose how to handle these . If you want to make each of these an issue we can do that ... or I can submit them as WGLC comments or we can just discuss using the list.- I still expect few ( if any ) of these are likely to result in important technical changes . 
 I , too , think that editors should edit . I take back my " requires its own issue " remark -- I did not mean to demand that it be done . On the other hand , since the issue has not been commented upon , I presume that the editors ' expectation is that PRs be opened . 
 I expect once most of the design issues have been closed , the editors will focus more on closing out remaining editorial issues . In the meantime , if there are small editorial issues I know how to fix , I try to fix them , but it 's best effort at the moment . As always , PRs to fix editorial issues are appreciated . 
 PRs are a great way to fix simple editorial issues -- spelling , broken references , etc . Things get dicey when an " editorial " PR changes the meaning or flow of the text and we do n't want to take the whole of a given PR . Then an editor needs to either accept the PR and partially revert it , or they need to duplicate the work for the things they want to keep . Without looking super closely at the list of changes here , I probably would n't want to get a single PR that made all of these changes at once . ( Noting , of course , that this is n't my document . ) So my personal recommendation : Combination PRs for totally obvious editorial fixes Separate PRs for more invasive or controversial editorial fixes Issues for design changes and/or editorial issues where the solution is n't obvious ( or you do n't want to write it yourself ) 
  's advice is almost perfect , though I would point out that an issue does give us more opportunity to discuss things in a place that is n't a PR , so issues for the category of more intricate editorial changes can be useful . 
 I went through original list of things , and crossed those out that I think are overtaken by edits , or for which I have a proposal in . There are still others in the list that need someone to take a look . 
 I think I will just break out the remaining things into their own issues . you owe me beer ! :-) 
 OK , I think this is all the ones that did n't cover yet . I will leave this open to discuss the resolution in , but please also look at the new tickets . 
 Nits only . Thanks for working through these .
Paragraph (version B):
An endpoint SHOULD supply a new connection ID when the peer retires a
connection ID.  If an endpoint provided fewer connection IDs than the
peer's active_connection_id_limit, it MAY supply a new connection ID
when it receives a packet with a previously unused connection ID.  An
endpoint MAY limit the total number of connection IDs issued for each
connection to avoid the risk of running out of connection IDs; see
reset-token.  An endpoint MAY also limit the issuance of connection
IDs to reduce the amount of per-path state it maintains, such as path
validation status, as its peer might interact with it over as many
paths as there are issued connection IDs.
Paragraph (version B):
Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects.  Clients that choose to
receive zero-length connection IDs can use the local address and port
to identify a connection.  Packets that do not match an existing
connection, based on Destination Connection ID or, if this value is
zero-length, local IP address and port, are discarded.
Paragraph (version B):
The definition of a new transport parameter (new-transport-
parameters) MUST specify whether storing the transport parameter for
0-RTT is mandatory, optional, or prohibited.  A client need not store
a transport parameter it cannot process.
Paragraph (version A):
This style of attack relies on the attacker using a path that is
approximately as fast as the direct path between endpoints.  The
attack is more reliable if relatively few packets are sent or if
packet loss coincides with the attempted attack.
Paragraph (version B):
This style of attack relies on the attacker using a path that has
approximately the same characteristics as the direct path between
endpoints.  The attack is more reliable if relatively few packets are
sent or if packet loss coincides with the attempted attack.
Paragraph (version B):
At any time, endpoints MAY change the Destination Connection ID they
transmit with to a value that has not been used on another path.
Paragraph (version B):
Migrating a connection to a new server address mid-connection is not
supported by the version of QUIC specified in this document.  If a
client receives packets from a new server address when the client has
not initiated a migration to that address, the client SHOULD discard
these packets.
Paragraph (version A):
If path validation succeeds, the client SHOULD immediately begin
sending all future packets to the new server address using the new
connection ID and discontinue use of the old server address.  If path
validation fails, the client MUST continue sending all future packets
to the server's original IP address.
Paragraph (version B):
As soon as path validation succeeds, the client SHOULD begin sending
all future packets to the new server address using the new connection
ID and discontinue use of the old server address.  If path validation
fails, the client MUST continue sending all future packets to the
server's original IP address.
Paragraph (version B):
Note that supporting ECN requires being able to set and read the ECN
codepoints in the IP headers of datagrams carrying QUIC packets.  On
platforms where this is not possible, QUIC cannot support ECN.
Paragraph (version B):
On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames; see
generating-acks and frame-ack.
Paragraph (version B):
It is possible for faulty network devices to corrupt or erroneously
drop packets with ECN markings.  To provide robust connectivity in
the presence of such devices, each endpoint independently validates
ECN counts and disables ECN if the path is not showing consistent
support for ECN.