Draft: draft-ietf-quic-recovery

Commentary: Text and pseudocode have been updated . 
 I just updated the pseudocode as well , since it 's quite straightforward . 
 When the PTO is not armed due to the amplification limit and then a packet is received : , it 's important to send data for the PN spaces the PTO is armed for(Initial or Handshake ) prior to new application data . Typically PTO suggests writing new data instead of retransmitting data which may or may not be lost , but that 's not true during the handshake . This is only an issue for the server , since it 's caused by enforcing the amplification limits prior to address confirmation . This is most evident when 0 - RTT is accepted , but address validation fails , since otherwise a server would not usually have enough data to write to create a problem . 
 I went and double checked the msquic code , and we always re - enable the loss detection timer when we become " unblocked " by amplification protection logic . I thought this logic was already driven by some statement in the spec . I just went back and found this : Do we need any more than this ? 
 The potential issue is that if the PTO is armed , but should have already expired , it 's important to execute it prior to sending any pending data . I 'm working on a PR to make this clearer , and we can whether the extra clarification is necessary ? 
 I wonder whether there is something else going on . Amplification or not , 0 - RTT packets can only be acknowledged by ACK frames in 1 - RTT packets . Those can only be received after the client gets the 1 - rtt keys . So implementation should just start a short timer after the handshake completes . 
 This seems like an editorial change , please confirm . Either way , lets ensure has an opportunity to comment before landing any changes . 
  has dedicated code for this situation : I feel this is a kind of optimization or implementation techniques . 
 In response to If the WG establish a consensus on the need for a change a particular fix then this PR can be applied in the AUTH48 with AD approval . I think we need to figure out if not merging the PR until AUTH48 is the best ? It makes it simple to provide the changes to the RFC - editor , but maybe makes it harder for the rest of the community to keep track of the changes if there are no editors copy that contain all agreed things . However , considering the hopefully limited time that may make sense . 
 We can tag the versions that entered the RFC Editor queue , and then generate a diff against those at AUTH48 . 
 That tag already exists , so we are good . 
 At the moment , states , quote : " Clients MUST ensure that UDP datagrams containing only Initial packets are sized to at least 1200 bytes , adding padding to packets in the datagram as necessary . " I think this is incorrect and that " only " should be dropped , as it excludes a UDP datagram that contains an Initial and a 0 - RTT packet . Pointed out by in . 
 Technically a design change . I think that it should be any packets that contain Initial and do n't contain Handshake or 1 - RTT packets . At least , that 's what I implemented . 
 I 'll note that I think there are other requirements formulated in other sections . Perhaps define a term such a minimal initial datagram size and have the requirement in one place rather than sprinkling 1200 bytes in multiple places where it can be difficult to get the finer points ( such as UDP vs QUIC packets and with or without header size ) . For example section 14 in transport : 
 What you implemented should be fine . However , Initial + 0 - RTT coalesced in a datagram should be padded I believe and I do n't think we 're clear on that today . 
 It might be simpler to require every UDP packet that contains an Initial be padded to at least 1200 ? I 'm worried that only requiring that of Initial if there is no Handshake/1 - RTT present might be tricky on the receiver : what do I do if I receive a non - padded Initial with Handshake but I ca n't decrypt the Handshake data ? 
 What we are talking here is a requirement specific to clients , and I am not sure if a client has a chance of sending Initial and Handshake packets at the same time . Quoting of the TLS draft , " a client MUST discard Initial keys when it first sends a Handshake packet . " And even if there is a possibility of a client sending Initial and Handshake at the same moment , I do not think requiring the client to pad a packet that contains only an Initial is correct , as coalescing is an optional behavior to the send side . It would mean that clients coalescing the QUIC packets would send a non - padded datagram , while clients not coalescing would send a padded datagram . That seems like an odd behavior . 
 And yet another issue gets sucked into the wormhole that is the key discard mess . I guess that we will have to make a final determination based on the outcome of that stuff . 
 On consideration , I think that the requirement is simple and we do n't have to stress about interactions with discarding keys . If the packet contains an Initial , it 's possible that the Initial packet is the only packet that can be used by a server . Therefore , the datagram should be padded to 1200 , regardless of whatever else is included . So we strike the " only " and we 're good . See . 
 I wonder - if 0 - RTT does not have huge certificates , would it not make sense to permit small packets in this case , provided the auth token validates . But in other cases 1200 bytes must be provided . But since 0 - RTT might fail , this could then require a retransmission . Resource constrained devices might be prefer the latter . 
 Regardless of 0 - RTT , for bandwidth constrained deployments , it makes sense for a client to always send a small packet and let the server validate the path . That said , the chartered goal of V1 is to reduce the connection establishment latency , and we have explicitly decided to require clients to send full - sized packets until the path is validated . I do not think we should revisit that design . Maybe we can in v2 . 
 I do not believe that this is necessarily correct . The reason is that we have not yet nailed down Initial key discard and in at least one version , an Initial ACK would appear in the client 's second flight , but that need not be padded . 
 I think the specification should mandate padding of server initial packets as well . When I was traveling a couple weeks ago , I was on a network where , when using IPv6 , it allowed 1200 - byte UDP packets through from client to server but blackholed them from server to client . Since our implementation pads initials in both directions , we were able to detect this failure during the handshake and fall back to TCP / TLS . If the server did n't pad its initials , we would have succeeded at the handshake but never gotten an HTTP response . 
 This definitely seems like a design issue . The purpose of the padding rule is solely to limit amplification , not to establish a minimum MTU . If you want some sort of MTU rule , that should be discussed separately . 
 This issue is marked as design . Are you suggesting I should open a separate one ? 
 I believe it is dual purpose : From the current transport draft : The payload of a UDP datagram carrying the first Initial packet MUST be expanded to at least 1200 bytes , by adding PADDING frames to the Initial packet and/or by coalescing the Initial packet ( see Section 12.2 ) . Sending a UDP datagram of this size ensures that the network path supports a reasonable Maximum Transmission Unit ( MTU ) , and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address ; see Section 8 . 
 Yeah , that 's dicta as far as I am concerned . I do n't think we ever had consensus that we were going to enforce MTU here . 
 The insight I had here was this : If you are sending Initial , it is possible that this is the only packet in the datagram that can be processed by your peer . If that is the case , then a client needs to ensure that it pads the datagram as though no other packets were present . You can infer from the fact that you have Handshake keys that the server is able to process Handshake packets , and then extend that to say that if you include Handshake packets then the server wo n't need padding . But then you can extend that inference to saying that there is no need to send any Initial packets ( as the current draft does ; currently , you are not required to keep Initial keys once you are sending with Handshake keys ) . Either way , I figure that it is better to keep things simple and say " if Initial , pad " . In those cases where padding ends up being excessive , it 's only excessive for a short while . 
 I do n't know where you get this from . It 's total datagram size that matters , not the contents of the rest of the datagram ( which is why the neqo padding strategy works ) . Anyway , the algorithm you propose seems fine , but it 's not necessary , and therefore there 's no need to specify it in the spec . 
 This was my thought too . 
 I 'm not seeing a conflict between these statements . If the packet contains an Initial , the total datagram size must be at least 1200 bytes . You can achieve this by padding any packet in the payload ; I do n't think anyone is advocating for requiring the padding be in a particular spot . 
 I do n't understand what " pads the datagram as though no other packets were present " is supposed to mean , then . The way neqo does this is that it puts the packets in the datagram and then pads the rest , without any regard to what keys the server might have . 
  wording on my part . " pads the datagram as though no other packets were present " might be better as " as though no other packets can be processed by the server " . Let 's keep in mind that the proposed changes is just striking " only " in " Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes , [ ... ] " . I agree that this will result in larger packets than are ideal in a couple of cases . But the ACK - only Initial packets a client sent are most likely coalesced with other packets outside of cases where the padding is genuinely required . 
 I 'm sorry , but I still do n't see what benefit this change provides . Perhaps this would be easier next week . 
 The change makes it clear that if you send Initial+0 - RTT then you should still pad to 1200 . That 's all . Previously , you would not have been required to pad , which would have been bad . Most of the debate and discussion is about the knock - on consequences of applying the broader rule , which I do n't think are that important . And yes , the whole " when do you discard Initial keys " thing does confound things a little . 
 Discussed in Cupertino . The word " only " is to be removed from the respective sentence . Moving to  . 
 Thanks  .
Paragraph (version A):
Until the server has validated the client's address on the path, the
amount of data it can send is limited to three times the amount of
data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no
additional data can be sent, the server's PTO timer MUST NOT be armed
until datagrams have been received from the client, because packets
sent on PTO count against the anti-amplification limit.  Note that
the server could fail to validate the client's address even if 0-RTT
is accepted.
Paragraph (version B):
Until the server has validated the client's address on the path, the
amount of data it can send is limited to three times the amount of
data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no
additional data can be sent, the server's PTO timer MUST NOT be armed
until datagrams have been received from the client, because packets
sent on PTO count against the anti-amplification limit.
Paragraph (version B):
When the server receives a datagram from the client, the
amplification limit is increased and the server resets the PTO timer.
If the PTO timer is then set to a time in the past, it is executed
immediately.  Doing so avoids sending new 1-RTT packets prior to
packets critical to the completion of the handshake.  In particular,
this can happen when 0-RTT is accepted but the server fails to
validate the client's address.