Subject: Abstract API

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Mar 2017 11:09:01 -0500

Having an abstract API would greatly help writing "Foo over QUIC"
specifications. Is anybody working on that?

-- Christian Huitema

---

From: Lucas Clemente <[email-masked]>
Date: Thu, 30 Mar 2017 16:24:25 +0000

For the record, the quic-go API is quite minimal and documented at
https://godoc.org/github.com/lucas-clemente/quic-go, with the most
important interface being
https://godoc.org/github.com/lucas-clemente/quic-go#Session

Note that we have decided against offering APIs for explicitly opening or
receiving streams by ID, and instead automatically assign stream IDs.

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Mar 2017 11:31:31 -0500

I think Mirja was talking about adding this to the applicability draft, but
I think it does make sense to have this in a separate doc.

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Thu, 30 Mar 2017 09:45:12 -0700

+1 to a separate doc.   Designing a new API is a very big deal IMHO.
Ossification of transport related APIs has been comparable to the wire
format etc.    For instance, I'd hope that after 30+ years of posix sockets
and Winsock, we'd make progress on things like:
  o clean zero-copy of data, at least between mappings and transport.
  o clean cooperation of mapping and transport wrt packetization and
framing.
       o important for apps to have better visibility into latency (which
messages go in which RTTs)
       o would pave the way for advanced features like application
controlled FEC etc.

On Thu, Mar 30, 2017 at 9:31 AM, Jana Iyengar <[email-masked]> wrote:

> I think Mirja was talking about adding this to the applicability draft,
> but I think it does make sense to have this in a separate doc.
>

-- 
Charles 'Buck' Krasic | Software Engineer | [email-masked] | +1 (408)
412-1141

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Mar 2017 15:37:20 -0500

On 3/30/2017 11:45 AM, Charles 'Buck' Krasic wrote:
> format etc.    For instance, I'd hope that after 30+ years of posix
> sockets and Winsock, we'd make progress on things like:
>        o important for apps to have better visibility into latency
> (which messages go in which RTTs)
That's why I mentioned "Abstract" API. Stuff like zero copy tend to be
very much system dependent, and he exact syntax is bound to be language
dependent. But when you design an application API, you are concerned
with issues like "can a node wait for the next stream initialization",
which is in the domain of "abstract".

-- Christian Huitema

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 31 Mar 2017 14:07:31 -0500

Note that working out how an abstract transport API needs to overlay on top of QUIC is part of the goals we have for TAPS and the Post-Sockets effort there. As part of that, we're planning on do an analysis of how applications need to interact with the security layer of its 'transport' as well as the basic transport features. Since QUIC is a prime example of way in which those elements are combined and integrated, supporting QUIC is a main goal.

Efforts so far in working on abstract API and requirements:
https://tools.ietf.org/html/draft-trammell-taps-post-sockets
https://tools.ietf.org/html/draft-pauly-taps-guidelines

Thanks,
Tommy

> On Mar 30, 2017, at 3:37 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
>