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

[Mike Bishop <[e-mail]>]

Fundamentally, I think there has to be a change, because we currently have an inconsistent mandate – mixed-CID packets are acceptable to send, but SHOULD be dropped on receipt.

First, there’s the privacy argument, in that the CIDs in the same datagram will become linked to external observers.  I think Marten has already argued convincingly why this will be rare during a typical handshake; Christian and Kazuho have argued that a privacy-sensitive implementation will need to do a CID jump once the handshake is confirmed, at which point you’re mostly not coalescing packets anyway.  So this is a mild argument for not mixing, but I don’t think it’s dispositive.

Second, the implementation arguments appear to boil down to two camps:

  *   Implementation X generates packets independently, then packages them into datagrams.  Since all packets waiting for packaging are from the same connection, there’s currently nothing to check to see whether they’re allowed in the same datagram.  Requiring the CIDs to match would require a new check and a code path for not coalescing packets in certain cases.
  *   Implementation Y consumes packets within a datagram independently, so the validation has to be done at the datagram level before doing any packet-level activities.  A requirement that can be evaluated solely on the contents of the datagram, independent of any connection state, is more efficient.

Of these two, I currently find the latter slightly more persuasive.  The first is a check that can be done between packets without needing to access any connection state, and there are already presumably code paths for handling when a waiting packet can’t go in the datagram currently being constructed (e.g. it’s too large to fit the remaining MTU).  However, I’m sure someone with such an implementation could tell me why it’s more complicated than that.  😊

Neither of the resolutions seems more technically correct than the other; we just need to pick one.

From: QUIC <[e-mail]> On Behalf Of Ian Swett
Sent: Wednesday, July 15, 2020 3:31 PM
To: Martin Thomson <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: Re: Need your help: different connection IDs in the same datagram

I don't think this change would be difficult for our implementation, but I also don't see it as necessary.  Given where we are in the process, that alone argues for not changing it I believe.

On Wed, Jul 15, 2020 at 2:02 PM Dmitri Tikhonov <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Jul 15, 2020 at 05:23:57PM +1000, Martin Thomson wrote:
> 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.

I can provide an example from lsquic.  The datagram is parsed into
QUIC packets in one function, lsquic_engine_packet_in():

  https://github.com/litespeedtech/lsquic/blob/v2.18.1/src/liblsquic/lsquic_engine.c#L2781L2816

Each QUIC packet is processed by process_packet_in(), where a
connection is looked up:

  https://github.com/litespeedtech/lsquic/blob/v2.18.1/src/liblsquic/lsquic_engine.c#L1352L1360

The DCID check is performed lsquic_engine_packet_in(), before
process_packet_in() is called:

  https://github.com/litespeedtech/lsquic/blob/v2.18.1/src/liblsquic/lsquic_engine.c#L2793L2806

The DCID information is readily available in the datagram parsing
loop, while connection information is not.

For lsquic to support the proposed change, it would have to remember
the current connection and then query it whether it is indeed the
owner of the next DCID (A) or look up DCID in the global hash (B):

    conn = NULL;
    while (quic_packet = parse_udp(pointers)) {
        dcid = parse(quic_packet);
        if (conn)
        {
  #if VARIANT_A
            if (!conn_owns_scid(conn, dcid))
  #else
            if (conn != lookup_by_dcid(dcid))
  #endif
                continue;
        }
        conn = process_packet(quic_packet);
    }

Not that it could not be done, of course, but it is both extra work
to modify lsquic and a more inefficient mechanism: what was a simple
CID comparison is now a hash lookup.

That's why I argued [1] for having solid rationale behind the change
rather than a personal preference.

  - Dmitri.

1. https://github.com/quicwg/base-drafts/issues/3800#issuecomment-656851626