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

[David Schinazi <[e-mail]>]

As I understand this, the current draft contradicts itself: it allows
senders to coalesce packets with different CIDs, and recommends that
receivers drop them.
I'll second Ian's comment that for us either option will be easy to
implement, but I believe we should fix the contradiction in the draft
before publication.

David

On Wed, Jul 15, 2020 at 12:31 PM Ian Swett <ianswett=
[e-mail]> wrote:

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