IETF Logo Mail Archive

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

Ross Finlayson <finlayson@live555.com> Sat, 15 February 2020 06:00 UTC

Return-Path: <finlayson@live555.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 A30541200C3 for <v3@ietfa.amsl.com>; Fri, 14 Feb 2020 22:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 273b2puXjblF for <v3@ietfa.amsl.com>; Fri, 14 Feb 2020 22:00:18 -0800 (PST)
Received: from us.live555.com (us.live555.com [52.8.240.222]) (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 189AA12004E for <v3@ietf.org>; Fri, 14 Feb 2020 22:00:18 -0800 (PST)
Received: from [127.0.0.1] (localhost.live555.com [IPv6:0:0:0:0:0:0:0:1]) by us.live555.com (8.15.2/8.15.2) with ESMTP id 01F600Wp009195; Fri, 14 Feb 2020 22:00:02 -0800 (PST) (envelope-from finlayson@live555.com)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Ross Finlayson <finlayson@live555.com>
In-Reply-To: <CA+23+fGNO86ii6q0hd3aiSdib2AT-iu3O+DmgGJXTFbFkGxLnQ@mail.gmail.com>
Date: Sat, 15 Feb 2020 19:00:00 +1300
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Jonathan Rosenberg <jdrosen@five9.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F72DFB60-1BA3-4CD3-9DB2-DF986F3729DE@live555.com>
References: <BYAPR06MB43914433BF91CE216E6123A6FB150@BYAPR06MB4391.namprd06.prod.outlook.com> <CAKKJt-eKB4wxqK8Xiho2tYaqpM3_fjQYsjJh5-cf_RWd6iR8sQ@mail.gmail.com> <CA+23+fGNO86ii6q0hd3aiSdib2AT-iu3O+DmgGJXTFbFkGxLnQ@mail.gmail.com>
To: "v3@ietf.org" <v3@ietf.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/2jAyqsXuYZZhKC_0D6xPMsl7PDM>
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: Sat, 15 Feb 2020 06:00:21 -0000

On Feb 15, 2020, at 1:15 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
> 
> RTP is in scope, in that, RIPT replaces RTP (and SDP and SIP).
> 
> Basically, the output of the codec is placed into something called a 'media chunk' which adds a few parameters which are similar to RTP (i.e., timestamp) and then sent in a PUT request or GET response.

Jonathan is ‘handwaving’ a bit here :-), as he understands (more than just about anyone) that replicating the functionality of RTP would involve a lot more than just adding a few parameters to PUT and GET.  For each media type being transported, you’d need to define how data is best framed within (QUIC) datagrams, how (optional) FEC could be used, what RTCP XR functionality will be retained (and how), how (the equivalent of) RTP header options would be defined/carried, etc. etc. etc.  Essentially, you’d be replicating all of the work that took place (over several years) within AVT to define a RTP payload format for each media type.  Therefore...


> No doubt an issue of contention will be whether we should just encapsulate RTP vs. whats in the draft.

If we want to get something standardized/working quickly, then this is a ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets directly in QUIC datagrams - in such a way that the existing RTP payload format defined for each media type could map directly (i.e., with no more media-specific IETF standardization work required).  Even if this means that there's some duplication of functionality between RTP and QUIC (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)

While - at some point in the future - it may be worthwhile defining a new version (v3?) of RTP that works more efficiently with QUIC, this should not be something that we require before we define/standardize a replacement for SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to show its age, but it’s not broken, and has lots of existing deployment that could, ideally, be leveraged quickly within a SIP replacement.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

v2.23.0 | Report a Bug | By Email