Love the directional extended stats...

[moeller0]

It seems that the extended stats are now reported per direction:
´´´
07-18-2023 16:15:31 UTC Go Responsiveness to mensura.cdn-apple.com:443...
Baseline RPM: 3274 (P90)
Baseline RPM: 3425 (Single-Sided 5% Trimmed Mean)
Download: 88.364 Mbps ( 11.046 MBps), using 7 parallel connections.
Extended Statistics:
Maximum Path MTU: 1500
Maximum Send MSS: 1440
Maximum Recv MSS: 1440
Total Retransmissions: 0
Total Reorderings: 21
Average RTT: 46647.142857142855

Download RPM: 541 (P90)
Download RPM: 835 (Single-Sided 5% Trimmed Mean)
Upload: 41.232 Mbps ( 5.154 MBps), using 9 parallel connections.
Extended Statistics:
Maximum Path MTU: 0
Maximum Send MSS: 0
Maximum Recv MSS: 0
Total Retransmissions: 0
Total Reorderings: 0
Average RTT: 0

Test did not run to stability, these results are estimates:
Upload RPM: 944 (P90)
Upload RPM: 2357 (Single-Sided 5% Trimmed Mean)
Final RPM: 606 (P90)
Final RPM: 2300 (Single-Sided 5% Trimmed Mean)
Working Conditions RPM Effect: 138% (P90)
Working Conditions RPM Effect: 39% (Single-Sided 5% Trimmed Mean)

´´´
However the client only has numbers for the download direction, the Upload stats always seem to be empty (at least in my cursory testing). My gut feeling is that the server would need to collect and send this information for us, so this would either need to be part of the spec or some fancy optional mode at least for the go-server application? Alternatively, maybe just report the numbers the client knows about once, but with a label indicating the direction. Sure people should be able to get the direction from first principles, but would it not be more user friendly to just label the report "Extended Statistics (server to client):"?

[moeller0]

Thinking this a bit over, I wonder about my assumptions a bit.
I guess the MTU should be identical in both directions, and the MSS is already reported directionaly, upload reorderings requires information from the remote end (but is partially contained in the ACKs) but number of retransmissions in upload direction should known to the client stack, after all it executes these retransmissions... and the RTT is bidirectional by definition...
So maybe just add a "Download" string between Total and Retransmissions/Reorderings (and potentially add Total Upload Retransmissions if that number can be deduced? That way a single report might suffice. Also if ECN usage and number of CE marks could be reported as well that would be sweet. But even as is this is a pretty cool feature!

[hawkinsw]

Hello!!

I think that you are going to like what we just did!! Let me know your thoughts!! If everything looks okay, feel free to close!!

[moeller0]

Indeed:
´´´
07-19-2023 16:47:38 UTC Go Responsiveness to mensura.cdn-apple.com:443...
Baseline RPM: 3234 (P90)
Baseline RPM: 3418 (Single-Sided 5% Trimmed Mean)
Download: 86.235 Mbps ( 10.779 MBps), using 6 parallel connections.
Extended Statistics:
Maximum Path MTU: 1492
Maximum Send MSS: 1208
Maximum Recv MSS: 1208
Total Retransmissions: 0
Total Reorderings: 18
Average RTT: 43295

Download RPM: 602 (P90)
Download RPM: 920 (Single-Sided 5% Trimmed Mean)
Upload: 37.984 Mbps ( 4.748 MBps), using 10 parallel connections.
Extended Statistics:
Maximum Path MTU: 1492
Maximum Send MSS: 1208
Maximum Recv MSS: 1208
Total Retransmissions: 2
Total Reorderings: 30
Average RTT: 26261.2

Upload RPM: 831 (P90)
Upload RPM: 2226 (Single-Sided 5% Trimmed Mean)
Final RPM: 630 (P90)
Final RPM: 2135 (Single-Sided 5% Trimmed Mean)
Working Conditions RPM Effect: 135% (P90)
Working Conditions RPM Effect: 46% (Single-Sided 5% Trimmed Mean)
´´´

I like it! Still don't understand how the reorderings are detected for the upload direction (assuming 1 ACK every two full MSS segments a simple inversion of two packets will only be visible if an ACK was released between the two, but I am quite TCP naive so this might be just my lack of imagination).