TCP and TLS handshakes are possibly under-defined

[LPardue]

The spec says:

the test measures the time needed to , establish a TCP connection on port 443, establish a TLS context using TLS1.3 [RFC8446],

there's several variations possible here. Are we expecting clients to game this, or stick rigidly to some well-defined interactions? I'm mainly thinking about things like session resumption, or optimizing TLS handshakes in various ways like cert compression or short cert chains.

[cpaasch]

#37 (comment)

Same comment as I have made in a few other places :) Any thoughts?

[cpaasch]

Tried to clarify with af69ae2. Please reopen if that's not sufficient.

[LPardue]

Thanks. The new text text that says

the TLS establishment time needs to be
normalized to the number of round-trips the TLS handshake takes until the connection
is ready to transmit data.

is good and I like it because it applies to many different things.

However, I would clarify it just a little further and state whether "ready to transmit data" means "client is ready to send application data" or if it means something else. The reason being that in 0-RTT, the client can send application data (e.g. an HTTP request alongside the TLS data.)

I can't seem to reopen this issue, perhaps a new comment will do that.

[cpaasch]

Good point on 0-RTT. We definitely don't want to show the TLS-latency as 0 milli-seconds.

What about arguing that the test should avoid using 0-RTT ?

Or, we can say that "ready to transmit non-idempotent data", which means effectively until at least one round-trip has elapsed.

Thoughts?

[LPardue]

I think I'd need some more time to think about on 0-RTT. In reality its used a lot on the Internet, so why wouldn't we try to measure that?

For probe measurements on an active HTTP/2 connection, the TCP and TLS duration would be 0, regardless of whether the TLS session was established using 1- or 0-RTT. So it doesn't seem that hard to extend this concept of zero to a request made as part of early data on a resumed connection.

[cpaasch]

Beyond 0-RTT. Even TFO would have the same problem. We definitely need to specify this more in detail.

If an implementation solely relies on W3C-metrics, things would end up being wrong in those cases. So, we need to very carefully list that out.