RE: Getting to consensus on packet number encryption

[Praveen Balasubramanian <[e-mail]>]

Love this idea. Expanding it a bit further I don’t think we need to make PN transform a transport parameter but rather connection migration itself. We could also simply use QUIC versioning for this. 

1. Ship QUIC v1 with no support for connection migration. Servers behind load balancers that are not QUIC aware will only advertise this version. I expect this to be a large fraction of servers especially those hosted in AWS, Azure, GCP. *This is important - I want the group to acknowledge that servers needs to be able to advertise support for connection migration*.
2. Ship QUIC v2 with support for connection migration. If a client and server use this version they MUST do PNE as per #1079. If we find a more efficient scheme before November then we use that instead. 

Eventually we will ship QUIV vN which has support for multi-path and we can revisit if PNE is needed or multiple PN spaces will work. Until then I can live with higher CPU cost for the fraction of connections that will migrate. 

Now there is the ossification problem in QUIC v1 as referred to above. We already require a random starting PN. The next problem is one that Kazuho brought up where middleboxes will start seeing strict increasing PN and try to reorder. I was thinking about short random jumps to fix this problem but the monotonic increase will remain. While I think sane middleboxes will not do any reordering, there might be a few crazy outliers like with TCP. I think we can solve this by making the in clear PN jump both forward and back within a "reordering degree". I am thinking about some ideas here and will reply back if I find a simple scheme.

>> FWIW, what I got from the info that Praveen and Ian have shared is that there are enough problems to solve with UDP that worrying about the performance hit from encryption is premature
Martin, we have plans to make UDP screaming fast in software. But the real advantage for TCP comes from the batch offloads (see email with subject " Impact of hardware offloads on network stack performance"). Batch offloads for QUIC are impossible to do without crypto offload. I would be happy to explain more on this front. I think we will exhaust software optimizations soon and then get blocked on crypto offload.


-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Wednesday, April 4, 2018 9:36 PM
To: Kazuho Oku <[e-mail]>
Cc: Lars Eggert <[e-mail]>; Mark Nottingham <[e-mail]>; IETF QUIC WG <[e-mail]>; Patrick McManus <[e-mail]>
Subject: Re: Getting to consensus on packet number encryption

On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku <[e-mail]> wrote:
> It is true that #1079 has issues with hardware crypto offload. I am 
> happy to support switching to a better encryption scheme (if we find
> one) at any moment; e.g., during the standardization of QUICv1, or as 
> an extension to v1, or part of vX.

Until this came up, I hadn't considered the use of an extension/transport parameter to negotiate a new scheme, but it's obvious.  This fits best with my view of things.

If that means that we get the DC-QUIC option that turns the packet number encryption function into identity or some cheaper function, then I think that's an OK outcome.  We should stop pretending that one size fits all is achievable; it's not been the case for years already.

FWIW, what I got from the info that Praveen and Ian have shared is that there are enough problems to solve with UDP that worrying about the performance hit from encryption is premature.