Subject: [Taps] QUIC API for WebRTC

From: Michael Welzl <[email-masked]>
Date: Thu, 11 Oct 2018 08:20:23 +0200

Hi,

I just thought that it’s good for this group to be aware about this API:
https://w3c.github.io/webrtc-quic/ <https://w3c.github.io/webrtc-quic/>

Sadly, not transport protocol independent…

Cheers,
Michael

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Oct 2018 14:14:46 -0700

Hi Michael,

Thanks for sharing! We recently saw this too, and my impression is similar. Ideally, from a WebRTC application's perspective, we should have a TAPS system that helps set up ICE, determines which protocol stack to use (SCTP/DTLS, SRTP, QUIC, etc), and lets the application interact with the the TAPS API regardless of the protocol.

At the very least, as an intermediate point before we go full TAPS, we should push for a model in which the API is transport independent and we use the surveys/minset of TAPS to guide the API surface.

I'm adding Youenn to the thread, who is participating in the W3C WG that's discussing this. Perhaps we can give some suggestions for feedback?

I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that aspect of the API really concrete.

Thanks,
Tommy

> On Oct 10, 2018, at 11:20 PM, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Fri, 12 Oct 2018 08:20:00 +0200

> On 11 Oct 2018, at 23:14, Tommy Pauly <[email-masked]> wrote:
> 
> Hi Michael,
> 

I agree - also, it seems to me that the original WebRTC API was more abstract, starting with the concept of channels and such...

> I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that…

To me, that seems like a very good suggestion!

Cheers,
Michael

---

From: "Aaron Falk" <[email-masked]>
Date: Fri, 12 Oct 2018 15:48:39 -0400

On 11 Oct 2018, at 17:14, Tommy Pauly wrote:

> I think this also brings up a point that it may be good to have a 
> discussion in Bangkok with the group about getting a bit more in 
> detail to how TAPS can best serve WebRTC use cases, and make that 
> aspect of the API really concrete.

Are you thinking an offline discussion or would you like to spend some 
agenda time on the topic?  I could invite the authors to present.

--aaron

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 12 Oct 2018 12:52:42 -0700

I think it would be useful to have agenda time in TAPS to discuss both:

- Transport API mappings for QUIC
- TAPS API mappings for WebRTC

Having input on the requirements and background for WebRTC + QUIC would be great.

Thanks,
Tommy

> On Oct 12, 2018, at 12:48 PM, Aaron Falk <[email-masked]> wrote:
> 
> Are you thinking an offline discussion or would you like to spend some agenda time on the topic? I could invite the authors to present.
> 
> --aaron
>

---

From: youenn fablet <[email-masked]>
Date: Mon, 15 Oct 2018 19:27:45 -0700

FWIW, this topic might also be discussed during next TPAC within the WebRC WG (https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit <https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit>).

What Pauly suggests makes sense to me. Having some discussion during next IETF meeting seems beneficial.
I would hope we could define a data channel API/QUIC mapping based on TAPS.

Understanding the shortcomings of current data channels would be useful.
I can see some cases that might be interesting to study further:
- Use the same QUIC connection for both media exchange and data channel
- Use an existing QUIC/HTTP connection for data channel: Web Socket or SCTP data channel replacement

	Y

> On Oct 12, 2018, at 12:52 PM, Tommy Pauly <[email-masked]> wrote:
> 
>> On Oct 12, 2018, at 12:48 PM, Aaron Falk <[email-masked] <mailto:[email-masked]>> wrote:
>>