Subject: Re: What to do about multipath in QUIC

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 16 Nov 2020 10:19:06 -0800

Why not use the connection ID for encoding the PN?

Mikkel

On 16 November 2020 at 19.12.02, Christian Huitema ([email-masked])
wrote:

Kazuho,

You are proposing to use a transform, in which the AEAD "sequence" is
the conjunction of a sequence number space identifier and the number
within that space. I agree that doing that solves the uniqueness
requirement, but I have two concerns.

First, your original proposal allocates just 2 bits for the sequence
number space identifier. You observe that the sequence number is encoded
as a varint, which can only encode 62 bits of value, and thus we can
reuse the two high order bits to encode a number space identifier. But
what happens if the connection uses more than 4 number spaces?

Second, we have a synchronization issue. At what point do nodes start
using the "path-specific" number space? If we want to be robust, don't
we need to encode a number space identifier in the packet header?

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 16 Nov 2020 11:56:12 -0800

> Why not use the connection ID for encoding the PN?

First, using the connection ID is a trade-off between ease of management
and transmission overhead. Some major client implementations use
zero-length CID precisely because of that. The combination of
zero-length CID on the client and long CID on the server works well,
allows for migration and NAT rebinding, and provides the lowest overhead
when the bulk of the transmission is from server to client.

Second, the life of the CID is not quite the same as the life of a path.
CID are only associated to paths when packets are sent with that CID on
that path. If we go for path specific packet numbers and encryption
contexts, we may well have transitions between using a given CID with
the default encryption context and allocating a specific encryption
context to the path.

And then, there is the issue of NAT rebinding. Suppose that the receiver
identifies a path by its 4 tuple, which is the only option if the CID is
zero length. In the case of NAT rebinding, the packets are suddenly
arriving on a new path. What key do you use for that new path? I think
the only safe way to do that is to carry a PN space identifier in the
packet header.

My initial feeling is that using a single key and a single PN avoids all
that key-management complexity. Clearly that's a trade-off: senders must
keep track of which PN was sent on what path, and the ACK frames may
become longer due to out-of-order arrivals. I believe this is an OK
tradeoff, because managing several number spaces and several encryption
keys also adds its own complexity. I prefer the single PN space design
because it puts all the complexity on the sender side -- a peer that
can't be bothered will just accept packets coming from whatever path,
and send on a single return path following pretty much the QUIC V1 logic.

-- Christian Huitema

>
> On 16 November 2020 at 19.12.02, Christian Huitema
> ([email-masked] <mailto:[email-masked]>) wrote:
>
>> Kazuho,
>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 16 Nov 2020 12:26:01 -0800

Clear 0-length CID is special, but I wonder if it makes sense to discuss
multi path in the context of 0-length CID. Already migration is severely
limited in that case.

Keeping track of that path of every packet can easily double the space
needed to maintain a connection: If you store the data expicitly, it
becomes a signficant overhead since a packet state can be recorded with a
few bits. If you store each packet in a per path collection, you cannot
coalesce ranges, causing each collection to swell, and you have multiple
places to look for the packet (or just one if you know where to look). Or
you can split the PN on the lower bits but that limits the number of
concurrent paths artificially.

Granted there might not be a 1-1 CID to path, but there could be if you
design it so. Especially if you allow nat rebindings to count as a single
paths in the terms of PN space and RTT etc.

If we still want to have 0 length CID on multi-path we could make a sepcial
allowance for very very short CIDs.

I have not thought this out in all details, so maybe using a CID in this
way is a bad idea, but up front I find it compelling even if not fully
solved as is.

There is also something to be said about routing and hardware off-load
where a CID could be helpful. I just for splitting the load on multiple
cores - although any packet header identifier could help with that.. It’s
just that there isn’t that much space in the packet header and we don’t
want to limit the number of concurrent paths unnecessarily.

Mikkel

On 16 November 2020 at 20.56.24, Christian Huitema ([email-masked])
wrote:

Mikkel

First, using the connection ID is a trade-off between ease of management
and transmission overhead. Some major client implementations use
zero-length CID precisely because of that. The combination of zero-length
CID on the client and long CID on the server works well, allows for
migration and NAT rebinding, and provides the lowest overhead when the bulk
of the transmission is from server to client.

Second, the life of the CID is not quite the same as the life of a path.
CID are only associated to paths when packets are sent with that CID on
that path. If we go for path specific packet numbers and encryption
contexts, we may well have transitions between using a given CID with the
default encryption context and allocating a specific encryption context to
the path.

And then, there is the issue of NAT rebinding. Suppose that the receiver
identifies a path by its 4 tuple, which is the only option if the CID is
zero length. In the case of NAT rebinding, the packets are suddenly
arriving on a new path. What key do you use for that new path? I think the
only safe way to do that is to carry a PN space identifier in the packet
header.

My initial feeling is that using a single key and a single PN avoids all
that key-management complexity. Clearly that's a trade-off: senders must
keep track of which PN was sent on what path, and the ACK frames may become
longer due to out-of-order arrivals. I believe this is an OK tradeoff,
because managing several number spaces and several encryption keys also
adds its own complexity. I prefer the single PN space design because it
puts all the complexity on the sender side -- a peer that can't be bothered
will just accept packets coming from whatever path, and send on a single
return path following pretty much the QUIC V1 logic.

-- Christian Huitema

Kazuho,

-- Christian Huitema