Re: ECN in QUIC

[Christian Huitema <[e-mail]>]

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