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

[Michael Tuexen <[e-mail]>]

> On 7. Aug 2020, at 02:16, 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?
Not sure what the criteria for success is. However, the implementers of SCTP for the
FreeBSD, Linux, and Solaris kernel used this document to come up with an API, which
is supported by the three SCTP kernel implementations. As an implementer, you had a spec
to know the application programmer expects.
You can now write a program and it should compile and run on all three platforms.
After the implementation phase, the document has been used by application program
developers to figure out how they can do what they want. When questions come up,
I regularly point application programmers to the relevant section.

Best regards
Michael
> 
> 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
> 
> Pretty different.
> 
> Lars