Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 19 February 2020 12:22 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6F7120046 for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 04:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ug2fqpHZ06KD for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 04:22:43 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C4F12003F for <v3@ietf.org>; Wed, 19 Feb 2020 04:22:43 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id c23so17283093lfi.7 for <v3@ietf.org>; Wed, 19 Feb 2020 04:22:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZdOJJbzXzm05r4IIpR1l5a4lIxmT+TnSRG617o/EFMA=; b=uYKBIqESMhjE1t4GLuOZAEfy5nUfUcjG/1srhvog+quMtjZqdoU1qqTBkrfmWCCdb/ a85vQVySDtQtM00TXenAQs8XwDO74K7LVP2kZNm3zh+4Vvx9FBQOoFrrW+QxnX4tqiwL Q1lihkd7evAPQySGN8KBPZr1+BJFs/wJ/4Ww8qHxUT17ASkLmfTGSVNSvAvlsbO+y+Lt aNTWF1E66WxSiEqOuJ5usRuXJJiSwVZArx+P15hhiP7pvGMq4jvfKq2Ljwk+x75iASd5 qT645/iJzrsoH3ODTC+36sB6uEm7ZKbsmwujgTFS68Y1FrnVugsh3Do/os8u0eu5bpej PzPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZdOJJbzXzm05r4IIpR1l5a4lIxmT+TnSRG617o/EFMA=; b=PL0Wa+Bsy1QqRK6aG0Le/cuFRGXPKZdsAWiC7A4NsLF9CdgK53rpX393PLi29dsskH KXVR4G792KTE226oSLWU91YeZzqAJGFtFsHhxUM0WGpB2wUoHaVrz+1xDmCPd+iosb1w IK9doOVbyQM8x3QZFpjFh6mCG8HOgO39uSqcWKVkOyeUGpgBnzR4srwiOmOhT6JH8a/j t/24lfjqLPfz2vcZcJIG7pkxPMCcjYT/JxNqgUPgfT7i1MH/hLMT2vHaSc/fLSF9kvMY KAWxe7k7zSJ4qcwR+JaPBZk+PjLpSUkF9jyEpTsVc8ZgNurpbUm5JIlkfXY23xSTd4C+ 9ipg==
X-Gm-Message-State: APjAAAWByqg7HpoMMWlV5dtfH64zyDRIxD8qfKusOCax1GTfI6eBkKFi itcUczlsuqF3YIQBsIZYkJbg8k9vs/o275xki78=
X-Google-Smtp-Source: APXvYqwV6+QKeOyVSRX+w2Xqzn3sVa4B36ce+7hyxHLtmiPrK6lDAEwVuWjKfN1jsZhav58nmhlHqk/XkXx9rQyeD00=
X-Received: by 2002:ac2:5e29:: with SMTP id o9mr13525640lfg.81.1582114961381; Wed, 19 Feb 2020 04:22:41 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR06MB43914433BF91CE216E6123A6FB150@BYAPR06MB4391.namprd06.prod.outlook.com> <CAKKJt-eKB4wxqK8Xiho2tYaqpM3_fjQYsjJh5-cf_RWd6iR8sQ@mail.gmail.com> <CA+23+fGNO86ii6q0hd3aiSdib2AT-iu3O+DmgGJXTFbFkGxLnQ@mail.gmail.com> <F72DFB60-1BA3-4CD3-9DB2-DF986F3729DE@live555.com> <BYAPR06MB4391E5B3FB4258BEF59F7BFBFB110@BYAPR06MB4391.namprd06.prod.outlook.com> <3254DED7-C105-4674-82E4-0D6968CB8744@live555.com> <CAOJ7v-0cQveZ5Gov=XkK4pc8m3typivWWGw-X3QESVCwaF956A@mail.gmail.com>
In-Reply-To: <CAOJ7v-0cQveZ5Gov=XkK4pc8m3typivWWGw-X3QESVCwaF956A@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 19 Feb 2020 06:22:14 -0600
Message-ID: <CAKKJt-ePx-iPk+5XKQ_EnvvQT+5docJF1CUPrV+oqOSFa2g0QQ@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Ross Finlayson <finlayson@live555.com>, Jonathan Rosenberg <jdrosen@five9.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>, "v3@ietf.org" <v3@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000445c21059eecd815"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/j_lmXk5D9jYFsGx31kl9jCNYLHA>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 12:22:45 -0000

Hi, Justin,

On Tue, Feb 18, 2020 at 9:55 PM Justin Uberti <juberti@google.com> wrote:

> Replying to Ross...
>

I'm not Ross, but I found this reply helpful.


> On Tue, Feb 18, 2020 at 12:02 PM Ross Finlayson <finlayson@live555.com>
> wrote:
>
>>
>> > On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <jdrosen@five9.com>
>> wrote:
>> >
>> > Also to be clear - whilst I agree that RTP on QUIC is interesting - it
>> is not in scope because httpbis is our target, not quic. We want to allow
>> voice signaling and media to run over web infrastructure services, so http
>> is our 'waist of the hourglass' not quic.
>>
>> So just to clarify here:  Is your goal (for this protocol) that media be
>> transferred only over streams (TCP or (reliable) QUIC), not datagrams?
>> Consequently, how important is end-to-end latency for audio/video calls
>> that would use this protocol?
>>
>
> Critical. We believe that there are techniques within HTTP/3 that can
> address this situation, although (speaking for myself) we may find
> ourselves needing to go lower in the protocol stack.
>

Yeah, that was certainly the goal (no one was ignoring latency in the QUIC
working group, either). IIUC, this approach would be tied to HTTP
infrastructure that hasn't had end-to-end latency for realtime
communication as a goal in the past, but we'll see where this goes.


> And are peer-to-peer audio/video calls (that would not involve a web
>> server at all, except perhaps for initial end-user lookup/discovery) out of
>> scope for this protocol?
>>
>
> P2P is in scope, but using existing WebRTC protocols. Since p2p scenarios
> require both endpoints to participate, there's a chicken-and-egg problem
> there, and we can look at that after we get things working in the c2s
> scenario.
>
>>
>> If that's the case, then you’re not really ‘replacing’ RTP, but rather
>> defining a new media transport protocol to be used in this one (restricted,
>> but important) environment: Transport using reliable protocols via web
>> server(s).  And if that’s the case, then I’m concerned that your SIP
>> replacement (i.e., replacement of the one thing that’s truly broken, and
>> needs replacing) might end up being too restrictive for more general media
>> transport (datagrams and/or peer-to-peer).
>>
>
> This is a reasonable concern, but we think that starting small and
> expanding scope later (especially when there is a sense of how that
> expansion might work) might allow for faster progress.
>

That's fair. Collecting actual experience and data is rarely wrong.

Best.

Spencer


>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>> --
>> V3 mailing list
>> V3@ietf.org
>> https://www.ietf.org/mailman/listinfo/v3
>>
>