Draft: draft-ietf-quic-transport

Commentary: Cleans up some text in the transport doc around reseting ( or not ) CC and RTT values on migration . 
 I think a normal transport assumption is that a change of path implies a ( potential ) loss of congestion state , and that the endpoint should reset the path CC parameters . Transport - ID : “ On confirming a peer 's ownership of its new address , an endpoint SHOULD immediately reset the congestion controller and round - trip time estimator for the new path . ” • Does the " reset " require setting the CC to the initial window value for a connection ? I think so . • Why not MUST ? Transport - ID : “ An endpoint MUST NOT return to the send rate used for the previous path unless it is reasonably sure that the previous send rate is valid for the new path . “ This could therefore be seen as a “ significant ” departure from conventional approaches considered safe - and extends this to “ reasonably sure ” . • Is there a rationale for extending this to “ reasonably sure ” , because this seems bolder than permitted for a new TCP connection . How do people quantify reasonably sure , and why not just in this case grow from the Initial window ? 
 Yes . We should articulate this better though . To allow for pre - existing knowledge , such as stored values . I think this can be changed to say " unless an endpoint has other knowledge , it MUST reset " ( or some such ) . Fair point . The intent here again was to allow pre - existing knowledge to be used , but I think the wording can be changed to reflect that more explicitly . 
 Discussed in London : to provide a PR 
 Re - opening issue . This needs a bit more work . 
 The associated issue is marked design , but this looks fine to me . Thanks , LGTMLGTM , " MUST , unless " seems like a nicer balance than the previous " SHOULD " .
Paragraph (version A):
On confirming a peer's ownership of its new address, an endpoint
SHOULD immediately reset the congestion controller and round-trip
time estimator for the new path to initial values (see Sections A.3
and B.3 in QUIC-RECOVERY).
Paragraph (version A):
An endpoint MUST NOT return to the send rate used for the previous
path unless it is reasonably sure that the previous send rate is
valid for the new path.  For instance, a change in the client's port
number is likely indicative of a rebinding in a middlebox and not a
complete change in path.  This determination likely depends on
heuristics, which could be imperfect; if the new path capacity is
significantly reduced, ultimately this relies on the congestion
controller responding to congestion signals and reducing send rates
appropriately.
Paragraph (version B):
On confirming a peer's ownership of its new address, an endpoint MUST
immediately reset the congestion controller and round-trip time
estimator for the new path to initial values (see Sections A.3 and
B.3 in QUIC-RECOVERY) unless it has knowledge that a previous send
rate or round-trip time estimate is valid for the new path.  For
instance, an endpoint might infer that a change in only the client's
port number is indicative of a NAT rebinding, meaning that the new
path is likely to have similar bandwidth and round-trip time.
However, this determination will be imperfect.  If the determination
is incorrect, the congestion controller and the RTT estimator are
expected to adapt to the new path.  Generally, implementations are
advised to be cautious when using previous values on a new path.