Re: QUIC API

Paul Vixie <paul@redbarn.org> Thu, 06 August 2020 23:11 UTC

Return-Path: <paul@redbarn.org>
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 97A3D3A0805 for <quic@ietfa.amsl.com>; Thu, 6 Aug 2020 16:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level:
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-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 uxc6d9WcJilH for <quic@ietfa.amsl.com>; Thu, 6 Aug 2020 16:11:50 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5EA3A0B64 for <quic@ietf.org>; Thu, 6 Aug 2020 16:11:48 -0700 (PDT)
Received: from [IPv6:2603:3024:2115:be00:59a0:117b:98d:b116] (unknown [IPv6:2603:3024:2115:be00:59a0:117b:98d:b116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 24613C3F19; Thu, 6 Aug 2020 23:11:45 +0000 (UTC)
Subject: Re: QUIC API
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Lars Eggert <lars@eggert.org>, quic <quic@ietf.org>
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>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <cafecddc-4f00-7345-ade6-e506cdeae17c@redbarn.org>
Date: Thu, 06 Aug 2020 16:11:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.25
MIME-Version: 1.0
In-Reply-To: <CAM4esxR+s-SCVOWb_-3TciVRk8Sp5NVWtjggqXM_XD2r3jup=Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------DB07EBBF39FB8219306089D0"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/si2m7jiVSXrq0SfIeQDVTVP9270>
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, 06 Aug 2020 23:11:58 -0000


Martin Duke wrote on 2020-08-06 15:57:
> 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.

i agree, in two ways. first, something like getdns (see 
https://getdnsapi.net/) to describe the core functions and standard 
language-specific bindings would be good. as with dns, there may be more 
than one instance of this kind of thing, but it would be good to see 
shared libraries generally available so that a quic app (and perhaps 
also HoQ, DoQ, and other layerings) could be normal dependencies of 
packages we install. RFC 6458 assumes that the the sockets API will be 
involved, which does not facilitate the kind of user-mode transport that 
QUIC anticipates.

second, something like RFC 2292 (see https://tools.ietf.org/html/rfc3542 
<https://tools.ietf.org/html/rfc3542>) or RFC 6458 [ibid] that explains 
how to access quic through the socket interface if some of us want to 
use the system call interface as a monitoring point (so, like dtrace) or 
a control point (so, like anti-malware), and where UDP sockets might be 
restricted to privileged processes and the kernel, but not generally 
available to apps who want to avoid the kernel operator's monitoring 
and/or controls. as a kernel operator i don't plan to trust my apps to 
do things that are not transparent to me.

if anybody decides to work on either one, i promise to review, 
comment/discuss, test where possible, and perhaps implement/prototype.

vixie

-- 
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>