IETF Logo Mail Archive

Re: [bfcpbis] FW: Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 01 December 2016 19:57 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B60129ED7 for <bfcpbis@ietfa.amsl.com>; Thu, 1 Dec 2016 11:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level:
X-Spam-Status: No, score=-17.417 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9nOBEfdJzgmy for <bfcpbis@ietfa.amsl.com>; Thu, 1 Dec 2016 11:57:15 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F525129D20 for <bfcpbis@ietf.org>; Thu, 1 Dec 2016 11:45:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12610; q=dns/txt; s=iport; t=1480621523; x=1481831123; h=from:to:subject:date:message-id:mime-version; bh=+V8+ZTdXCXUwAu3zlNw1S/LhfOcIgGbjHz2/apRbyag=; b=YjG3/eZRp/gp+NQ9Xwgg64ZzzG5F2j7svTTWKLJ8lnPUgVCFJR1I1cjm 2FbRtpa/EusoL5TSYtj6B8c5wlMlR4VSTt3UzSAPpbOV0XAaYGPgbIcSm 3PGhrcAQYqsffPmaSWfXUrhtHle7BOI+I71c7iXkqJRtI24XqWiqBV05H 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CCAQAkfUBY/5ldJa1cGgEBAQECAQEBAQgBAQEBgnNFAQEBAQEfWIEGB40+lwuPWIUgggWGIgIagXA/FAECAQEBAQEBAWIohGgBAQUjaAEIEQMBAQEkBAMCBDAUCAEKBAESiG2sSYIpL4sMAQEBAQEBAQEBAQEBAQEBAQEBAR6IOwiCVoRpFoJOLYIwBYlDkRsBkQ+BcoR7iUmNeoQLAR43MGkjDgEBg12BRXKINoENAQEB
X-IronPort-AV: E=Sophos;i="5.33,726,1477958400"; d="scan'208,217";a="353607949"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2016 19:45:22 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB1JjMFX005112 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Dec 2016 19:45:22 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Dec 2016 13:45:22 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Thu, 1 Dec 2016 13:45:21 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] FW: Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?
Thread-Index: AQHSTAtz9sVBeuUTy0em3W4FN9quUg==
Date: Thu, 01 Dec 2016 19:45:21 +0000
Message-ID: <3211B903-DD95-4169-B6F2-64C16A5F8A50@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: multipart/alternative; boundary="_000_3211B903DD954169B6F264C16A5F8A50ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/TtbGHPdeRyTbBNKdp0cDsZ8KjAw>
Subject: Re: [bfcpbis] FW: Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 19:57:17 -0000

For BFCP, requiring support for transport switch on-the-fly before nomination seems like overkill.

Cheers,
Charles


From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Saturday, November 19, 2016 at 1:30 AM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] FW: Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

Forwarding to bfcpbis, as this is very much related to BFCP. If you have comments, please bring those to the ICE WG list, so we get everything in one place :)

Regards,

Christer

From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 19 November 2016 11:27
To: ice@ietf.org
Subject: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

Hi,

One potential issue that came to my mind while reading the SDP m- line thread.

Previously, before removal of aggressive nomination, while and endpoint might support both UDP and TCP for a protocol, it didn’t have to be able to simultaneously use the protocol with both UDP and TCP, and switching between. Because, until nomination was done, no protocol data was sent. And, once nomination had been done, endpoints used the protocol with the selected transport.

Now, with the allowed-to-send-media-before-nomination rules, protocols basically have to support switch of transport (from UDP to TCP, and vice versa), until the nomination takes place.

Now, even people always say that a good designed protocol should be transport-independent, isn’t *mandating* transport switching on-the-fly (before nomination takes place) by all protocols supporting ICE and multiple transports a bad thing to do?

Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should indicate whether transport switching is supported, and whether there are protocol specific procedures associated with that. I guess a protocol could also specify that data shouldn’t be sent in the first place before nomination has been done, if there are good reasons for that.

Regards,

Christer

v2.23.0 | Report a Bug | By Email