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

[Kazuho Oku <[e-mail]>]

+1 to others pointing out that it is difficult to define a common API.

In fact, I would point out that the APIs provided by existing QUIC stacks
are very different. Some QUIC stacks are designed like a layer. Others are
designed like a codec that takes inputs (of bytes) and returns an output
(of bytes). Some QUIC stacks are designed under the assumption that
applications "push" data, whereas other QUIC stacks are designed under the
assumption that the QUIC stacks would "pull" the data from application when
there's room to send something.

There are pros and cons in these approaches, and I do not think it would
be productive to agree on one particular approach through discussion.

At the same time, I would point out sometimes it is inevitable to define a
standard API, and I had assumed that that is happening in WebTransport (on
the W3C side). So maybe people looking for an API can contribute there?


2020年8月7日(金) 17:18 Robin MARX <[e-mail]>:

> Personally, I would agree that creating a general purpose API just for
> QUIC would be difficult.
> I'm mainly thinking about what the interface for steering stream
> multiplexing/prioritization would look like, seeing as the specs are very
> light on details for these.
> Speccing something out for HTTP/3 should be do-able (and is being
> contemplated by some, e.g., https://github.com/hyperium/h3/pull/1),
> though potentially not as useful.
>
> I would echo Lucas' reference in thinking that abstracting from QUIC to a
> more high-level view of transport features with something like TAPS is more
> logical in the long run.
> Rather than putting all eggs in one basket, it would be good to get at
> least this one egg into that particular basket imo.
>
> Like Lucas and David, I'm also not sure how common/realistic of a use case
> the "I want to switch ad-hoc between QUIC implementations" argument will
> be.
> To me, a common API would be mostly interesting in writing re-usable
> high-level coding tutorials and teaching materials to help new devs use the
> protocol more quickly.
> From that perspective, you can make an even stronger argument for TAPS
> imo.
>
> With best regards,
> Robin
>
>
>
> On Fri, 7 Aug 2020 at 08:39, Christian Huitema <[e-mail]>
> wrote:
>
>>
>> On 8/6/2020 5:58 PM, David Schinazi wrote:
>> > In theory, it could mean that one could write an application
>> > in such a way that it could swap QUIC implementations.
>> > I don't see that happening in practice. The application
>> > developer would have to periodically test against these
>> > implementations for them to work reliably, so the idea
>> > of a drop-in replacement sounds unreal to me.
>>
>> Yes. We had an example of that when testers wanted to plug their tools
>> to different QUIC stacks. Not impossible, but there was a lot of glue
>> required.
>>
>> >
>> > Additionally, in 2020, networking APIs are asynchronous.
>> > That means that a QUIC API would need to be tied to
>> > a specific asynchronous IO model, and those are tied
>> > to programming language and library choices. So any
>> > API would only work for applications that pick the same
>> > language and standard libraries.
>>
>>
>> People today are experimenting with a variety of application--stack
>> interactions. I think that's a good thing at this point. Take the
>> example of out-of-order delivery: really cool potential, but we have
>> very little experience. It might require tight integration with the
>> application, dealing with the intricacies of video codecs. I think that
>> in the next year or two we will gain some experience and maybe see a
>> small number of API models emerge. But attempting standardization before
>> that seems very premature.
>>
>> -- Christian Huitema
>>
>>
>>
>
> --
>
> Robin Marx
> PhD researcher - web performance
> Expertise centre for Digital Media
>
> T [phone] - GSM [phone]
>
> www.uhasselt.be
> Universiteit Hasselt - Campus Diepenbeek
> Agoralaan Gebouw D - B-3590 Diepenbeek
> Kantoor EDM-2.05
>
>
>

-- 
Kazuho Oku