Re: [QUIC] Draft charter

[Jana Iyengar <[e-mail]>]

On Mon, May 16, 2016 at 1:52 PM, Yoav Nir <[e-mail]> wrote:

>
> > On 16 May 2016, at 11:45 PM, Martin Thomson <[e-mail]>
> wrote:
> >
> > On 16 May 2016 at 16:42, Yoav Nir <[e-mail]> wrote:
> >>> There is nothing about QUIC API in the charter. Will the group work on
> it?
> >>
> >> We’re still discussing the charter. Do you want the group to work on
> it?  Are you proposing to write an API draft?  Are you volunteering to
> write it?
> >
> > The API is exactly the HTTP API if we narrow the scope as has been
> suggested.
>

As Yoav alludes, there is the question of the transport API to HTTP ---
basically the QUIC equivalent of the socket API for TCP or SCTP. That said,
the socket API is usually Informational (see RFC 6458
<https://tools.ietf.org/html/rfc6458> as an example), since most
traditional transport implementations live in the kernel. Since the
expectation is that QUIC will mostly have userspace implementations, the
interaction model (sync/async, push/pull) will depend on the specific
implementations of both QUIC and the application. Given that we don't even
have a sockets framework (which defines a very specific interaction model)
to operate in, I'm not sure how specific this API between QUIC and the
application can be.

My instinct is to deal with it if/when the need arises. I'm willing to be
convinced otherwise... I suppose we could do a functional API in the spirit
of what was defined for TCP in RFC 793
<https://tools.ietf.org/html/rfc793#section-3.8>.

- jana

HTTP runs over TCP, so some of the tweaking you can do to TCP is not in the
> HTTP API but in socket options.
>
> QUIC runs over UDP, so many of the flow control attributes have to be part
> of the QUIC API, because UDP doesn’t have flow control. This is mostly the
> stuff in sections 9 and 10 of draft-tsvwg-quic-protocol.
>
> Yoav
>
>