Draft: draft-ietf-quic-transport

Commentary: Cleans up ECN verification text . . 
 I 've taken in all feedback and reworked this section a fair bit . It 's structured differently now , PTAL . 
 The wall of commits is a little disconcerting there . 
 I think this is ready . Unless someone disagrees , I 'll mark the corresponding issue as proposal - ready tomorrow . 
 I do n't think that we 'll find new objections . I marked it myself . 
 Section 13.3.2 " ECN Verification " Although I understand the intent here , retransmission timeouts , as a term , do n't exist anymore in QUIC except during handshakes . Disabling ECN after any PTO firing seems a bit extreme , so I 'd like to see a better recommendation here , which covers both handshakes and short headers . 
 Fixing the naming(retransmission timeout to probe timeout ) is trivial , but I 'm not sure what to recommend here for when to disable ECN . Also , probe timeouts do n't occur until the handshake is complete , is that a problem ? One idea that 's somewhat in keeping with RFC3168 would be to disable ECN on crypto handshake timeouts and probe timeouts , and if the un - marked packets get through and the marked do not , disable ECN . But even that is subject to random loss and I believe is likely to spuriously trigger . We could disable ECN temporarily on only the second timeout , to reduce the chance of spurious disabling ? RFC8311 ( ) says we can do something different from 3168 if we document it , but does n't specify what . Is there some useful RFC I can cite that I have n't found , or are we on our own in designing a mechanism here ? 
 I reclassified this as design , because it 's not just the name update . If we decide to just fix the name , then we can change it back . Correct me if I 'm wrong . 
 How about probing ECN on even packet numbers for the first N packets before making a decision , where N is tunable . 
 I believe what the text was actually meant to say was that if you set the ECT code point and you loose ALL packets with the code point set , you MAY disable it . 
 What says makes sense . We do n't need to document a full algorithm here , but the proposed text works for me . 
 So the intention here is that if you hit an ECN blackhole that you disable ECT marking the sent packet in a timely fashion to minimize the impact on connection establishment . And I do n't think a single sender behavior is necessary . 
 mentioned that this should be triggered on persistent congestion . 
 Agreed in London for to write a PR . 
 Just to clarify : RFC8311 permits other uses that are specified by an RFC : i.e. , currently this is  , and the expected RFC to be published by the L4S work items in TSVWG ( expecting to be Lc'ed later in 2019 ) . 
 There seems two things : • What to do during handshake ( maybe is described in transport ) • Disabling after handshake which I think is in the loss / recovery draft , rather than transport ? - I thought I heard  argue that this reaction depends on the loss / marking observations on the path - which I would agree with . 
 is that ready for a consensus call ? 
 There are a lot of open comments on the PR , so I think not yet ? 
 Not yet , the PR needs some work .
Paragraph (version A):
An endpoint can verify support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in ecn-
verification.
Paragraph (version A):
To use ECN, QUIC endpoints first determine whether a path supports
ECN marking and the peer is able to access the ECN codepoint in the
IP header.  A network path does not support ECN if ECN marked packets
get dropped or ECN markings are rewritten on the path.  An endpoint
verifies the path, both during connection establishment and when
migrating to a new path (see migration).
Paragraph (version A):
If an ECT codepoint set in the IP header is not corrupted by a
network device, then a received packet contains either the codepoint
sent by the peer or the Congestion Experienced (CE) codepoint set by
a network device that is experiencing congestion.
Paragraph (version A):
If a QUIC packet sent with an ECT codepoint is newly acknowledged by
the peer in an ACK frame without ECN feedback, the endpoint stops
setting ECT codepoints in subsequent IP packets, with the expectation
that either the network path or the peer no longer supports ECN.
Paragraph (version A):
Upon successful verification, an endpoint continues to set ECT
codepoints in subsequent packets with the expectation that the path
is ECN-capable.
Paragraph (version A):
If verification fails, then the endpoint ceases setting ECT
codepoints in subsequent IP packets with the expectation that either
the network path or the peer does not support ECN.