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

[Kazuho Oku <[e-mail]>]

2020年7月16日(木) 5:43 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.
>

+1 to what Mike says here (as well as others).

We need to fix either the send side or the receive side.

Regarding which side to fix, my preference goes to fixing the receive side
(i.e. change the text to allow coalesced QUIC packets using different
DCIDs).

IIUC, that's the extension of our principle that "datagrams" can be routed,
while packets have to be handled individually.

I do understand that some of us want to reduce the cost of checking the
CIDs when their stacks receive a coalesced QUIC packet. I am not sure if
that is worth having an exception on the aforementioned principle. The
performance gain is going to be much smaller than (un)protecting packets or
processing TLS handshake messages contained in the coalesced packets.

All that said, as an implementer, I am fine with either way of fixing it.


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

-- 
Kazuho Oku