diff options
| author | eunhhu <[email protected]> | 2026-09-29 18:15:11 +0100 |
|---|---|---|
| committer | eunhhu <[email protected]> | 2026-09-29 18:15:11 +0100 |
| commit | b09bda62059e11ee43ae6d1fd62bf31e2e4fbde6 (patch) | |
| tree | 3efc11d95871bbc4445c083fe225587bd41ceeba /docs/research/094-idle-links.md | |
| parent | ed118d278e4f088a0416f11db96951231cb6851e (diff) | |
| download | pure-b09bda62059e11ee43ae6d1fd62bf31e2e4fbde6.tar.gz pure-b09bda62059e11ee43ae6d1fd62bf31e2e4fbde6.zip | |
Say what adopting the link took, and how it fares against ngtcp2 (102)
102: the spec (012) and a receiver written from it alone; the four holes
writing it found (REFUSED, the record's size, a peer's run places, the
memo's places beside) and the credit M6 showed fixed at 1,024 records;
M6 with ngtcp2 as a third, two rounds. Under reordering Pure carries the
most (45 Mbit/s; ngtcp2 29-47, quinn 1-2), under random loss the three
are the same, on a clean bottleneck Pure carries 3-5 % less (its framing,
some 112 B a packet to QUIC's 41), and where loss and reordering meet
ngtcp2 carries 1.3-3.6 times as much: undoing a loss it took for
reordering, it restores the window a real loss had cut too (its log: 22
of 34 undos past the window before the last cut; none without
reordering). Shares beside TCP stay within 25 %.
011 and the status table say so; 012 also says that a receiver answers
within 25 ms (a sender's PTO counts on it), that a shape and a record's
bytes are the app's, and why a packet of the past does no harm.
Diffstat (limited to 'docs/research/094-idle-links.md')
0 files changed, 0 insertions, 0 deletions
