Re: [Taps] QUIC API for WebRTC

Michael Welzl <michawe@ifi.uio.no> Fri, 12 October 2018 06:20 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1781292F1 for <taps@ietfa.amsl.com>; Thu, 11 Oct 2018 23:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pkg3Kd9i4pGa for <taps@ietfa.amsl.com>; Thu, 11 Oct 2018 23:20:09 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3850130DFB for <taps@ietf.org>; Thu, 11 Oct 2018 23:20:08 -0700 (PDT)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1gAqnt-0004R6-Ap; Fri, 12 Oct 2018 08:20:05 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1gAqns-000Bqb-T9; Fri, 12 Oct 2018 08:20:05 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <FF152FCC-0EB3-4A20-8079-F17BFB3BE824@apple.com>
Date: Fri, 12 Oct 2018 08:20:00 +0200
Cc: "taps@ietf.org" <taps@ietf.org>, youenn fablet <yfablet@apple.com>, Colin Perkins <csp@csperkins.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <04D9C9F3-5013-43FE-89EB-4BB19AD57B7A@ifi.uio.no>
References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> <FF152FCC-0EB3-4A20-8079-F17BFB3BE824@apple.com>
To: Tommy Pauly <tpauly@apple.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 3F94219D266DC092A7475C6A655F6F7304A0E1E3
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/FN4PHDKTQnH0PWj_YEL4klN2WzQ>
Subject: Re: [Taps] QUIC API for WebRTC
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2018 06:20:12 -0000


> On 11 Oct 2018, at 23:14, Tommy Pauly <tpauly@apple.com> wrote:
> 
> 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 agree - also, it seems to me that the original WebRTC API was more abstract, starting with the concept of channels and such...


> 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.

To me, that seems like a very good suggestion!

Cheers,
Michael