Subject: Re: Getting to consensus on packet number encryption

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 1 May 2018 07:19:06 -0500

On Mon, Apr 30, 2018 at 09:55:31PM +0000, Praveen Balasubramanian wrote:
> 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.

There is benefit in uniformity and simplicity of implementation; I concede that
the claimed potential benefits about the middlebox ecosystem are speculative,
but the simplicity seems clear to me.

With respect to the cost of the crypto, yes we have some numbers, but AFAICT we
don't have a great view for how they will fit into the broader picture as
implementations mature, so to some extent the estimate of the magnitude of
growing cost of crypto is also a speculative position.  (Also, who is the "we"
that has several optimizations planned?)

In other words, how do we know this is not premature optimization?  Shouldn't
we wait until we have actual performance numbers before doing lots of
optimization?  I was under the impression that QUIC versions were going to be
lightweight, so putting out v1 with mandatory PNE would not preclude quickly
following with a V3 that adapts to any discovered performance concerns, whether
for datacenter usage or otherwise.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 May 2018 12:24:22 +0000

> 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?

I am concerned that people will mis-interpret the meaning of a datacenter, and think that a bunch of servers, or even a rack, in an open colo space is a "datacenter."  Computers keep getting faster.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 1 May 2018 15:13:06 +0000

Also, Prism.

-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 May 2018 10:47:38 -0500

FWIW,

On Tue, May 1, 2018 at 7:19 AM, Benjamin Kaduk <
bkaduk=[email-masked]> wrote:

> > 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.
>
> optimization?

I can't speak to whether this optimization is premature, but I do suspect
that if more people were looking at more actual performance numbers, this
conversation might converge more quickly ...

> I was under the impression that QUIC versions were going to be

Yeah, about that ...

I've been asking in a few places - most recently, at
https://datatracker.ietf.org/meeting/101/materials/minutes-101-quic-00.html
- about version appearance rates, and I haven't heard answers that sounded
like the working group had strong agreement that versions were going to
roll out pretty quickly. For example, from that conversation, I got

Spencer (as AD): *[deleted first three points, to get to] *4. (as Spencer)
don't have a good feeling about version negotiating and how much we might
roll them.

mnot: not going to wait 5 years for v2.

So, the chairs can correct me (and should, and they have before on other
topics), but I think I've heard a lot of "we don't have to get everything
perfect in QUICv1, because there will be other versions", and not a lot of
"and the other versions will appear pretty quickly".

I don't know what all the participants are thinking, but that's what the
people who are talking have been saying to me.

IMO, of course.

Spencer, as individual

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 May 2018 08:55:00 -0700

> -=R
That's a little more succinct than I would be, but yes.  How does an
application know that the flow it is initiating will traverse a topology
that is deemed to be within a controlled environment?  You can say
"configuration" but I fear it will turn up on a post-it
<https://i.kinja-img.com/gawker-media/image/upload/s--Edu6LPu9--/c_scale,f_auto,fl_progressive,q_80,w_800/194thbtyencs0jpg.jpg>if
you do.  Loads shift, resources move, and suddenly you find that host which
used to be in the same rack, being down, has load-shifted to the next
instance,  in a datacenter 500 miles away across a very different network.

Many modern deployments are also in someone else's data center, so saying
"Data center networks" doesn't say much about why you're trusting the
network inside.

Ted

> To: Benjamin Kaduk <bkaduk=[email-masked]>, Praveen
> Balasubramanian <pravb=[email-masked]>
> benefit?
> I am concerned that people will mis-interpret the meaning of a datacenter,
> and think that a bunch of servers, or even a rack, in an open colo space is
> a "datacenter."  Computers keep getting faster.
>
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 1 May 2018 16:34:28 +0000

This is not about putting plaintext data on the network, this is about not adding PNE which is intended for preventing ossification. So I don’t understand what the trust issue being referred to is in case of the rare misconfig.

Within a DC several things are different – the deployment may need different congestion control like DCTCP, different settings for various transport parameters (like minrto and max ACK delay), larger flow control window etc. This is true for TCP today. The out of box default uses the handshake RTT to make a determination of what’s intra-DC but there is rich configuration to override the default and set it based on 4-tuple filters.

And there workloads like cloud storage and live migration that are by virtue of deployment intra-DC. These cannot be load shifted as they use private IP address space.

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, May 1, 2018 8:55 AM
To: Roberto Peon <[email-masked]>
Cc: Salz, Rich <[email-masked]>; Benjamin Kaduk <[email-masked]>; Praveen Balasubramanian <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Getting to consensus on packet number encryption

On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
Also, Prism.

-=R

That's a little more succinct than I would be, but yes.  How does an application know that the flow it is initiating will traverse a topology that is deemed to be within a controlled environment?  You can say "configuration" but I fear it will turn up on a post-it  <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.kinja-img.com%2Fgawker-media%2Fimage%2Fupload%2Fs--Edu6LPu9--%2Fc_scale%2Cf_auto%2Cfl_progressive%2Cq_80%2Cw_800%2F194thbtyencs0jpg.jpg&data=02%7C01%7Cpravb%40microsoft.com%7C4da44e8ac1df4708ad8808d5af7bfca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636607869411258976&sdata=ProlSHkbF2SgMH3qdQN%2BZFokXvsEBf%2F3o9MaUnil0g8%3D&reserved=0> if you do.  Loads shift, resources move, and suddenly you find that host which used to be in the same rack, being down, has load-shifted to the next instance,  in a datacenter 500 miles away across a very different network.

Many modern deployments are also in someone else's data center, so saying "Data center networks" doesn't say much about why you're trusting the network inside.
Ted

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 1 May 2018 18:56:30 +0200

hi Ted, all,

At this point I've pretty much come around to the opinion we should just land 1079 and discuss the rest, but this conversation continues to have me worried that we're coming to consensus on a feature we do not fully understand the applicability and limitations of.

PNE's primary utility is anti-ossification. While it reduces the amount of information available to an attacker attempting to achieve linkability of flows across a purposeful path migration, or with a single-PN-space multipath design, it does not eliminate it, so expecting more than a marginal privacy benefit from the feature per se is setting oneself up for disappointment.

The reason to disable PNE in (admittedly ill-defined) "datacenter" environments is to trade off the (~1%ish) overhead for ossification protection you know you don't need because you didn't deploy anything that tries to abuse the packet number.

(on which, more below; and on preview, what Praveen said)

> On 1 May 2018, at 17:55, Ted Hardie <[email-masked]> wrote:
> 
> That's a little more succinct than I would be, but yes.  How does an application know that the flow it is initiating will traverse a topology that is deemed to be within a controlled environment?  You can say "configuration" but I fear it will turn up on a post-it  if you do.  Loads shift, resources move, and suddenly you find that host which used to be in the same rack, being down, has load-shifted to the next instance,  in a datacenter 500 miles away across a very different network.
> 

The "load-shifted to the next instance" example is an interesting one iff said load shifting causes the traffic that used to cross a private network to transit the open Internet instead. Is this a thing that ever happens in any of the environments that get called "datacenter" for networking technology purposes?

Cheers,

Brian

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 1 May 2018 17:11:03 +0000

Wait, the entire purpose of PNE is to make flow linking during connection migrations harder.  A server in an "open colo" talking to another server in an "open colo" is a perfect example when PNE is not needed.

The "uniformity and simplicity of implementation" makes sense, but we certainly did much weirder things (like a new transport) to gain performance.  Praveen's point is that a large portion of communication is between devices that are not mobile.  If PNE has a non-negligible cost (for example, HW acceleration requires more ASIC and is costlier), is "uniformity and simplicity" gained by the lack of the extra option worth it?

Another way of putting this is that QUIC's advantage over TCP is especially evident for the 90th percentile of connections, and these are likely not to be fixed server-to-server connections (within a DC or even between "open colos").  Any extra cost of QUIC over TCP (extra CPU-per-bit or server-cost-per-bit) will make it less likely that QUIC will be adopted for server-to-server connections.  Is the adoption risk and the extra costs risk worth the simplicity gained by not having an extra option?

  *   Igor

From: Roberto Peon [mailto:[email-masked]]
Sent: Tuesday, May 01, 2018 11:13 AM
To: Salz, Rich <rsalz=[email-masked]>; Benjamin Kaduk <bkaduk=[email-masked]>; Praveen Balasubramanian <pravb=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Getting to consensus on packet number encryption

Also, Prism.

-=R

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 May 2018 10:43:44 -0700

On Tue, May 1, 2018 at 9:56 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> hi Ted, all,
>
> At this point I've pretty much come around to the opinion we should just
> land 1079 and discuss the rest, but this conversation continues to have me
> worried that we're coming to consensus on a feature we do not fully
> understand the applicability and limitations of.
>
> I also think that just landing 1079 and moving on is the right thing to do.

> PNE's primary utility is anti-ossification. While it reduces the amount of
> information available to an attacker attempting to achieve linkability of
> flows across a purposeful path migration, or with a single-PN-space
> multipath design, it does not eliminate it, so expecting more than a
> marginal privacy benefit from the feature per se is setting oneself up for
> disappointment.
>
> The reason to disable PNE in (admittedly ill-defined) "datacenter"
> environments is to trade off the (~1%ish) overhead for ossification
> protection you know you don't need because you didn't deploy anything that
> tries to abuse the packet number.
>
> "configuration" but I fear it will turn up on a post-it  if you do.  Loads
> shift, resources move, and suddenly you find that host which used to be in
> the same rack, being down, has load-shifted to the next instance,  in a
> datacenter 500 miles away across a very different network.
> >
> > Many modern deployments are also in someone else's data center, so
> saying "Data center networks" doesn't say much about why you're trusting
> the network inside.
>
> The "load-shifted to the next instance" example is an interesting one iff
> said load shifting causes the traffic that used to cross a private network
> to transit the open Internet instead.

Well, a long-haul link, certainly.  That may or may not be "the open
Internet" and the chances of it traversing a completely unknown middlebox
are low.  The chances of it passing by an unknown observer, on the other
hand, are not currently known but are presumed to be high.

> Is this a thing that ever happens in any of the environments that get
> called "datacenter" for networking technology purposes?
>
>
So, the way I look at this boils down to:

If the linkability or ossification concerns with packet numbers in the
clear are justified, you either need to have it on all the time or have
very clear methods for determining when the concerns are not present.  The
protocol is not aware of the l2 or l3 topology between an initiator and its
peer, much less the management of that path.

So the clear methods for determination really boil down to "someone turns
this off when they think it is right to do so".  Flows entirely within the
domain of control of a single provider might be a case where folks think it
is right to do so.  A subset of that domain of control is when the flow has
no long-haul links (for however you want to define that), the shorthand for
which is "datacenter network" (though it might well also be a small complex
of datacenters, an enterprise campus, or similar).  But the key is that you
believe that the topology between peer A and peer B has no middleboxes
outside of the shared domain of control that might ossify the behavior and
no observers whose use of this data concerns you.

If you control both peers and the network between them, using a QUIC
version where this is always turned off might make sense.  But having  QUIC
negotiate this outside of the version does not make sense to me, because
there is no way for an initiator or a responding peer to judge whether the
other side's assertion of safety is well-founded or even well-meant.  If it
has no independent data on this (and the protocol provides none), this
allows one side or the other to unilaterally turn off an anti-ossification
and anti-linkability feature for whatever gain it wants.  Since we're
trying to optimize for the long-term flexibility of the protocol, allowing
that particular point optimization seems contrary to our interests, much
less the privacy interests of the peers.

regards,

Ted

> > I am concerned that people will mis-interpret the meaning of a
> datacenter, and think that a bunch of servers, or even a rack, in an open
> colo space is a "datacenter."  Computers keep getting faster.
> >
> >
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 1 May 2018 18:39:58 +0000

*   But having  QUIC negotiate this outside of the version does not make sense to me, because there is no way for an initiator or a responding peer to judge whether the other side's assertion of safety is well-founded or even well-meant.

Would it satisfy your concerns, if _both_ peers need to express interest in having PNE off for the PNE to be “negotiated off”?

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, May 01, 2018 1:44 PM
To: Brian Trammell (IETF) <[email-masked]>
Cc: Praveen Balasubramanian <pravb=[email-masked]>; IETF QUIC WG <[email-masked]>; Roberto Peon <[email-masked]>; Salz, Rich <rsalz=[email-masked]>; Benjamin Kaduk <bkaduk=[email-masked]>
Subject: Re: Getting to consensus on packet number encryption

On Tue, May 1, 2018 at 9:56 AM, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
hi Ted, all,

> On 1 May 2018, at 17:55, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:
>

The "load-shifted to the next instance" example is an interesting one iff said load shifting causes the traffic that used to cross a private network to transit the open Internet instead.

Well, a long-haul link, certainly.  That may or may not be "the open Internet" and the chances of it traversing a completely unknown middlebox are low.  The chances of it passing by an unknown observer, on the other hand, are not currently known but are presumed to be high.

Is this a thing that ever happens in any of the environments that get called "datacenter" for networking technology purposes?

So, the way I look at this boils down to:
If the linkability or ossification concerns with packet numbers in the clear are justified, you either need to have it on all the time or have very clear methods for determining when the concerns are not present.  The protocol is not aware of the l2 or l3 topology between an initiator and its peer, much less the management of that path.

So the clear methods for determination really boil down to "someone turns this off when they think it is right to do so".  Flows entirely within the domain of control of a single provider might be a case where folks think it is right to do so.  A subset of that domain of control is when the flow has no long-haul links (for however you want to define that), the shorthand for which is "datacenter network" (though it might well also be a small complex of datacenters, an enterprise campus, or similar).  But the key is that you believe that the topology between peer A and peer B has no middleboxes outside of the shared domain of control that might ossify the behavior and no observers whose use of this data concerns you.
If you control both peers and the network between them, using a QUIC version where this is always turned off might make sense.  But having  QUIC negotiate this outside of the version does not make sense to me, because there is no way for an initiator or a responding peer to judge whether the other side's assertion of safety is well-founded or even well-meant.  If it has no independent data on this (and the protocol provides none), this allows one side or the other to unilaterally turn off an anti-ossification and anti-linkability feature for whatever gain it wants.  Since we're trying to optimize for the long-term flexibility of the protocol, allowing that particular point optimization seems contrary to our interests, much less the privacy interests of the peers.

regards,
Ted

Cheers,

Brian

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 1 May 2018 18:59:26 +0000

Yeah this doesn’t have to be unilateral and is a negotiation. Either side is free to terminate the handshake and fall back to TCP if it doesn’t want to support the transforms being offered in the negotiation. This works perfectly fine for the intra-DC use cases.

From: Lubashev, Igor [mailto:[email-masked]]
Sent: Tuesday, May 1, 2018 11:40 AM
To: Ted Hardie <[email-masked]>; Brian Trammell (IETF) <[email-masked]>
Cc: Praveen Balasubramanian <[email-masked]>; IETF QUIC WG <[email-masked]>; Roberto Peon <[email-masked]>; Salz, Rich <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: RE: Getting to consensus on packet number encryption

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, May 01, 2018 1:44 PM
To: Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>
Cc: Praveen Balasubramanian <pravb=[email-masked]<mailto:pravb=[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Roberto Peon <[email-masked]<mailto:[email-masked]>>; Salz, Rich <rsalz=[email-masked]<mailto:rsalz=[email-masked]>>; Benjamin Kaduk <bkaduk=[email-masked]<mailto:bkaduk=[email-masked]>>
Subject: Re: Getting to consensus on packet number encryption

regards,
Ted

Cheers,

Brian

---

From: Roberto Peon <[email-masked]>
Date: Tue, 1 May 2018 23:20:08 +0000

Yup. I know.
Prism was eye-opening partially because of the fact that the packets were not going across the internet, but rather within a secure network.

I believe that ossification alone is a good enough reason to do PNE.
The cherry for me is that it, along with other actions/mitigations, makes linkability more difficult for malicious actors.
CRIME and related was eye-opening because it exposed the power of the observable side-channel.

-=R

From: QUIC <[email-masked]> on behalf of Praveen Balasubramanian <pravb=[email-masked]>
Date: Tuesday, May 1, 2018 at 9:35 AM
To: Ted Hardie <[email-masked]>, Roberto Peon <[email-masked]>
Cc: "Salz, Rich" <[email-masked]>, Benjamin Kaduk <[email-masked]>, IETF QUIC WG <[email-masked]>
Subject: RE: Getting to consensus on packet number encryption

-=R

That's a little more succinct than I would be, but yes.  How does an application know that the flow it is initiating will traverse a topology that is deemed to be within a controlled environment?  You can say "configuration" but I fear it will turn up on a post-it  <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fi.kinja-2Dimg.com-252Fgawker-2Dmedia-252Fimage-252Fupload-252Fs-2D-2DEdu6LPu9-2D-2D-252Fc-5Fscale-252Cf-5Fauto-252Cfl-5Fprogressive-252Cq-5F80-252Cw-5F800-252F194thbtyencs0jpg.jpg-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C4da44e8ac1df4708ad8808d5af7bfca8-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636607869411258976-26sdata-3DProlSHkbF2SgMH3qdQN-252BZFokXvsEBf-252F3o9MaUnil0g8-253D-26reserved-3D0&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=TuVfzypo-CZLo522lgMRrLpKxcFaHvW9kdNSI57lXT0&s=By2d_to7XzLEgAL3Or9cZc2Aykye-PZEenFQDviAUlw&e=> if you do.  Loads shift, resources move, and suddenly you find that host which used to be in the same rack, being down, has load-shifted to the next instance,  in a datacenter 500 miles away across a very different network.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 1 May 2018 23:21:20 +0000

Given much of what I we need for our deployments for pub-sub and video will not likely be in V1, ya, I’m also expecting v2 to happen quickly.
-=R

From: QUIC <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Tuesday, May 1, 2018 at 8:48 AM
To: Benjamin Kaduk <bkaduk=[email-masked]>
Cc: Praveen Balasubramanian <pravb=[email-masked]>, IETF QUIC WG <[email-masked]>
Subject: Re: Getting to consensus on packet number encryption

FWIW,

On Tue, May 1, 2018 at 7:19 AM, Benjamin Kaduk <bkaduk=[email-masked]<mailto:bkaduk=[email-masked]>> wrote:

I can't speak to whether this optimization is premature, but I do suspect that if more people were looking at more actual performance numbers, this conversation might converge more quickly ...

Yeah, about that ...

I've been asking in a few places - most recently, at https://datatracker.ietf.org/meeting/101/materials/minutes-101-quic-00.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_101_materials_minutes-2D101-2Dquic-2D00.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=7dkMb2YVXH0780vIyoRwRNriZUwhUG4n61AbEnU7PTg&s=y5lIU1Q-ygBoOaGs4EInChi2rd-ZnZkrCp82g4dqDaU&e=> - about version appearance rates, and I haven't heard answers that sounded like the working group had strong agreement that versions were going to roll out pretty quickly. For example, from that conversation, I got

Spencer (as AD): [deleted first three points, to get to] 4. (as Spencer) don't have a good feeling about version negotiating and how much we might roll them.

So, the chairs can correct me (and should, and they have before on other topics), but I think I've heard a lot of "we don't have to get everything perfect in QUICv1, because there will be other versions", and not a lot of "and the other versions will appear pretty quickly".

I don't know what all the participants are thinking, but that's what the people who are talking have been saying to me.

IMO, of course.

Spencer, as individual

-Ben

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 May 2018 22:48:36 -0500

Speaking as a curious observer with no hat on ...

On Tue, May 1, 2018 at 1:59 PM, Praveen Balasubramanian <
pravb=[email-masked]> wrote:

> Yeah this doesn’t have to be unilateral and is a negotiation. Either side
> is free to terminate the handshake and fall back to TCP if it doesn’t want
> to support the transforms being offered in the negotiation. This works
> perfectly fine for the intra-DC use cases.
>

So, please help me understand whether I'm tracking this.

Most of the time, QUIC connections are expected to traverse something like
the public Internet, so a bunch of participants want PNE as an
anti-ossification thing in this case.

Sometimes, QUIC connections would traverse only a controlled network path
(which I THINK is the point of the conversation about datacenters), for
server-to-server connections. Some participants would like to avoid any
overhead they can avoid in those situations, and don't see any need for
PNE, only additional (single-digit percentage) costs, and would like to
negotiate not using PNE for those connections.

Is that about right, so far? Assuming so ...

Is it correct that those connections are using TCP today, and are seeing
sufficiently good performance with TCP to make additional overhead look
problematic?

Is it correct that if an implementation doesn't want to use QUIC with PNE
overhead, Plan A would be to refuse the QUIC connection and fall back to
TCP?

Thanks in advance for clues ...

Spencer

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 2 May 2018 06:18:30 +0000

I think there are cases where the PNE overhead is more than single digit pct:

Small packets with, say, latest stockquote would have PNE double the packet protection overhead - and there isn’t much other overhead. This adds latency.

Another example is sending a transaction ID serially through 3 out of 5 masters to reach consensus. PNE could dominate the achievable transaction rate assuming very fast networks.

________________________________
From: QUIC <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Sent: Wednesday, May 2, 2018 5:48:36 AM
To: Praveen Balasubramanian
Cc: Ted Hardie; Salz, Rich; Lubashev, Igor; Roberto Peon; Brian Trammell (IETF); Benjamin Kaduk; IETF QUIC WG
Subject: Re: Getting to consensus on packet number encryption

On Tue, May 1, 2018 at 1:59 PM, Praveen Balasubramanian <pravb=[email-masked]<mailto:pravb=[email-masked]>> wrote:
Yeah this doesn’t have to be unilateral and is a negotiation. Either side is free to terminate the handshake and fall back to TCP if it doesn’t want to support the transforms being offered in the negotiation. This works perfectly fine for the intra-DC use cases.

Most of the time, QUIC connections are expected to traverse something like the public Internet, so a bunch of participants want PNE as an anti-ossification thing in this case.

Sometimes, QUIC connections would traverse only a controlled network path (which I THINK is the point of the conversation about datacenters), for server-to-server connections. Some participants would like to avoid any overhead they can avoid in those situations, and don't see any need for PNE, only additional (single-digit percentage) costs, and would like to negotiate not using PNE for those connections.

Is it correct that those connections are using TCP today, and are seeing sufficiently good performance with TCP to make additional overhead look problematic?

Is it correct that if an implementation doesn't want to use QUIC with PNE overhead, Plan A would be to refuse the QUIC connection and fall back to TCP?

Spencer