Re: Hardware acceleration and packet number encryption

[Jana Iyengar <[e-mail]>]

A few quick thoughts as I catch up on this thread.

I spent some time last week working through a design using multiple PN
spaces, and it is quite doable. I suspect we'll head towards multiple PN
spaces as we consider multipath in the future. That said, there is
complexity (as Christian notes). This complexity may be warranted when
doing multipath in v2 or later, but I'm not convinced that this is
necessary as a design primitive for QUICv1.

We may want to creatively use the PN bits in v2, say to encode a path ID
and a PN, for multipath. We want to retain flexibility in these bits going
into v2. We've used encryption to ensure that we don't lose flexibility
elsewhere in the header, and it follows that we should use PNE to retain
flexibility in these bits as well. (Simplicity of design is the other value
in using PNE, since handling migration linkability is non-trivial without
it.)

This leaves the question of HW acceleration being at loggerheads with the
design in PR #1079. First, I expect that the primary benefit of
acceleration will be in DC environments. Yes, there are some gains to be
had in serving the public Internet as well, but I'm unconvinced that this
is the driving use case for hardware acceleration. I understand that others
may disagree with me here.

AFAIK, QUIC has not been used in DC environments yet. I expect there are
other things in the protocol that we'd want to change as we gain experience
deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is
not only appropriate, I would recommend it. This allows for rapid
iterations internally, and the experience can drive subsequent changes to
QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.

So, in short, I think we should go ahead with PR# 1079. This ensures that
future versions are guaranteed the flexibility to change the PN bits for
better support of HW acceleration or multipath or what-have-you.

- jana

On Mar 26, 2018 9:41 AM, "Christian Huitema" <[e-mail]> wrote:


On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:

Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_
AMD_x86_architecture it seems to imply a large range of server, desktop and
mobile chips all have a CPU instruction set available to do AES
acceleration and other similar operations (other instruction sets are also
available).

If we are considering the AES instructions then it looks like it is (or at
least will be in the near future) a sizeable proportion of the public
internet have it to be used.


Certainly, but that's not the current debate. PR #1079 is fully compatible
with use of the AES instructions. The issue of the debate is that the
mechanism in PR #1079 required double buffering, first encrypt the payload,
then use the result of the encryption to encrypt the PN. This is not an
issue in a software implementation that can readily access all bytes of the
packet from memory, but it may be an issue in some hardware implementations
that are designed to do just one pass over the data.


-- Christian Huitema