Connection overhead

[huitema]

Looking at the logs of a client session, we see the following packets exchanged in the trace:

1- Client initial, 1232 bytes
2- Server initial + server handshake, 1232 bytes
3- Server handshake + 1rtt (8new connection_id), 531 bytes
4- Server PMTU probe, 1440 bytes
5- Client Initial(ack) + Handshake(finished) + 1-RTT(8new connection id + DNS query), 1232 bytes
6- Client MTU probe, 1440 bytes
7- Server 1RTT (ACK + ACK Frequency), 55 bytes
8- Client 1RTT (ACK + ACK Frequency), 55 bytes
9- Server 1RTT (Handshake done), 55 bytes
10- Server 1RTT (ACK), 55 bytes
11- Client 1RTT (ACK), 55 bytes
12- Server 1RTT (DNS response) 85 bytes

That seems like a lot of messages for a simple exchange. Things to consider:

• Is the PMTU probe really needed? No actual message was more than a few 100 bytes.
• Do client and server need to send 8 connection IDs?
• Do client and server really need to select the ACK Frequency extension?
• Why is the server sending 7 and 9 in separate packets?
• Why did we not see 1RTT?

Some of the extra packets may disappear later.

[huitema]

Setting the right parameters does reduce the number of messages from 12 to 8:

1- Client initial, 1232 bytes
2- Server initial + server handshake, 1232 bytes
3- Server handshake + 1rtt (2new connection_id), 241 bytes
4- Client Initial(ack) + Handshake(finished) + 1-RTT(2new connection id + DNS query), 1232 bytes
5- Server 1RTT (ACK), 55 bytes
6- Server 1RTT (Handshake done), 55 bytes
7- Client 1RTT (ACK), 55 bytes
8- Server 1RTT (DNS response) 85 bytes

There are still a couple issues:

• Should the client really send an Initial ACK? This is not necessary if the handshake key is available, and it forces padding of the message to full MTU size.
• Why is the server not coalescing ACK and Handshake Done?
• Why do we not see the "New Ticket" in a crypto frame from the server?

[huitema]

With 0-RTT enabled, the exchanges are:

1- Client initial + 0-RTT (DNS query), 1232 bytes, including 669 bytes of padding
2- Server Initial + handshake + 1-RTT (Crypto ticket, 2x new connection ID), 606 bytes
3- Client Initial (ack) + Handshake (finished) + 1 RTT (2x new connection ID) 1232 bytes, including 1010 bytes of padding
4- Server 1RTT(handshake done) 55 bytes
5-Client 1-RTT(ACK) 55 bytes
6- Server 1-RTT (DNS response) 85 bytes

Looks almost fine, except for:

• Initial ACK in packet Basic UDP test. #3 causes 1010 bytes of padding.

This is a picoquic issue: private-octopus/picoquic#849.