Re: [quicwg/base-drafts] PTO after handshake completion is not well-defined (#3831)

[Kazuho Oku <[e-mail]>]

@martinthomson Yes.

@marten-seemann 
> The problem is that this is not a "real" tail. It's only a tail because we have different packet number spaces. Note that the server completes the handshake when receiving the CFIN, which is also when it derives the client 1-RTT secret. This means there's no way it could have received and processed an ACK for any 1-RTT packet.

I would point out that the example is a corner case. It is about the first flight of the server getting lost, then the first set of PTO probes reaching the client. The assumption is that there were some 0.5 RTT data in the first flight but none in the first set of PTO probes.

While that could happen in practice, as the amount of data the server is allowed to send is different between the two occasions, I would point out that the amount of Initial and Handshake data could be less than the amount of data you could send as a PTO probe (e.g., when resuming a connection or when certificate compression is used). In such case, the server would be sending 0.5 RTT data in the first PTO event. I think that is a fine thing to do.

To paraphrase, the example is about the server sending 0.5 RTT probes than it could have, due to the space of probes being restricted. That's why I do not think it's important to consider about the example.

As previously stated, I do think that there is are issues regarding the interaction of handshake and PTO probes, but my point is that there is nothing wrong with how the PTO timeout is being calculated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3831#issuecomment-655247801