Re: Towards a Scalable Modular QUIC Server

[Eric Rescorla <[e-mail]>]

I'm not sure what to make of this paper:

"A single thread in cQUIC based on DPDK achieves 600 and 1000
connections/s for 2-RTT and 0-RTT, respectively.

...

Interestingly, the performance gap between the 2-RTT and 0-RTT
handshakes is around 75%, but cQUIC scarcely overcomes the threshold
of 1000 connections/s for the 0-RTT. "



1. 1000/600 = 1.667, which isn't really 75% (this is a nit).
2. As MT says, you would expect a far larger gap between any handshake
involving RSA and one which does not, so that's surprising. As MT says,
ECDSA should make this is a lot faster.


Without knowing more about their methodology, and about their profiles,
etc., I don't think we can draw that many conclusions from this beyond
what we already know from the standard microbenchmarks.

-Ekr


On Mon, Aug 21, 2017 at 5:21 PM, Martin Thomson <[e-mail]>
wrote:

> On 22 August 2017 at 10:13, Eggert, Lars <[e-mail]> wrote:
> > On 2017-8-21, at 17:06, Martin Thomson <[e-mail]> wrote:
> >> Clearly the authors didn't understand why RSA was chosen by Google.
> >
> > I asked whether they had thoughts on whether their results might be
> influenced by QUIC-Crypto and if IETF-QUIC might perform differently...
>
> ECDSA might produce entirely different results here.  The computation
> effort is largely dominated by the cost of the signature.  That is
> assuming that they used x25519 for key exchange, which is pretty close
> to zero cost in comparison to RSA.
>
>