Draft: rfc9002

Commentary: Just in case you want to use this , I 've rebased . I 'll replay my suggestions too . 
 RFC 3390 states ( and RFC 5681 has similar text ): If the SYN or SYN / ACK is lost , the initial window used by a sender after a correctly transmitted SYN MUST be one segment consisting of MSS bytes . For safety reasons we should add similar text to reduce cwnd to the minimum congestion window when loss is observed / confirmed during the handshake . 
 I just spotted this deviation when reviewing a TCP issue . 
 Is that a fair comparison ? SYN - SYN / ACK is the exchange of just two packets . A QUIC handshake will involve significantly more packets : at least 3 ( ClientHello , ServerHello + Cert + SFIN , CFIN ) , in practice probably 4 - 5 , depending on the size of the certificate . And even more when TLS client authentication is used . 
 I do n't think we should change this , particularly at this point . As Marten said , there are typically multiple packets in a QUIC handshake exchange , so it 's not clear to me what the best analogue would be ? Also , Initial and Handshake keys can be discarded prior to ever processing an ACK , so there are cases one might not know whether the Initial or Handshake packets area lost . Also , I expect TCP SYN and SYN / ACKs are treated specially in many networks , so the odds of losing them is extra low in practice . 
 Let 's decouple when to change anything ( and if at all ) from the issue discussion and its resolution . No congestion reaction to loss seems incorrect to me particularly if multiple packets are involved ( which increases the probability ) . From point of view of network the loss of handshake packets should still be subject to a cc reaction otherwise under extreme congestion you could have collapse just due to new handshakes . 
  does result in a reaction . My understanding is that lost packets are reported as lost , the congestion window is reduced , and a recovery period started , just like everywhere else . The TCP behaviour is analogous to detecting persistent congestion , which I suppose is the defense QUIC provides . That is consistent and seems reasonable enough to me . If that is acceptable , we could add a note explaining the difference from TCP . That is , QUIC does not treat loss of the first packets specially like TCP does , relying instead on the same loss detection and persistent congestion mechanisms that apply to all other packets ; the only difference in handling is the retention of PTO during the handshake , which exists to address deadlocks caused by anti - amplification protections . 
 Yes , as stated , detected losses trigger a reduction in the congestion window . Additionally , PTO has exponential backoff , even though the CWND does not collapse immediately . Adding a note about the differences from TCP seems sensible to me . Additionally , TCP collapses the congestion window and declares packets lost because that 's how its mechanism to send a single ( ie : RTO ) packet works . QUIC can send a single packet without declaring packets lost or collapsing the congestion window . 
 As long as detected losses during handshake result in a reaction , we are good to go . Let 's add clarifying text and close this . Thanks !
Paragraph (version B):
TCP treats the loss of SYN or SYN-ACK packet as persistent congestion
and reduces the congestion window to one packet (RFC5681).  QUIC
treats loss of a packet containing handshake data the same as other
losses.