RE: Getting to consensus on packet number encryption

[Praveen Balasubramanian <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, May 1, 2018 8:55 AM
To: Roberto Peon <[e-mail]>
Cc: Salz, Rich <[e-mail]>; Benjamin Kaduk <[e-mail]>; Praveen Balasubramanian <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: Re: Getting to consensus on packet number encryption

On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <[e-mail]<mailto:[e-mail]>> 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

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


-------- Original message --------
From: "Salz, Rich" <rsalz=[e-mail]<mailto:[e-mail]>>
Date: 5/1/18 5:25 AM (GMT-08:00)
To: Benjamin Kaduk <bkaduk=[e-mail]<mailto:[e-mail]>>, Praveen Balasubramanian <pravb=[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: Getting to consensus on packet number encryption

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