Re: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system)

Dirkjan Ochtman <dirkjan@ochtman.nl> Mon, 10 August 2020 20:34 UTC

Return-Path: <dirkjan@ochtman.nl>
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 48E8F3A0DE7 for <quic@ietfa.amsl.com>; Mon, 10 Aug 2020 13:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 F2eVC1Cx32TZ for <quic@ietfa.amsl.com>; Mon, 10 Aug 2020 13:34:46 -0700 (PDT)
Received: from enrai.xavamedia.nl (enrai.xavamedia.nl [217.115.195.245]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1BA3A0D64 for <quic@ietf.org>; Mon, 10 Aug 2020 13:34:38 -0700 (PDT)
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by enrai.xavamedia.nl (Postfix) with ESMTPSA id 580CE9000FD for <quic@ietf.org>; Mon, 10 Aug 2020 22:34:37 +0200 (CEST)
Received: by mail-vs1-f48.google.com with SMTP id r7so4897457vsq.5 for <quic@ietf.org>; Mon, 10 Aug 2020 13:34:37 -0700 (PDT)
X-Gm-Message-State: AOAM533UDxw+tCwQzFXEbeaNWh52dh5n10gIpJpV0+fyWi5fqqufBlHJ haItCzNURaKm9OjdtO0MfSXtq6DgI/lPzuIKWXI=
X-Google-Smtp-Source: ABdhPJzLwHyoPONAQZ0Oq0gPRb8vfyiPJUf5WYK/grHnCtetBHC/ZSbao1l0xLI3U5pmyVcaNZ1jThdk3cviOKNjMSo=
X-Received: by 2002:a67:edd8:: with SMTP id e24mr20673426vsp.150.1597091676204; Mon, 10 Aug 2020 13:34:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAA=hcWS0V8ipsoAEFK3ejdA++Vzi+czth37=ntP4mnt8d=mtRg@mail.gmail.com> <F384B33C-70F8-45EF-AB5C-30D0A145659A@eggert.org> <CAA=hcWQ60GH2TnjvqBEGvVQ1whxNYwEWjQ+b9FW948GKvN570Q@mail.gmail.com> <2499749.AO4zfZtjs8@linux-9daj> <3D493D2B-BC8D-4CE9-B189-48770C3FA06F@eggert.org> <CAM4esxR+s-SCVOWb_-3TciVRk8Sp5NVWtjggqXM_XD2r3jup=Q@mail.gmail.com>
In-Reply-To: <CAM4esxR+s-SCVOWb_-3TciVRk8Sp5NVWtjggqXM_XD2r3jup=Q@mail.gmail.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Mon, 10 Aug 2020 22:34:25 +0200
X-Gmail-Original-Message-ID: <CAKmKYaBxTQsYjYNm_OJAFXKXg_7Uz=5PYeO83C=rRYXrW8EtBw@mail.gmail.com>
Message-ID: <CAKmKYaBxTQsYjYNm_OJAFXKXg_7Uz=5PYeO83C=rRYXrW8EtBw@mail.gmail.com>
Subject: Re: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system)
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Lars Eggert <lars@eggert.org>, quic <quic@ietf.org>, Paul Vixie <paul@redbarn.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8P9LOxm7vCqinmghd3YZPRI7HA8>
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: Mon, 10 Aug 2020 20:34:54 -0000

On Fri, Aug 7, 2020 at 12:57 AM Martin Duke <martin.h.duke@gmail.com> wrote:
> On this subject, (speaking as individual) I think it would be useful to define a QUIC application API. SCTP did one (https://datatracker.ietf.org/doc/rfc6458/) and the idea that an application would have to be written separately for each quic implementation is silly.

For what it's worth, for the hyper library (the most popular HTTP
library in the Rust ecosystem) we're trying to define a set of Rust
traits (abstract interfaces) that cover the basic QUIC API insofar as
H3 support needs it.

https://github.com/hyperium/h3/blob/master/design/PROPOSAL.md#4-public-api

Kind regards,

Dirkjan