RE: Getting to consensus on packet number encryption

[Praveen Balasubramanian <[e-mail]>]

I disagree that we need any more data for not doing PNE in the datacenter. Why would we add an extra encrypt-decrypt step for no obvious benefit? The cost of this operation will keep magnifying as UDP performance improves. We have several optimizations planned for UDP, but short of hardware offload, none for crypto – this is an important trend to account for performance wise. For short packets like ACKs an extra encrypt decrypt step can become a large fraction of CPU cost over time.

If QUIC is not intended to be a general purpose transport but only for the Internet, then we should say so in the charter. Then we can invent custom protocols over UDP for datacenter scenarios and give up on interop.

Also, what is the urgency behind getting PNE adopted – is it blocking progress on interop or other issues? If it is deemed urgent then I am fine with adopting PNE as long as we add a negotiation mechanism in V1.

From: QUIC [mailto:[e-mail]] On Behalf Of Ian Swett
Sent: Monday, April 30, 2018 1:38 PM
To: huitema <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; Lubashev, Igor <[e-mail]>; Mark Nottingham <[e-mail]>; Mike Bishop <[e-mail]>; Erik Kline <[e-mail]>; Brian Trammell <[e-mail]>; IETF QUIC WG <[e-mail]>; Deval, Manasi <[e-mail]>; Kazuho Oku <[e-mail]>
Subject: Re: Getting to consensus on packet number encryption

SGTM

On Mon, Apr 30, 2018 at 4:34 PM Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:


On 4/28/2018 1:08 AM, Jana Iyengar wrote:
> I agree that negotiating PNE runs the risk of having two types of
> connections on the Internet. I agree that the risk of blockage doesn't
> seem high, but honestly, having seen how middlebox features get
> deployed, I'm not convinced that it won't happen (though I suspect
> it's unlikely to happen at a large scale). I understand the desire to
> have it off within DCs though, so I'm sensitive to that need.
>
> I'd like to hear more about why making PNE optional isn't a decision
> that we can punt to later though. I'd like to move along with PNE now,
> and come back to negotiating this as an option once we have some
> deployment work/experience in intra DC environments. I'm not yet
> convinced that this is going to be your biggest cost in an intra-DC
> environment, and if it is, then we can surely revisit this decision
> and add a param later to make PNE optional, either later in v1 or in
> v2. We are talking about a very narrow view into total cost at this
> point -- this one AES op is unlikely to be the bottleneck. But I have
> no data, and I don't think anyone has any full deployment experience yet.
>
> TL;DR: I'd like to suggest that we move ahead with PR #1079, and
> continue discussion on adding optional PNE in Issue #1296.

+1

-- Christian Huitema