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

"Asveren, Tolga" <tasveren@rbbn.com> Sat, 15 February 2020 20:10 UTC

Return-Path: <tasveren@rbbn.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 9C13B1200F9 for <v3@ietfa.amsl.com>; Sat, 15 Feb 2020 12:10:54 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 9VAhVq9t9plr for <v3@ietfa.amsl.com>; Sat, 15 Feb 2020 12:10:51 -0800 (PST)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0B21200E3 for <v3@ietf.org>; Sat, 15 Feb 2020 12:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1581797450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H9aqe+kD036j5ysJlouoRn01AKGeILqWzypPX9ztggg=; b=ME83TH5gMktXYg2lLsS+rwlLOEzYgt24MIo8Cis8i4AgonTc5brS7Nx4XWvKa59nyImlPe 3/zEgnE59VGBoAmGiPYe5QFnFPkBOOQ+59qm8uF6scBDKdijsDZfV0u4yPgfX55mKIohuO m5sBLinHR/FuH6gJqO+R/WdtFQOhxzk=
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2173.outbound.protection.outlook.com [104.47.56.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-353-I6Tu6zOdNTKthgrA_BVDqw-1; Sat, 15 Feb 2020 15:10:47 -0500
Received: from BN7PR03MB3827.namprd03.prod.outlook.com (20.176.26.205) by BN7PR03MB4562.namprd03.prod.outlook.com (20.176.31.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.23; Sat, 15 Feb 2020 20:10:42 +0000
Received: from BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::9c17:4041:33fc:4de]) by BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::9c17:4041:33fc:4de%7]) with mapi id 15.20.2729.028; Sat, 15 Feb 2020 20:10:42 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>, Ross Finlayson <finlayson@live555.com>
CC: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>, Jonathan Rosenberg <jdrosen@five9.com>, "v3@ietf.org" <v3@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sat, 15 Feb 2020 15:10:42 -0500
Thread-Topic: [V3] RIPT BoF approved for IETF 107 - Draft charter below
Thread-Index: AQHV45U4cZj76Gp4skah7JWVZNy8Q6gckIxLgAAfIBA=
Message-ID: <BN7PR03MB382750D9E7076A0479F8919CA5140@BN7PR03MB3827.namprd03.prod.outlook.com>
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> <CAOJ7v-3s4mPZVxye2Lemz5uf5_6Dg_F+OOfshQ8xG5qBkXh7vw@mail.gmail.com>
In-Reply-To: <CAOJ7v-3s4mPZVxye2Lemz5uf5_6Dg_F+OOfshQ8xG5qBkXh7vw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@rbbn.com;
x-originating-ip: [73.80.74.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13fa4c4b-cfd0-4737-d4a6-08d7b253228b
x-ms-traffictypediagnostic: BN7PR03MB4562:
x-microsoft-antispam-prvs: <BN7PR03MB456265C41B41A8A964C0D8A6A5140@BN7PR03MB4562.namprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 03142412E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(396003)(39850400004)(136003)(199004)(189003)(81156014)(81166006)(8936002)(86362001)(8676002)(71200400001)(966005)(4326008)(33656002)(478600001)(9686003)(55016002)(7696005)(76116006)(2906002)(5660300002)(66946007)(53546011)(6506007)(186003)(316002)(66556008)(66446008)(64756008)(52536014)(26005)(66476007)(54906003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR03MB4562; H:BN7PR03MB3827.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OAHOD+O1+UUXtQnxhWzsMQCZVtwHoyBxMvR+nyNCOmiEP62QcCQy/Tv9MkCzDAObAfkklbFKv4YPAYPO24R34/nDadCENcP66ZlcSYL+22cjxQ+WsYx7RseG63rhzdLwmHSLw4eJTdptD7eTA2eM8X2ukMlRmcw/J7ev8H834JP5DNESxO+Qo26xPETPa6WtKvSSQJoPcUKjK+EqaHyrZ61TPmlYO1v+LT0BeaLqsQSuVFP4ykNgkKmweAUf/OrS0koA/+L+/UXsm/kXILPIKS3GQYOv5sIkbS9Pj7sCn3ZrrB7L3hv/04f687kJU52nC9jsxK4Q3Ju2pyQlDtg25wHeXRcCIX/V4R4HdIHbhZmCKSPoPM9d+AYWaPDC7N9vAB63aXQUzsTS3rsh0B57OtbpzlGRFCmkiibQdIyqlR1bXCr1jvUvk1oBHDKXcUEm8YOjk1vqxVNbdblvXCjj8cKNU7shjXY+jcahW9+ZNVd4nehYclYv18Dhbv+giZiVXdt7VV91GjYCP2MhFVJEVQ==
x-ms-exchange-antispam-messagedata: HYezFHJ9UgvrLNCowVYvMjOmEYqn4nbdYI8yLrFYPglt8qssUgVrUJa4szjTNK2LLf4hc8QeFg8899aPw/ZnZqwUbaOSEO5ikkyERmslbTu6vP4B07VOxJLl+09lK1HulW7KJcel5LZygJu0so1pHg==
x-ms-exchange-transport-forked: True
x-originatororg: rbbn.com
x-ms-exchange-crosstenant-network-message-id: 13fa4c4b-cfd0-4737-d4a6-08d7b253228b
x-ms-exchange-crosstenant-originalarrivaltime: 15 Feb 2020 20:10:42.7263 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: 8loJ0NwY/CAfJSq5nBv1zCyLFh4DFQiOi4FK7soIQe1VbskCd1CoHJlLTgbKgB+l8T2jZDyiKjP0Jim3FaX3fw==
x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB4562
x-mc-unique: I6Tu6zOdNTKthgrA_BVDqw-1
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Type: multipart/alternative; boundary="_000_BN7PR03MB382750D9E7076A0479F8919CA5140BN7PR03MB3827namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/Q7iSA6mrZdPrvvd0qTO8DL0kDaY>
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 20:10:55 -0000

I also would think that “encapsulated RTP” approach is more promising as a starting point for all the reasons already mentioned. Having said that, and despite probably being one of the most “legacy oriented” people in the WG, I think it is worth to assess other strategies as well. I would consider cloud/legacy/failover friendliness as important parameters during this process.

Thanks,
Tolga

From: V3 <v3-bounces@ietf.org> On Behalf Of Justin Uberti
Sent: Saturday, February 15, 2020 2:55 AM
To: Ross Finlayson <finlayson@live555.com>
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com>om>; Jonathan Rosenberg <jdrosen@jdrosen.net>et>; Jonathan Rosenberg <jdrosen@five9.com>om>; v3@ietf.org; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________



On Fri, Feb 14, 2020 at 10:00 PM Ross Finlayson <finlayson@live555.com<mailto:finlayson@live555.com>> wrote:
On Feb 15, 2020, at 1:15 PM, Jonathan Rosenberg <jdrosen@jdrosen.net<mailto: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.)

Yes, this is my preferred approach. There still will be a lot of work just to get this up and running, figure out how congestion control works in this world, and avoid ending up with a lot of bloat from the encapsulation. Assuming this works, we get fairly straightforward gatewaying between the old and new worlds.


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/<http://www.live555.com/>


--
V3 mailing list
V3@ietf.org<mailto:V3@ietf.org>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------