Byte count in zerortt scenario looks funny.

[huitema]

I am trying to debug the reason why the Z scenario is marked failing between picoquic client and server in the interop run started 4/7/2020 4:21:05 AM. The output.txt file says:

2020-04-08 03:24:37,236 0-RTT size: 11119
2020-04-08 03:24:37,236 1-RTT size: 5462
2020-04-08 03:24:37,236 Client sent too much data in 1-RTT packets.

The weird part is that the client sent less than 3K in 1RTT packets, not 5.4K. How is the byte count computed?

[marten-seemann]

@huitema Can you post the pcap please?

The payload size is the sum of the payloads (as decoded by Wireshark): https://github.com/marten-seemann/quic-interop-runner/blob/536f3e661bd59f916fb0cd7a97c852fc07547833/testcases.py#L160-L172

[huitema]

I think I understand what is happening. This zip container has both the left and right traces of a Z test between picoquic server and client. There are two connections. The total provided are:

2020-04-12 08:12:41,788 Check of downloaded files succeeded.
2020-04-12 08:12:42,790 0-RTT size: 11119
2020-04-12 08:12:42,790 1-RTT size: 4877

When I checks the corresponding logs or Qvis, I see the picoquic client always sending less than 3K of 1RTT packets during the zero RTT connection: 1-RTT padding of an initial ACK for 1K, 1.4K for PMTUD, and some control packets. I realize now that the 4.8K total includes both the zeroRTT connection and the one before that, in which the client also attempted PMTUD.

But that's still very weird. The goal of your test is to verify that the "GET file-xxxx" requests are mostly sent over 0-RTT packets, not spread over 0-RTT and a complement of 1-RTT packets, or maybe sent as 0-RTT to no avail and then repeated as 1-RTT. You measure that by measuring 0-RTT and 1-RTT volume.

Problem is, 1-RTT volume does not just include delayed or repeated "GET file-xxxx" requests. In fact, there is none of that in the Picoquic recordings. But there are other 1-RTT data, the biggest ones being the PMTUD packets. I think there are simple workarounds. Instead of counting 1RTT packets, you could verify for example that all the files arrive in 1-RTT. Or you could only count the bytes sent in the second connection. Or maybe admit that there is uncertainty in the results and relax the volume test somewhat.

I suppose that I could use special parameters to disable PMTUD when doing the zeroRTT test, and the Z tests would reliably pass. But that smells of "programming to the test", and I don't want to do that.