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

"Asveren, Tolga" <tasveren@rbbn.com> Thu, 20 February 2020 00:37 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 2F7FF120113 for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 16:37:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IOrj_e90Uk25 for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 16:37:34 -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 4D0EE1200F5 for <v3@ietf.org>; Wed, 19 Feb 2020 16:37:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1582159053; 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=sInHCy33UnRhCbppCR96/Vi4LFmTzvhzbeCU5ReVlf0=; b=hmTuHY/DGBdUwrlWDLv/uAciaAs5jMEXDFiwC9sShFeenDZt9UkVeWp7TFp8+Ig8uYV2/T MfpwsWaYX5BhT1JVd6XiqujfaSLsO+afA2f/O9phARIygu/Mm/snodJnfXrlXuPUQW3cP1 Rv4t69klJ1+VhMU1iVyRv8hc6/4Cyic=
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-427-Yz_UIMK4PfeXsw5k7IpMJQ-1; Wed, 19 Feb 2020 19:37:31 -0500
Received: from BN7PR03MB3827.namprd03.prod.outlook.com (2603:10b6:408:23::13) by BN7PR03MB4436.namprd03.prod.outlook.com (2603:10b6:408:3d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.26; Thu, 20 Feb 2020 00:37:27 +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.033; Thu, 20 Feb 2020 00:37:27 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Ross Finlayson <finlayson@live555.com>, Jonathan Rosenberg <jdrosen@five9.com>
CC: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>, "v3@ietf.org" <v3@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [V3] RIPT BoF approved for IETF 107 - Draft charter below
Thread-Index: AQHV45U4cZj76Gp4skah7JWVZNy8Q6gbwyUAgAViGQCAAEBWAIAALfkAgABXswCAAJExgIAAFm4AgAAOTYCAAJ+gcA==
Date: Thu, 20 Feb 2020 00:37:26 +0000
Message-ID: <BN7PR03MB3827B4A0429BD4372DA9B1ECA5130@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> <CAOJ7v-0YiTZUQ5C7T8zOoe7f4jLWG8hYE08mC_cNuqzVLMZy6w@mail.gmail.com> <CAKKJt-ewJuBY_wu9Uhg2ijOcCRXpFy-tXzFwoKjarA3EV6-EkA@mail.gmail.com> <BYAPR06MB43911753D17BCADE1B0DF40DFB100@BYAPR06MB4391.namprd06.prod.outlook.com> <B0796F47-9F6C-4242-8A96-33A9FCEF73B5@live555.com>
In-Reply-To: <B0796F47-9F6C-4242-8A96-33A9FCEF73B5@live555.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: b8fbbe74-aff4-430b-9a47-08d7b59d0f95
x-ms-traffictypediagnostic: BN7PR03MB4436:
x-microsoft-antispam-prvs: <BN7PR03MB44361837CE44ABA847AC9081A5130@BN7PR03MB4436.namprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(376002)(39850400004)(366004)(189003)(199004)(8676002)(8936002)(81156014)(2906002)(81166006)(55016002)(9686003)(4326008)(54906003)(5660300002)(316002)(66946007)(110136005)(52536014)(66476007)(66446008)(66556008)(64756008)(7696005)(478600001)(966005)(71200400001)(76116006)(33656002)(6506007)(53546011)(186003)(66574012)(86362001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR03MB4436; 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: RuQu06JPv6fUWdEJvgBn0KshvW50cCwSwDp2TxEB9cu6Zb0pt4uSkTDN+f1Bm26GAYv0WqROHr7PHJ0ssCNtRyMKvjZ4yRHy4bLHmvojbopnk17tHk0kK4gkrPQb3XwC9nWqEIsHjoTEgaJ8VydrcCRCmWnnbVZU4uwGtslHF/qqhYhttuqFdFkN3ConJataT1A2a6z5wqvx4OyGZ45t7GMlusmQyiWVRavczEczfdGMue4UoywhZSLRYc2+G10nyUCtxkaXjaXSR6doMtOTCK8WN0aYxXe+WHL+2Khlc8wXAUDkxAe1CSASphRXobhuJn0QalH7bz+Zq3GYvWkx9vkShBvbyVQ05vZ0Z7sXftuys4bz/ZKiIzEdQ/zGuyCXJBv424ByeY7g5v9I6rL0z/ZC+DCiHy3+xQTNeW4rTYgB+MqWhEEEVjUmjCXuknRr8Ym9ajtlC/7lMQA/q5iOEG5Z5V6goO+hpVSe+++j+4A5qnvfyIz5kla99vcGZ9k/wW7NAOC66x/ZV2H5ju21gA==
x-ms-exchange-antispam-messagedata: KbTaNTrOKOusRwnLd6aXAV+7ncJ1v+6v4xPhftDg8TYqVtmvBXTMnYMs8aR8KLjS/wc5VdfOohkWlc6kOl9mnlaSbphChTqkFE7sYrT53QEpINYcaTqvnOI6/VZYseo7NXyO5QRPf0oR+EHK9/Ov8A==
x-ms-exchange-transport-forked: True
x-originatororg: rbbn.com
x-ms-exchange-crosstenant-network-message-id: b8fbbe74-aff4-430b-9a47-08d7b59d0f95
x-ms-exchange-crosstenant-originalarrivaltime: 20 Feb 2020 00:37:26.8382 (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: 5I6Z0DoUL5VcJW+xH7RYAVeWpaaPnbgsKH2u1NfdR3xeuW7OGR/TUKaoGz5GrZTVvV3dRuNfHVekQ42eKwOAxA==
x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB4436
x-mc-unique: Yz_UIMK4PfeXsw5k7IpMJQ-1
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Type: multipart/alternative; boundary="_000_BN7PR03MB3827B4A0429BD4372DA9B1ECA5130BN7PR03MB3827namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/U6PGq8ZZUz79prvn-A2axZVqtC4>
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: Thu, 20 Feb 2020 00:37:38 -0000

“Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice.”

I would like to point out that this is an important assumption and does not entirely overlap with reality. Application specific and L4 load balancers are used widely in Cloud deployments for real-time sessions. I doubt standard HTTP  load balancers can be used as is even if all real time session messaging (signaling, media, …) is HTTP based. Required semantics, e.g. different treatment based on RPH, overload control etc…,  are simply different than what is needed/used/sufficient for standard Web applications.

On another note, a core issue for Cloud load balancing is failure detection/failover time for back ends servers. This again is an area where “just using HTTP” wouldn’t help.

Having “HTTP only” as a core principle is fine but I think the rationale for that should be articulated more in detail and clarity.

Thanks,
Tolga

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

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



> On Feb 20, 2020, at 3:01 AM, Jonathan Rosenberg <jdrosen@five9.com<mailto:jdrosen@five9.com>> wrote:
>
> Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice. That means that clients have to send media through HTTP. Secondly, we assume that sticky routing happens in these load balancers the ‘normal’ way – through a combo of hashing of 5-tuples and usage of session cookies. That means that, in order to get the media to the server handling the signaling (which is what we want), the media needs to come in the same connection, and use cookies. This further ties it to HTTP. In order to deal with failures of those servers and enable mid-call recovery without loss of media packets, we also need the transport to contain call identifiers. This way, media can just ‘be sent’ to a new server in the pool behind the load balancer, and it can pick up where things left off in the previous server without losing any media packets (like - not one). In RIPT this happens because all media are PUT/GET from the call URI.

OK, thanks - this explanation makes it very clear that what you’re planning is a protocol for audio/video calls *over HTTP* - and over HTTP only. A lot of the confusion (largely on my part, I admit) about what you’re proposing would have been avoided if this had been clearer in the name of the protocol (and BOF) - i.e., if there had been an “H” in there (I would have preferred something like MoH: “Media over HTTP” :-)

And grandiose statements about this protocol "replacing SIP, RTP and SDP” don’t help either - unless you really see the “HTTP Internet” (hourglass) becoming the entire Internet. (Not all of us are ready to concede that, just yet ;-)


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