Re: Need your help: different connection IDs in the same datagram

[Marten Seemann <[e-mail]>]

Let's have a look where this situation can occur:

During the early stages of the handshake it is not possible: The client
changes its connection ID used for Initial and 0-RTT packets as soon as it
receives a new connection ID provided by the server in a Retry or Initial
packet. The earliest time where a client could possibly coalesce packets
with different connection IDs is after receiving the Server Preferred
Address, and decides (for whatever reason) to not migrate to that address,
but to use that connection ID on the original path (and before the
handshake is confirmed).

The server needs to receive a NEW_CONNECTION_ID frame before it can change
connection IDs. The earliest this can happen is in a 0-RTT packet, so in
principle a server could start using that connection ID in its first flight.

I can see little reason to 1. start using a new connection ID during the
handshake and at the same time 2. to not completely switch to that
connection ID, but instead to continue using both at the same time.
To be clear, it isn't prohibited to use multiple connection IDs at the same
time (and on the same path), it's just that there's no good reason to do
so. I don't think it's too much of a burden to ask implementations that
still decide to do so to make sure that the connection IDs used in a
coalesced packet match, considering that for the receiver it's more
cumbersome to check that all connection IDs are actually valid for this
connection than to just validate that all packets use the same connection
ID.

On Wed, Jul 15, 2020 at 2:24 PM Martin Thomson <[e-mail]> wrote:

> https://github.com/quicwg/base-drafts/issues/3800 discovered a minor
> "discrepancy" in our requirements for coalescing packets.  We required that:
>
> * senders not coalesce packets for different connections in the same
> datagram.
>
> * receivers reject packets with different connection **IDs** in the same
> datagram.
>
> https://github.com/quicwg/base-drafts/pull/3870/files was the result of a
> discussion where I was convinced that looser constraints here weren't
> harmful.  The requirements would identify connections, not connection IDs.
>
> Originally, my inclination was to fix the requirement on the sender to use
> connection IDs, which would remove some linkability.  But then I was
> reminded that linkability is already defeated for several reasons.  You
> can't coalesce outside of the handshake and we require a stable path for
> the handshake AND long headers include a source connection ID that can be
> used for linkability.  So the linkability concern is basically lost.
>
> We also learned that some implementations were generating packets while
> processing incoming packets.  Later they would coalesce these into a
> datagram that might then have different connection IDs on the packets it
> contains.
>
> There has been some opposition to the proposed resolution in PR 3870.
>
> Apparently, for some, having multiple connection IDs in the same datagram
> complicates processing.  I don't understand this objection.  It seems to me
> more difficult to retain state across packets than it is to process each
> atomically.  I was hoping that Christian or Nick can explain more about how
> this affects them.
>
> Marten also indicated that there was a reason not to allow this, but if I
> understand that, this is based on some potential for future optimization,
> which could be conditional on having consistent connection IDs.  If we
> moved to a scheme that required consistent connection IDs, anyone using
> that scheme could be required to avoid coalescing different connection
> IDs.  So this seems more of a theoretical concern.
>
> And - in anticipation of maybe choosing to make senders use a consistent
> connection ID - if you might be generating coalesced datagrams with
> different connection IDs in packets, how hard would it be to ensure that
> these are consistent?  Lars and Ian, I think both of you indicated that you
> might do this.
>
>