Draft: draft-ietf-quic-transport

Commentary: This does n't address both editorial clarifications in , but the second one is now getting covered in . 
 This is awkward , because the issue of assumptions about the path appears spread over multiple places . Section 9.4 of draft - ietf - quic - transport : The capacity available on the new path might not be the same as the old path . Packets sent on the old path SHOULD NOT contribute to congestion control or RTT estimation for the new path . GF : That would be fine IF the new path were a separate CC context , which I am not yet clear whether it is , read on : — Section 9.4 of draft - ietf - quic - transport : 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 . GF : Why not MUST ? - because I think this is a new path , I think it can only be should if something can confirm this is the same set of network - devices and classifiers on the path . I do n't know how you would know that , and I do n't like the guess . — draft - ietf - quic - transport : 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 . GF : So . maybe this is the guess , and I do n't believe it ! In a world of ECMP and other methods , this needs to be treated as a potential change of path . — Section 9.4 of draft - ietf - quic - transport : While multiple paths might be used during connection migration , a single congestion control context and a single loss recovery context ( as described in [ QUIC - RECOVERY ] ) may be adequate . GF : Well it could if the paths WERE known to be identical , but how would an endpoint guarantee that ? Section 9.2 of QUIC transport seems to suggest the CC is reset for the new path , which I would agree with , but which part of QUIC recovery says that ? — draft - ietf - quic - recovery : For instance , an endpoint might delay switching to a new congestion control context until it is confirmed that an old path is no longer needed ( such as the case in Section 9.3.3 ) . GF : This seems underspecified and novel to me . I think it may b quite OK to continue using the old path and the old CC , for a while . Same question : is this implying the two paths share a single CC and is there some real mechanism to detect that they are really the same set of network devices on path ? 
 1 ) SHOULD NOT -MUST NOT Suggestion : " New paths have new congestion control contexts , implementations can reset the existing congestion control context . " 2 ) In keeping with the first resolution , it 's a new CC , and whether a new CC is created or the existing one is reset is an implementation decision . 3 ) Instead of saying it 's the same path , say that the path parameters(RTT and CC state ) are likely to be similar . 4 ) This is resolved with the resolution to 1 , we can decide where the implementation note should live . 5 ) ( In Section 9.4 of transport ) This is really " A path can be validated , but not switched to immediately , particularly in the presence of a potential attack . When you switch , you need to use a new(or reset ) congestion controller . " 
 For 5 , we need to say a bit more about the fact that the attack is that when a sender receives data on a new path causing it to potentially reset its CC state immediately if it switches immediately . 
 For 1,2,4 : I think this was always the intent -- some implementations do n't want to have two CC contexts so they can reset it and start with zero assumptions about the new path . Implementations that are okay with having more than one will make a new one and use that on the new path , switching back to the old one if they use the old path and the information is still relevant ( i.e. it 's been < 1 RTT and you decided the new path was n't actually better -- pick some threshold I do n't have a strong preference ) . 3 : Yes , it 's not necessarily exactly the same path . An endpoint that wants to put in extra effort in determining which paths are equivalent to make a smarter decision can do so while the default behavior is a complete reset every time ( after confirming the migration ) . This also impacts ( 5 ) around some of the attacks . 5 : I agree with we should be a bit more explicit about preventing an off - path attacker from being able to cause continuous resets as you go back and forth between paths , that 's a good case where you would want to keep CC state around ( if you 're being told to swap multiple times per - RTT you 've got other issues , too , which are mostly addressed but might need some more text , likely in transport ) . 
 Discussed in Cupertino . to propose a PR , current belief is that it will be  ( classifying as such ) ; if not , we 'll reclassify . 
 We 've summarized some discussion for these above , but to go through the resolution plan for concrete changes for each one : The intent here was that either ( a ) you only ever have a singe CC context and you reset it for each path , or ( b ) you have a CC context for each path , in which case each context is strongly tied to a path and you do n't need to reset anything . We require that everyone does at least ( a ) , while not preventing folks who want to do extra work for a potential performance gain from doing ( b ) . Addressing this in a PR : They can contribute to the CC / RTT estimation for the old path if it 's still around and you 're willing to maintain that state , which is why this ( mistakenly ) was a SHOULD . Yes , this should be a MUST , because the CC / RTT for that path has to be reset for a new address , either by making a new one for the new path and keeping the old one around for the old path , or by resetting your single one . This is now a MUST in the current editor 's copy . A very good point ! This is now : This seems to address the need for caution here . This is intended to say that you are n't required to maintain additional per - path state , it 's adequate to reset it for each path . In recovery , the section entitled " Handshakes and New Paths " discusses initial values to use on a new path . In general , recovery seems to be an instance of CC / LR , so if transport instructed you to toss out the old one and make a new one , you 'd be using initial values , etc . as specified in recovery . Transport does require that you reset CC / RTT a few paragraphs above ( as noted in your previous comment ): I do n't think we 're trying to specify a new mechanism to determine equality of paths across a network . The intent here is to recommend that an endpoint be a little bit cautious about throwing out its state before it knows it 's really going to be sticking with the new path . 
 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 .
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.
Paragraph (version B):
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).