0-RTT behaviour readonly

	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q	R	S
1		bad results	as it should be	unwanted behaviour
2
3	bytes sent by client in first flight	1370		5330		9370		41750		5330				1280	1370	5330	1370
4
5	run	run2_addressFixed_homeWifi												run3	run4	run4	run1
6		factor0	cwnd0	factor1	cwnd1	factor2	cwnd2	factor10	cwnd10	6kmax	NEW_TOKEN	*_BLOCKED		firstFlightOnly no 0RTT, with ticket	firstflightOnly 0RTT factor0	firstflightOnly 0RTT factor1	addressChanged ampfactor0	comments
7	quinn	3.12	4274.4	3.09	16469.7	3.05	28578.5	1.65	68887.5	1.33	no	no	quinn	1.23	2.04	2.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	lsquic	36.09	49443.3	9.37	49942.1	5.32	49848.4	1.34	55945	1.61	yes	data_	lsquic	1.93	40.45	10.47	36
9	aioquic	3.93	5384.1	0.14	746.2	1.47	13773.9	0.33	13777.5	0.14	no	no	aioquic	1.56	2.93	3	3.93
10	facebook	2.1	2877	3.31	17642.3	0.31	2904.7	0.07	2922.5	0.52	no	no	facebook	8.86	15.82	4.06	9.35	- 0-RTT data comes in after handshake is done due to fetch-from-origin - padded ack-only initials of 1252 bytes
11	fbcdn	12.96	17755.2	3.35	17855.5	1.9	17803	0.43	17952.5	1.69	no	no	fbcdn	8.67	15.81	4.04	6.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	fbcdnBusted	2.02	575.4	3.33	17748.9	0.31	2904.7	0.42	17535	0.54	no	no	fbcdnBusted	8.67	15.81	4.02	2.02	- same as Facebook (fetch-from-origin)
13	ngtcp2	3.91	5356.7	2.68	14284.4	1.52	14242.4	0.34	14195	1.34	no	no	ngtcp2	1.04	3		3.91	- like quinn, sends server-side MAX_DATA early
14	picoquic	3.63	4973.1	3.33	17748.9	2.44	22862.8	0.55	22962.5	2.26	yes	no	picoquic	2.46	2.58	2.8	3.63	- sends PMTUD - pads his ack-onlies to 55 bytes (probably to obfuscate their size?)
15	quiche	4.16	5699.2	2.89	15403.7	1.7	15929	0.38	15865	1.6	no	no	quiche	0.96	3	2.7		- sends H3 qpack streams in their own QUIC packet (does not coalesce, we already knew that from packetization results. This is intentional)
16	quicly	4.22	5781.4	3.26	17375.8	3.21	30077.7	2.25	93937.5	0.41	yes	no	quicly	1.98	1.42	3.01	4.22
17	f5	3	4110	3.05	16256.5	1.73	16210.1	0.4	16700
18	quinn after cwnd update	3.11	4260.7	2.41	12845.3	1.36	12743.2	0.31	12942.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