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

Kazuho Oku <kazuhooku@gmail.com> Thu, 16 July 2020 06:40 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FA63A0F9A for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 23:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A1w48ugxPws for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 23:40:52 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559573A0F9C for <quic@ietf.org>; Wed, 15 Jul 2020 23:40:52 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id w6so5388568ejq.6 for <quic@ietf.org>; Wed, 15 Jul 2020 23:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xnpycQDCmgZhNCqt+dGjyFhRqZrLPLZG0g2+ESYsAsM=; b=GZqYTL0+BwAdPcdC6SgHDcLTl6ZxH1UIdUEdI0NzNJOaWDw5nPlHSPWFyFpedf8KTn FNJibhSbGqDPQDoidBaKpYNaXr3VI73kUslVmJepy3Gaz59A7XfZkUV4o5cGelSJEnEv fLPWS5Y7ArixRjSnr8rIKlZVZp2X5dZPGZF/e3iO0ZM0xOgLnfaeLZItyAkHzSe4KDdd DSlKkL/+cU6fEPqiGEblFwn9tcANdJ0/aCwPSr5LWGqUGNVOZJqYOGSyoe1nXVnxEKZA mHwmiJ/g2PMlrsgrtkVUhu6OyVpOp38WVG4xCLwtM2/xb8g5DH3gRxik4mzgw2bRb0YY 6sdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xnpycQDCmgZhNCqt+dGjyFhRqZrLPLZG0g2+ESYsAsM=; b=TtAp0bdH7BIBoacbvt4ytdDE98EjAue3cd7wpflxj4RBeE66x+c6LMkE//udwEjI1i vi8d6Jpnabx/43qMo7uXHnNxueNX2J0gfDH0RrJSMIBiJu5XXgDCPV+qQZujGpiraIkq Gjz8HrQsYLvGsvLoM5u5U9P52ytobqlHeHHNuz0KQK4vt8QGrtnLDxiZCCTsICIgmhEH FRSCVPCmkapjSPIAZdz1RP52IuHTJvZEtxWgU8uBfRT427bTzvNSB7Vns8SoS62AIquI xFeiRFT5lFTSzUy5QSAOlh5w2geVprPKxfFsar/gSGM/6kM84SuQokFdYr/fJ38oZZ1E r0wA==
X-Gm-Message-State: AOAM531AebxNv1glYBCc5/OUi1P2mhSbI4+deY5fo2YdGrEFdIlR84e/ Cc6Oo1YuZUmLOlETT5s2p9r+VZXeQv7rCMIOKJDQCw==
X-Google-Smtp-Source: ABdhPJz2iTwawlXiO/yKzlD1Ca6rTN4OZr+kb0M7AM4Brv3lnQpFw0jcwvWNRjQZHVPWw/N/P9QZrZKGjb8I7ASwnCw=
X-Received: by 2002:a17:906:1ec3:: with SMTP id m3mr2388979ejj.197.1594881650773; Wed, 15 Jul 2020 23:40:50 -0700 (PDT)
MIME-Version: 1.0
References: <ae21cc02-3357-40c8-a1e9-3966fdf575a5@www.fastmail.com> <20200715180231.GB9808@lubuntu> <CAKcm_gPfc3sFy0kuyTzUFk2XFMZ8NdXTd7CuNf0o0v+RXDG=xg@mail.gmail.com> <CH2PR22MB20861D3BEA06EE61AA882245DA7E0@CH2PR22MB2086.namprd22.prod.outlook.com>
In-Reply-To: <CH2PR22MB20861D3BEA06EE61AA882245DA7E0@CH2PR22MB2086.namprd22.prod.outlook.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 16 Jul 2020 15:40:39 +0900
Message-ID: <CANatvzxwbF4_oUZusQOXvD4_JNo88fQa6t5kZ9Oo5_2Ok3qWPw@mail.gmail.com>
Subject: Re: Need your help: different connection IDs in the same datagram
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Martin Thomson <mt@lowentropy.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040d1e005aa895221"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Xa4uwCJp5cg6mzwpWFHxH24-vGw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2020 06:40:56 -0000

2020年7月16日(木) 5:43 Mike Bishop <mbishop@evequefou.be>be>:

> 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 <quic-bounces@ietf.org> *On Behalf Of * Ian Swett
> *Sent:* Wednesday, July 15, 2020 3:31 PM
> *To:* Martin Thomson <mt@lowentropy.net>et>; IETF QUIC WG <quic@ietf.org>
> *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 <
> dtikhonov@litespeedtech.com> 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