Subject: negotiating Packet Number Protection

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 6 Sep 2018 22:55:24 +0000

Folks,

We just submitted a draft to negotiate Packet Number Protection. This would allow disabling it in environments (e.g., in a datacenter) where it may no be needed if both sides agree. Browsers, of course, would probably not bother with this.

https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00

thanks,

Gabriel, Nick, Praveen

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Sep 2018 10:05:48 +1000

This is an entirely appropriate use of transport parameters and it
looks like the design works as intended.  I tend to think that the
IETF doesn't need to publish this - this sort of extension is why we
have relatively loose registration policies - but I'm happy to have
that conversation at the appropriate time.
On Fri, Sep 7, 2018 at 8:55 AM Gabriel Montenegro

---

From: Christian Huitema <[email-masked]>
Date: Thu, 6 Sep 2018 19:09:01 -0700

This draft requests assignment of single byte code point. I would rather
not do that know, as we are discussing reserving several consecutive
codes for ACK variants and options. Would it be a deal breaker if the
option used a longer code?

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 7 Sep 2018 03:30:15 +0000

The MUST not disable PNP on internet facing nodes is too strong - you want a deployment to be able to move to a new DC while talking to the old DC - although ossification could br a concern, it is not egen limited to quasi stationært use cases.

________________________________
From: QUIC <[email-masked]> on behalf of Christian Huitema <[email-masked]>
Sent: Friday, September 7, 2018 4:09:01 AM
To: Martin Thomson; Gabriel.Montenegro=[email-masked]
Cc: QUIC WG
Subject: Re: negotiating Packet Number Protection

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Sep 2018 13:49:33 +1000

> option used a longer code?

Transport parameters don't use the varint encoding in any way right
now.  There has been the suggestion to use it for values, but I don't
believe that this was for identifiers (what is being asked for here),
or the length field.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 6 Sep 2018 21:15:02 -0700

> believe that this was for identifiers (what is being asked for here),

Yes, you are right and I am wrong. I was somehow confusing with frame
types. Transport parameters' code is a 16 bit field, so I assume they
are allocated First Come First Served.

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Fri, 7 Sep 2018 08:38:39 -0400

I agree with Mikkel that the MUST not enable it on the public internet is
either too strong or potentially impractical to enforce, so I would be
inclined to change that to a SHOULD.

I would request that this MUST not be used when voluntary/intentional
connection migration is enabled.

On Thu, Sep 6, 2018 at 11:30 PM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> The MUST not disable PNP on internet facing nodes is too strong - you want
> a deployment to be able to move to a new DC while talking to the old DC -
> although ossification could br a concern, it is not egen limited to quasi
> stationært use cases.
>
> ------------------------------
> *From:* QUIC <[email-masked]> on behalf of Christian Huitema <
> [email-masked]>
> *Sent:* Friday, September 7, 2018 4:09:01 AM
> *To:* Martin Thomson; Gabriel.Montenegro=[email-masked]
> *Cc:* QUIC WG
> *Subject:* Re: negotiating Packet Number Protection
>
> >> We just submitted a draft to negotiate Packet Number Protection. This
> would allow disabling it in environments (e.g., in a datacenter) where it
> may no be needed if both sides agree. Browsers, of course, would probably
> not bother with this.
> >>
> >>
> >>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 7 Sep 2018 15:56:41 +0000

Yes that’s fair feedback. We will get those two changes made.

From: QUIC <[email-masked]> On Behalf Of Ian Swett
Sent: Friday, September 7, 2018 5:39 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Martin Thomson <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>; gabriel.montenegro=[email-masked]
Subject: Re: negotiating Packet Number Protection

I agree with Mikkel that the MUST not enable it on the public internet is either too strong or potentially impractical to enforce, so I would be inclined to change that to a SHOULD.

I would request that this MUST not be used when voluntary/intentional connection migration is enabled.

On Thu, Sep 6, 2018 at 11:30 PM Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
The MUST not disable PNP on internet facing nodes is too strong - you want a deployment to be able to move to a new DC while talking to the old DC - although ossification could br a concern, it is not egen limited to quasi stationært use cases.

________________________________
From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Christian Huitema <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 7, 2018 4:09:01 AM
To: Martin Thomson; Gabriel.Montenegro=[email-masked]<mailto:[email-masked]>
Cc: QUIC WG
Subject: Re: negotiating Packet Number Protection

-- Christian Huitema

On 9/6/2018 5:05 PM, Martin Thomson wrote:
> <Gabriel.Montenegro=[email-masked]<mailto:[email-masked]>> wrote:
>> Folks,
>>
>>
>>
>> https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-montenegro-quic-negotiate-pnp-00&data=02%7C01%7Cpravb%40microsoft.com%7Cbdf36f5a1c304bedcc2c08d614bf1a03%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719208367114539&sdata=mJvvKauxNmo5k4%2FnQas2iicdMOARXGXSYI%2Ftnys60Bc%3D&reserved=0>
>>
>>
>>
>> thanks,
>>
>>
>>
>> Gabriel, Nick, Praveen

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 7 Sep 2018 16:17:14 +0000

Since QUIC is a general purpose transport and not just for the HTTP2/Internet scenario, IMO this mechanism should ideally have been in the core transport RFC. We were asked to write up a separate draft. What's the purpose of a draft that won't be published :-)? Will we have to keep renewing it so it doesn’t expire? That seems burdensome process wise. This should either be an informational RFC or be subsumed into the core transport RFC.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Martin Thomson
Sent: Thursday, September 6, 2018 5:06 PM
To: Gabriel.Montenegro=[email-masked]
Cc: QUIC WG <[email-masked]>
Subject: Re: negotiating Packet Number Protection

This is an entirely appropriate use of transport parameters and it looks like the design works as intended.  I tend to think that the IETF doesn't need to publish this - this sort of extension is why we have relatively loose registration policies - but I'm happy to have that conversation at the appropriate time.
On Fri, Sep 7, 2018 at 8:55 AM Gabriel Montenegro <Gabriel.Montenegro=[email-masked]> wrote:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools
> .ietf.org%2Fhtml%2Fdraft-montenegro-quic-negotiate-pnp-00&amp;data=02%
> 7C01%7Cpravb%40microsoft.com%7C482eb9e921cf4bd3bc4508d61455b743%7C72f9
> 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636718755725915944&amp;sdata=a3
> IhzBI%2BAC4tNSaz6nSQpDDF71JGpQE9jXSqPnHIp7A%3D&amp;reserved=0
>
>
>
> thanks,
>
>
>
> Gabriel, Nick, Praveen

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 7 Sep 2018 17:10:48 +0000

I agree with relaxing the MUST for Internet-facing.

There may be some future applications of future versions of QUIC where the benefits of PNP are harder to rationalise (i.e. traceabiity of mutlicasted QUIC packets that share a packet number). Indeed, there may be some other schemes that a benefit from a readble and/or deterministic packet number. However, that's all a long way off. What I like about the extension for the QUIC we have today is that it sets the right frame up for implementations that might want to do things slightly differently.

Regards
Lucas
________________________________
From: QUIC [[email-masked]] on behalf of Ian Swett [ianswett=[email-masked]]
Sent: 07 September 2018 13:38
To: Mikkel Fahnøe Jørgensen
Cc: Martin Thomson; IETF QUIC WG; Christian Huitema; gabriel.montenegro=[email-masked]
Subject: Re: negotiating Packet Number Protection

-- Christian Huitema

>> https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Christian Huitema <[email-masked]>
Date: Fri, 7 Sep 2018 21:20:14 -0700

On the "migration" point. I think that proposing the "no packet number
protection" option without also proposing the "migration not supported"
option should be treated as a protocol error.

-- Christian Huitema

On 9/7/2018 10:10 AM, Lucas Pardue wrote:
> There may be some future applications of future versions of QUIC where
> the benefits of PNP are harder to rationalise (i.e. traceabiity of
> mutlicasted QUIC packets that share a packet number). Indeed, there
> may be some other schemes that a benefit from a readble and/or
> deterministic packet number. However, that's all a long way off. What
> I like about the extension for the QUIC we have today is that it sets
> the right frame up for implementations that might want to do things
> slightly differently.
>
> Regards
> Lucas
> ------------------------------------------------------------------------
> *From:* QUIC [[email-masked]] on behalf of Ian Swett
> [ianswett=[email-masked]]
> *Sent:* 07 September 2018 13:38
> *To:* Mikkel Fahnøe Jørgensen
> *Cc:* Martin Thomson; IETF QUIC WG; Christian Huitema;
> gabriel.montenegro=[email-masked]
> I agree with Mikkel that the MUST not enable it on the public internet
> is either too strong or potentially impractical to enforce, so I would
> be inclined to change that to a SHOULD.
>
> On Thu, Sep 6, 2018 at 11:30 PM Mikkel Fahnøe Jørgensen
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The MUST not disable PNP on internet facing nodes is too strong -
>     you want a deployment to be able to move to a new DC while talking
>     to the old DC - although ossification could br a concern, it is
>     not egen limited to quasi stationært use cases.
>
>     ------------------------------------------------------------------------
>     *From:* QUIC <[email-masked]
>     <mailto:[email-masked]>> on behalf of Christian Huitema
>     <[email-masked] <mailto:[email-masked]>>
>     *To:* Martin Thomson;
>     Gabriel.Montenegro=[email-masked]
>     <mailto:[email-masked]>
>     *Cc:* QUIC WG
>     > <Gabriel.Montenegro=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> Folks,
>     >>
>     >>
>     >>
>     >> We just submitted a draft to negotiate Packet Number
>     Protection. This would allow disabling it in environments (e.g.,
>     in a datacenter) where it may no be needed if both sides agree.
>     Browsers, of course, would probably not bother with this.
>     >>
>     >>
>     >>
> http://www.bbc.co.uk <http://www.bbc.co.uk>
> This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless specifically
> stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 10 Sep 2018 22:01:21 +0000

Thanks folks for the comments and suggestions.

They seem reasonable, namely

  *   relaxing from a MUST NOT to a SHOULD NOT on internet-facing clients
  *   requiring disable_migration as well.

New version here: https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-01

Is this simple enough to include in the transport document? Alternatively, it would be great if this could be published as an informational (or experimental) document to make it a stable reference.

Thanks,

Gabriel

From: QUIC <[email-masked]> On Behalf Of Christian Huitema
Sent: 7 September, 2018 21:20
To: [email-masked]
Subject: Re: negotiating Packet Number Protection

On the "migration" point. I think that proposing the "no packet number protection" option without also proposing the "migration not supported" option should be treated as a protocol error.

-- Christian Huitema

Regards
Lucas
________________________________
From: QUIC [[email-masked]<mailto:[email-masked]>] on behalf of Ian Swett [ianswett=[email-masked]<mailto:ianswett=[email-masked]>]
Sent: 07 September 2018 13:38
To: Mikkel Fahnøe Jørgensen
Cc: Martin Thomson; IETF QUIC WG; Christian Huitema; gabriel.montenegro=[email-masked]<mailto:gabriel.montenegro=[email-masked]>
Subject: Re: negotiating Packet Number Protection
I agree with Mikkel that the MUST not enable it on the public internet is either too strong or potentially impractical to enforce, so I would be inclined to change that to a SHOULD.

-- Christian Huitema

On 9/6/2018 5:05 PM, Martin Thomson wrote:
>> https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-montenegro-quic-negotiate-pnp-00&data=02%7C01%7CGabriel.Montenegro%40microsoft.com%7C82c986f3194048f795e108d615427fd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719772700583188&sdata=bwlaL%2FgyUxAxXBl%2BrraKlkCvZKYtxV8i8oI55ijCzK4%3D&reserved=0>
>>
>>
>>
>> thanks,
>>
>>
>>
>> Gabriel, Nick, Praveen

http://www.bbc.co.uk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.co.uk&data=02%7C01%7CGabriel.Montenegro%40microsoft.com%7C82c986f3194048f795e108d615427fd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719772700583188&sdata=trJmli6Qlnd3PUJejUnkLP5SUWMuonzJXvIPuFtLt7c%3D&reserved=0>

---------------------

---

From: Christopher Wood <[email-masked]>
Date: Mon, 10 Sep 2018 15:19:01 -0700

On Mon, Sep 10, 2018 at 3:01 PM Gabriel Montenegro
<Gabriel.Montenegro=[email-masked]> wrote:
> relaxing from a MUST NOT to a SHOULD NOT on internet-facing clients
> requiring disable_migration as well.
>
>

Albeit simple, I want to echo Martin's earlier comment in that this
should remain as an extension (if anything at all). I don't think this
sort of knob should be added to the transport document.

Best,
Chris

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 12 Sep 2018 19:23:35 +0000

> sort of knob should be added to the transport document.

Yes, definitely an extension sounds good.

Lars/Mnot, any thoughts on informational RFC status for the negotiating PNP draft? Perhaps for discussion in New York?

Gabriel

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Sep 2018 09:17:57 +0300

Hi,

> Lars/Mnot, any thoughts on informational RFC status for the negotiating PNP draft? Perhaps for discussion in New York?

I'd say pick what you think is most appropriate, given that it's an individual document at this stage.

Since I guess you'll ask for WG adoption eventually, it'd probably be helpful if that status reflected what you think the consensus of the WG feedback is you've gotten so far. Which of course does not guarantee that the broader WG wouldn't want to change it during the adoption discussion.

Lars

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 14 Sep 2018 00:29:32 +0000

> Since I guess you'll ask for WG adoption eventually, it'd probably be helpful if
> that status reflected what you think the consensus of the WG feedback is
> you've gotten so far. Which of course does not guarantee that the broader WG
> wouldn't want to change it during the adoption discussion.Thanks, Lars.

I've gotten some private nods from folks who think informational RFC would make sense, so that's what I would go for. 

This is reflected now in the "intended status":
https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-02

Is it ok to ask for adoption for info RFC at this point?

Thanks,

Gabriel