Re: Need your help: different connection IDs in the same datagram
Dmitri Tikhonov <dtikhonov@litespeedtech.com> Wed, 15 July 2020 18:02 UTC
Return-Path: <dtikhonov@litespeedtech.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 2BF5A3A0874 for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 11:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 sbZUELF5ygOg for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 11:02:45 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 CA4D23A0BF1 for <quic@ietf.org>; Wed, 15 Jul 2020 11:02:41 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id g13so2425874qtv.8 for <quic@ietf.org>; Wed, 15 Jul 2020 11:02:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=G1TxWxiQTQ0FQgfGH1RrIttXUADdjybDjZuwyWcI0q0=; b=ZjcHQnvKS069XgSvvgQr/fkMgXlXp6BJMrleYGI1/iYpaAkDO9urcyr9KG1z9TJaVY cZwbqAkx4hBuzCfeRq7mFTTHOb9oRo0wmqVGjSBY3bHKjMyIIoCa1V01a3lVwMEwcvvr NgG1U5w4bwB+ECjwA91q5Ik2imwzDIdFJODFi43PIZjFt8e2M2Gv1j5HYkjqBtTjhT/z o7HKuxt03Vy6EPurNHBVOE+p5uX73FfNvtS2xH+YN+YDGHwZ8A3JbUXcnUz+GOseTGYe BADqdOusfbHW4hCyzsOhFUGKnudwZ/K66NRQDmPTx5QC51C+mLocRmli4zn5vM88gFOO gCEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=G1TxWxiQTQ0FQgfGH1RrIttXUADdjybDjZuwyWcI0q0=; b=MJMImfgC6m23qQ7VgiUO6m665oUnJPr3qZYU2XW2/sF2cEll8PuhNBt/icO23k0bwh SKkN5Kb6nHE0oBGDBU8IZiHomAqFtxmzYOVBxwGCdpbXW/9CxfivmneAuenaD20huhHb 4iddUUuwFIq+H2QUVHCyk6qeO2ljbLDWkMjRIdfgyeCFprFMrS4IV+hqv9GDN/A+qWy+ vpLU2nzM7GmTfbovwpC28IFHshdkESYkBETU/cD7Q5lL+qzCKiJ38oO8TFtUwL60a5RR A0CzH6A9sF7P04gBAOSvxgL8KL5t15+FOlXLhdJxOSpfsGEPbWM/IqjgzWJiBl9gHtfI EMCQ==
X-Gm-Message-State: AOAM5309ZrEWYmpnc/JfOsb+E2lg1QfPszwaNL8Z2Cwsrnuda9ospdmg O9HY7uX+wFOxPFQ6J0b4MpvDODArxIx40Q==
X-Google-Smtp-Source: ABdhPJylLq6i5eJ+TP+CFmBVknkcYqsqCl+2oejNu4+uvRQebIAwQ+hv7WPOu98FnF9QpozpKKb5AQ==
X-Received: by 2002:aed:2967:: with SMTP id s94mr1098843qtd.258.1594836160825; Wed, 15 Jul 2020 11:02:40 -0700 (PDT)
Received: from lubuntu (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id p36sm4688914qta.0.2020.07.15.11.02.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2020 11:02:40 -0700 (PDT)
Date: Wed, 15 Jul 2020 14:02:32 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: quic@ietf.org
Subject: Re: Need your help: different connection IDs in the same datagram
Message-ID: <20200715180231.GB9808@lubuntu>
Mail-Followup-To: Martin Thomson <mt@lowentropy.net>, quic@ietf.org
References: <ae21cc02-3357-40c8-a1e9-3966fdf575a5@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ae21cc02-3357-40c8-a1e9-3966fdf575a5@www.fastmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9dHym3C8WHYdfD4ED3W56evNhjw>
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: Wed, 15 Jul 2020 18:02:47 -0000
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
- Need your help: different connection IDs in the s… Martin Thomson
- Re: Need your help: different connection IDs in t… Marten Seemann
- RE: Need your help: different connection IDs in t… Nick Banks
- Re: Need your help: different connection IDs in t… Dmitri Tikhonov
- Re: Need your help: different connection IDs in t… Ian Swett
- Re: Need your help: different connection IDs in t… David Schinazi
- RE: Need your help: different connection IDs in t… Mike Bishop
- Re: Need your help: different connection IDs in t… Ian Swett
- Re: Need your help: different connection IDs in t… Martin Thomson
- Re: Need your help: different connection IDs in t… Martin Thomson
- Re: Need your help: different connection IDs in t… Dmitri Tikhonov
- Re: Need your help: different connection IDs in t… Dmitri Tikhonov
- Re: Need your help: different connection IDs in t… Martin Thomson
- Re: Need your help: different connection IDs in t… David Schinazi
- Re: Need your help: different connection IDs in t… Dmitri Tikhonov
- Re: Need your help: different connection IDs in t… Martin Thomson
- Re: Need your help: different connection IDs in t… Jana Iyengar
- Re: Need your help: different connection IDs in t… Kazuho Oku