Re: negotiating Packet Number Protection

[Christian Huitema <[e-mail]>]

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:
> 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 [[e-mail]] on behalf of Ian Swett
> [ianswett=[e-mail]]
> *Sent:* 07 September 2018 13:38
> *To:* Mikkel Fahnøe Jørgensen
> *Cc:* Martin Thomson; IETF QUIC WG; Christian Huitema;
> gabriel.montenegro=[e-mail]
> *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
> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> on behalf of Christian Huitema
>     <[e-mail] <mailto:[e-mail]>>
>     *Sent:* Friday, September 7, 2018 4:09:01 AM
>     *To:* Martin Thomson;
>     Gabriel.Montenegro=[e-mail]
>     <mailto:[e-mail]>
>     *Cc:* QUIC WG
>     *Subject:* Re: negotiating Packet Number Protection
>      
>     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
>
>
>     On 9/6/2018 5:05 PM, Martin Thomson wrote:
>     > 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=[e-mail]
>     <mailto:[e-mail]>> 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.
>     >>
>     >>
>     >>
>     >> https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00
>     >>
>     >>
>     >>
>     >> thanks,
>     >>
>     >>
>     >>
>     >> Gabriel, Nick, Praveen
>
>  
>
> ----------------------------
>
> 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.
> 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.
>
> ---------------------
>