IETF Logo Mail Archive

Re: [Taps] QUIC API for WebRTC

Tommy Pauly <tpauly@apple.com> Thu, 11 October 2018 21:15 UTC

Return-Path: <tpauly@apple.com>
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 2C54112426A for <taps@ietfa.amsl.com>; Thu, 11 Oct 2018 14:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 VKWdTMtgsBzb for <taps@ietfa.amsl.com>; Thu, 11 Oct 2018 14:15:08 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 10F8F12777C for <taps@ietf.org>; Thu, 11 Oct 2018 14:15:08 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9BLCEKI062608; Thu, 11 Oct 2018 14:15:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wsTlA/0Kp0zTOiyQffNw/xvsc3tthpTfjHEQd3kX7rA=; b=MhoXtLzDofC9kafpqHZhYUpO1/w/HRUd0r+yB0YGgA3g//Wk15BGpNNghvLy6OCtzPk9 o2dMK2dxucmkiVaKLdC8Mk0PM0Vn0ZJKcxEO/E6oEfyVn9m4KEL09UyiHmhwnPXuCVhA t5zBan76FyYBEDwGYw3O8m4GF8P9BdSqixCBUTIXEOA/dhweV8vmlA/ssiMZz49cMUoh WukjdADJQsr2bVhcIA0AKJEF3L96i/gAecYb3ltAQjIiTm0gn1oX72JEx9NxxFaxMGfZ zwEIFnQY5xNTjqER3l412h3JhR7QXZEo28Fl86BRWFGih11Ix0DpxC8jDOKT2ezKgDch KA==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2mxskc8tbp-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Oct 2018 14:15:00 -0700
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_j4kq/I/vF3Y4MnUceO3sig)"
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGG005KIDOYS3D0@ma1-mtap-s02.corp.apple.com>; Thu, 11 Oct 2018 14:14:59 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGG00C00D96D400@nwk-mmpp-sz13.apple.com>; Thu, 11 Oct 2018 14:14:58 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 91949cb67ad5a17194231cf3cf1e09f7
X-Va-E-CD: 63013081a6a18f67a6b5985da63079b3
X-Va-R-CD: 093da20303732465ced0230bd12ee60d
X-Va-CD: 0
X-Va-ID: 06aeabb7-0aa8-4930-a582-6a6d25ed9990
X-V-A:
X-V-T-CD: 91949cb67ad5a17194231cf3cf1e09f7
X-V-E-CD: 63013081a6a18f67a6b5985da63079b3
X-V-R-CD: 093da20303732465ced0230bd12ee60d
X-V-CD: 0
X-V-ID: 96f1643b-a5c9-4332-afa4-8943bd352b49
Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGG00C00D8PCJ00@nwk-mmpp-sz13.apple.com>; Thu, 11 Oct 2018 14:14:57 -0700 (PDT)
Authentication-results: corp.apple.com; spf=pass smtp.mailfrom=tpauly@apple.com; dmarc=pass header.from=apple.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-11_09:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1
Received: from [17.234.110.84] (unknown [17.234.110.84]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGG002VTDOXV880@nwk-mmpp-sz13.apple.com>; Thu, 11 Oct 2018 14:14:57 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <FF152FCC-0EB3-4A20-8079-F17BFB3BE824@apple.com>
Date: Thu, 11 Oct 2018 14:14:46 -0700
In-reply-to: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no>
Cc: "taps@ietf.org" <taps@ietf.org>, youenn fablet <yfablet@apple.com>, Colin Perkins <csp@csperkins.org>
To: Michael Welzl <michawe@ifi.uio.no>
References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.100.36)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-11_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/xcFuPRa9L6dTvyIc8B256RJkCg0>
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: Thu, 11 Oct 2018 21:15:10 -0000

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 <michawe@ifi.uio.no> wrote:
> 
> 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
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

v2.23.0 | Report a Bug | By Email