Re: [clue] [art] ICE, ICE-bis, and Cluster 238

Christer Holmberg <> Fri, 07 September 2018 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13C28130EC2 for <>; Fri, 7 Sep 2018 00:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.308
X-Spam-Status: No, score=-4.308 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ISOhmSPZ4ioT for <>; Fri, 7 Sep 2018 00:25:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C38E8130DF9 for <>; Fri, 7 Sep 2018 00:25:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1536305117; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FkGBDykQ/ya0c1IzjIFgjsVVAsc0Zz2Uq5JoqQAveR0=; b=LNIXG9KzlLieZgUEgSP1c1Vj/8bkD+6Es3FHM6yJTAV3ZVjXufckRjIJGUJpyZXV jwuE4O2rIt3yGAuRPboYpeP1YcYVdMo9ZBso8ERsrhXhsVP82UBBaYudW9uaUMrw UKpxVMoorR9gHcKjp5VmD6n9Qw0VNpechEWctOhRBTM=;
X-AuditID: c1b4fb2d-5ecb19c0000055ff-e8-5b9227dc84ff
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id EB.F6.22015.CD7229B5; Fri, 7 Sep 2018 09:25:17 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Sep 2018 09:25:13 +0200
Received: from ([]) by ([]) with mapi id 15.01.1466.003; Fri, 7 Sep 2018 09:25:13 +0200
From: Christer Holmberg <>
To: Cullen Jennings <>, "Applications and Real-Time Area Discussion" <>
CC: RTCWeb IETF <>, "" <>, "" <>, "" <>
Thread-Topic: [art] [clue] ICE, ICE-bis, and Cluster 238
Thread-Index: AQHURh+v3CEVPFpjI0266oWKAGTzsaTkftOA
Date: Fri, 7 Sep 2018 07:25:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_46E40ED2D2894C0F8C0B82A5980B2692ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyM2J7he5d9UnRBstuMVqsuOthsf/UZWaL D+t/MFp8u1BrMXX5YxaLtf/a2R3YPJYs+cnkcfn8R8YApigum5TUnMyy1CJ9uwSujJbdygWX m5grdkyobWA89oOpi5GDQ0LARGLShPIuRk4OIYGjjBIfGvQg7K+MEidbCiHspYwS75Yxg5Sz CVhIdP/TBgmLCCRJTNo9m7GLkYuDWaCDUWL77kOsIDXCAuYS7w6xQdRYSGx/+ZkFwjaSuDVz LSuIzSKgIvF41X8wm1fAXmLdroXsIK1CAnkS9z9LgIQ5Bawk1nQ2sIPYjAJiEt9PrWECsZkF xCVuPZkPZksICEgs2XOeGcIWlXj5+B/YBaIC+hLTLgdAhJUktvRugWpNltj89QYbxFZBiZMz n7BMYBSbhWTqLCRls5CUzQKayiygKbF+lz5EiaLElO6H7BC2hkTrnLlQtrXE/b9PmJHVLGDk WMUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGLcHt/zW3cG4+rXjIUYBDkYlHt5ZYpOihVgT y4orcw8xSnAwK4nwMikAhXhTEiurUovy44tKc1KLDzFKc7AoifPqrdoTJSSQnliSmp2aWpBa BJNl4uCUamAs+HJ9+aa/Deu2b7hR8fRH6VkzDYct52MyPzMWJP5btknsgNucS3HLdz/RTXDu 1XjzcbvgljX/vJ0kuHq/LrmY0fZQkLfLu0V+0jK1XOdV24wb6torhN98vNJt+1K4vluea5U3 /+9DNxYa6KzhSHKpNroeqB87K1A4R/AEa7PD7D9OL7S9OpmVWIozEg21mIuKEwEAy+Xg1wIA AA==
Archived-At: <>
Subject: Re: [clue] [art] ICE, ICE-bis, and Cluster 238
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Sep 2018 07:25:33 -0000


> I object to this plan.
> It is not merely an issue of which document we point out, and they are all the same. The problem is the timing of 8445 is not clearly interoperable with the timing of 5245. ICE relies on both
> sides to do sequence things at roughly the same order so that suicided packets open pinholes in the reverse direction at the right time. The changes in timing change how this happens and is a problem for the ICE algorithm.
> This was discussed in the WG, and though not everyone agrees it is a problem or not, no one has ever provided a convincing argument that it is not. This is a very substantial change to the on the wire protocol and at a minimum
> would need to be reviewed and discussed in the WG not slipped through in Auth 48 during a one week period in the summer while everyone is on vacation. We will also need to change other examples and normative text in drafts like JSEP.

What normative text do you need to change in JSEP?

In fact, I would even claim that the JSEP text is more aligned with 8445 than 5245. For example, JSEP does not talk about aggressive and normative nomination, only about nomination.

> I would propose that instead of the parts of specs that use the trickle mechanism purely reference that part of the new ICE spec that defines the syntax and say to transfer trickle candidates.

It is not only about the syntax. The trickle procedures are based on procedures in 8445.

> Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These gratuitous changes, years after the implementation were coded, with no real benefit will ensure that we are not
> and will not become compliant with the RFC. It's unlikely we will upgrade to the new ICE until it has real befits.

The main reason we did 8445 was because people had identified issues with 5245. The work was driven mostly by the WebRTC community, including yourself and the Chrome people (or, at least the Google people), and one of the reason it took time to finalize 8445 was because you (among others) wanted to make sure we get things right (by making network measurements etc). Are you now saying all those changes bring no benefit? Did we all waste our time?

> It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. Instead, we will move to say "works with Browser X version Y or later." We have watched at W3C as it moved to be that unless chrome does it, it rare that it becomes a standard.
> Right here I am watching how the stuff IETF defines will be less relevant than the issue of what chrome implements.

What exactly would Justin have to change?



On Aug 22, 2018, at 10:58 AM, Adam Roach <<>> wrote:

Members of the ART community interested in real-time communications:
Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.
One long-running complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.
It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).
Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.
In order to get Cluster 238 published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.
This would result in a request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:

While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.
There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:


   | Name              | Notes                     | Level | Mux       |

   |                   |                           |       | Category  |


   | ice2              | Not Impacted              | S     | NORMAL    |

   |                   |                           |       |           |


For clarity, the affected documents are as follows.
The following documents would be updated to reference RFC 8445 prior to IESG evaluation:

  *   draft-ietf-clue-datachannel
  *   draft-ietf-clue-signaling
  *   draft-ietf-rtcweb-security
  *   draft-ietf-rtcweb-security-arch

The following documents would be updated to reference RFC 8445 by the RFC Editor:

  *   draft-ietf-mmusic-mux-exclusive
  *   draft-ietf-mmusic-sctp-sdp
  *   draft-ietf-rtcweb-alpn
  *   draft-ietf-rtcweb-data-channel
  *   draft-ietf-rtcweb-rtp-usage

The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:

  *   draft-ietf-rtcweb-jsep
  *   draft-ietf-rtcweb-overview

The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:

  *   draft-ietf-mmusic-sdp-mux-attributes

This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <><>. Thank you.
/Adam on behalf of the ART Area Directors
clue mailing list<>