Draft: draft-ietf-quic-transport

Commentary: This turned out to be fairly simple , but I think that it 's worth writing down . I do n't have concrete recommendations , but I could add them if people thought that they help . See the commented - out bit . 
 Thanks both for the reviews , I 've taken some of the suggestions and moved this to the appendix . 
 After discussing with editors , we agreed that this was a reasonable interpretation of existing text . We do agree that it would be worth discussing  's views on ECN reliability and possibly changing the algorithm to reflect that , but it would be a design change . 
 In , suggested that a different algorithm might be better to recommend enabling ECN and only disabling it if a failure is detected . That algorithm adopts the same posture as the draft : that ECN is optional and that endpoints are permitted to be cautious in enabling it . If we want to adopt the view that ECN works and endpoints are required to use it unless it breaks , that 's a bigger change . I open this issue , while being aware that this is re - opening something we discussed and agreed previously , without there being new information to present .  , if you do think we should discuss this , it 's a design issue . 
 I would not be in favor of reopening this . 
 Just to clarify the proposal was that if you decide to enable ECN , you should just do it and only disable if you notice a failure , instead of having the more complicated probing logic that we have right now ( in the appendix I think ) 
 The shows that out of 14 implementations doing active tests , only 3 demonstrate ECN support . No ill will , but major places like AWS or the Windows OS do not support ECN , so it is not clear what more text in the spec would change . 
 This is just about this one paragraph : The concrete proposal would be to remove this paragraph . 
 Discussed in ZRH . Proposed resolution is to close with no action . 
 I will make a proposal for an editorial PR for the paragraph mention above to make it sounds less scary that this risk exists . 
 ECN - capable is not a constant condition , but we do n't have any algorithm that governs it . I do n't think that we can just say " mark until validation of ECN counts fails " . Maybe the following algorithm is OK : When starting a new path : ECN state to " testing " N packets or M round trips , set ECN state to " unknown " every ACK , check ECN counts ECN validation fails set ECN state to " failed " . ECN validation passes and ECN state is " uncertain " , set it to " capable " . sending packets , mark with ECT(0 ) if state is " testing " or " capable " ( I know that this is unchanged text , but I just realized that we could be clearer . )  pointed out that we can add an extra thing : if a path is marked as " failed " , you MAY choose to occasionally switch back to " testing " .  pointed out that we need to deal with bleaching more than we need to worry about black holes . We should negotiate that . Originally posted by in 
 I also would suggest one more intro sentence could please some to say " When a path supports ECN , this enables ECN marking and uses ECN for a new path " - to effectively say that the validation is about how to detect and react to problems with a path that is not ECN capable . 
 Discussed in Cupertino . 
 Presumably this is just another section in Section 13.4 ? That would be useful .
Paragraph (version A):
Endpoints validate ECN for packets sent on each network path
independently.  An endpoint thus validates ECN on new connection
establishment, when switching to a new server preferred address, and
on active connection migration to a new path.
Paragraph (version B):
Endpoints validate ECN for packets sent on each network path
independently.  An endpoint thus validates ECN on new connection
establishment, when switching to a new server preferred address, and
on active connection migration to a new path.  ecn-alg describes one
possible algorithm for testing paths for ECN support.