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