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>
- Small size of core QUIC library to replace TCP fo… Jupiter
- RE: Small size of core QUIC library to replace TC… Nick Banks
- Re: Small size of core QUIC library to replace TC… Jana Iyengar
- Re: Small size of core QUIC library to replace TC… Lars Eggert
- Re: Small size of core QUIC library to replace TC… Jupiter
- Re: Small size of core QUIC library to replace TC… Lars Eggert
- Re: Small size of core QUIC library to replace TC… Jupiter
- Re: Small size of core QUIC library to replace TC… Paul Vixie
- Re: Small size of core QUIC library to replace TC… Lars Eggert
- QUIC API (was: Re: Small size of core QUIC librar… Lars Eggert
- Re: QUIC API (was: Re: Small size of core QUIC li… Martin Duke
- Re: QUIC API Paul Vixie
- RE: QUIC API Nick Banks
- Re: QUIC API (was: Re: Small size of core QUIC li… Lucas Pardue
- Re: QUIC API (was: Re: Small size of core QUIC li… Martin Duke
- Re: QUIC API (was: Re: Small size of core QUIC li… Lucas Pardue
- Re: QUIC API (was: Re: Small size of core QUIC li… David Schinazi
- Re: QUIC API (was: Re: Small size of core QUIC li… Christian Huitema
- Re: QUIC API (was: Re: Small size of core QUIC li… Robin MARX
- Re: QUIC API (was: Re: Small size of core QUIC li… Michael Welzl
- Re: QUIC API (was: Re: Small size of core QUIC li… Kazuho Oku
- Re: QUIC API (was: Re: Small size of core QUIC li… Michael Tuexen
- Re: QUIC API (was: Re: Small size of core QUIC li… Lucas Pardue
- Re: QUIC API (was: Re: Small size of core QUIC li… Bajpai, Vaibhav
- Re: QUIC API (was: Re: Small size of core QUIC li… Roberto Peon
- Re: QUIC API (was: Re: Small size of core QUIC li… Dirkjan Ochtman
- Re: QUIC API (was: Re: Small size of core QUIC li… Ian Swett