Draft: draft-ietf-quic-version-negotiation

Commentary: in this example , it would be very stupid of the client to select version C and start another negotiation after the sever has indicated D is what it prefers . The server can again select D as preferred and there exits a potential loop . However , it is possible . What are the rule we have in the specification that stops this kind of loop ? 
 I 'm not sure that I understand this question . A client makes a choice about what version to attempt ( and offer ) when it creates a connection . It might learn that its versions are incompatible with a server ( with a Version Negotiation packet ) and try again , but that retry would be a separate action . But if the connection is successfully established , the negotiation is done . 
 There is at most one round of incompatible VN followed by one connection that may or may not use compatible VN to switch versions again . There is no potential for a loop here . can you clarify what you meant ? 
 The scenario i was thinking is a follows - Chosen = A , Other Versions = ( A , B ) -----------------<----------------- Chosen = D , Other Versions = ( D , C ) Chosen = C , Other Versions = ( C , D ) -----------------<----------------- Chosen = D , Other Versions = ( D , C ) Chosen = C , Other Versions = ( C , D ) -----------------<----------------- Chosen = D , Other Versions = ( D , C ) ..... is this prohibited by this specification ? can you show me the description ? also , is the following interaction by the client and server possible ? Chosen = A , Other Versions = ( A , B ) -----------------<----------------- Chosen = D , Other Versions = ( D , C ) Chosen = E , Other Versions = ( E , F ) -----------------<----------------- Chosen = G , Other Versions = ( G , H ) ........ the draft only says the client 's first flight contain This contains the list of versions that the client knows its first flight is compatible with ( A , B ) . It does not force the client to list ALL the compatible versions , so it might not list all the compatible versions . I think , there is also no requirement on the server to list ALL the compatible versions . Now server sends back another list of compatible versions ( D , C ) . This new list triggers the client to realise it knows about versions that are compatible ( E , F ) , and sends it back to the client as it has not interest in D or C. That trigger the server to reply with new list of compatible version ( G , H ) .. and this goes on . It is also possible that client made a mistake by not listing all the compatible version ( well it does not have to ) and as it is not interested in D or C , it wants to list ( E , F ) and keep in negotiating . I would like to understand the with current specification this kind of interaction is not possible and the negotiation should not go on like that . 
 The scenarios you describe are n't allowed : if the server performs compatible version negotiation it MUST select a that was included in the client 's : 
 yes , but servers are allowed to do incompatible version negotiation . in my 1st scenario , the server initiates incompatible version negotiation , the server selects D instead of C as chosen by client . The expectation here is that D will be the final negotiated version , and the version negotiation will end . But is there anything stopping the client to try to enforce it 's chosen one ( C ) again ? shall we have some to avoid this case ? in the 2nd scenario , it is not possible if A , B , C , D , E , F all are compatible . if the server starts incompatible version negotiation with ( C , D ) and client does not find any supported version , it aborts the connection . I just realized - there is no normative text for aborting the connection attempt .. As the server expresses all the versions it support in the supported versions list , the client knows there is not point on continuing with another attempt with ( E , F ) . Unless I am mistaken there is nothing now prohibiting the client to do so . It can continue to do so . 
 That does n't make sense . The server initiates incompatible version negotiation by sending a VN packet , there 's no notion of chosen version in the VN packet . There 's no need for normative text when there 's nothing else a client can do , are you saying the client could do something wrong as opposed to aborting due to lack of versions ? The client will ignore any VN packet apart from the first one : 
 right , my bad . I think I have drawn the picture wrong . Server send ( D , C ) and the client choses C but the server choses D. does this make sense ? and the main issue goes away ? sniped from my previous comment . The expectation here is that D will be the final negotiated version , and the version negotiation will end . But is there anything stopping the client to try to enforce it 's chosen one ( C ) again ? shall we have some to avoid this case ? yes . and should we try to prevent it ? OK , I see the client ignores , but what does happen then ? does it abort the connection attempt ? Is it possible for the client to start another connection attempt with complete new original versions and a new set of other versions ? 
  and I discussed this first scenario offline . In this scenario , the client indicated that it was happy with D by sending it in its Other  , so the client will be happy when D is negotiated even if it preferred C. If the client did n't like D , it could have removed D from Other  and then the connection would have negotiated C. Fair enough , this can be fixed with a small tweak - see below . Zahed and I discussed this second scenario offline as well . I wrote up to make the incompatible VN text more normative and that addresses  's concern here . Now we have normative text to guarantee a failure in that scenario . If the client wants to start a separate connection attempt later , it will restart the algorithm from the top . We explicitly decided as a WG to avoid telling the client to remember information from previous connection attempts because VN packets do n't carry an expiration date so caching them is fraught . 
 LGTM
Upon receiving the Version Negotiation packet, the client will search
for a version it supports in the list provided by the server.  If it
doesn't find one, it aborts the connection attempt.  Otherwise, it
selects a mutually supported version and sends a new first flight
with that version - this version is now the negotiated version.
Upon receiving the Version Negotiation packet, the client SHALL
search for a version it supports in the list provided by the server.
If it doesn't find one, it SHALL abort the connection attempt.
Otherwise, it SHALL select a mutually supported version and sends a
new first flight with that version - this version is now the
negotiated version.