Hi Panos, You're of course right that the bane of too much javascript probably affects the median website much more than "a few extra bytes" of key exchange material. But I do think that measuring time-to-last-byte is also tricky in other ways, for example, in the question of if/how to consider server-side processing. Probably, different things are important depending on the particular application. Probably, we should consider modeling and measuring both things in future experiments.
As an aside, we also have experimental results ( https://eprint.iacr.org/2023/734) that show that (on Android) applications sometimes do hundreds of super tiny TLS/HTTP requests, doing full handshakes each time. Now, of course, those apps probably should all be using resumption, QUIC, h/2, or h/3 but for whatever reason, they're not doing that. But at least for those bursty handshakes the time-to-first-byte of application data is pretty close to time-to-last-byte. (should this thread on networking/measurement strategies be split off and moved elsewhere? I guess it is still about post-quantum use in protocols (PQUIP) in the motivation of the discussion at least...) Cheers, Thom Op di 27 jun 2023 om 22:48 schreef Kampanakis, Panos <kpa...@amazon.com>: > Imo, we have been measuring handshake time as an indication or > performance, but time-to-last-byte or time-to-x%-byte should be used > instead. There is nothing wrong with your study Thom. It is pretty detailed > and useful. I just think that if these new algos get deployed, we would > know if their impact would be noticeable by measuring different things that > what we have been measuring so far. An 150KB (on average) web page over a > lossy LTE connection will have pretty bad user experience regardless of > adding 10-15KB of Dilithium certs or 1-2KB of Kyber keys/ciphertexts. > > > > *From:* Pqc <pqc-boun...@ietf.org> *On Behalf Of * Thom Wiggers > *Sent:* Tuesday, June 27, 2023 4:04 PM > *To:* Bas Westerbaan <b...@cloudflare.com> > *Cc:* Martin Thomson <m...@lowentropy.net>; Sofía Celi <cheren...@riseup.net>; > tls@ietf.org; p...@ietf.org > *Subject:* RE: [EXTERNAL][Pqc] [TLS] Post-Quantum TLS instantiations and > synthetic benchmarks > > > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > Hi Bas, > > > > Op di 27 jun 2023 om 14:44 schreef Bas Westerbaan <b...@cloudflare.com>: > > Thanks for preparing the excerpt; this will be helpful for many use cases. > (For the WebPKI, as you already mention, we also need to consider SCTs and > realistically crappy networks.) > > > > "this is LTE in a city", and "this is what a poor-quality rural 3G link > looks like". But alas, these don't seem to exist either. > > > > Unfortunately, it will not be as simple as plugging in a single packet > loss number and then dropping that fraction of packets. Because TCP > interpets packet loss as congestion, it grinds down to a halt much earlier > than at a loss of 2%. Instead, lossy links such as WiFi and cellular have > their own retransmission protocols hidden from TCP. > > > > Yeah, I'm all too familiar with wireless retransmission (a previous laptop > had a bad wifi chip that would drop up to 1/3rd of the packets leading to > massive latency spikes). Still, I hope that someone has a good idea on how > to best represent these facets of real-world networking in some way that is > useful for experiments :) > > > > Cheers, > > > > Thom >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
