ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAG
1
bad resultsas it should be
unwanted behaviour
2
3
bytes sent by client in first flight
1370533093704175053301280137053301370
4
5
run
run2_addressFixed_homeWifi
run3run4run4run1
6
factor0cwnd0factor1cwnd1factor2cwnd2factor10cwnd106kmaxNEW_TOKEN*_BLOCKED
firstFlightOnly no 0RTT, with ticket
firstflightOnly 0RTT factor0firstflightOnly 0RTT factor1
addressChanged ampfactor0
comments
7
quinn3.124274.43.0916469.73.0528578.51.6568887.51.33nonoquinn1.232.042.86
- sends FC updates from server to client very early: why not just use TP's?
- same ACK is repeated with eack 1-RTT
8
lsquic36.0949443.39.3749942.15.3249848.41.34559451.61yesdata_lsquic1.9340.4510.4736
9
aioquic3.935384.10.14746.21.4713773.90.3313777.50.14nonoaioquic1.562.9333.93
10
facebook2.128773.3117642.30.312904.70.072922.50.52nonofacebook8.8615.824.069.35
- 0-RTT data comes in after handshake is done due to fetch-from-origin
- padded ack-only initials of 1252 bytes
11
fbcdn12.9617755.23.3517855.51.9178030.4317952.51.69nonofbcdn8.6715.814.046.56
- does do fetch from CDN node, but uses session ticket for address validation, so doesn't do amplification prevention when address is fixed (always sends full cwnd)
12
fbcdnBusted2.02575.43.3317748.90.312904.70.42175350.54nonofbcdnBusted8.6715.814.022.02
- same as Facebook (fetch-from-origin)
13
ngtcp23.915356.72.6814284.41.5214242.40.34141951.34nonongtcp21.0433.91
- like quinn, sends server-side MAX_DATA early
14
picoquic3.634973.13.3317748.92.4422862.80.5522962.52.26yesnopicoquic2.462.582.83.63
- sends PMTUD
- pads his ack-onlies to 55 bytes (probably to obfuscate their size?)
15
quiche4.165699.22.8915403.71.7159290.38158651.6nonoquiche0.9632.7
- sends H3 qpack streams in their own QUIC packet (does not coalesce, we already knew that from packetization results. This is intentional)
16
quicly4.225781.43.2617375.83.2130077.72.2593937.50.41yesnoquicly1.981.423.014.22
17
f5341103.0516256.51.7316210.10.416700
18
quinn after cwnd update
3.114260.72.4112845.31.3612743.20.3112942.5
Note: weird that these values are lower than the run2 without first flight only. Those are much more like the addressChanged ones. Don't have a good explanation for that at this time though...
- re-running this gives results closer to the expected values, but not always on-point... seems like some packet loss might have been involved when running these tests
19
20
take up with implementers
21
TODO: see if quicly does session ticket address validation as well (though they also use a NEW_TOKEN) -> asked this before though, re-ask if they found this problem. looking at address_changed, they don't seem to do ticket address validation though.
facebook servers do address validation based on ticket, so that explains higher values here
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100