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

[David Schinazi <[e-mail]>]

What would be the purpose of defining a QUIC API?

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.

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.

David

On Thu, Aug 6, 2020 at 5:16 PM Lucas Pardue <[e-mail]>
wrote:

>
>
> On Fri, 7 Aug 2020, 00:37 Martin Duke, <[e-mail]> wrote:
>
>> I am all for using TAPS concepts wherever possible, but I am not sure we
>> should put all of our eggs in that basket.
>>
>
> I'm no TAPS or SCTP aficionado so take my view with a pinch of salt.
>
> It's just that looking at RFC 6458 and seeing a 100 page document makes me
> wonder what would be required to do something for QUIC, who would implement
> that, and who would pick up the pen.
>
> It seems like a possible divergent effort from other API work, which seems
> like a fragmented outcome.
>
> How successful is RFC 6458?
>
> Also, I think it help would me to understand the incentives. The
> supposition was about an application wanting to use different QUIC stacks?
> Curl is already doing this and it doesn't seem too onerous. I'm sure there
> are other incentives though.
>
> Lucas
>
>
>
>
>
>> On Thu, Aug 6, 2020 at 4:27 PM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>> Would TAPS fit your bill?
>>>
>>> https://tools.ietf.org/html/draft-ietf-taps-interface-09
>>>
>>> On Thu, 6 Aug 2020, 23:57 Martin Duke, <[e-mail]> 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.
>>>>
>>>> On Tue, Jul 21, 2020 at 11:18 PM Lars Eggert <[e-mail]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 2020-7-21, at 20:02, Paul Vixie <[e-mail]> wrote:
>>>>> > my question is, has any QUIC implementor been thinking along these
>>>>> lines? i
>>>>> > believe that the parameters to a QUIC "connect" syscall would be
>>>>> larger and
>>>>> > more numerous than for a TCP or SCTP or UDP "connect" syscall, for
>>>>> example.
>>>>>
>>>>> most QUIC implementations have an API that is at a high level pretty
>>>>> similar to the socket API, but different in all the details. And they are
>>>>> all different from each other.
>>>>>
>>>>> Since you asked about a "connect" equivalent, here is what some of the
>>>>> C stacks offer:
>>>>>
>>>>> quant:
>>>>> https://github.com/NTAP/quant/blob/master/lib/include/quant/quant.h#L110-L118
>>>>>
>>>>> msquic:
>>>>> https://github.com/microsoft/msquic/blob/master/src/inc/msquic.h#L745-L757
>>>>>
>>>>> quicly:
>>>>> https://github.com/h2o/quicly/blob/master/include/quicly.h#L892-L900
>>>>> <https://github.com/h2o/quicly/blob/master/include/quicly...h#L892-L900>
>>>>>
>>>>> Pretty different.
>>>>>
>>>>> Lars
>>>>>
>>>>