RE: ECN in QUIC

[Mike Bishop <[e-mail]>]

I may have missed the final state where this landed, but with Martin's reworking of the key schedule that includes the Connection ID in the key generation, wouldn't you automatically have a different encryption context any time you intentionally changed Connection IDs (which is likely when changing paths) anyway?

And if you don't change Connection ID, you're already linkable because of the CID, so you don't care if you're continuing to use the same sequence numbers.  (But we agreed to encrypt them anyway.)

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Christian Huitema
Sent: Thursday, January 25, 2018 2:11 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; Lubashev, Igor <[e-mail]>; Brian Trammell (IETF) <[e-mail]>
Cc: Ingemar Johansson S <[e-mail]>; QUIC WG <[e-mail]>; Bob Briscoe ([e-mail]) <[e-mail]>
Subject: Re: ECN in QUIC

On 1/25/2018 12:10 AM, De Schepper, Koen (Nokia - BE/Antwerp) wrote:

> Some questions related to the remark of Christian: "We are heading towards a single packet sequence number space shared by multiple paths"
> What is the rationale behind this?
> Is the reason for this that there are currently no per path states/communications required? (because congestion control is currently out of scope, and it is currently the only per path processing required). In that case I understand why the current design of QUIC is optimizing itself towards application to application state, but we must make sure we don't make our live difficult if we have per connection state (when it is needed, like congestion control).

This is related to encryption options for multipath. I explained the design choices in https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/. AEAD encryption requires that sequence numbers do not repeat for a given encryption context. For multipath, this requirement can be met by either having separate encryption contexts per path, or having a single encryption context for all paths and using the same sequence number space for every paths. This is also a requirement when multiple paths are used for connection migration.

We had that discussion in Melbourne, and the sense of the room was clearly that having separate encryption contexts per paths was too complicated. Having a single sequence number space and a single encryption context is significantly simpler. There is a privacy issue, linkability via the sequence numbers, but that privacy issue can be addressed by encrypting the sequence numbers, and we pretty much agreed to do that. Hence my statement that "We are heading towards a single packet sequence number space shared by multiple paths".

Of course we still need to maintain per path variables for RTT, PMTU and congestion control. As long as we only support migration, that could be finessed somewhat by resetting these variables to their initial state at the end of the migration. But when we do true multipath, there will be a need to associate congestion control signals with paths. If we have a single sequence number, the way to do that is to maintain associations between packets and path, e.g. having a path tag in the packet copy kept for retransmission purposes. That's sufficient for signals like ACK or losses, but it requires that ECN signals be tied to specific packets.

-- Christian Huitema