Re: Getting to consensus on packet number encryption

[Benjamin Kaduk <[e-mail]>]

Hi Praveen,

On Wed, May 02, 2018 at 02:02:37AM +0000, Praveen Balasubramanian wrote:
> We can get (1) done but I disagree that we can decouple (2). It doesn’t make sense to require performance overhead all the time with no benefit. For the Internet, PNE can prevent ossification so it is seen as a reasonable trade-off. For the datacenter, there is no known benefit, only cost.

Most of why I am pushing back so hard on this point is that I am having a
*really* hard time getting the statement of "no benefit" (i.e., exactly zero)
to mesh with my understanding of the situation.  I don't know the best
way past this impasse -- it doesn't really seem right for me to make a
list of potential benefits and have you shoot them down, for example.  I
think maybe you are trying to make a slightly different point involving
something like ongoing operational benefits (as opposed to cost of
implementation/risk of bugs/ecosystem benefits), but I'm not entirely
sure.

> We know that there is a CPU cost, this is not speculation. Doesn’t matter if
> the cost is 1% or 10%. Hardware implementers have also raised concerns. Every

Well, I think it rather does matter for 1% vs. 10%.  If it was 0.1%
(unlikely, I suppose), then that might be "in the noise" and not worth
doing anything about, ever.  For a 1% cost, that's significant enough to
make me want to address it in my long-term plans, but it is not
necessarily a big enough impact to require immediate attention.  10%, on
the other hand, probably would require immediate attention and be a
show-stopper.

> CPU cycle we spend on things that add no value to the user should be
> questioned. Every extra instruction we execute in the hot data path leaves
> less CPU for workloads, burns more power and makes for a worse comparison
> with HTTPS over TCP. The same argument as privacy holes holds here – just

The "burns more power" argument can be applied to every single CPU
instruction; relative measures (i.e., percentage of total CPU) from
actual deployment are what I find to be most compelling.

> because there are some existing perf bottlenecks doesn’t mean we add more,
> particularly ones we cannot mitigate. I said it before that there are lots of
> ways we can improve UDP perf but I don’t know of any technique for reducing
> crypto CPU cost other than hardware offload.

And I ask again, who is "we"?  (At this point I am mostly assuming "all
QUIC implementors", but it would be nice to be sure.)

> The cost is certainly worth saving with something as simple as a negotiation
> mechanism. Am I missing something about a transport parameter being

>From the rest of the discussion, I don't think you've really sold people
on "certainly", yet.

> complicated to implement? Implementations are free to support only PNE and
> not negotiate anything else. There is actually an even simpler mechanism if a
> transport parameter is deemed as costly: if the peer sends PN = 0 in the CI,
> then its requesting no PNE and the receiver can choose to proceed or drop and
> force TCP fall back. This should take only an extra if check on the receiver
> CI processing logic to implement. I am assuming here that PNE on input of 0
> will not produce 0 so it’s a safe sentinel value.

I think some people are worried not just about the complexity/simplicity
of the mechanism implemented, but broader-scope ecosystem and
architecture issues, whether that's a general complexity reduction
initiative or more subtle issues involving middleboxes attempting to
coerce certain sorts of behavior.

-Ben