RE: QUIC API

[Nick Banks <[e-mail]>]

MsQuic has a fairly generic (msquic.h<https://github.com/microsoft/msquic/blob/master/src/inc/msquic.h#L992>) API that is used in Windows by two completely different production protocols (HTTP & SMB), a number of tools/tests and several prototypes. It’s also a WIP to be exposed in .NET core. It has some documentation (start here<https://github.com/microsoft/msquic/blob/master/docs/API.md>). It’s still a work in progress, but probably about 90% complete. I’d like to think that our API exposes pretty much the entire QUIC spec’s worth of functionality in a general purpose way. It uses all async IO (which I know quite a few aren’t a fan of) and it’s completely separate from sockets. I’d be happy to work with any group that wishes to try to outline a general API for QUIC. Also, if you have any questions or comments on our API, feel free to file issues on our GitHub repo: https://github.com/microsoft/msquic.

Thanks,
- Nick

From: QUIC <[e-mail]> On Behalf Of Paul Vixie
Sent: Thursday, August 6, 2020 4:12 PM
To: Martin Duke <[e-mail]>
Cc: Lars Eggert <[e-mail]>; quic <[e-mail]>
Subject: Re: QUIC API



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/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6458%2F&data=02%7C01%7Cnibanks%40microsoft.com%7C42ecbc69fb5744fd4c4808d83a5e2e0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637323524361871926&sdata=4Y9dkOYeSsWkZMPYWGWwCA%2Br7Bw2BpLx6ws1ErWPOFo%3D&reserved=0>) 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/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetdnsapi.net%2F&data=02%7C01%7Cnibanks%40microsoft.com%7C42ecbc69fb5744fd4c4808d83a5e2e0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637323524361871926&sdata=Amdt0pV4oLxGtZvF%2FEpuMoZMp9WRKUth3iCul%2FEa%2Bg4%3D&reserved=0>) 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3542&data=02%7C01%7Cnibanks%40microsoft.com%7C42ecbc69fb5744fd4c4808d83a5e2e0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637323524361881882&sdata=9ygGCiFbsP9phEF78igkzrUWP%2FBaX0aPyw0kfeckhqA%3D&reserved=0>) 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postbox-inc.com%2F%3Futm_source%3Demail%26utm_medium%3Dsiglink%26utm_campaign%3Dreach&data=02%7C01%7Cnibanks%40microsoft.com%7C42ecbc69fb5744fd4c4808d83a5e2e0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637323524361881882&sdata=LSRr0XnJj65RuVVXzwwdKbA7kverhGC5nzMugqrcLQ0%3D&reserved=0>