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

[Ian Swett <[e-mail]>]

I forgot there's a contradiction, because I thought we disallowed sending
mixed-CID packets.  So I'd prefer changing to MUST NOT coalesce packets
with different CIDs.  Even if you generate them and then coalesce
them(which we do), that's not that hard to enforce in the coalescing code.

On Wed, Jul 15, 2020 at 4:42 PM Mike Bishop <[e-mail]> wrote:

> 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]> 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
>
>