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

"Asveren, Tolga" <tasveren@rbbn.com> Wed, 19 February 2020 01:26 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 38152120871 for <v3@ietfa.amsl.com>; Tue, 18 Feb 2020 17:26:05 -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=ham 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 fbZIWeZ3RJy8 for <v3@ietfa.amsl.com>; Tue, 18 Feb 2020 17:26:02 -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 C67C512086E for <v3@ietf.org>; Tue, 18 Feb 2020 17:26:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1582075560; 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=iI5kInOA2dTFHpDNCU1tRdOd8NZHOyV0KEcmlryeJ2g=; b=SH0FUgV8S2cQqPxtTJMZ7LXzUeI9ZSQR+53JKz3ehDLv+nNlGxlNY/Y2IG1KbtZHnvYvqA tWC/wcxLGU2oS60mamD2vtJ66hmTe1GTt4TXEjQNGXTU22j/fy/raB8xjRCnz+dOa8uIqW /zsLMxY+m3yZqpHb6BhPvVFOofi8P8U=
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-287-izTitLlZMmu-MDqXsajqmg-1; Tue, 18 Feb 2020 20:25:57 -0500
Received: from BN7PR03MB3827.namprd03.prod.outlook.com (20.176.26.205) by BN7PR03MB4321.namprd03.prod.outlook.com (20.176.28.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22; Wed, 19 Feb 2020 01:25:55 +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.032; Wed, 19 Feb 2020 01:25:55 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, 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>
Date: Tue, 18 Feb 2020 20:25:54 -0500
Thread-Topic: [V3] RIPT BoF approved for IETF 107 - Draft charter below
Thread-Index: AQHV45U4cZj76Gp4skah7JWVZNy8Q6gbwyUAgAViGQCAAEBWAIAALfkAgAAsDUA=
Message-ID: <BN7PR03MB3827992D5CC087C489672451A5100@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> <BYAPR06MB4391E5B3FB4258BEF59F7BFBFB110@BYAPR06MB4391.namprd06.prod.outlook.com> <3254DED7-C105-4674-82E4-0D6968CB8744@live555.com> <CAKKJt-e5byVGLTgQAKWn=c9q1eU4mf8e=b8mucPOppPsmFnShw@mail.gmail.com>
In-Reply-To: <CAKKJt-e5byVGLTgQAKWn=c9q1eU4mf8e=b8mucPOppPsmFnShw@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: cf481c73-300a-4dc2-fe79-08d7b4daaa62
x-ms-traffictypediagnostic: BN7PR03MB4321:
x-microsoft-antispam-prvs: <BN7PR03MB4321DA6E269CF7BACFF5D838A5100@BN7PR03MB4321.namprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(366004)(376002)(189003)(199004)(54906003)(966005)(4326008)(110136005)(55016002)(52536014)(5660300002)(478600001)(71200400001)(26005)(86362001)(8936002)(186003)(81156014)(33656002)(81166006)(66946007)(8676002)(316002)(7696005)(76116006)(64756008)(9686003)(66476007)(2906002)(66446008)(66556008)(53546011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR03MB4321; H:BN7PR03MB3827.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zTgYmfPAwpgI7Mfhg89pfCWeOL7P4qC8xhzWid1PIlC7jRSx1tc4zeVB22yqi4t3TVY5Se39VRM8qcj4xcrcPkJ9NlfwmjNMk62AfSerZ3hLunS41shBIBN1ixDOWQ5gfKJRDZQcDamcOSzRqvOWY9Llho0ZISHvWehPyoSh5je2TEWZCJRTV5BQPXQ/tBAYSe/wMhJqgLEvqLVeSEg+LCVGZr1OE1pqtWYeeFijpV7LTa6N08Aa3pF4Jq6jDqr1cIJnXgi6wqnWgkX4/0tY4Q71UGpj/vcKxZy03IBYWIoi0K4J9gYR8PPBj5swbGXm0w5ocD3WNCc2O9VbhddmB2uOex83TxFyfq723Y5w/q2+UzyI39kTW/mR6g2fGRYauwSAmRMSfrWj5AQOkiCBJRuOe1ae2qWNA8hPSHDm/y2CSZ36+l59IV6xtW+YuNYRx5hlYhlOdJLcpT8F/YDNbXbpL8sKavMucpFB1comiepN44h+N80YoODvghfN6pCuiT2zp6JwNc2dvEw/LcmmWQ==
x-ms-exchange-antispam-messagedata: /AtPGxnSisu4O0bsTHe7a4SS9aF38LX6FGtLvc1qdAdi4d5JxQqmKjPa3SXOpdcgLZL+6m2+ZY2YhRUFilEgvKT+IoRb/RehYDv0LqVQKTL70nC5erAdjfoa59A8rpaMyx4cXr+lqqCcV/nJnMOq9g==
x-ms-exchange-transport-forked: True
x-originatororg: rbbn.com
x-ms-exchange-crosstenant-network-message-id: cf481c73-300a-4dc2-fe79-08d7b4daaa62
x-ms-exchange-crosstenant-originalarrivaltime: 19 Feb 2020 01:25:54.9979 (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: JnaUHBDO4DDYTGJvNkQBtM5PhUkKTOO3hc+QgXcKjOrMlFAq3H1pPhzr++MRwBUCGZ5I9KVljWC5NgdoTBAzmQ==
x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB4321
x-mc-unique: izTitLlZMmu-MDqXsajqmg-1
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Type: multipart/alternative; boundary="_000_BN7PR03MB3827992D5CC087C489672451A5100BN7PR03MB3827namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/hhppNrfrvyQ3nZMjF3QWURdkBwg>
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 01:26:05 -0000

“So, the first suggestion I'd make at the BOF, if work on media transport of whatever flavor is still part of the proposed RIPT charter, is to split it off into a separate proposal, which I'd love to see go forward on its own, unless there are really strong reasons why RIPT signaling specification work and RIPT media transport work need to be coupled, need to fate-share, and need to compete for attention in the same working group. “

Couldn’t agree more.

Thanks,
Tolga

From: V3 <v3-bounces@ietf.org> On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, February 18, 2020 5:47 PM
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
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

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

I am also hoping for clarity here, or at least clue.

On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <finlayson@live555.com<mailto:finlayson@live555.com>> wrote:

> On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <jdrosen@five9.com<mailto: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?

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?

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

I think I arrived at the same place as Ross, coming from the opposite direction. ("Thunk!")

ISTM that the proposal floating through here for a new media transport protocol, if it is successful, would be useful for non-RIPT applications as well, and ISTM that other proposals for RTP over QUIC (or whatever we're all muttering about privately), if one of them is successful, might be useful for RIPT applications as well.

So, the first suggestion I'd make at the BOF, if work on media transport of whatever flavor is still part of the proposed RIPT charter, is to split it off into a separate proposal, which I'd love to see go forward on its own, unless there are really strong reasons why RIPT signaling specification work and RIPT media transport work need to be coupled, need to fate-share, and need to compete for attention in the same working group.

I can say more about that at a mike in Vancouver, but let me start with this, on a mailing list ...

Best,

Spencer

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


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