From nobody Fri Apr 1 11:26:30 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0BC12D6B0 for ; Fri, 1 Apr 2016 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ImhI9-eN1HEp for ; Fri, 1 Apr 2016 11:26:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B800F12D69E for ; Fri, 1 Apr 2016 11:26:25 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-e7-56febd4ff7bc Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.9E.22880.F4DBEF65; Fri, 1 Apr 2016 20:26:23 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Fri, 1 Apr 2016 20:26:18 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "ice@ietf.org" Thread-Topic: Removing ICE frozen algorithm Thread-Index: AQHRjEP7zVDF6SpZL0qnL8oxrj6Wsg== Date: Fri, 1 Apr 2016 18:26:17 +0000 Message-ID: <1F541F0A-F666-4A10-AFD7-76E6974C8291@ericsson.com> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <90035D2DC5055247AC38E9E5864DF437@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7rq7/3n9hBt+2KVh8u1BrcW35a1aL Y3v6mR2YPRZsKvVYsuQnk8fcPS+YA5ijuGxSUnMyy1KL9O0SuDK6361nK1giUbHqQQtLA+MV 8S5GTg4JAROJ9Zv3s0HYYhIX7q0Hs4UEjjBKnGs06GLkArIXM0q8frmUHSTBJmAr8aR1HyuI LSKgKDGz5RkzSBGzQDujRPPeO0xdjBwcwgJqEsc3sUPUaEtc3vuBBSQsIqAnMXGaNkiYRUBF ov31S7AxvAL2Ehs3fGeD2PWURWLpsnlg9ZwCgRL/P0qD1DAC3fb91BomEJtZQFzi1pP5TBA3 C0gs2XOeGcIWlXj5+B8rhK0ksfbwdrAxzAKaEut36UO0Wku8WLyQEcJWlJjS/ZAd4gRBiZMz n7BMYBSfhWTDLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwMg7 uOW37g7G1a8dDzEKcDAq8fA+mPs3TIg1say4MvcQowQHs5IIb/CGf2FCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEeXMigVIC6YklqdmpqQWpRTBZJg5OqQZG7cCYxCSzaZOkAi8cUy2rn+vT/+Cu UJ+NU9S5KD+OJt/Jk7LXOjLV1ux/qPlHIaNj97d5Mda/T/mx+IWEebydU5MlKSVy9CFj0UWm 1q/JueHnLHe3mKmJT4gWnFL84OlxngA796ilIptrF71WNBaXaO3xrihYy/9q7tVNW0tPv/4Q OVP4hrMSS3FGoqEWc1FxIgB+ZVUcuAIAAA== Archived-At: Cc: Peter Thatcher , Peter Saint-Andre , Christer Holmberg Subject: [Ice] Removing ICE frozen algorithm X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 18:26:29 -0000 QWxsLA0KDQpXaGF0IGRvIHlvdSB0aGluayBhYm91dCByZW1vdmluZyByZXF1aXJlbWVudCBmb3Ig aW1wbGVtZW50aW5nIGZyb3plbiBhbGdvcml0aG0gYWx0b2dldGhlciBmcm9tIElDRS1iaXM/DQoN ClRoaXMgd291bGQgb2J2aW91c2x5IGJlIGEgYmlnZ2VyIGNoYW5nZSB0aGFuIHdoYXQgd2Ugb3Jp Z2luYWxseSBwbGFubmVkIGZvciBJQ0UtYmlzIHdvcmssIGJ1dCBiYXNlZCBvbiB0aGUgZGlzY3Vz c2lvbiBzbyBmYXIgdGhlcmUgY291bGQgYmUgbWVyaXQgdG8gaXQuDQoNCkZyb3plbiBhbGdvcml0 aG0gaXMgZXNzZW50aWFsbHkgYW4gb3B0aW1pc2F0aW9uIHRoYXQgYWxsb3dzIG9uZSB0byBub3Qg Y2hlY2sgaGlnaC1wcmlvcml0eSBjYW5kaWRhdGUgcGFpcnMgdGhhdCBhcmUgbGlrZWx5IG5vdCB0 byB3b3JrIChlLmcuLCBob3N0LWhvc3QgY2FuZGlkYXRlIGZvciBtb3JlIHRoYW4gb25lIHN0cmVh bS9jb21wb25lbnQpLiBJZiBhZ2VudCBoYXMgb25seSBvbmUgb25lIHN0cmVhbSBhbmQgY29tcG9u ZW50LCBvciB1c2VzIFJUQ1AtbXV4IGFuZCBCdW5kbGVzIGFsbCBzdHJlYW1zLCBmcm96ZW4gYWxn b3JpdGhtIGlzIG5vdCBldmVuIHVzZWQgdG9kYXkuIEFuZCBjdXJyZW50IGRyYWZ0IHNheXMgeW91 IGRvbid0IGhhdmUgdG8gaW1wbGVtZW50IGl0IGZvciB1c2FnZXMgd2l0aCBvbmx5IG9uZSBzdHJl YW0gYW5kIGNvbXBvbmVudC4gSG93ZXZlciwgd2l0aCBtdWx0aXBsZSBzdHJlYW1zIGFuZC9vciBj b21wb25lbnRzLCBpdCBtYWtlcyBhIGRpZmZlcmVuY2UuDQoNCkFwcGFyZW50bHkgZXZlbiBpZiBv bmUgZW5kcG9pbnQgZG9lcyBub3QgaW1wbGVtZW50IHRoZSBmcm96ZW4gYWxnb3JpdGhtLCBpdCB3 b3VsZCBzdGlsbCBpbnRlcm9wZXJhdGUgd2l0aCBvbmUgdGhhdCBkb2VzLiBUaGUgY2hlY2tzIHdv dWxkIGJlIHNsaWdodGx5IG91dCBvZiBzeW5jIChvbmUgZW5kcG9pbnQgaXMgZG9pbmcgY2hlY2tz IGZvciB0aGUgY2FuZGlkYXRlIHBhaXJzIHRoYXQgYXJlIGZyb3plbiBvbiB0aGUgb3RoZXIpLCBi dXQgaWYgd2UgcmVkdWNlIHRoZSBTVFVOIHBhY2luZyB2YWx1ZSwgdGhpcyB3aWxsIGJlIGxlc3Mg b2YgYSBwcm9ibGVtIHNpbmNlIHRoZSBOQVQgYmluZGluZ3Mgc2hvdWxkIGJlIGFsaXZlIGFuZCB0 aGUgd2hvbGUgcHJvY2VzcyBpcyBsaWtlbHkgdG8gZW5kIGluIHJlYXNvbmFibGUgdGltZS4gQW5k IGlmIG9uZSBjYXJlcyBhYm91dCBtaW5pbWlzaW5nIGFtb3VudCBvZiBzZW50IGNoZWNrcywgb25l IGNvdWxkIHN0aWxsIGltcGxlbWVudCB0aGUgYWxnb3JpdGhtLg0KDQpXaGF0IGlzIHlvdXIgb3Bp bmlvbj8gU2hvdWxkIHdlIGtlZXAgb3IgcmVtb3ZlIHRoZSBmcm96ZW4gYWxnb3JpdGhtIHJlcXVp cmVtZW50IGZyb20gSUNFIGJpcz8NCg0KDQpDaGVlcnMsDQpBcmkNCg0KPiBPbiAxNyBNYXIgMjAx NiwgYXQgMTY6MzIsIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT4gd3JvdGU6 DQo+IA0KPiANCj4gDQo+IE9uIFRodSwgTWFyIDE3LCAyMDE2IGF0IDEyOjIyIFBNLCBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gSGks DQo+IA0KPiA+PiBJIHdhcyB0aGlua2luZyB0aGF0IHdlIHdvdWxkbid0IGNhcmUgaWYgY2FuZGlk YXRlcyBzaGFyZSB0aGUgc2FtZSBmb3VuZGF0aW9uIG9yIG5vdCAtIHdlIGRlYWwgd2l0aCBhbGwg Y2FuZGlkYXRlcyBpbiB0aGUgc2FtZSB3YXkuDQo+ID4NCj4gPiBGb3IgdHJpY2tsZSBJQ0Ugc3Bl Y2lmaWNhbGx5IG9yIGZvciA1MjQ1YmlzPyAg4oCLDQo+ID4NCj4gPiBJJ20gYWxsIGZvciBzaW1w bGlmaWNhdGlvbiBhbmQgcmVtb3ZpbmcgdGhpbmdzIHdlIGRvbid0IG5lZWQuICBJIGp1c3Qgd2Fu dCB0byB1bmRlcnN0YW5kIHRoZSBzY29wZSBvZiB3aGljaCB5b3UgYXJlIHByb3Bvc2luZyB3ZSBk byBzby4NCj4gDQo+IEkgd2FzIHRoaW5raW5nIDUyNDViaXM6IHJlbW92ZSBldmVyeXRoaW5nIHRo YXQgdGFsa3MgYWJvdXQgZnJvemVuIGNhbmRpZGF0ZXMuDQo+IA0KPiANCj4gU291bmRzIGdvb2Qg dG8gbWUsIGlmIHdlIGZlZWwgbGlrZSB0aGUgZG93bnNpZGVzIG9mIG5vdCBoYXZpbmcgZnJlZXpp bmcgYXJlIHN1Y2ggdGhhdCB3ZSBjYW4gc2ltcGx5IHNheSAiaWYgeW91IGNhcmUgYWJvdXQgdGhl c2UgZG93bnNpZGVzLCB1c2UgcnRjcC1tdXgiLiAgSSdkIGxpa2UgdG8gaGVhciBmcm9tIGV2ZXJ5 b25lIGVsc2UgaWYgZmVlbHMgdGhlIHNhbWUu4oCL4oCLDQo+IA0KPiAgDQoNCg== From nobody Fri Apr 1 11:52:37 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668712D0DC for ; Fri, 1 Apr 2016 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LuJKfMoJKx8b for ; Fri, 1 Apr 2016 11:52:34 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A35C12D0A9 for ; Fri, 1 Apr 2016 11:52:34 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e128so75741867pfe.3 for ; Fri, 01 Apr 2016 11:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1gru4UbnV1a47xkgLKd2ibAUe/X+CVQiESgngLW1iM=; b=NzN3lnVFDkLU6vgMXBVBf69wHpG3yXd1uqDFR8VaQ39sdoZupBxL2Wsrl9TvG7UJLS SqmGHleXEOAwfiwQd/JPsNbv03Tsqhw96/u6Jr+BFyJKeSFeyeUUS4rwzUZQ/RnhwgOX fcwPVpYxzVqFkU8F98vptwpHJffNAz6XpOK5eQ6bgo1188wrh824btoR8hWd6wGwDrA2 g8P9b6bVByDyiP2P5ziXvk29kXIDPplcMU/YrXc1TuxPZtC7x2OLvneJ9MNwI3kWOYWl 357wZg/2DzNQjidmaRnetjS/C6QbsKN+RgYMLdQt3llj182iwrMocuVW2rvo12BU7yfe yIwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1gru4UbnV1a47xkgLKd2ibAUe/X+CVQiESgngLW1iM=; b=Vqr4/neV+qpCp1TdHKjmmF8Gviqpbyq4G9jKtzMEWwzy1vyabMJoGoo3tgrgb9BzPY FwM8bV+6nd3anJmsOns7fSjdMjbaq85byRNKH7aBdJTJz77mvM51BPs5uycMO89mxr1o 9g5u5Q07wJelO81EObeAzft2x0coqAM0EGvSHa6WZt6yl9/IxCrz9FVrpV4LTbjrG+nP i/rtAfw+xSxp2iojpGtkiVXHJfQUS127wIA0++W1sDr6jmn+JfiaOS9a5shGA1rdE5hV 0gN3Lsac3ahma+B96XkSS8OjnR+zDVHSTudRIZgv3FEzhb7fNPPGUV8HhB7ClZYG+CcR pEsg== X-Gm-Message-State: AD7BkJI7GpXCjZPlAwJJRpz0PvZqPiWgZ/SCTPFDHmH1LoYBId4eFnHKEYxQh6dT5/2rvQ== X-Received: by 10.98.11.205 with SMTP id 74mr735638pfl.98.1459536753689; Fri, 01 Apr 2016 11:52:33 -0700 (PDT) Received: from [10.104.96.18] ([167.220.62.199]) by smtp.gmail.com with ESMTPSA id i9sm21596962pfi.95.2016.04.01.11.52.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2016 11:52:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E234) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> Date: Fri, 1 Apr 2016 11:52:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> To: Christer Holmberg Archived-At: Cc: Peter Thatcher , Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 18:52:35 -0000 On Mar 17, 2016, at 12:22 PM, Christer Holmberg wrote: >=20 > I was thinking 5245bis: remove everything that talks about frozen candidat= es. [BA] 5245bis applies to legacy applications, not just WebRTC. This includes i= mplementations that do not multiplex RTP and RTCP or use BUNDLE. So removing= the discussion of freezing would be unwise.= From nobody Tue Apr 5 13:31:48 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4407912D14E for ; Tue, 5 Apr 2016 13:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zcSKlFtA1Hir for ; Tue, 5 Apr 2016 13:31:45 -0700 (PDT) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74E912D184 for ; Tue, 5 Apr 2016 13:31:45 -0700 (PDT) Received: by mail-vk0-f42.google.com with SMTP id k1so32888212vkb.0 for ; Tue, 05 Apr 2016 13:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=sUxDmBx0Ubnz7HW0fYk4pACwSvy+MwVg92lvG4ncOr8=; b=hHVzqLtQznoh067rmse6c2juD+IlHFKBqCH0RVAe6pWUaohLosnk6UJnFGYZAp3esk 5VH2Z9NFZVdFdOgMfoV/iD+Z+JhtEboGDvS7YxUfZOHN+JxFwPKHnu+EibxGI7EbIkuZ ECThDui1nE7dCUifH5rCYpBdxF58XGz5oq2Y4yPMoXeck69vruDiVPfuwB7D2ldxd//0 Bvj7yPpW5aYhsNKKtOqlRqOdFmEtyOs76ASwypC81BMZGz2XkuJTeEfYJedpBaEY9dZ/ ia590OYXpnElwhcLDmgdtjFwdBDQW+TSaoM0+FEgOjYxVFfR38AUNSlWl4j4R4Ctfqnd cRnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sUxDmBx0Ubnz7HW0fYk4pACwSvy+MwVg92lvG4ncOr8=; b=b1lh8f2aojP0HW/TJqeaWwDqrdSu0n0l/UkAVut1FiF/UlCSAdEeN5UhYH8gWRJYrD 3PEx4JlseWd0yHq8hZvjwpaKXvHZ0tKdqRWelUdlAmWpf94Nm0Xhegz2DJQ6ZeuhVxTq 07nhRtaeTtlKacXzDQ46BbFzwnP2AbcXDb7ysmh6bbklBGqhW1LFd16VKrRv8PmNrLfP ZJaZK26ll5f0vycIvy/b13oCT4kMK7Mi0zKiouVFG/hmuI8nprLtPl1fXdfxkC6dIxwe NVYrbke7c4KqDfo4p2dE3LVJGgEkfUBRhOZ5ms/enSlYMrdJnKC5BbIAnoQNRQoskaJ1 vcYg== X-Gm-Message-State: AD7BkJJFK+pcxqo9KiESeXLGT8we3JZlEW92Yn9qUqft5mRiX1mjOWDQkcWjMD6Af/GFoAGNzcrzO5MHRK1yWi3D X-Received: by 10.31.58.193 with SMTP id h184mr11188849vka.111.1459888004364; Tue, 05 Apr 2016 13:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Tue, 5 Apr 2016 13:26:04 -0700 (PDT) From: Peter Thatcher Date: Tue, 5 Apr 2016 13:26:04 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a1143ff70e9c2bd052fc2a959 Archived-At: Subject: [Ice] One more idea for how to resolve trickle ICE freezing behavior X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:31:47 -0000 --001a1143ff70e9c2bd052fc2a959 Content-Type: text/plain; charset=UTF-8 (With chair hat off) We still haven't figured out how to handle the freezing algorithm for trickle ICE. I'd be happy with saying "freezing is an optimization left to the implementation" and leave it out of the spec, which avoids the issue altogether. But if that doesn't work, here's another idea: Change the rule from "attempts to unfreeze all candidates belonging to the first component on the first media stream" to "attempts to unfreeze all candidates belonging to the first component on the first media stream *of the candidates received so far*" This means that if you receive a trickled candidate out of order according to the "stream/component order", then its unfrozen. When you receive a trickled candidate later that is earlier in that order, then its unfrozen also. This avoids candidates being frozen indefinitely and at worse leads to some candidates being unfrozen prematurely. This has solves our problem with little downside. I propose we use it and remove the requirement that candidates be signaled in "media/component order". --001a1143ff70e9c2bd052fc2a959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(With chair hat off)

We still have= n't figured out how to handle the freezing algorithm for trickle ICE.= =C2=A0 I'd be happy with saying "freezing is an optimization left = to the implementation" and leave it out of the spec, which avoids the = issue altogether.=C2=A0 But if that doesn't work, here's another id= ea:

Change the rule from=C2=A0

&q= uot;attempts to unfreeze all candidates belonging to the first=C2=A0compone= nt on the first media stream"

to=C2=A0
<= br>
"attempts to unfreeze all candidates belonging to the firs= t=C2=A0component on the first media stream=C2=A0of the candidates receiv= ed=C2=A0so far"


This means t= hat if you receive a trickled candidate out of order according to the "= ;stream/component order", then its unfrozen.=C2=A0 When you receive a = trickled candidate later that is earlier in that order, then its unfrozen a= lso. =C2=A0 This avoids candidates being frozen indefinitely and at worse l= eads to some candidates being unfrozen prematurely. =C2=A0=C2=A0
This has solves our problem with little downside.=C2=A0 I propos= e we use it and remove the requirement that candidates be signaled in "= ;media/component order".
--001a1143ff70e9c2bd052fc2a959-- From nobody Thu Apr 7 08:05:34 2016 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6412D103; Thu, 7 Apr 2016 08:05:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407150532.19772.13591.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 08:05:32 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-01.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:05:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : ICE Multihomed and IPv4/IPv6 Dual Stack Fairness Authors : Paal-Erik Martinsen Tirumaleswar Reddy Prashanth Patil Filename : draft-ietf-ice-dualstack-fairness-01.txt Pages : 10 Date : 2016-04-07 Abstract: This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-dualstack-fairness-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-dualstack-fairness-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 7 10:12:26 2016 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126A12D10D; Thu, 7 Apr 2016 10:12:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407171222.19780.38732.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 10:12:22 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-02.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:12:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : ICE Multihomed and IPv4/IPv6 Dual Stack Fairness Authors : Paal-Erik Martinsen Tirumaleswar Reddy Prashanth Patil Filename : draft-ietf-ice-dualstack-fairness-02.txt Pages : 10 Date : 2016-04-07 Abstract: This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-dualstack-fairness-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-dualstack-fairness-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 7 10:21:12 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1512D188 for ; Thu, 7 Apr 2016 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 Cusx9Rsn2SY8 for ; Thu, 7 Apr 2016 10:21:09 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010CB12D0BD for ; Thu, 7 Apr 2016 10:21:09 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q128so101967742iof.3 for ; Thu, 07 Apr 2016 10:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=yP+U7t6wx1WKTLI97PWzdl8qSg+xJ/yLxoRaXmhsTF8=; b=16byam4gipA5L7RM2Z88bqrpHudjSMzcFc3b4jABSxkSA02YHfs2y3BA1omEEsOhlZ kmhXd1cSImtSQVbo0FTnY0iDgKZo4VeUH/hP1hBLSgGyjJm956qtzg2cyqXzHnTdi4DX gmiTv4BoGUOcDC9I2HUNigyg5x0/Plrs32edWCS9S6PU2OuA3bA8ikAh2luUnOPYQWk4 gR727ZhZBrrQxe1N072vTo0fUdZ1/9l5oqFOAUMQUk1h2TJlL8nq/yWJEsVbXbaaq4ke 5EidZ9DdOtGVSDe944gxrs+cAOQ7Ik+sAAzQh8tJi3y+d4C7BZqmPlF1V0r/AQTxJbDd UbHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yP+U7t6wx1WKTLI97PWzdl8qSg+xJ/yLxoRaXmhsTF8=; b=mNhPubZSzRDut89cE3hk1aHBZQb4OijrZCG3RffyiGkT3bSDMkTZ8v3teNisVUy38R 3wyMTczr3FawHVSGPtjjeGee5xhCiLHAtKDan2JiMy/7ZQ+vs75LU33Ij73DNpKenNf7 gKbHMorYajcW+IVLJQCzIqfC+w4yJ3MLqs1OdWXHh4RHIWJJatXsK38gYvKJO5JaBnQf 2K/IZ0PtedpDqZuZi9/9CnLyLhThULCwNHYscrO6L4qV2IIlGTCnXH86i/2gphYEIoII DzH9M4tC384fX2jMxSBoUv99516Nj8qiko22/H590rfxEHJbkL7b3FPOYOV6skwVHO4o c2Ew== X-Gm-Message-State: AD7BkJLnU1ICFietvvpp+kr9DIwyLditzkj3tvJPyzcPNwCRcc5y+HJ5to0qmLJzjYfjYg== X-Received: by 10.107.26.203 with SMTP id a194mr5386109ioa.115.1460049668174; Thu, 07 Apr 2016 10:21:08 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id au6sm201107igc.0.2016.04.07.10.21.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 10:21:07 -0700 (PDT) To: Peter Thatcher , ice@ietf.org References: From: Emil Ivov Message-ID: <57069702.9030106@jitsi.org> Date: Thu, 7 Apr 2016 12:21:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] One more idea for how to resolve trickle ICE freezing behavior X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:21:11 -0000 On 5.04.16 г. 15:26, Peter Thatcher wrote: > (With chair hat off) > > We still haven't figured out how to handle the freezing algorithm for > trickle ICE. I'd be happy with saying "freezing is an optimization left > to the implementation" and leave it out of the spec, which avoids the > issue altogether. But if that doesn't work, here's another idea: > > Change the rule from > > "attempts to unfreeze all candidates belonging to the first component on > the first media stream" > > to > > "attempts to unfreeze all candidates belonging to the first component on > the first media stream /of the candidates received so far/" > > > This means that if you receive a trickled candidate out of order > according to the "stream/component order", then its unfrozen. When you > receive a trickled candidate later that is earlier in that order, then > its unfrozen also. This avoids candidates being frozen indefinitely > and at worse leads to some candidates being unfrozen prematurely. > > This has solves our problem with little downside. I propose we use it > and remove the requirement that candidates be signaled in > "media/component order". An important aspect of ICE is the ability to do checks simultaneously which is necessary for things behind NATs to talk to each other. Here's what trickle ICE says about this: Respecting the order in which lists have been reported to an ICE implementation, or in other words, the order in which they appear in SDP, is crucial to the frozen candidates algorithm and important when making sure that connectivity checks are performed simultaneously by both agents. Following your suggestion and removing the above text would allow for a race condition where both sides are waiting for checks on different components/streams (i.e. ports) to succeed ... or essentially a deadlock. Emil -- https://jitsi.org From nobody Thu Apr 7 10:50:51 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E012D62F for ; Thu, 7 Apr 2016 10:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 xdYdZrc9J6_C for ; Thu, 7 Apr 2016 10:50:48 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515BD12D5F4 for ; Thu, 7 Apr 2016 10:50:31 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id s79so108359860oie.1 for ; Thu, 07 Apr 2016 10:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=96mm2Om5yE8s/sPL8czxz05PwayMp42Xtv7spLTuA8A=; b=Yqw7TgF3zTOpdeMIldVwfGK51N4ApDnmhIgLTp51yau6JLZ4V0NjhqWasN1ZE0IDSF K/zkF1Hwj6e4/4SQmB6RYq/BRidmBzs7if31pglUJbl3FSoBUfr4Nwvhd+k/Tn3pLExM LO7sH8oIlG271r9vMFl46IpifmysyZQ3EDNFf9oSu2hTL6RyNG+fFP7zL/gZ+va2isgU I3XXZR1HtPcSn0LAYf+aowBeLb8znmPY6/52axn061Zsb4DGrqa24UVb/cVQnRhe5wRh 5R4L2YZNFUaCBmGhZ66AItmKQCncxI0aUZyzoygCk+J6MWeZ2dOAf2X1u4VkOCWaiNO4 xeVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=96mm2Om5yE8s/sPL8czxz05PwayMp42Xtv7spLTuA8A=; b=dOfg6GVMCGqPlZnrNQoWaBWlp3RJDIYTN1tj+vvNoHKB2Tv4bamUr1wMRjk1ko3DYO n/fNZOT/H7psxH2EwlTuGL/8NazcNDwGONIFq9gOjAioVBGngOPmQaSUtj3U/OO3v903 TLgAWwYq61mgBZeYjhL9vpK3DN/NvYQE8E2RxEtsTHUQ4TD9OuzB9jiSQ1zLURSdTF+K Ujas/IVrmeUokd2bXypSoNwuXjFCzO5h8KMUDFXBUJrP83FeY6sojeA+V7EVetSzjSwo fg1r6I3NVVFkw+Fpg3/hBQzhdx++O8v8itE6X2gP4i/nfAYfMJLBrRh6z4/ZFw2x+YP0 7bRg== X-Gm-Message-State: AD7BkJI042EiR7/2yA/OreMeUsysmat3UX3++8Bil8YWVRXQRmYZyl8zrfLXw/3AkiF7wQ== X-Received: by 10.157.63.116 with SMTP id m107mr2080869otc.115.1460051430260; Thu, 07 Apr 2016 10:50:30 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id ek7sm2727990obb.15.2016.04.07.10.50.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 10:50:29 -0700 (PDT) To: Peter Thatcher , ice@ietf.org References: From: Emil Ivov Message-ID: <57069DE4.1070805@jitsi.org> Date: Thu, 7 Apr 2016 12:50:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:50:50 -0000 On 21.03.16 г. 19:07, Peter Thatcher wrote: > As an author (not a chair), I just submitted a draft for an idea I'd > like to propose for ICE: network cost. > > Here's the draft: > > https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/ > > > The idea is basically to allow the controlled side to tell the > controlling side which candidates "cost" more than others (such as > cellular costing more than Wi-Fi). This is different than candidate > priority for reasons explained in the draft. I see the value here but I have a few problems with the current state. To begin with, I find the "cost" name overly confusing. I realize the draft already says this is not necessarily real cost but it still leaves people with the wrong impression (and I've confirmed this in conversations these days). So let's just go for bias or something (I also like fondness). The draft is not currently very explicit about exactly how this works in the selection of candidates but I assume it basically means: "if it's all the same to you, I'd much rather you get in touch with me here than there." The trickiest part here is how to assign importance to this new bias as opposed to existing metrics such as RTT for example. We could say it's up to implementations or try to come up with some recommendation for a formula. The other thing is that I cannot at all see the value of the network ID. Why is this necessary? Emil -- https://jitsi.org From nobody Thu Apr 7 11:41:06 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56412D195 for ; Thu, 7 Apr 2016 11:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 h2Sy5I4V0OGQ for ; Thu, 7 Apr 2016 11:41:03 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497E112D0A0 for ; Thu, 7 Apr 2016 11:41:03 -0700 (PDT) Received: by mail-ob0-x229.google.com with SMTP id bg3so58586561obb.1 for ; Thu, 07 Apr 2016 11:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DXlztYiLYyXtMmCl+eF0INGmP3rOLClgrFVrWW3BGvo=; b=kKYBltGkAhXSmbZQ31IuK07e2RGKP6AEqxZlKfRUbMSApz5uJYCCkPfqFh5JoHSRBh S9nvz0sY6NVcaf3LTNjgfBEf/O3NQFzEogBK69mQY+qls4DX/uTv2Zq7nhGMPDUJ2+QR UVRkIdtSo4aULIWvFZgFiXD37fK4dNrds+BHm72NRoqHRCzjWNBz8vQ6jOCxHoq9IM+a ZiIm+p0q122yOjoyBWPLA+BiG3AQg+LXujSicFXF6ZWyXIqysi45hGhWXxm3mvZx7+V0 qhDicmppJVFVRjt65I58WLJazNK3PU0Cf9+eTPu9DlXFEG6WVuMjCCK3nsXfrFqmJgGZ epcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DXlztYiLYyXtMmCl+eF0INGmP3rOLClgrFVrWW3BGvo=; b=C6Rv4D3oe9/sGEmtW6hwpUiLgrBjjQ3Mp5v/Lb6psFlRfngF2WKuwRanj5PvT1atRA TQIw8kPM5OOqG5Lqn8xTOu0dhju65el2qdEy+kqdXtJJXVoWWB0Vf2nFdDVmwJK2p9aP Brsrt0bSHxwcKQLF53ytJpRUOH1odbIbnFmYBrus1km4H9+gtxZZonLQWQARuRosz9TV EIkVGRR7BtD03iUijD6zBZhSIY6XDZ88WKo4cqkgFX6/uvRPH/rxfHSFz+X1ysygX94w apG+gCq/pZr+mHNongvaXt0tmMNbda1954047tpOEtI+ZvJNV+I+naEo9+HYOqbjXalx +5fQ== X-Gm-Message-State: AD7BkJKsLkju1ZxsFlPn8wS2WosHeutd/+8jvyKJuGl2nBv84YA2SMlW7vJ9x6TQgaJLPA== X-Received: by 10.182.109.233 with SMTP id hv9mr2266985obb.21.1460054462655; Thu, 07 Apr 2016 11:41:02 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id fg8sm2816329oeb.16.2016.04.07.11.41.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 11:41:01 -0700 (PDT) To: Peter Thatcher , ice@ietf.org References: <57069702.9030106@jitsi.org> From: Emil Ivov Message-ID: <5706A9BD.7020701@jitsi.org> Date: Thu, 7 Apr 2016 13:41:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57069702.9030106@jitsi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] One more idea for how to resolve trickle ICE freezing behavior X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:41:05 -0000 CORRECTION below! On 7.04.16 г. 12:21, Emil Ivov wrote: > > > On 5.04.16 г. 15:26, Peter Thatcher wrote: >> (With chair hat off) >> >> We still haven't figured out how to handle the freezing algorithm for >> trickle ICE. I'd be happy with saying "freezing is an optimization left >> to the implementation" and leave it out of the spec, which avoids the >> issue altogether. But if that doesn't work, here's another idea: >> >> Change the rule from >> >> "attempts to unfreeze all candidates belonging to the first component on >> the first media stream" >> >> to >> >> "attempts to unfreeze all candidates belonging to the first component on >> the first media stream /of the candidates received so far/" >> >> >> This means that if you receive a trickled candidate out of order >> according to the "stream/component order", then its unfrozen. When you >> receive a trickled candidate later that is earlier in that order, then >> its unfrozen also. This avoids candidates being frozen indefinitely >> and at worse leads to some candidates being unfrozen prematurely. >> >> This has solves our problem with little downside. I propose we use it >> and remove the requirement that candidates be signaled in >> "media/component order". > > An important aspect of ICE is the ability to do checks simultaneously > which is necessary for things behind NATs to talk to each other. > > Here's what trickle ICE says about this: > > Respecting the order in which lists have been reported to an ICE > implementation, or in other words, the order in which they appear in > SDP, is crucial to the frozen candidates algorithm and important when > making sure that connectivity checks are performed simultaneously by > both agents. > > Following your suggestion and removing the above text would allow for a > race condition where both sides are waiting for checks on different > components/streams (i.e. ports) to succeed ... or essentially a deadlock. I had misread the above and missed the second sentence which effectively removes the deadlock I mention. I also like this. From nobody Thu Apr 7 14:15:25 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5F712D6FB for ; Thu, 7 Apr 2016 14:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jDXNX7D_cVlh for ; Thu, 7 Apr 2016 14:15:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858E712D622 for ; Thu, 7 Apr 2016 14:15:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-de-5706cde2a0e6 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1E.80.22880.2EDC6075; Thu, 7 Apr 2016 23:15:14 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 23:15:14 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: ICE WG Thread-Topic: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-02.txt Thread-Index: AQHRkPC1whJcBQYPFEyDEV9dy5qWwJ9+4bwA Date: Thu, 7 Apr 2016 21:15:13 +0000 Message-ID: References: <20160407171222.19780.38732.idtracker@ietfa.amsl.com> In-Reply-To: <20160407171222.19780.38732.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbE9XPfRWbZwgz8rrSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG8ZOrmAv28lXMP7yDrYFxPncXIyeHhICJxK7db1khbDGJC/fW s3UxcnEICRxhlFjS8YwZwlnMKLF/9jJmkCo2AXuJyWs+MoLYIgKSEi1/NoJ1Cwu4Szy73sgE EfeQuPx/NTuEbSTx5eFXsDiLgIrEr9tr2UBsXqA5y1tOsoDYQgKOEvfmtYDN5xRwkpgzeTFY PSPQRd9PrQGzmQXEJW49mc8EcamAxJI955khbFGJl4//QX2gKHF1+nKoej2JG1OnsEHY1hKr HrxngbC1JZYtfM0McYOgxMmZT1gmMIrNQrJiFpL2WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCNj vdSizOTi4vw8vbzUkk2MwBg6uOW37g7G1a8dDzEKcDAq8fAq7GcNF2JNLCuuzD3EKMHBrCTC G3CGLVyINyWxsiq1KD++qDQntfgQozQHi5I4b07kvzAhgfTEktTs1NSC1CKYLBMHp1QDYzPr RR0ThuMxIeY8/sb+aW2Fta8F7+fI39LiVNyRZJ100vHFg7T8zwXOP630PdWYpESyttvyLm3Z uy9cPndOqNtRUc9t+Rc8d4XYpf9qZFzo6lCjOsH0YU7ljZV6c96w5OxXbb+wZfZTxrh3p3+x xMR2MaosVVTWXXsrfbepzatey3nHVzkosRRnJBpqMRcVJwIA8T9ZMZ0CAAA= Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-02.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:15:25 -0000 WG, As discussed at the ICE WG session today, we have now requested publication= of this version of the draft. Cheers, Ari > On 07 Apr 2016, at 14:12, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Interactive Connectivity Establishment o= f the IETF. >=20 > Title : ICE Multihomed and IPv4/IPv6 Dual Stack Fairness > Authors : Paal-Erik Martinsen > Tirumaleswar Reddy > Prashanth Patil > Filename : draft-ietf-ice-dualstack-fairness-02.txt > Pages : 10 > Date : 2016-04-07 >=20 > Abstract: > This document provides guidelines on how to make Interactive > Connectivity Establishment (ICE) conclude faster in multihomed and > IPv4/IPv6 dual-stack scenarios where broken paths exist. The > provided guidelines are backwards compatible with the original ICE > specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ice-dualstack-fairness-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ice-dualstack-fairness-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Thu Apr 7 14:28:06 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E600612D736 for ; Thu, 7 Apr 2016 14:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cUGzNw5_cvq8 for ; Thu, 7 Apr 2016 14:28:02 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A518B12D6FB for ; Thu, 7 Apr 2016 14:28:00 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id k1so116139977vkb.0 for ; Thu, 07 Apr 2016 14:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PosWOuuLlkJ8qOnG9ZlH5EaPSaffg0nGoWv9xTPwd1Q=; b=KbTCbeiwaicAYy0UXZijHm6u7icZJOSpAEqyyzqbN73d2lhn3Urz1Z6EgXnyA8EfFV op9uyfiwV/te4665UBePKo3XgoLr6NpklRO7k0duEGBJpk/jn79uQkosMzWe3xNuFY+I 20q9EOrJxw5tnSCHXFViq8eaSLHdIbx75KIG3UbOn3QSayx9ATWHt/ySafqKkdXMAZb7 XLR5EuVAXmIs3PJ/K3PnThRaONqMPL1TbFA0F2llsViACM9VlU7aMGFyLpIAEBF6Gl0x pd/CzqzbDwYPTqsI1nGIMpyF9gnkiAYjcYr2aOWe5aX19lleT4nawmVkJpLhwg4JEPEX l8xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PosWOuuLlkJ8qOnG9ZlH5EaPSaffg0nGoWv9xTPwd1Q=; b=VkjNRGVr/+E+aRq6l1vPbdVQSR1Oy0pd0wfjQAXBo76/13zIC8ZukwaSlGLiOusoSG 0A1npWrBlBeHDJHPFCDLB4vROEjPAph25Or82t0oczVvQuGQqnt11W/MtbDxfyQywHBR UTIgC/vstNRItLw8hzCSZtBs+DnCYaQ0cljE5DPP/EP0J1xhT5R7yMkZOKc4sRz8pHVP 0p/ytNtvLDnZzd09btU6PmQ+a5qSIlEY5ukwGnJGiRqmIED518MWD3k62+iHxYJWfMDG gtgjH1y53MLUBg/zZHda+oxXj2ZDicrQ4DMOUQdJBanX13KVLh30MvUM3lW4dUBL2FBm J6Gg== X-Gm-Message-State: AD7BkJLYtpjRi94y38VEUDPQ8GJmk0nIMpa8BCQFydlWjsmz7UjSoAcZ+FLnAKrLryxTl389E0orIF2Xx4td6tV/ X-Received: by 10.31.137.17 with SMTP id l17mr2113191vkd.98.1460064479681; Thu, 07 Apr 2016 14:27:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.164 with HTTP; Thu, 7 Apr 2016 14:27:20 -0700 (PDT) In-Reply-To: <57069DE4.1070805@jitsi.org> References: <57069DE4.1070805@jitsi.org> From: Peter Thatcher Date: Thu, 7 Apr 2016 14:27:20 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a114510fea965c2052febc0c6 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:28:05 -0000 --001a114510fea965c2052febc0c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov wrote: > On 21.03.16 =D0=B3. 19:07, Peter Thatcher wrote: > >> As an author (not a chair), I just submitted a draft for an idea I'd >> like to propose for ICE: network cost. >> >> Here's the draft: >> >> https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/ >> >> >> The idea is basically to allow the controlled side to tell the >> controlling side which candidates "cost" more than others (such as >> cellular costing more than Wi-Fi). This is different than candidate >> priority for reasons explained in the draft. >> > > I see the value here but I have a few problems with the current state. > > To begin with, I find the "cost" name overly confusing. I realize the > draft already says this is not necessarily real cost but it still leaves > people with the wrong impression (and I've confirmed this in conversation= s > these days). So let's just go for bias or something (I also like fondness= ). > =E2=80=8BThere are two question here: the name and the direction. The cho= ice of direction is more important than the name. I prefer the direction where 0 means "free/use-freely" and a big number means "expensive/restrained/last-resort". This is because if we ever expand the range, I think it would be better in the direction of "I really don't want to use this" rather than "this is even more free to use". You'll note that this direction is the opposite of fondness/preference/priority. In other words, I think modeling this as "badness' is better than as "goodness". So if we're going to debate names, let's debate synonyms of "badness". The best I could come up with is cost. But I'd love to hear good synonyms.=E2= =80=8B =E2=80=8B > > The draft is not currently very explicit about exactly how this works in > the selection of candidates but I assume it basically means: "if it's all > the same to you, I'd much rather you get in touch with me here than there= ." > > Close. 0 means "use this freely". A small number means "I'd rather not use this". A large number means "Only use this if nothing else works".=E2= =80=8B =E2=80=8B > The trickiest part here is how to assign importance to this new bias as > opposed to existing metrics such as RTT for example. We could say it's up > to implementations or try to come up with some recommendation for a formu= la. > =E2=80=8BThat's exactly what I think we should do: standardized how informa= tion is conveyed from controlled to controlling, but then let the controlling side decided how to select and nominate.=E2=80=8B =E2=80=8B > The other thing is that I cannot at all see the value of the network ID. > Why is this necessary? =E2=80=8BTechnically, I could make it a separate draft, but the kind of go = well together (they both fit in one nice STUN attribute, for example). The value of network ID is the following: if the remote side's network interface changes, it's wise to notify your bandwidth estimator, because the change may have been drastic (wifi to 2g). =E2=80=8B It could change e= ither by TURN mobility, or by continual gathering, or by the use of backup candidate pairs (I realized the last two are not yet standardized). > > > Emil > > -- > https://jitsi.org > --001a114510fea965c2052febc0c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov &= lt;emcho@jitsi.org= > wrote:
On 21= .03.16 =D0=B3. 19:07, Peter Thatcher wrote:
As an author (not a chair), I just submitted a draft for an idea I'd like to propose for ICE: network cost.

Here's the draft:

https://datatracker.ietf.org/doc/dr= aft-thatcher-ice-network-cost/


The idea is basically to allow the controlled side to tell the
controlling side which candidates "cost" more than others (such a= s
cellular costing more than Wi-Fi).=C2=A0 This is different than candidate priority for reasons explained in the draft.

 I see the value here but I have a few problems with the current state.

To begin with, I find the "cost" name overly confusing. I realize= the draft already says this is not necessarily real cost but it still leav= es people with the wrong impression (and I've confirmed this in convers= ations these days). So let's just go for bias or something (I also like= fondness).

=E2=80=8B= There are two question here: =C2=A0the name and the direction.=C2=A0 The ch= oice of direction is more important than the name.=C2=A0 I prefer the direc= tion where 0 means "free/use-freely" and a big number means "= ;expensive/restrained/last-resort".=C2=A0 This is because if we ever e= xpand the range, I think it would be better in the direction of "I rea= lly don't want to use this" rather than "this is even more fr= ee to use".=C2=A0 You'll note that this direction is the opposite = of fondness/preference/priority.

In other words, I think modeling this as &qu= ot;badness' is better than as "goodness".=C2=A0

So if we're= going to debate names, let's debate synonyms of "badness".= =C2=A0 The best I could come up with is cost.=C2=A0 But I'd love to hea= r good synonyms.=E2=80=8B
=E2=80=8B
=C2=A0

The draft is not currently very explicit about exactly how this works in th= e selection of candidates but I assume it basically means: "if it'= s all the same to you, I'd much rather you get in touch with me here th= an there."


Close. =C2=A00 means "use this freely".=C2=A0 A small number = means "I'd rather not use this".=C2=A0 A large number means &= quot;Only use this if nothing else works".=E2=80=8B
=E2=80=8B
=
=C2=A0
The trickiest part here is how to assign importance to this new bias as opp= osed to existing metrics such as RTT for example. We could say it's up = to implementations or try to come up with some recommendation for a formula= .

=E2=80=8BThat's exactly what I think we should d= o: standardized how information is conveyed from controlled to controlling,= but then let the controlling side decided how to select and nominate.=E2= =80=8B
=E2=80=8B

=C2=A0
The other thing is that I cannot at all see the value of the network ID. Wh= y is this necessary?

=E2=80=8BTechnicall= y, I could make it a separate draft, but the kind of go well together (they= both fit in one nice STUN attribute, for example).

Th= e value of network ID is the following: =C2=A0if the remote side's netw= ork interface changes, it's wise to notify your bandwidth estimator, be= cause the change may have been drastic (wifi to 2g). =C2=A0=E2=80=8B It cou= ld change either by TURN mobility, or by continual gathering, or by the use= of backup candidate pairs (I realized the last two are not yet standardize= d).=C2=A0

=C2=A0


Emil

--
https://= jitsi.org

--001a114510fea965c2052febc0c6-- From nobody Thu Apr 7 15:14:09 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4609B12D135 for ; Thu, 7 Apr 2016 15:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 lGOwWHdiaqJc for ; Thu, 7 Apr 2016 15:14:05 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C156D12D0BF for ; Thu, 7 Apr 2016 15:14:05 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q128so110918605iof.3 for ; Thu, 07 Apr 2016 15:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Ry8R8MQ61YyaxUAfRAdvJiZDTKYT4cTLXR/pQsZ92LE=; b=ZTNr+f8ChdymnCyA9aJLlDh/oL59LnioHJhq1w2+UCeOB1WBNq6xK/eI6M8SqYXAOO YSQ7/DgFIjT2ItGDCQg6dM2IyCqmeme/OduEYsRe+cb/m6ewThzOXmbaWyq6h/RRhqHr wP8ABEwCvKk/ZpzWfPcg1IhggL2essC0ORvfH46wzrJEZCdXq+BUFqtsXuczoQ62bR67 v4jXV8/UJoTi3wjA2UtcDHz3WnWDrcNRx5I9EpkITImQUyOn0mStSzryddocwlUgCzzf 13gWynBAAgLeybcEvNpwmK9AEbMsgQQRD0z6sWxmrZWZvqSf9ORxyBycsiarrnnpiB5o jjHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ry8R8MQ61YyaxUAfRAdvJiZDTKYT4cTLXR/pQsZ92LE=; b=NANSkIJ1Fgz7VKz9tIuzYsLpIy3ctbrhyaQ81c83wdTv2SLeuT0CKimQF809FfgoIF FpEPpX0p/JudtIRDbPTOESJbWFZXmltds8rJESHcZYPlhNr3ILNbeQvfqY/P4raIM98g MOkz38St2qVFMIRCytPZC/tCeNeLhZ8C7da70EaV556mhAdZpzjYEsKA0Di+fYJRFCmf AN7Jml2VSHXBgaibaZ2ONz9XlYaCxH5Lgmjzxags8qCEk3v1JXYQlcaNJnbjuNU6JL0S Ml7DK7FNkyY1aPH1BUxKPYR7niTtpT1hkJQV7IwIaJkPWfF4JZ7g4n0DW0MsCY8z+QYe 07Ng== X-Gm-Message-State: AD7BkJKs3QFAMbe3krlFbhKpAE5vlce0uiIGMeAevYnGRcUXPlvPGL8u+R7yRy0wRDnU6g== X-Received: by 10.107.162.7 with SMTP id l7mr6623811ioe.147.1460067244968; Thu, 07 Apr 2016 15:14:04 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id in6sm54219igb.0.2016.04.07.15.14.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 15:14:03 -0700 (PDT) To: Peter Thatcher References: <57069DE4.1070805@jitsi.org> From: Emil Ivov Message-ID: <5706DBAB.7030703@jitsi.org> Date: Thu, 7 Apr 2016 17:14:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:14:08 -0000 On 7.04.16 г. 16:27, Peter Thatcher wrote: > > > On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov > wrote: > > On 21.03.16 г. 19:07, Peter Thatcher wrote: > > As an author (not a chair), I just submitted a draft for an idea I'd > like to propose for ICE: network cost. > > Here's the draft: > > https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/ > > > The idea is basically to allow the controlled side to tell the > controlling side which candidates "cost" more than others (such as > cellular costing more than Wi-Fi). This is different than candidate > priority for reasons explained in the draft. > > > I see the value here but I have a few problems with the current state. > > To begin with, I find the "cost" name overly confusing. I realize > the draft already says this is not necessarily real cost but it > still leaves people with the wrong impression (and I've confirmed > this in conversations these days). So let's just go for bias or > something (I also like fondness). > > > ​There are two question here: the name and the direction. The choice > of direction is more important than the name. I prefer the direction > where 0 means "free/use-freely" and a big number means > "expensive/restrained/last-resort". This is because if we ever expand > the range, I think it would be better in the direction of "I really > don't want to use this" rather than "this is even more free to use". > You'll note that this direction is the opposite of > fondness/preference/priority. > > In other words, I think modeling this as "badness' is better than as > "goodness". OK, this makes sense. > So if we're going to debate names, let's debate synonyms of "badness". > The best I could come up with is cost. But I'd love to hear good synonyms.​ Let's go with "handicap" then? (If not we always have aversion and reluctance). > The draft is not currently very explicit about exactly how this > works in the selection of candidates but I assume it basically > means: "if it's all the same to you, I'd much rather you get in > touch with me here than there." > > > Close. 0 means "use this freely". A small number means "I'd rather not > use this". A large number means "Only use this if nothing else works".​ > ​ > > The trickiest part here is how to assign importance to this new bias > as opposed to existing metrics such as RTT for example. We could say > it's up to implementations or try to come up with some > recommendation for a formula. > > > ​That's exactly what I think we should do: standardized how information > is conveyed from controlled to controlling, but then let the controlling > side decided how to select and nominate.​ The problem here is that unless we give directions about how it should be used in practice, then we greatly limit the usefulness and interoperability. I actually think we can be very helpful without going into the details that much. Like for example: 0: use freely as you say. h>0: you MAY use if no valid pairs exist where the remote candidate has a lower handicap but you SHOULD/MUST switch if such a pair becomes valid. Also, unless your nominated pair has pair.remoteCandidate.handicap==0, then you MUST continue running checks until either you run through all of them or at least one pair with zero handicap becomes valid. When that happens you must switch. Also if your selected pair has a remoteCandidate with non-zero handicap H and another pair becomes valid where the remoteCandidate has a lower handicap h (i.e., h The other thing is that I cannot at all see the value of the network > ID. Why is this necessary? > > > ​Technically, I could make it a separate draft, but the kind of go well > together (they both fit in one nice STUN attribute, for example). > > The value of network ID is the following: if the remote side's network > interface changes, it's wise to notify your bandwidth estimator, because > the change may have been drastic (wifi to 2g). ​ It could change either > by TURN mobility, or by continual gathering, or by the use of backup > candidate pairs (I realized the last two are not yet standardized). I am not a huge fan of this. I think it requires the remote side to know more than it needs to. If you want to reinit your bwe engine then we should have a message that says that (and it should probably be in RTCP). There could be other reasons for this that cannot be directly mapped to changing interfaces. An interface ID mainly bothers me as it delivers more knowledge than one needs for that sort of stuff and it encourages implementers to make assumptions ... and ICE is all about avoiding them. Emil -- https://jitsi.org From nobody Sun Apr 10 17:04:39 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F098112D850 for ; Sun, 10 Apr 2016 17:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 p_Qprkxcv0DE for ; Sun, 10 Apr 2016 17:04:35 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4BD12D844 for ; Sun, 10 Apr 2016 17:04:35 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f198so124795215wme.0 for ; Sun, 10 Apr 2016 17:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=9QLu+mH99j7h2Sxtqxt3S7qmCOJcnugSXHYsECl4E7s=; b=I58WdtF3aanh5VM69dDaHPIB0PnInHP1pk+o/kgypK3eBCsH4U7b5E7ugI9ePqsi+e Mi9pH9qIxqownkZLUMvUISP8VH3DkOx55wWBFGI6faQeZrpreuGr4+fIeuY80q7pQMb9 epXVfDfLRyd1pZGKu2XKegaHHFM7gUe6jQ3xZxUKwSsfIFjD9rFaqyST9IlJA7Ym0lgE jAyE/RO9PpggC9BFSKx45pLNvFXw5mFzeWkQ8Z+w9CQqJSDidOZuzAQwahsrnf18elSi q7Iyj1gl84gjUZ4FnUeyMVqnwABALLNon2HfhoU9IkSSniHkKaeBDAEwmy5oRpqqTqtn Ip+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9QLu+mH99j7h2Sxtqxt3S7qmCOJcnugSXHYsECl4E7s=; b=OzAMUlFUgDH80retfJQ5FTWAxhlypHbyc4dGJlQ6KJOO0CN6pkDNf0JiAdR2trRNON /roo4cyadlL8IFWTbOls3wOQ3gFvb/aSWSffMZFqS1IzxA/gn0I+A70JFfyM576dNOJm b+nDEBgS5unvnxglwGsEZAUinc2sI8NNS/qzQoKatHghYBZsOxDPWgZEZOtoqOB7l+nM F8vbSii4oq5q8ULCwGYrlF14/t7005WJVo4dnYJaL+fEVKP3zfI1Gje7EHTgMZxC8Qe9 xQE2ay5fA2HDstz//iiafmPEtYtviZUuZK5jOjdTrNtvefwXW5WZopulL1v7HrTlX2P2 g9QQ== X-Gm-Message-State: AD7BkJJb3l+meIewF59tHHnHKQXGsXtWwF2/Uwo/uMSje5kGwuKJLotQG5MW5bGz26t9LavQyL+fCOabUl0i1KOZ X-Received: by 10.28.220.67 with SMTP id t64mr14566280wmg.57.1460333073440; Sun, 10 Apr 2016 17:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.152.23 with HTTP; Sun, 10 Apr 2016 17:04:13 -0700 (PDT) From: Justin Uberti Date: Sun, 10 Apr 2016 21:04:13 -0300 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114b2d5a1913ea05302a4a20 Archived-At: Subject: [Ice] Bandwidth needed for various connectivity check rates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 00:04:38 -0000 --001a114b2d5a1913ea05302a4a20 Content-Type: text/plain; charset=UTF-8 Following up on my action item from the meeting regarding bandwidth numbers for ICE checks: I wrote a script to generate some bandwidth numbers. Below are the bandwidths for various scenarios, with ufrags of 4, 8, 12, or 16 bytes. As you can see a 10 ms rate generates ~100 kbps of traffic, not counting responses, and a 5 ms rate generates ~200 kbps. I also included the numbers for my "shaved ice" proposal, which cut the rates by ~half, but may still be excessive at 10 ms. One other exercise that may be useful here is to consider the number of STUN checks needed in typical cases to complete connectivity testing; this will give an idea of how long these bandwidth values need to be sustained. *5245, ipv4 (108 byte base packet size)* | packet len: 108+2 ufrag ms | 4 8 12 16 -----|------------------------ 500 | 1.86k 1.98k 2.11k 2.24k 200 | 4.64k 4.96k 5.28k 5.6k 100 | 9.28k 9.92k 10.6k 11.2k 50 | 18.6k 19.8k 21.1k 22.4k 20 | 46.4k 49.6k 52.8k 56.0k 10 | 92.8k 99.2k 105k 112k 5 | 185k 198k 211k 224k 2 | 464k 496k 528k 560k 1 | 928k 992k 1.06M 1.12M *5245, ipv6 (128 byte base packet size)* | packet len: 128+2 ufrag ms | 4 8 12 16 -----|------------------------ 500 | 2.18k 2.3k 2.43k 2.56k 200 | 5.44k 5.76k 6.08k 6.4k 100 | 10.9k 11.5k 12.2k 12.8k 50 | 21.8k 23.0k 24.3k 25.6k 20 | 54.4k 57.6k 60.8k 64.0k 10 | 108k 115k 121k 128k 5 | 217k 230k 243k 256k 2 | 544k 576k 608k 640k 1 | 1.09M 1.15M 1.22M 1.28M *shaved , ipv4 (52 byte base packet size)* | packet len: 52+2 ufrag ms | 4 8 12 16 -----|------------------------ 500 | 0.96k 1.09k 1.22k 1.34k 200 | 2.4k 2.72k 3.04k 3.36k 100 | 4.8k 5.44k 6.08k 6.72k 50 | 9.6k 10.9k 12.2k 13.4k 20 | 24.0k 27.2k 30.4k 33.6k 10 | 48.0k 54.4k 60.8k 67.2k 5 | 96.0k 108k 121k 134k 2 | 240k 272k 304k 336k 1 | 480k 544k 608k 672k --001a114b2d5a1913ea05302a4a20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up on my action item from the meeting regar= ding bandwidth numbers for ICE checks:

I wrote a script= to generate some bandwidth numbers. Below are the bandwidths for various s= cenarios, with ufrags of 4, 8, 12, or 16 bytes. As you can see a 10 ms rate= generates ~100 kbps of traffic, not counting responses, and a 5 ms rate ge= nerates ~200 kbps.

I also included the numbers for my &q= uot;shaved ice" proposal, which cut the rates by ~half, but may still = be excessive at 10 ms.

One other exercise that may= be useful here is to consider the number of STUN checks needed in typical = cases to complete connectivity testing; this will give an idea of how long = these bandwidth values need to be sustained.

5245= , ipv4 (108 byte base packet size)
=C2=A0=C2=A0 =C2=A0 | packet len: 108+2 ufrag
=C2=A0 ms | =C2=A0 =C2=A0 4 =C2=A0 = =C2=A0 8 =C2=A0 =C2=A012 =C2=A0 =C2=A016
-----|------------------------
=C2=A0500 | 1.86k 1.98k 2.11k 2.24k
=C2=A0200 | 4.64k 4.96k 5.28k =C2= =A05.6k
=C2=A0100 | 9.= 28k 9.92k 10.6k 11.2k
= =C2=A0 50 | 18.6k 19.8k 21.1k 22.4k
=C2=A0 20 | 46.4k 49.6k 52.8k 56.0k
=C2=A0 10 | 92.8k 99.2k =C2=A0105k =C2=A0112k
=C2=A0 =C2=A05 | =C2=A0= 185k =C2=A0198k =C2=A0211k =C2=A0224k
=C2=A0 =C2=A02 | =C2=A0464k =C2=A0496k =C2=A0528k =C2=A0560= k
=C2=A0 =C2=A01 | =C2= =A0928k =C2=A0992k 1.06M 1.12M

5245, ipv6 (128 byte base packet size)
=C2=A0 =C2=A0 =C2=A0| p= acket len: 128+2 ufrag
=C2=A0 ms | =C2=A0 =C2=A0 4 =C2=A0 =C2=A0 8 =C2=A0 =C2=A012 =C2=A0 =C2=A01= 6
-----|--------------= ----------
=C2=A0500 |= 2.18k =C2=A02.3k 2.43k 2.56k
=C2=A0200 | 5.44k 5.76k 6.08k =C2=A06.4k
=C2=A0100 | 10.9k 11.5k 12.2k 12.8k
=
=C2=A0 50 | 21.8k 23.0k 24.3k 25.6= k
=C2=A0 20 | 54.4k 57= .6k 60.8k 64.0k
=C2=A0= 10 | =C2=A0108k =C2=A0115k =C2=A0121k =C2=A0128k
=C2=A0 =C2=A05 | =C2=A0217k =C2=A0230k =C2=A024= 3k =C2=A0256k
=C2=A0 = =C2=A02 | =C2=A0544k =C2=A0576k =C2=A0608k =C2=A0640k
=C2=A0 =C2=A01 | 1.09M 1.15M 1.22M 1.28M

shaved, ipv4 (52 byte base packet size)
=C2=A0 =C2=A0 =C2=A0| p= acket len: 52+2 ufrag
= =C2=A0 ms | =C2=A0 =C2=A0 4 =C2=A0 =C2=A0 8 =C2=A0 =C2=A012 =C2=A0 =C2=A016=
-----|---------------= ---------
=C2=A0500 | = 0.96k 1.09k 1.22k 1.34k
=C2=A0100 | =C2=A04.8k 5.44k 6.08k 6.72k
<= div>=C2=A0 50 | =C2=A09.6k 10.9k 12.2k = 13.4k
=C2=A0 20 | 24.0= k 27.2k 30.4k 33.6k
= =C2=A0 10 | 48.0k 54.4k 60.8k 67.2k
=C2=A0 =C2=A05 | 96.0k =C2=A0108k =C2=A0121k =C2=A0134k
=C2=A0 =C2=A02 | =C2=A0240k= =C2=A0272k =C2=A0304k =C2=A0336k
=C2=A0 =C2=A01 | =C2=A0480k =C2=A0544k =C2=A0608k =C2=A0672k


--001a114b2d5a1913ea05302a4a20-- From nobody Mon Apr 11 21:43:29 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FF512E2AF for ; Mon, 11 Apr 2016 21:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ecRGJteNPz7z for ; Mon, 11 Apr 2016 21:43:26 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570C612E2AE for ; Mon, 11 Apr 2016 21:43:26 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id v188so110970221wme.1 for ; Mon, 11 Apr 2016 21:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=//1EtVwMtuV37kjDk0M0h4kRa+VuNHq/3Y8zC8tyVVU=; b=KNi9jPQ8DbGoNrjRP1IkoD5Rd4hxU1KaVgBtwkPxAwHyYG7ZG/8j2QZnmn0RdcoRor ok7+AVifYdROWxpgBXyBhU+ulNfrCAyzNw4cnQLOkfu8WOKBudXIkeDASzvfrXga0Q5A ljkVNTHpbhhtEqIs1l8MF0zfrXRYFm0uiPc81X+DZocDmfsvBXRjye2g/ayltwl7zYYR M1jIl321mIOEw2e7eir7a2PvbAIAdQwW0is7t3JRddjC+LW/C39vjhXTTaE+7gZlwlSV xkAdc6R3LSN/I/W7v/NX4bjvLmue/V+0eZkwZSG7Okz9e1748jXIBAyH2Hu73dW0Axw7 JzLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=//1EtVwMtuV37kjDk0M0h4kRa+VuNHq/3Y8zC8tyVVU=; b=KCGI9iN5ydupTO2fcbTCOZPbLz+GITWo9xepPbb51tZsuiA51qegQhaZT9cTfZJ0aS io9XAI3i1MJTyDDk+Xa6wPhSzfSoSe/iKcr+TNqLqvBrIk76DiO7s3NcqTJsOS6smrvC DqGBvZSZhBmsrXsUsXqTFL7IcoRlDllVhha5LJniRz9nUhveu0sM/aHIwuxGxcaRdO93 bSGR2INHeZCLDYfo6qN2kTJFt7ehf9PvJ04RsKzspmJZGXRYoSiDjuIghL0AiW0jkkhb FkhT4KBuBlS8QzJlzGgUBkds56nGGWPfAlJcqxPr47hidVgujrx3WwaE+zhll0Zl3t4P M3MA== X-Gm-Message-State: AOPr4FXH5xpTh+yjUjQs3A5Apg5jIXOLyK7xU07fapYogr8WwjGgvhVYPFXvreRaNwwuao/apDiwLAGDV/zWmNKx X-Received: by 10.28.4.131 with SMTP id 125mr1463290wme.44.1460436204772; Mon, 11 Apr 2016 21:43:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.152.23 with HTTP; Mon, 11 Apr 2016 21:43:05 -0700 (PDT) From: Justin Uberti Date: Mon, 11 Apr 2016 21:43:05 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a1141e8ae3434df0530424db4 Archived-At: Subject: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 04:43:28 -0000 --001a1141e8ae3434df0530424db4 Content-Type: text/plain; charset=UTF-8 In BA, I noted that unfreezing the candidate pairs associated with a candidate that arrives for a media stream other than the first one will cause all of that stream's candidate pairs to unfreeze, due to the rules in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8). Someone mentioned that there was only a single check list, which would make this a non-issue. However, I checked and indeed each stream is supposed to have its own check list (ignoring bundle), as described in S 5.7 ( https://tools.ietf.org/html/rfc5245#section-5.7). Therefore, while this concern of prematurely unfreezing check lists isn't an issue for candidates that arrive for a different component (since they share a check list), I think it is an issue for candidates that arrive for different m= lines, and as such I'm not sure this new unfreezing behavior is the correct solution in these cases. --001a1141e8ae3434df0530424db4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In BA, I noted that unfreezing the candidate pairs associa= ted with a candidate that arrives for a media stream other than the first o= ne will cause all of that stream's candidate pairs to unfreeze, due to = the rules in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8).

Someone mentioned that there was only a single check list, which would m= ake this a non-issue. However, I checked and indeed each stream is supposed= to have its own check list (ignoring bundle), as described in S 5.7 (https://tools.ietf.o= rg/html/rfc5245#section-5.7).

Therefore, while= this concern of prematurely unfreezing check lists isn't an issue for = candidates that arrive for a different component (since they share a check = list), I think it is an issue for candidates that arrive for different m=3D= lines, and as such I'm not sure this new unfreezing behavior is the co= rrect solution in these cases.
--001a1141e8ae3434df0530424db4-- From nobody Mon Apr 11 22:06:43 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCDB12E10A for ; Mon, 11 Apr 2016 22:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 EQHrLthO7VUB for ; Mon, 11 Apr 2016 22:06:39 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AF612DF38 for ; Mon, 11 Apr 2016 22:06:39 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i84so9915340ywc.2 for ; Mon, 11 Apr 2016 22:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=r19Uau8jAXFyFU1YSdTQnHqArPhjeElmMwVjtXqlDBk=; b=NHsMylKLaYT1h8se6szKluJ8IsiLgPjRQhMY90C82EbMbfo+0wmmM83Lt8PnZrOmbL S/KWkmRKZOICJb3uZwOXkwiuX+2abAchBWcTpmyOx1liDr/OFQspBSOaCTRy++CCj9+8 8jP+AvwLLpCBwOe0bDrqjqyz33t1KGkdwmNPc1ngbqjUktEvV2ne3W0c6m0FNb4yFK/j 8zOyGULEcEW0am+KmGikCwYkrYHOlpfwClY8ltzQSxe450wOBDa9AA4eZFlROCbGsd96 1p4GnQUgia4S1cgz5vcE8SFXUO5YoAbDMXBxnedwgN7SdNP7s/U7X5YH0YzECHQ9q9Kq tseQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=r19Uau8jAXFyFU1YSdTQnHqArPhjeElmMwVjtXqlDBk=; b=ImOYCaCk7vuGtra402NnRMMWJ/S7/LZUBOMOtDPpKFG2wPeAhr/tOKMJgBCxH8xcgT 1YTRLupRCoJLAPHHA8McMnecHn4ILn+CXNw93h0FtrtTAd716jXKG5HBbL61qT4nWf9Y kRn07TaH3Y0MmbO90hPbj3hyALndjiMrhz/BcxLUZgVjdwcpgwOq0K0Yoab77RyMuDSe G5oy62yCb7iII4KK04ENVUkpzjmuVkq4W5aA4GygbrpjpRpE43Xp5c5MbngW/aFZW6n5 8tWtY04/uxCMsQrKQjA4fBEIMJBgfgGQqTTLM93ZjcOsbRjfXq15AP1kSggamoQdRSYv T5lg== X-Gm-Message-State: AOPr4FVaEjydtPSgrKQ2JjLgMVnFD4wn0H771ZiIZ1cL+X+WbX19hVNXqzm+xuabNMCbIQ== X-Received: by 10.13.223.2 with SMTP id i2mr591972ywe.302.1460437598346; Mon, 11 Apr 2016 22:06:38 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com. [209.85.161.174]) by smtp.gmail.com with ESMTPSA id i188sm16763081ywg.33.2016.04.11.22.06.37 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 22:06:38 -0700 (PDT) Received: by mail-yw0-f174.google.com with SMTP id d68so9987287ywe.1 for ; Mon, 11 Apr 2016 22:06:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.252.67 with SMTP id m64mr652041ywf.67.1460437597193; Mon, 11 Apr 2016 22:06:37 -0700 (PDT) Received: by 10.83.46.67 with HTTP; Mon, 11 Apr 2016 22:06:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2016 00:06:37 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: Justin Uberti Content-Type: multipart/alternative; boundary=94eb2c06b22c32bf81053042a0e8 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 05:06:41 -0000 --94eb2c06b22c32bf81053042a0e8 Content-Type: text/plain; charset=UTF-8 Hey Justin, On Monday, 11 April 2016, Justin Uberti wrote: > In BA, I noted that unfreezing the candidate pairs associated with a > candidate that arrives for a media stream other than the first one will > cause all of that stream's candidate pairs to unfreeze, due to the rules in > S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8). > I may be missing your point but I don't think there's anything in 5245 (5.8 or elsewhere) that ever unfreezes all the pairs in a checklist in one go. There's text that talks about activating a check list and there's text that unfreezes an entire foundation actoss all check lists but neither of them should be an issue with Peter's suggestion I do agree with the rest of the mail here ... I just don't think any of it is a problem. Emil > Someone mentioned that there was only a single check list, which would > make this a non-issue. However, I checked and indeed each stream is > supposed to have its own check list (ignoring bundle), as described in S > 5.7 (https://tools.ietf.org/html/rfc5245#section-5.7). > > > Therefore, while this concern of prematurely unfreezing check lists isn't > an issue for candidates that arrive for a different component (since they > share a check list), I think it is an issue for candidates that arrive for > different m= lines, and as such I'm not sure this new unfreezing behavior > is the correct solution in these cases. > -- sent from my mobile --94eb2c06b22c32bf81053042a0e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Justin,

On Monday, 11 April 2016, Justin Uberti <juberti@google.com> wrote:
In BA, I noted that unfreezing the cand= idate pairs associated with a candidate that arrives for a media stream oth= er than the first one will cause all of that stream's candidate pairs t= o unfreeze, due to the rules in S 5.8 (https://tools.ietf.org/html/rfc52= 45#section-5.8).

I may be missing= your point but=C2=A0I don't think there's anything in 5245 (5.8 or= elsewhere)=C2=A0that ever unfreezes all the pairs in a=C2=A0checklist in o= ne go.=C2=A0

There's text that talks about act= ivating a check list and there's text that unfreezes an entire foundati= on actoss all check lists but neither of them should be an issue with Peter= 's suggestion

I do agree with the rest of the = mail here ... I just don't think any of it is a problem.

=
Emil


Someone mentioned that there was = only a single check list, which would make this a non-issue. However, I che= cked and indeed each stream is supposed to have its own check list (ignorin= g bundle), as described in S 5.7 (https://tools.ietf.org/html/rfc5245#se= ction-5.7).

=C2=A0

Therefore,= while this concern of prematurely unfreezing check lists isn't an issu= e for candidates that arrive for a different component (since they share a = check list), I think it is an issue for candidates that arrive for differen= t m=3D lines, and as such I'm not sure this new unfreezing behavior is = the correct solution in these cases.=C2=A0


= --
sent from my mobile
--94eb2c06b22c32bf81053042a0e8-- From nobody Tue Apr 12 11:43:40 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09612D1E9 for ; Tue, 12 Apr 2016 11:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UwlWUzj7Fm76 for ; Tue, 12 Apr 2016 11:43:37 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C476512D64C for ; Tue, 12 Apr 2016 11:43:36 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id k1so37471874vkb.0 for ; Tue, 12 Apr 2016 11:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6Qz+HWh2Hq0jRDZNrJkUXP7qcjgMp4153K46p2T4KVo=; b=H0hguurI3Smf95UCErdmDtgyArEPAuOgaOVvuUz5/bGPCqJi6hziFkMa1nQ5MUNtOQ 45JW63oZWyKigu/XmtiBg0i2r9jFEvBb5TWMj9W+VE7jB95vfQSBtbERiGtDvy1ATxnx Z1mBzeJRCAxk1pAcCmv3NZ4NK80KHRSrMDbUpeXEyulrAe6ma6CQ0XU9fH8Ci8hCpNve znXYvfFYpRsmR9GnOh4CUovE8gxYWzAw3Loa/zZxiBdrQENKMjUi95W2yFl5AZwFuDzs 9/VrnHLomjm6N/p9bqVfqceiVaZ4oK6kBdk/BU/8erAoNSGHGjfmbleYwqFEqJzhc7rU oR6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6Qz+HWh2Hq0jRDZNrJkUXP7qcjgMp4153K46p2T4KVo=; b=IdO+F/D+kM52+K/w/Z7r8ghOGMzoSfV1it40w96Pu7C/HMGkubiDyj/AV+BpHPmWIM PddMOnDURkjsvylGDmL0bJt87CdUPpDKeqFRfPsouHbQVHPHq7SyHhFGzcNk7E0kugSP NCLOK4ym74N1GI+uI++PG/bBN3wcv51H5EyAV+miSLH/3sznG/xMF05FJ/O9/tqiIJi+ cH9vkZ+Bf1F1OP/bK992wNJzweWJo5DQp8QAeLhGVbV+DRkyPMLJfN5GrrpJwF7GaMtK h0ZJ/L0mMmUlO8m5hI0UU9F7DHkl5bo48AFNIujL5owzjyVxVHju0ybAXwhrvk++qhsH 0LMg== X-Gm-Message-State: AOPr4FXkPgaxkcxJy3DyUnMxuiPN5ulcCWz5LKIJWZddAWPuqKtc7hY5luo6hs/0p84JStUz77tmoONaikpFz1dT X-Received: by 10.31.44.77 with SMTP id s74mr2494802vks.4.1460486615609; Tue, 12 Apr 2016 11:43:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.164 with HTTP; Tue, 12 Apr 2016 11:42:56 -0700 (PDT) In-Reply-To: <5706DBAB.7030703@jitsi.org> References: <57069DE4.1070805@jitsi.org> <5706DBAB.7030703@jitsi.org> From: Peter Thatcher Date: Tue, 12 Apr 2016 11:42:56 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c075a2ec6b6105304e0900 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 18:43:39 -0000 --001a11c075a2ec6b6105304e0900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2016 at 3:14 PM, Emil Ivov wrote: > > > On 7.04.16 =D0=B3. 16:27, Peter Thatcher wrote: > >> >> >> On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov > > wrote: >> >> On 21.03.16 =D0=B3. 19:07, Peter Thatcher wrote: >> >> As an author (not a chair), I just submitted a draft for an idea >> I'd >> like to propose for ICE: network cost. >> >> Here's the draft: >> >> https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost= / >> >> >> The idea is basically to allow the controlled side to tell the >> controlling side which candidates "cost" more than others (such = as >> cellular costing more than Wi-Fi). This is different than >> candidate >> priority for reasons explained in the draft. >> >> >> I see the value here but I have a few problems with the current stat= e. >> >> To begin with, I find the "cost" name overly confusing. I realize >> the draft already says this is not necessarily real cost but it >> still leaves people with the wrong impression (and I've confirmed >> this in conversations these days). So let's just go for bias or >> something (I also like fondness). >> >> >> =E2=80=8BThere are two question here: the name and the direction. The = choice >> of direction is more important than the name. I prefer the direction >> where 0 means "free/use-freely" and a big number means >> "expensive/restrained/last-resort". This is because if we ever expand >> the range, I think it would be better in the direction of "I really >> don't want to use this" rather than "this is even more free to use". >> You'll note that this direction is the opposite of >> fondness/preference/priority. >> >> In other words, I think modeling this as "badness' is better than as >> "goodness". >> > > OK, this makes sense. > > So if we're going to debate names, let's debate synonyms of "badness". >> The best I could come up with is cost. But I'd love to hear good >> synonyms.=E2=80=8B >> > > Let's go with "handicap" then? (If not we always have aversion and > reluctance). =E2=80=8BI'm not a fan of any of those words. I'd prefer "badness" over th= ose. =E2=80=8B > > > The draft is not currently very explicit about exactly how this >> works in the selection of candidates but I assume it basically >> means: "if it's all the same to you, I'd much rather you get in >> touch with me here than there." >> >> >> Close. 0 means "use this freely". A small number means "I'd rather not >> use this". A large number means "Only use this if nothing else works".= =E2=80=8B >> =E2=80=8B >> >> The trickiest part here is how to assign importance to this new bias >> as opposed to existing metrics such as RTT for example. We could say >> it's up to implementations or try to come up with some >> recommendation for a formula. >> >> >> =E2=80=8BThat's exactly what I think we should do: standardized how info= rmation >> is conveyed from controlled to controlling, but then let the controlling >> side decided how to select and nominate.=E2=80=8B >> > > The problem here is that unless we give directions about how it should be > used in practice, then we greatly limit the usefulness and interoperabili= ty. > I actually think we can be very helpful without going into the details > that much. Like for example: > > 0: use freely as you say. =E2=80=8Bh=E2=80=8B > >0: you MAY use if no valid pairs exist where the remote candidate has a > lower handicap but you SHOULD/MUST switch if such a pair becomes valid. > I think such a rule is too restrictive of cost/badness > 0. Perhaps such a rules for cost/badness =3D=3D MAX would make sense. Basically, MAX would m= ean "last resort". However, we do need to be careful about the case where there are only two candidate pairs available, one of which is (0, MAX) and the other (MAX, 0). In other words, either the controlling side or the controlled side has to end up using a "last resort". Do we standardize which is picked, or leave that up to the controlling side to decide (let it decide to be gracious or not). =E2=80=8B > > Also, unless your nominated pair has pair.remoteCandidate.handicap=3D=3D0= , > then you MUST continue running checks until either you run through all of > them or at least one pair with zero handicap becomes valid. When that > happens you must switch. > > =E2=80=8BSo, basically, don't prune less-bad networks just because a more-b= ad network worked first? That seems reasonable. I'm not sure if it's MUST-worthy, though. And, again, be careful with the "must switch"=E2=80=8B, since you need to r= emember the case where only two candidate pairs exist: (N, 0) and (0, N) and the controlling side needs to pick who pays more (and whether to be gracious or not). > Also if your selected pair has a remoteCandidate with non-zero handicap H > and another pair becomes valid where the remoteCandidate has a lower > handicap h (i.e., h > The other thing is that I cannot at all see the value of the network >> ID. Why is this necessary? >> >> >> =E2=80=8BTechnically, I could make it a separate draft, but the kind of = go well >> together (they both fit in one nice STUN attribute, for example). >> >> The value of network ID is the following: if the remote side's network >> interface changes, it's wise to notify your bandwidth estimator, because >> the change may have been drastic (wifi to 2g). =E2=80=8B It could chang= e either >> by TURN mobility, or by continual gathering, or by the use of backup >> candidate pairs (I realized the last two are not yet standardized). >> > > I am not a huge fan of this. I think it requires the remote side to know > more than it needs to. If you want to reinit your bwe engine then we shou= ld > have a message that says that =E2=80=8BIt's not as simple as just "reinit the BWE". The BWE wants to kno= w *why*, and knowing its because the remote network changed is important information.=E2=80=8B =E2=80=8B And the other problem with message sent from the remote side is that the local/controlling side may switch candidate pairs, and it needs to know if doing so changes the remote network or not, so it can know if it should reset or not. If it had to wait for a message from the remote side, it would have to wait for the remote side to receive a message from the local side, and then for the remote side to send back a message saying "by the way, that candidate pair changed my local network", which just adds an extra round trip for no good reason. (and it should probably be in RTCP). =E2=80=8BThat's not going to work for data channels, which also use ICE.=E2= =80=8B There could be other reasons for this that cannot be directly mapped to > changing interfaces. =E2=80=8BIn which case, the BWE would like to know which case it is, becaus= e it might behave differently between them. =E2=80=8B > An interface ID mainly bothers me as it delivers more knowledge than one > needs for that sort of stuff and it encourages implementers to make assumptions > ... and ICE is all about avoiding them. =E2=80=8BIt's basically the minimal information to know that the remote net= work path is changing between two candidate pairs. And the assumption that can be made is that if the ID is different, the network is different, which is exactly the information it is meant to convey. =E2=80=8B > > Emil > > -- > https://jitsi.org > =E2=80=8BI mostly disagree here. The controlled side is always at the merc= y of the controlling side, and t he status-quo is that the controlled side has no way to say anything about the networks it finds costly/bad. Being able to communicate 0/max/something-in-between is very useful for the controlled side with any reasonably implemented controlling side. But for the values of things in between 0 and max, I agree. =E2=80=8BThe difference between 100 and 200 are hard to nail down. We tried to nail it down according to how we think it would be useful, and we realized two things: 1. Everyone might not agree with how we were thinking to nail it down. 2. We might change our minds 6-12 months from now anyway. Being able to signal these things is valuable even if we haven't nailed down what the difference between 100 and 200 means (if we ever nail it down). So I'd prefer standardizing the signaling of these things (signaling here includes the STUN attribute) and the range of values, and then leave the interpretation of the difference of particular values to implementations or future specs once we have more implementation experience= . --001a11c075a2ec6b6105304e0900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 3:14 PM, Emil Ivov &l= t;emcho@jitsi.org> wrote:<= br>


On 7.04.16 =D0=B3. 16:27, Peter Thatcher wrote:


On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov <emcho@jitsi.org
<mailto:emcho@jitsi.org>> w= rote:

=C2=A0 =C2=A0 On 21.03.16 =D0=B3. 19:07, Peter Thatcher wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As an author (not a chair), I just submitted a = draft for an idea I'd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 like to propose for ICE: network cost.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Here's the draft:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.= org/doc/draft-thatcher-ice-network-cost/


=C2=A0 =C2=A0 =C2=A0 =C2=A0 The idea is basically to allow the controlled s= ide to tell the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 controlling side which candidates "cost&qu= ot; more than others (such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellular costing more than Wi-Fi).=C2=A0 This i= s different than candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 priority for reasons explained in the draft.

=C2=A0 =C2=A0 I see the value here but I have a few problems with the curre= nt state.

=C2=A0 =C2=A0 To begin with, I find the "cost" name overly confus= ing. I realize
=C2=A0 =C2=A0 the draft already says this is not necessarily real cost but = it
=C2=A0 =C2=A0 still leaves people with the wrong impression (and I've c= onfirmed
=C2=A0 =C2=A0 this in conversations these days). So let's just go for b= ias or
=C2=A0 =C2=A0 something (I also like fondness).


=E2=80=8BThere are two question here:=C2=A0 the name and the direction.=C2= =A0 The choice
of direction is more important than the name.=C2=A0 I prefer the direction<= br> where 0 means "free/use-freely" and a big number means
"expensive/restrained/last-resort".=C2=A0 This is because if we e= ver expand
the range, I think it would be better in the direction of "I really don't want to use this" rather than "this is even more free t= o use".
You'll note that this direction is the opposite of
fondness/preference/priority.

In other words, I think modeling this as "badness' is better than = as
"goodness".

OK, this makes sense.

So if we're going to debate names, let's debate synonyms of "b= adness".
The best I could come up with is cost.=C2=A0 But I'd love to hear good = synonyms.=E2=80=8B

 Let's go with "handicap" then? (If not we always have aversio= n and reluctance).

=E2=80= =8BI'm not a fan of any of those words.=C2=A0 I'd prefer "badn= ess" over those.
=E2=80=8B
=C2= =A0


=C2=A0 =C2=A0 The draft is not currently very explicit about exactly how th= is
=C2=A0 =C2=A0 works in the selection of candidates but I assume it basicall= y
=C2=A0 =C2=A0 means: "if it's all the same to you, I'd much ra= ther you get in
=C2=A0 =C2=A0 touch with me here than there."


Close.=C2=A0 0 means "use this freely".=C2=A0 A small number mean= s "I'd rather not
use this".=C2=A0 A large number means "Only use this if nothing e= lse works".=E2=80=8B
=E2=80=8B

=C2=A0 =C2=A0 The trickiest part here is how to assign importance to this n= ew bias
=C2=A0 =C2=A0 as opposed to existing metrics such as RTT for example. We co= uld say
=C2=A0 =C2=A0 it's up to implementations or try to come up with some =C2=A0 =C2=A0 recommendation for a formula.


=E2=80=8BThat's exactly what I think we should do: standardized how inf= ormation
is conveyed from controlled to controlling, but then let the controlling side decided how to select and nominate.=E2=80=8B

 The problem here is that unless we give directions about how it should be u= sed in practice, then we greatly limit the usefulness and interoperability.=

I actually think we can be very helpful without going into the details that= much. Like for example:

0: use freely as you say.
= =E2=80=8Bh=E2=80=8B
>0: you MAY use if no valid pairs exist where t= he remote candidate has a lower handicap but you SHOULD/MUST switch if such= a pair becomes valid.

I think such a rule is too rest= rictive of cost/badness > 0.=C2=A0 Perhaps such a rules for cost/badness= =3D=3D MAX would make sense.=C2=A0 Basically, MAX would mean "last re= sort". =C2=A0

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;display:inline">However, we do need to be careful about the case where the= re are only two candidate pairs available, one of which is (0, MAX) and the= other (MAX, 0).=C2=A0 In other words, either the controlling side or the c= ontrolled side has to end up using a "last resort".=C2=A0 Do we s= tandardize which is picked, or leave that up to the controlling side to dec= ide (let it decide to be gracious or not).
=C2=A0=E2=80=8B
=C2=A0=C2=A0

Also, unless your nominated pair has pair.remoteCandidate.handicap=3D=3D0, = then you MUST continue running checks until either you run through all of t= hem or at least one pair with zero handicap becomes valid. When that happen= s you must switch.


=E2=80=8BSo, basically, don't p= rune less-bad networks just because a more-bad network worked first?=C2=A0 = That seems reasonable.=C2=A0 I'm not sure if it's MUST-worthy, thou= gh.

And, again, be careful with the "must switch&= quot;=E2=80=8B, since you need to remember the case where only two candidat= e pairs exist: (N, 0) and (0, N) and the controlling side needs to pick who= pays more (and whether to be gracious or not).

=C2= =A0
Also if your selected pair has a remoteCandidate with non-zero handicap H a= nd another pair becomes valid where the remoteCandidate has a lower handica= p h (i.e., h<H) then you SHOULD switch to that new pair.

<= div>
=E2=80=8BWell, as mentioned, the badness of both sides needs to be balanc= ed.=C2=A0 A given candidate pair might be slight better for you but a lot w= orse for me.=E2=80=8B
=E2=80=8B



=C2=A0 =C2=A0 The other thing is that I cannot at all see the value of the = network
=C2=A0 =C2=A0 ID. Why is this necessary?


=E2=80=8BTechnically, I could make it a separate draft, but the kind of go = well
together (they both fit in one nice STUN attribute, for example).

The value of network ID is the following:=C2=A0 if the remote side's ne= twork
interface changes, it's wise to notify your bandwidth estimator, becaus= e
the change may have been drastic (wifi to 2g).=C2=A0 =E2=80=8B It could cha= nge either
by TURN mobility, or by continual gathering, or by the use of backup
candidate pairs (I realized the last two are not yet standardized).

 I am not a huge fan of this. I think it requires the remote side to know mo= re than it needs to. If you want to reinit your bwe engine then we should h= ave a message that says that

=E2=80=8BI= t's not as simple as just "reinit the BWE".=C2=A0 The BWE wan= ts to know *why*, and knowing its because the remote network changed is imp= ortant information.=E2=80=8B
=E2=80=8B
And the other= problem with message sent from the remote side is that the local/controlli= ng side may switch candidate pairs, and it needs to know if doing so change= s the remote network or not, so it can know if it should reset or not.=C2= =A0 If it had to wait for a message from the remote side, it would have to = wait for the remote side to receive a message from the local side, and then= for the remote side to send back a message saying "by the way, that c= andidate pair changed my local network", which just adds an extra roun= d trip for no good reason.

(and it shoul= d probably be in RTCP).

=E2=80=8BThat&#= 39;s not going to work for data channels, which also use ICE.=E2=80=8B

There could be other reasons for thi= s that cannot be directly mapped to changing interfaces.
<= br>
=E2=80=8BIn which case, the BWE would like to know which c= ase it is, because it might behave differently between them. =E2=80=8B
=C2=A0
An interface ID mainly bothers me as it delivers more knowledge than one ne= eds
for that sort of stuff and it encourages i= mplementers to make assumptions ... and ICE is all about avoiding them.

=E2=80=8BIt's basically the minimal = information to know that the remote network path is changing between two ca= ndidate pairs.=C2=A0 And the assumption that can be made is that if the ID = is different, the network is different, which is exactly the information it= is meant to convey.
=E2=80=8B=C2=A0

Emil

--
https://jitsi.org


<= /div>

=
=E2=80=8BI = mostly disagree here.=C2=A0 The controlled side is always at the mercy of t= he controlling side, and t
he status-quo is that th= e controlled side has no way to say anything about the networks it finds co= stly/bad.=C2=A0 Being able to communicate 0/max/something-in-between is ver= y useful for the controlled side with any reasonably implemented controllin= g side.

But for the values of things in= between 0 and max, I agree. =C2=A0=E2=80=8BThe difference between 100 and = 200 are hard to nail down.=C2=A0 We tried to nail it down according to how = we think it would be useful, and we realized two things:
1.=C2=A0 E= veryone might not agree with how we were thinking to nail it down.
= 2.=C2=A0 We might change our minds 6-12 months from now anyway.
Be= ing able to signal these things is valuable even if we haven't nailed d= own what the difference between 100 and 200 means (if we ever nail it down)= .=C2=A0 So I'd prefer standardizing the signaling of these things (sign= aling here includes the STUN attribute) and the range of values, and then l= eave the interpretation of the difference of particular values to implement= ations or future specs once we have more implementation experience.= =C2=A0

--001a11c075a2ec6b6105304e0900-- From nobody Tue Apr 12 17:25:27 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F6A12D5B3 for ; Tue, 12 Apr 2016 17:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 otrOmyoJ6C9Z for ; Tue, 12 Apr 2016 17:25:24 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E592A12D590 for ; Tue, 12 Apr 2016 17:25:22 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id u206so48330916wme.1 for ; Tue, 12 Apr 2016 17:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FRIHqqcmG4ShGdqagVxpeayf+LyP4Q/beXhMT/tEU6k=; b=pt8wc+3ozG0P6dAAFgfrlhVB81eTw8wvnPHDL4z3jKutA3Xl0Jy3e4o6B/IICiZuA9 +K6WJ7CE0ZWf3OT19zXaN61KqCgTgtviPveUCpW23cPJ8zZUAdTpDKoFr1+DA1MBfkUb g2Y6fSSlwQC8bR4qhDYsQ9oXWAk9Ke8M5tGxLDYRq3+x7ILC2+I6SkwFjI18MvJUBcg0 chhbixc0miQNwJYHULIueyq5gBeULVASAgWoD+Hoh2g30zJ063to8cKrx4uBwxOhBCZr Wn58fKLaJKD4okP437ZZ6ss2Eljm6p4Y63/1UdM80mDWl7M0vnNd3KpdVrPpLVf7siR7 N4PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FRIHqqcmG4ShGdqagVxpeayf+LyP4Q/beXhMT/tEU6k=; b=QSxadMnW3haURM26C/YpAc46Z4rfOMnX7g5ZpLrIJ1S/ZA7hktOdSPmQu3g+ZDgNR2 e786Fa4immQq8Q3AHj932htdPQDlGyNIHGQb/dZXyqu9tiZ8VNCx/wbd7Vg0iX0A1v6+ fFC3MrpuLVeNysg4HDPFwHkiu+KmYg0LbX0haFeIybdgL20DtxfLqfEEhKqYoVTjNrXM 26s+1oNTUz0AfC7TxKLOYCrr2tYlhU37jmjTqNY3Eaq38yGMwkA2mSnavTXK+BdEbtfF EB1YKbTh3cvjY5aZ3h43wNOmiqXkujwyTeDwvNsRWaBAZcdZPopiQxLLCnstgA8PsOBh 3TqQ== X-Gm-Message-State: AOPr4FWaiRbqtyc3YVrFcJ1U+s1t8HNxdakcLH9VKRw0/LGdB4VvmpP/YRIBxogNZ3R38Cnu4qq/dqMtrirEYDPV X-Received: by 10.194.6.36 with SMTP id x4mr6539280wjx.122.1460507121114; Tue, 12 Apr 2016 17:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.152.23 with HTTP; Tue, 12 Apr 2016 17:25:01 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 12 Apr 2016 17:25:01 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7b5d295c25c3e4053052d060 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 00:25:26 -0000 --047d7b5d295c25c3e4053052d060 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov wrote: > Hey Justin, > > On Monday, 11 April 2016, Justin Uberti wrote: > >> In BA, I noted that unfreezing the candidate pairs associated with a >> candidate that arrives for a media stream other than the first one will >> cause all of that stream's candidate pairs to unfreeze, due to the rules in >> S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8). >> > > I may be missing your point but I don't think there's anything in 5245 > (5.8 or elsewhere) that ever unfreezes all the pairs in a checklist in one > go. > > It's not that the checklist unfreezes all at once - it's that once you unfreeze any pair in a checklist, the algo in 5.8 will necessarily unfreeze the entire checklist in short order. That defeats the purpose of a frozen checklist (i.e., you'll end up checking both streams in parallel). > There's text that talks about activating a check list and there's text > that unfreezes an entire foundation actoss all check lists but neither of > them should be an issue with Peter's suggestion > > I do agree with the rest of the mail here ... I just don't think any of it > is a problem. > > Emil > > >> Someone mentioned that there was only a single check list, which would >> make this a non-issue. However, I checked and indeed each stream is >> supposed to have its own check list (ignoring bundle), as described in S >> 5.7 (https://tools.ietf.org/html/rfc5245#section-5.7). >> > > > >> >> Therefore, while this concern of prematurely unfreezing check lists isn't >> an issue for candidates that arrive for a different component (since they >> share a check list), I think it is an issue for candidates that arrive for >> different m= lines, and as such I'm not sure this new unfreezing behavior >> is the correct solution in these cases. >> > > > -- > sent from my mobile > --047d7b5d295c25c3e4053052d060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey Justin,
On Monday, 11 April 2016, Justin Uberti <juberti@google.com> wrote:
In BA, I noted that unfreezing the= candidate pairs associated with a candidate that arrives for a media strea= m other than the first one will cause all of that stream's candidate pa= irs to unfreeze, due to the rules in S 5.8 (https://tools.ietf.org/html/= rfc5245#section-5.8).

I ma= y be missing your point but=C2=A0I don't think there's anything in = 5245 (5.8 or elsewhere)=C2=A0that ever unfreezes all the pairs in a=C2=A0ch= ecklist in one go.=C2=A0


It's not that the checklist unfreezes all at once - it's that on= ce you unfreeze any pair in a checklist, the algo in 5.8 will necessarily u= nfreeze the entire checklist in short order. That defeats the purpose of a = frozen checklist (i.e., you'll end up checking both streams in parallel= ).
=C2=A0
The= re's text that talks about activating a check list and there's text= that unfreezes an entire foundation actoss all check lists but neither of = them should be an issue with Peter's suggestion

I do agree with the rest of the mail here ... I just don't think any = of it is a problem.

Emil


Someone mentioned that there was o= nly a single check list, which would make this a non-issue. However, I chec= ked and indeed each stream is supposed to have its own check list (ignoring= bundle), as described in S 5.7 (https://tools.ietf.org/html/rfc5245#sec= tion-5.7).

=C2=A0

Therefore, = while this concern of prematurely unfreezing check lists isn't an issue= for candidates that arrive for a different component (since they share a c= heck list), I think it is an issue for candidates that arrive for different= m=3D lines, and as such I'm not sure this new unfreezing behavior is t= he correct solution in these cases.=C2=A0


<= /div>
--
sent from = my mobile

--047d7b5d295c25c3e4053052d060-- From nobody Tue Apr 12 18:25:56 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B86B12D887 for ; Tue, 12 Apr 2016 18:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 ZziVGXFDUlMR for ; Tue, 12 Apr 2016 18:25:52 -0700 (PDT) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200AC12D940 for ; Tue, 12 Apr 2016 18:25:51 -0700 (PDT) Received: by mail-yw0-x243.google.com with SMTP id i125so4668630ywe.3 for ; Tue, 12 Apr 2016 18:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=F+uB5IcDUGvWoEpvneGw5+epanqrneNuqgzRexRgkQ8=; b=L64hcY2E7Sp/mKY/xpqvi6+JLTl4Y3CvCURAC/zAyjNGuw//QdfZg88NY5QDs8PGhq 7D4KkB1ojmxlakL1isZDDl1pfQzySRbsOtx5+G4NJboWqTw/LLp4ukPOioqc79ZI9svu 1Lhs1teQPapDGA++Psxoh4UUZYTwXrBkV7Y+ft3DDl/3Mli8nj0WZRLKAi7FrqAgep/M VCvX13BrYLCyOLLzdbQeFH+p7jR4IsrzvDgTXAqgc81EC+BNo0vRye234eZNQhVYq7WY xxrVW6HcengyuKPNHDOgQtnZGtdFJkWSJg6DGHJyJFBrrcckCRdtxk9ertHaytE3GSQc Rs1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=F+uB5IcDUGvWoEpvneGw5+epanqrneNuqgzRexRgkQ8=; b=YhdgF1AMNPGYiTs/FQ1yvm/0jzy3hYfbdO9QaoWbp9d3cj2KKz5YnJJyNjv71kLmFO YAdD64SOOuZUWhO6psR/j+M2Ql/Rz1vpf4aoWdnSNwpfrX0GWU+oeQnZ+JVtFtuZiU8W h/fkZbLqPY6R938mH2vlc4upPnX36QyvFA3PvbCdgt89d+BhQNKx2tfa385cchTc7lSO sVWavbArkpQXF7zfbPG3bg6pcJhfEz81gE0fTNlLRIlsnE//REd3Qo9C5IBufin5Luww l7vLZvMJQ+23VjSRQwTiaL925TkR9RDQoowGp+YqxT6EhoZCed24xra/ca10THYrtVq7 GuFg== X-Gm-Message-State: AOPr4FVYnbsxsb2OjDIjBDMxr9hPBbxKixJo8MwWKaAQL0o3MwGIfSwx9F/opve6Wlrjhw== X-Received: by 10.13.252.197 with SMTP id m188mr3391774ywf.281.1460510750294; Tue, 12 Apr 2016 18:25:50 -0700 (PDT) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com. [209.85.161.175]) by smtp.gmail.com with ESMTPSA id h63sm19300690ywc.37.2016.04.12.18.25.49 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 18:25:50 -0700 (PDT) Received: by mail-yw0-f175.google.com with SMTP id i84so49392032ywc.2 for ; Tue, 12 Apr 2016 18:25:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.237.1 with SMTP id w1mr3463690ywe.62.1460510749450; Tue, 12 Apr 2016 18:25:49 -0700 (PDT) Received: by 10.83.46.67 with HTTP; Tue, 12 Apr 2016 18:25:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2016 20:25:49 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: Justin Uberti Content-Type: multipart/alternative; boundary=94eb2c0864a869b081053053a851 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 01:25:55 -0000 --94eb2c0864a869b081053053a851 Content-Type: text/plain; charset=UTF-8 On Tuesday, 12 April 2016, Justin Uberti wrote: > > > On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov > wrote: > >> Hey Justin, >> >> On Monday, 11 April 2016, Justin Uberti > > wrote: >> >>> In BA, I noted that unfreezing the candidate pairs associated with a >>> candidate that arrives for a media stream other than the first one will >>> cause all of that stream's candidate pairs to unfreeze, due to the rules in >>> S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8). >>> >> >> I may be missing your point but I don't think there's anything in 5245 >> (5.8 or elsewhere) that ever unfreezes all the pairs in a checklist in one >> go. >> >> > It's not that the checklist unfreezes all at once - it's that once you > unfreeze any pair in a checklist, the algo in 5.8 will necessarily unfreeze > the entire checklist in short order. That defeats the purpose of a frozen > checklist (i.e., you'll end up checking both streams in parallel). > I really don't think that's the case (and if you are saying what I think you are saying then freezing would have been pointless even in vanilla ice) Could you please point to the specific text that's bothering you? The whole idea about unfreezing is that it happens along a foundation and across lists. There are many cases where you would unfreeze some candidates in a checklist (either because it was their turn or because their entire foundation got unfrozen) but other pairs in the same check list would remain frozen till ICE completes. Emil > >> There's text that talks about activating a check list and there's text >> that unfreezes an entire foundation actoss all check lists but neither of >> them should be an issue with Peter's suggestion >> >> I do agree with the rest of the mail here ... I just don't think any of >> it is a problem. >> >> Emil >> >> >>> Someone mentioned that there was only a single check list, which would >>> make this a non-issue. However, I checked and indeed each stream is >>> supposed to have its own check list (ignoring bundle), as described in S >>> 5.7 (https://tools.ietf.org/html/rfc5245#section-5.7). >>> >> >> >> >>> >>> Therefore, while this concern of prematurely unfreezing check lists >>> isn't an issue for candidates that arrive for a different component (since >>> they share a check list), I think it is an issue for candidates that arrive >>> for different m= lines, and as such I'm not sure this new unfreezing >>> behavior is the correct solution in these cases. >>> >> >> >> -- >> sent from my mobile >> > > -- sent from my mobile --94eb2c0864a869b081053053a851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, 12 April 2016, Justin Uberti <juberti@google.com> wrote:


On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov = <emcho@jitsi.org> wrote:
Hey Justin,

On Monday, 11 April 2016, Just= in Uberti <juberti@google.com> wrote:
In BA, I noted that unfreezin= g the candidate pairs associated with a candidate that arrives for a media = stream other than the first one will cause all of that stream's candida= te pairs to unfreeze, due to the rules in S 5.8 (https://tools.ietf.org/= html/rfc5245#section-5.8).

I may be missing your point but=C2=A0I don't think there's anythin= g in 5245 (5.8 or elsewhere)=C2=A0that ever unfreezes all the pairs in a=C2= =A0checklist in one go.=C2=A0


It's not that the checklist unfreezes all at once - it's th= at once you unfreeze any pair in a checklist, the algo in 5.8 will necessar= ily unfreeze the entire checklist in short order. That defeats the purpose = of a frozen checklist (i.e., you'll end up checking both streams in par= allel).
=C2=A0
I really = don't think that's the case (and if you are saying what I think you= are saying then freezing would have been pointless even in vanilla ice)=C2= =A0

Could you please point to the specific text th= at's bothering you?

The whole idea about u= nfreezing is that it=C2=A0happens along a foundation and across lists. Ther= e are many cases where you would=C2=A0unfreeze some=C2=A0candidates in a ch= ecklist (either because it was their turn or=C2=A0because their entire=C2= =A0foundation got unfrozen)=C2=A0but other pairs in the same check list=C2= =A0would remain frozen till ICE completes.

Emil
=C2=A0
There's text that talks about activating a check list = and there's text that unfreezes an entire foundation actoss all check l= ists but neither of them should be an issue with Peter's suggestion

I do agree with the rest of the mail here ... I just = don't think any of it is a problem.

Emil=



--
sent from my mobile
--94eb2c0864a869b081053053a851-- From nobody Tue Apr 12 22:04:59 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA18F12D79F for ; Tue, 12 Apr 2016 22:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 aifWGQ-4Ej9D for ; Tue, 12 Apr 2016 22:04:55 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870F612D582 for ; Tue, 12 Apr 2016 22:04:55 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id a140so79756331wma.0 for ; Tue, 12 Apr 2016 22:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wv4hBGp0veyHaFDyDevVDHsr5hLZ22bmYdviR7bwrZM=; b=UpK0JVdaAtBCcK2aqciC+HxY3E48PIiQWCVZ8JRl9hEGWQmJ/3FZCMC9fufH+C0Y3f e+4ADxp9lGfG1X+GMUq4RjRINKiRkxdc8FMXBpilTMDux31U7GMC3yLz+XtHo/zq+Z4S gM6lkekOsIHwQtBdAShfZVh5d6qemH36zoSF/Tu6C46eockJsgahyrH9OFZR6DKo6JlM MPA9pjjmXOw2janxQPmQ77J4MDTwA/bkoZu3AZtXkFrG4w7vB+jBkeSvYmmUGrA0Ljl8 TFNldiggWchktuKDUvs6TrIAA0PDeXWE8Q7B62ERCBRFPMvBEuW/NaEyOnkiVKhi4JII VTdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wv4hBGp0veyHaFDyDevVDHsr5hLZ22bmYdviR7bwrZM=; b=Q8V6hnEW5MuryJvjbkWpNihpKPlETbDFgc1txudqV8AYsr4puF5/mBf3s8i9wUe5xI 2PuP2dz15y4LR4Mx1ClBkFKwSyJ/2zL+XcySof7+J4BmTppsLgIKwKPBtTXNNAyU4H4I ss+WP3eyI3CSKWIraOcq+w642+J/cIgDgB0qkIpunB5Q1x0kiFq1fsTDmgMWwiFQwUcw RB9LX9rT/KNps7i0A2YNb4NItassvcoXZsTH/USunllwnLoZOum0rBWoSlpdABRIeMgN CALGaS6UbvOSQarMjVi0jjlWlzCgK7yKcPhf+ZURuN8OngYypCySyP9zWHq44PBTZRrT acmQ== X-Gm-Message-State: AOPr4FUI1svA3EHboK2fTK/eSqJdkBW2E1WB+hq2aIjbYmIk2Rjg67AY7zM0xvVrT26KFmfUHC8087PKtG9vSPLZ X-Received: by 10.194.202.168 with SMTP id kj8mr6992627wjc.8.1460523893990; Tue, 12 Apr 2016 22:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.152.23 with HTTP; Tue, 12 Apr 2016 22:04:34 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 12 Apr 2016 22:04:34 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7bae451ae38613053056b7c1 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 05:04:58 -0000 --047d7bae451ae38613053056b7c1 Content-Type: text/plain; charset=UTF-8 reading 5.8, the algo indicates that for an active checklist, you check the highest-prio pair in the waiting state, and if there is none, you check the highest-prio frozen pair, thereby unfreezing it. This repeats on each timer tick. Basically, once a checklist is active, you will soon end up checking all of its pairs. What am I missing? On Tue, Apr 12, 2016 at 6:25 PM, Emil Ivov wrote: > > > On Tuesday, 12 April 2016, Justin Uberti wrote: > >> >> >> On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov wrote: >> >>> Hey Justin, >>> >>> On Monday, 11 April 2016, Justin Uberti wrote: >>> >>>> In BA, I noted that unfreezing the candidate pairs associated with a >>>> candidate that arrives for a media stream other than the first one will >>>> cause all of that stream's candidate pairs to unfreeze, due to the rules in >>>> S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8). >>>> >>> >>> I may be missing your point but I don't think there's anything in 5245 >>> (5.8 or elsewhere) that ever unfreezes all the pairs in a checklist in one >>> go. >>> >>> >> It's not that the checklist unfreezes all at once - it's that once you >> unfreeze any pair in a checklist, the algo in 5.8 will necessarily unfreeze >> the entire checklist in short order. That defeats the purpose of a frozen >> checklist (i.e., you'll end up checking both streams in parallel). >> > > I really don't think that's the case (and if you are saying what I think > you are saying then freezing would have been pointless even in vanilla ice) > > Could you please point to the specific text that's bothering you? > > The whole idea about unfreezing is that it happens along a foundation and > across lists. There are many cases where you would unfreeze some candidates > in a checklist (either because it was their turn or because their > entire foundation got unfrozen) but other pairs in the same check > list would remain frozen till ICE completes. > > Emil > > >> >>> There's text that talks about activating a check list and there's text >>> that unfreezes an entire foundation actoss all check lists but neither of >>> them should be an issue with Peter's suggestion >>> >>> I do agree with the rest of the mail here ... I just don't think any of >>> it is a problem. >>> >>> Emil >>> >>> >>>> Someone mentioned that there was only a single check list, which would >>>> make this a non-issue. However, I checked and indeed each stream is >>>> supposed to have its own check list (ignoring bundle), as described in S >>>> 5.7 (https://tools.ietf.org/html/rfc5245#section-5.7). >>>> >>> >>> >>> >>>> >>>> Therefore, while this concern of prematurely unfreezing check lists >>>> isn't an issue for candidates that arrive for a different component (since >>>> they share a check list), I think it is an issue for candidates that arrive >>>> for different m= lines, and as such I'm not sure this new unfreezing >>>> behavior is the correct solution in these cases. >>>> >>> >>> >>> -- >>> sent from my mobile >>> >> >> > > -- > sent from my mobile > --047d7bae451ae38613053056b7c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
reading 5.8, the algo indicates that for an active checkli= st, you check the highest-prio pair in the waiting state, and if there is n= one, you check the highest-prio frozen pair, thereby unfreezing it. This re= peats on each timer tick.

Basically, once a checklist is= active, you will soon end up checking all of its pairs. What am I missing?=

On Tu= e, Apr 12, 2016 at 6:25 PM, Emil Ivov <emcho@jitsi.org> wrote:=


On Tuesday, 12 = April 2016, Justin Uberti <juberti@google.com> wrote:


On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov <= emcho@jitsi.org> wrote:
= Hey Justin,

On Monday, 11 April 2016, Justin Uberti <jub= erti@google.com> wrote:
In BA, I noted that unfreezing the candidate pairs associated with= a candidate that arrives for a media stream other than the first one will = cause all of that stream's candidate pairs to unfreeze, due to the rule= s in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8).
<= /blockquote>

I may be missing your point but=C2= =A0I don't think there's anything in 5245 (5.8 or elsewhere)=C2=A0t= hat ever unfreezes all the pairs in a=C2=A0checklist in one go.=C2=A0
=


It's not that the check= list unfreezes all at once - it's that once you unfreeze any pair in a = checklist, the algo in 5.8 will necessarily unfreeze the entire checklist i= n short order. That defeats the purpose of a frozen checklist (i.e., you= 9;ll end up checking both streams in parallel).
=C2=A0
I really don't think that's t= he case (and if you are saying what I think you are saying then freezing wo= uld have been pointless even in vanilla ice)=C2=A0

Could you please point to the specific text that's bothering you?
<= /div>

The whole idea about unfreezing is that it=C2=A0ha= ppens along a foundation and across lists. There are many cases where you w= ould=C2=A0unfreeze some=C2=A0candidates in a checklist (either because it w= as their turn or=C2=A0because their entire=C2=A0foundation got unfrozen)=C2= =A0but other pairs in the same check list=C2=A0would remain frozen till ICE= completes.

Emil

=C2=A0
There's text that talks about activating a check list and t= here's text that unfreezes an entire foundation actoss all check lists = but neither of them should be an issue with Peter's suggestion

I do agree with the rest of the mail here ... I just don&#= 39;t think any of it is a problem.

Emil


Someone mentioned that there was only a single ch= eck list, which would make this a non-issue. However, I checked and indeed = each stream is supposed to have its own check list (ignoring bundle), as de= scribed in S 5.7 (https://tools.ietf.org/html/rfc5245#section-5.7).<= /div>

=C2=A0

Therefore, while this co= ncern of prematurely unfreezing check lists isn't an issue for candidat= es that arrive for a different component (since they share a check list), I= think it is an issue for candidates that arrive for different m=3D lines, = and as such I'm not sure this new unfreezing behavior is the correct so= lution in these cases.=C2=A0


--
sent from my mobile



--
sent from my mobile

--047d7bae451ae38613053056b7c1-- From nobody Tue Apr 12 22:05:11 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3463F12DAC6 for ; Tue, 12 Apr 2016 22:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 68MMsQtPtQ-K for ; Tue, 12 Apr 2016 22:04:57 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FA912D704 for ; Tue, 12 Apr 2016 22:04:57 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id e190so3098441pfe.0 for ; Tue, 12 Apr 2016 22:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lQJdTMQn7xJWUKBIlK0b9muHMwKRoVxPwSz3WoxhCvA=; b=uEGkfowZazc/E66d7HqFst6m1+UUWXg7SM+w7exGw29640fSYA12YS1ATAOUgy6GyL fxjd6AagAeI5xt9IZiIfOrOXTGiqo9jdeveTMozq4tfO63Z67pEp9AcEesK6KTvneyZa GsGCDxWlDShzZYjLjXGQbhqHB8yWTqz67NGpPKlpHXUSkJ2ZQ0zH6y067BSPAiAeNiyn Hq2spAKy/3qVgh8mCzHSSW/rCKii1rMMtwimCDHRFoYgz76X8MXSkV9BVYr94Gj+BNHn 5nDHmEKR9SbxrdJjSNPdGhwNg07XllEQAhHUMItcdBqt+X0kCplVXU8o356by53AiAhW BcqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lQJdTMQn7xJWUKBIlK0b9muHMwKRoVxPwSz3WoxhCvA=; b=NBDaDxeDkwlxrV6HiQwgBCLYRwLbHWJCMHxPBSNXz+druYMBKnYd2RIhbNsgYoeom8 i4FdAAaIpMZNRhLoI6YXUIhKeTSzGFQAamZqSgOgKKMcQbVa0+d7+RhGDch79kG64gnP /+VJAHdlquwKqkCmrcO1w2s5TNsZVARLwmVxuaKvDh6SmDKBKH0rAKeYRzldstIVLd18 UyxOZgo9gz4E0KI1IJ0/wPTFxtjf1yUuewb1MavRXfHPCz65l6ZzJk5sRwKAzbuBhLm7 KYUAcI/5NGWzEDwyUeHsn5Va1ffgSMUOYtntDOOEw3AFrCoCxNprTwbUTLCuZw54iu14 9u3w== X-Gm-Message-State: AOPr4FVofR4gpe0mC6smhhaLzWaLOJNW20OR/uWMvfiH5nGSZYaXIuHEo3+olMAfR/gTEQ== X-Received: by 10.98.44.70 with SMTP id s67mr10114810pfs.59.1460523896708; Tue, 12 Apr 2016 22:04:56 -0700 (PDT) Received: from camionet.local ([2602:306:83fc:cd90:4591:4eeb:de64:ad7c]) by smtp.googlemail.com with ESMTPSA id a77sm1423034pfj.2.2016.04.12.22.04.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 22:04:54 -0700 (PDT) To: Peter Thatcher References: <57069DE4.1070805@jitsi.org> <5706DBAB.7030703@jitsi.org> From: Emil Ivov Message-ID: <570DD372.2090203@jitsi.org> Date: Wed, 13 Apr 2016 00:04:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 05:05:00 -0000 Hey Peter, On 12.04.16 г. 13:42, Peter Thatcher wrote: > > > On Thu, Apr 7, 2016 at 3:14 PM, Emil Ivov > wrote: > > On 7.04.16 г. 16:27, Peter Thatcher wrote: > > On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov > >> wrote: > > On 21.03.16 г. 19:07, Peter Thatcher wrote: > > As an author (not a chair), I just submitted a draft > for an idea I'd > like to propose for ICE: network cost. > > Here's the draft: > > https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/ > > > The idea is basically to allow the controlled side to > tell the > controlling side which candidates "cost" more than > others (such as > cellular costing more than Wi-Fi). This is different > than candidate > priority for reasons explained in the draft. > > > I see the value here but I have a few problems with the > current state. > > To begin with, I find the "cost" name overly confusing. I > realize > the draft already says this is not necessarily real cost but it > still leaves people with the wrong impression (and I've > confirmed > this in conversations these days). So let's just go for bias or > something (I also like fondness). > > > ​There are two question here: the name and the direction. The > choice > of direction is more important than the name. I prefer the > direction > where 0 means "free/use-freely" and a big number means > "expensive/restrained/last-resort". This is because if we ever > expand > the range, I think it would be better in the direction of "I really > don't want to use this" rather than "this is even more free to use". > You'll note that this direction is the opposite of > fondness/preference/priority. > > In other words, I think modeling this as "badness' is better than as > "goodness". > > > OK, this makes sense. > > So if we're going to debate names, let's debate synonyms of > "badness". > The best I could come up with is cost. But I'd love to hear > good synonyms.​ > > > Let's go with "handicap" then? (If not we always have aversion and > reluctance). > > > ​I'm not a fan of any of those words. I'd prefer "badness" over those. And I guess I'd still prefer "handicap" (I can also be talked into preferring "lousiness" ;) ) > The draft is not currently very explicit about exactly how this > works in the selection of candidates but I assume it basically > means: "if it's all the same to you, I'd much rather you get in > touch with me here than there." > > > Close. 0 means "use this freely". A small number means "I'd > rather not > use this". A large number means "Only use this if nothing else > works".​ > ​ > > The trickiest part here is how to assign importance to this > new bias > as opposed to existing metrics such as RTT for example. We > could say > it's up to implementations or try to come up with some > recommendation for a formula. > > > ​That's exactly what I think we should do: standardized how > information > is conveyed from controlled to controlling, but then let the > controlling > side decided how to select and nominate.​ > > > The problem here is that unless we give directions about how it > should be used in practice, then we greatly limit the usefulness and > interoperability. > > > I actually think we can be very helpful without going into the > details that much. Like for example: > > 0: use freely as you say. > > ​h​ > >0: you MAY use if no valid pairs exist where the remote candidate > has a lower handicap but you SHOULD/MUST switch if such a pair > becomes valid. > > > I think such a rule is too restrictive of cost/badness > 0.Perhaps > such a rules for cost/badness == MAX would make sense. Basically, MAX > would mean "last resort". It sounds like the algorithm you have in mind basically cares about three sets of values: 0, anything, MAX_HANDICAP. If that is the case we might as well go for 0,1 and 2 and not allow other values. I personally like the idea of allowing all integers but then that has to have a meaning in order to be useful. Otherwise it would just sloppy. I think we are talking about different things though. My bad(ness). I was only referring to remote handicap comparison. Here's how the above rule should look like. How about this: 0: user freely h>0: you MAY use if no valid pairs exist *for the same local candidate* where the remote candidate has a lower handicap but you SHOULD/MUST switch if such a pair becomes valid. > However, we do need to be careful about the case where there are only > two candidate pairs available, one of which is (0, MAX) and the other > (MAX, 0). In other words, either the controlling side or the controlled > side has to end up using a "last resort". Do we standardize which is > picked, or leave that up to the controlling side to decide (let it > decide to be gracious or not). Agreed. We don't need to stipulate it, but we can say that (Controlling.0, Controlled.MAX) is the most likely outcome. > Also, unless your nominated pair has > pair.remoteCandidate.handicap==0, then you MUST continue running > checks until either you run through all of them or at least one pair > with zero handicap becomes valid. When that happens you must switch. > > ​So, basically, don't prune less-bad networks just because a more-bad > network worked first? That seems reasonable. I'm not sure if it's > MUST-worthy, though. As a matter of fact I am wondering whether even SHOULD makes sense. It is very hard to reconcile these things with other constraints such as RTT. I see no easy way where application developers could know whether an RTT of 5 seconds would be preferable to using an LTE interface ... You may want to avoid LTE because it would exhaust your 5GB plan (but you'd still rather not have to suffer through a 5 second RTT) or you may want to avoid it because you are on roaming in Congo and having an HD call on it would cost more than your house ... So maybe we could write all the rules without any 2119 language. > And, again, be careful with the "must switch"​, since you need to > remember the case where only two candidate pairs exist: (N, 0) and (0, > N) and the controlling side needs to pick who pays more (and whether to > be gracious or not). Yes, rectified the rule above. > Also if your selected pair has a remoteCandidate with non-zero > handicap H and another pair becomes valid where the remoteCandidate > has a lower handicap h (i.e., h new pair. > > > ​Well, as mentioned, the badness of both sides needs to be balanced. A > given candidate pair might be slight better for you but a lot worse for me.​ The minute we start comparing local and remote badness we will go into an arms race. All ICE implementations will become moody teens that find all candidates disgusting except for their favourite ones. I think we really should keep comparisons only for local2local and remote2remote. In other words, the controlling pick their favourite local candidate L1 and pick a pair [L1, R.DECENT] such that R.DECENT is the least crappy handicap that was ever validated against L1. Then they have to continue checks if those checks could lead to validating [L1, R.MIN] where MIN < DECENT > The other thing is that I cannot at all see the value of > the network > ID. Why is this necessary? > > > ​Technically, I could make it a separate draft, but the kind of > go well > together (they both fit in one nice STUN attribute, for example). > > The value of network ID is the following: if the remote side's > network > interface changes, it's wise to notify your bandwidth estimator, > because > the change may have been drastic (wifi to 2g). ​ It could > change either > by TURN mobility, or by continual gathering, or by the use of backup > candidate pairs (I realized the last two are not yet standardized). > > > I am not a huge fan of this. I think it requires the remote side to > know more than it needs to. If you want to reinit your bwe engine > then we should have a message that says that > > > ​It's not as simple as just "reinit the BWE". The BWE wants to know > *why*, and knowing its because the remote network changed is important > information.​ And we can communicate the *why* just as easily. > And the other problem with message sent from the remote side is that the > local/controlling side may switch candidate pairs, and it needs to know > if doing so changes the remote network or not, so it can know if it > should reset or not. If it had to wait for a message from the remote > side, it would have to wait for the remote side to receive a message > from the local side, and then for the remote side to send back a message > saying "by the way, that candidate pair changed my local network", which > just adds an extra round trip for no good reason. True. Before we go on though ... can you think of many cases out there (other than TURN mobility) where a change of interface is not directly visible to the remote end through the change of address? > (and it should probably be in RTCP). > > > ​That's not going to work for data channels, which also use ICE.​ I agree ... although the rest of the BWE communications today don't seem to be bothered by that. > There could be other reasons for this that cannot be directly mapped > to changing interfaces. > > > ​In which case, the BWE would like to know which case it is, because it > might behave differently between them. ​ My point exactly. > An interface ID mainly bothers me as it delivers more knowledge than > one needs > > for that sort of stuff and it encourages implementers to make > assumptions ... and ICE is all about avoiding them. > > > ​It's basically the minimal information to know that the remote network > path is changing between two candidate pairs. And the assumption that > can be made is that if the ID is different, the network is different, > which is exactly the information it is meant to convey. > ​ > > > Emil > > -- > https://jitsi.org > > > I am not sure what the following responds to but still ... :) > ​I mostly disagree here. The controlled side is always at the mercy of > the controlling side, and t > he status-quo is that the controlled side has no way to say anything > about the networks it finds costly/bad. Being able to communicate > 0/max/something-in-between is very useful for the controlled side with > any reasonably implemented controlling side. > > But for the values of things in between 0 and max, I agree. ​The > difference between 100 and 200 are hard to nail down. We tried to nail > it down according to how we think it would be useful, and we realized > two things: > 1. Everyone might not agree with how we were thinking to nail it down. > 2. We might change our minds 6-12 months from now anyway. > > Being able to signal these things is valuable even if we haven't nailed > down what the difference between 100 and 200 means (if we ever nail it > down). So I'd prefer standardizing the signaling of these things > (signaling here includes the STUN attribute) and the range of values, > and then leave the interpretation of the difference of particular values > to implementations or future specs once we have more implementation > experience. There have been other similar discussions on the IETF. One that I can remember happened around Dan's draft for Spam score SIP headers. IIRC, what the authors were suggesting was: we don't know how SPAM scores will be generated, but we want to standardize how it's signalled. There was pretty strong opposition to that. Many people felt that unless you know exactly what the informations means, it is unreasonable to standardize it. I didn't necessarily agree one way or another back then but this does serve as an IETF precedent. I feel it is even more of an argument for ICE. The whole point of standardizing this is so that Chrome can send that information to other ICE implementations and get it back from them. Yet, other ICE implementations would neither know how to handle it nor how to generate it for you unless they know exactly what it means. Emil -- https://jitsi.org From nobody Wed Apr 13 11:18:36 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34B12B029 for ; Wed, 13 Apr 2016 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PQsSuY4x39Dj for ; Wed, 13 Apr 2016 11:18:31 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C7A12DE9D for ; Wed, 13 Apr 2016 11:12:19 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id k1so80732227vkb.0 for ; Wed, 13 Apr 2016 11:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oKXLpg0UGRzzoF1PuA33EXkjNaBRZ7MtGlm0AIktrtw=; b=KrHiKVdzzH0yNMR7kQqhE/1vFlEVcEuokiKOUhoUpZXfbEZjkh9SmsHl39B1dLVZQK kp4smFoqS6FCEvh2lqNrn0D2xyLAe49OTOwD20h2Ak2t5jnTS98LNZcqZL4XsY8mrSAP BW2uCQHB4YBf21DKwSZ5Gq6q1WO1r0BsCNwkI3lJwY42G4VVXm46UqE4GAPLmsRjAW2E cksIZ8O5ih8Kgwwrue3YKXgs6PCH2XvNkXwxAagYwbdv3NhZhn3wwQ2eF8FleYhX6YBj UR3aMZe07PPF6QTVgRrTsOOvYCu+ez+HuuMi7NVDfpOEC5xSHjmphctlP1YnvhC0HEyw odnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oKXLpg0UGRzzoF1PuA33EXkjNaBRZ7MtGlm0AIktrtw=; b=V9BmYHckpnbNs0TxZfJff/UA4Gr3HBpj3Gq8TToYqIpTth7QZZHA8O76vo9vuv6fJ1 epCdR5f//VCddBiwNqwnV/ad7SuJvhpWgNYxS558WJY9C/7I/6lIYsW3dr+U7l9+YbUh QZtGZTusUE4VPebTd6SEl7ggX6QxlYiE9v7EmKu9JG1PHi0jjdJ4AF3x0SsXqbKqc0kf +PO79c4OxUTCOxgOudiHR3I88eoZ8IMo1Z0Hk8cBUwquzhAmrHu8qfmtAHJ4W8Z+QR/B ab79zsurhekW3DSqpe98o5zw9IfQBY6+q2SPve3DerIIZX5/yj0UiYeIn+XMvU0DXFvP t8Ww== X-Gm-Message-State: AOPr4FWLoaqElfBNQDxxypOjLOpUUhagqDytkAGo+cI8fIIvvcrHzaKn5zattVCuljwiCC2yW8vksQzeR4FdQfni X-Received: by 10.31.194.10 with SMTP id s10mr5508960vkf.72.1460571138150; Wed, 13 Apr 2016 11:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.164 with HTTP; Wed, 13 Apr 2016 11:11:38 -0700 (PDT) In-Reply-To: <570DD372.2090203@jitsi.org> References: <57069DE4.1070805@jitsi.org> <5706DBAB.7030703@jitsi.org> <570DD372.2090203@jitsi.org> From: Peter Thatcher Date: Wed, 13 Apr 2016 11:11:38 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a114661dcdc5ec5053061b759 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 18:18:34 -0000 --001a114661dcdc5ec5053061b759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2016 at 10:04 PM, Emil Ivov wrote: > Hey Peter, > > On 12.04.16 =D0=B3. 13:42, Peter Thatcher wrote: > >> >> >> On Thu, Apr 7, 2016 at 3:14 PM, Emil Ivov > > wrote: >> >> On 7.04.16 =D0=B3. 16:27, Peter Thatcher wrote: >> >> On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov > >> >> wrote: >> >> On 21.03.16 =D0=B3. 19:07, Peter Thatcher wrote: >> >> As an author (not a chair), I just submitted a draft >> for an idea I'd >> like to propose for ICE: network cost. >> >> Here's the draft: >> >> https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost= / >> >> >> The idea is basically to allow the controlled side to >> tell the >> controlling side which candidates "cost" more than >> others (such as >> cellular costing more than Wi-Fi). This is different >> than candidate >> priority for reasons explained in the draft. >> >> >> I see the value here but I have a few problems with the >> current state. >> >> To begin with, I find the "cost" name overly confusing. I >> realize >> the draft already says this is not necessarily real cost bu= t >> it >> still leaves people with the wrong impression (and I've >> confirmed >> this in conversations these days). So let's just go for bia= s >> or >> something (I also like fondness). >> >> >> =E2=80=8BThere are two question here: the name and the directio= n. The >> choice >> of direction is more important than the name. I prefer the >> direction >> where 0 means "free/use-freely" and a big number means >> "expensive/restrained/last-resort". This is because if we ever >> expand >> the range, I think it would be better in the direction of "I >> really >> don't want to use this" rather than "this is even more free to >> use". >> You'll note that this direction is the opposite of >> fondness/preference/priority. >> >> In other words, I think modeling this as "badness' is better tha= n >> as >> "goodness". >> >> >> OK, this makes sense. >> >> So if we're going to debate names, let's debate synonyms of >> "badness". >> The best I could come up with is cost. But I'd love to hear >> good synonyms.=E2=80=8B >> >> >> Let's go with "handicap" then? (If not we always have aversion and >> reluctance). >> >> >> =E2=80=8BI'm not a fan of any of those words. I'd prefer "badness" over= those. >> > > And I guess I'd still prefer "handicap" (I can also be talked into > preferring "lousiness" ;) ) > > > "lousiness" is ... lousy :). =E2=80=8BHow about "woe" or "dislike"? Maybe we should just call it "preference" but then only allow negative (or zero) values. The draft is not currently very explicit about exactly how thi= s >> works in the selection of candidates but I assume it >> basically >> means: "if it's all the same to you, I'd much rather you ge= t >> in >> touch with me here than there." >> >> >> Close. 0 means "use this freely". A small number means "I'd >> rather not >> use this". A large number means "Only use this if nothing else >> works".=E2=80=8B >> =E2=80=8B >> >> The trickiest part here is how to assign importance to this >> new bias >> as opposed to existing metrics such as RTT for example. We >> could say >> it's up to implementations or try to come up with some >> recommendation for a formula. >> >> >> =E2=80=8BThat's exactly what I think we should do: standardized = how >> information >> is conveyed from controlled to controlling, but then let the >> controlling >> side decided how to select and nominate.=E2=80=8B >> >> >> The problem here is that unless we give directions about how it >> should be used in practice, then we greatly limit the usefulness and >> interoperability. >> >> >> I actually think we can be very helpful without going into the >> details that much. Like for example: >> >> 0: use freely as you say. >> >> =E2=80=8Bh=E2=80=8B >> >0: you MAY use if no valid pairs exist where the remote candidate >> has a lower handicap but you SHOULD/MUST switch if such a pair >> becomes valid. >> >> >> I think such a rule is too restrictive of cost/badness > 0.Perhaps >> such a rules for cost/badness =3D=3D MAX would make sense. Basically, M= AX >> would mean "last resort". >> > It sounds like the algorithm you have in mind basically cares about three > sets of values: 0, anything, MAX_HANDICAP. If that is the case we might a= s > well go for 0,1 and 2 and not allow other values. > > I personally like the idea of allowing all integers but then that has to > have a meaning in order to be useful. Otherwise it would just sloppy. > =E2=80=8BThat was our original design, but it fails in an important way: if= the controlling side wants to do something more sophisticated, like factor in RTT values into the selection algorithm, it can't do that if the range of values has such low precision. In other words, that might work for now, but it doesn't leave any flexibility for the future.=E2=80=8B > I think we are talking about different things though. My bad(ness). I was > only referring to remote handicap comparison. Here's how the above rule > should look like. > > How about this: > > 0: user freely > h>0: you MAY use if no valid pairs exist *for the same local candidate* > where the remote candidate has a lower handicap but you SHOULD/MUST switc= h > if such a pair becomes valid. =E2=80=8BThat sounds reasonable, except for leaving open the possibility of factoring in things like RTT (which means that SHOULD might be better than MUST). Oh, and instead of keying in on the same local candidate, perhaps just key in on the same local network cost (multiple local candidates might have the same local network cost). =E2=80=8B > > > However, we do need to be careful about the case where there are only >> two candidate pairs available, one of which is (0, MAX) and the other >> (MAX, 0). In other words, either the controlling side or the controlled >> side has to end up using a "last resort". Do we standardize which is >> picked, or leave that up to the controlling side to decide (let it >> decide to be gracious or not). >> > > Agreed. We don't need to stipulate it, but we can say that > (Controlling.0, Controlled.MAX) is the most likely outcome. > > =E2=80=8BI was thinking that if we were to write a SHOULD, it should be (Controlling=3DMAX, Controlled=3D0). In other words, the controlling side SHOULD be gracious.=E2=80=8B > Also, unless your nominated pair has >> pair.remoteCandidate.handicap=3D=3D0, then you MUST continue running >> checks until either you run through all of them or at least one pair >> with zero handicap becomes valid. When that happens you must switch. >> >> =E2=80=8BSo, basically, don't prune less-bad networks just because a mor= e-bad >> network worked first? That seems reasonable. I'm not sure if it's >> MUST-worthy, though. >> > > As a matter of fact I am wondering whether even SHOULD makes sense. It is > very hard to reconcile these things with other constraints such as RTT. I > see no easy way where application developers could know whether an RTT of= 5 > seconds would be preferable to using an LTE interface .. > =E2=80=8B.=E2=80=8B > > You may want to avoid LTE because it would exhaust your 5GB plan (but > you'd still rather not have to suffer through a 5 second RTT) or you may > want to avoid it because you are on roaming in Congo and having an HD cal= l > on it would cost more than your house ... > > So maybe we could write all the rules without any 2119 language. > > =E2=80=8BYeah, now you see where this gets tricky. We want to be able to b= alance against RTT and other metrics, but there's no common unit of network badness that we can use. > And, again, be careful with the "must switch"=E2=80=8B, since you need to >> remember the case where only two candidate pairs exist: (N, 0) and (0, >> N) and the controlling side needs to pick who pays more (and whether to >> be gracious or not). >> > > Yes, rectified the rule above. > > Also if your selected pair has a remoteCandidate with non-zero >> handicap H and another pair becomes valid where the remoteCandidate >> has a lower handicap h (i.e., h> new pair. >> >> >> =E2=80=8BWell, as mentioned, the badness of both sides needs to be balan= ced. A >> given candidate pair might be slight better for you but a lot worse for >> me.=E2=80=8B >> > > The minute we start comparing local and remote badness we will go into an > arms race. All ICE implementations will become moody teens that find all > candidates disgusting except for their favourite ones. I think we really > should keep comparisons only for local2local and remote2remote. > =E2=80=8BIt's not really an arms race, though, because the controlling side= has all the power. The controlling side can always just ignore what the remote side wants. It's more like the controlled side saying what it dislikes least and hopes the controlling side will be nice about it. But I think you are right that whatever rules we right (if any) should be in terms of when the local network cost is fixed/the-same (similar to what you were saying about a fixed local candidate above). > > In other words, the controlling pick their favourite local candidate L1 > and pick a pair [L1, R.DECENT] such that R.DECENT is the least crappy > handicap that was ever validated against L1. Then they have to continue > checks if those checks could lead to validating [L1, R.MIN] where MIN < > DECENT > > The other thing is that I cannot at all see the value of >> the network >> ID. Why is this necessary? >> >> >> =E2=80=8BTechnically, I could make it a separate draft, but the = kind of >> go well >> together (they both fit in one nice STUN attribute, for example)= . >> >> The value of network ID is the following: if the remote side's >> network >> interface changes, it's wise to notify your bandwidth estimator, >> because >> the change may have been drastic (wifi to 2g). =E2=80=8B It cou= ld >> change either >> by TURN mobility, or by continual gathering, or by the use of >> backup >> candidate pairs (I realized the last two are not yet >> standardized). >> >> >> I am not a huge fan of this. I think it requires the remote side to >> know more than it needs to. If you want to reinit your bwe engine >> then we should have a message that says that >> >> >> =E2=80=8BIt's not as simple as just "reinit the BWE". The BWE wants to = know >> *why*, and knowing its because the remote network changed is important >> information.=E2=80=8B >> > > And we can communicate the *why* just as easily. > > And the other problem with message sent from the remote side is that the >> local/controlling side may switch candidate pairs, and it needs to know >> if doing so changes the remote network or not, so it can know if it >> should reset or not. If it had to wait for a message from the remote >> side, it would have to wait for the remote side to receive a message >> from the local side, and then for the remote side to send back a message >> saying "by the way, that candidate pair changed my local network", which >> just adds an extra round trip for no good reason. >> > > True. Before we go on though ... can you think of many cases out there > (other than TURN mobility) where a change of interface is not directly > visible to the remote end through the change of address? =E2=80=8B Yes, continual gathering. If the selected candidate pair is over remote wifi, and then the remote wifi goes away and the remote side gathers a cellular candidate and then starts pinging from it, and it works (hopefully very quickly) the local side needs to know whether the remote side is on a different network interface or not. It's not robust to just assume any new candidate is a different network, because then you may over-react, especially if you get a random peer reflexive candidate. A similar situation comes up with "backup" candidate pairs where if a backup candidate pair is kept alive and then either clients switches to that one, the other side needs to know if that involved a network interface change or not. I realize that neither continual gathering nor backup candidate pairs aren't even proposed yet (but we plan to propose them), which is why I'm using TURN mobility as the example for now. But our real use case is with continual gathering and backup candidate pairs. > > > (and it should probably be in RTCP). >> >> >> =E2=80=8BThat's not going to work for data channels, which also use ICE.= =E2=80=8B >> > > I agree ... although the rest of the BWE communications today don't seem > to be bothered by that. > > =E2=80=8BI think you're overly assuming that everything will be using RTCP.= ICE is useful outside of the context of RTCP.=E2=80=8B > There could be other reasons for this that cannot be directly mapped >> to changing interfaces. >> >> >> =E2=80=8BIn which case, the BWE would like to know which case it is, bec= ause it >> might behave differently between them. =E2=80=8B >> > > My point exactly. > > An interface ID mainly bothers me as it delivers more knowledge than >> one needs >> >> for that sort of stuff and it encourages implementers to make >> assumptions ... and ICE is all about avoiding them. >> >> >> =E2=80=8BIt's basically the minimal information to know that the remote = network >> path is changing between two candidate pairs. And the assumption that >> can be made is that if the ID is different, the network is different, >> which is exactly the information it is meant to convey. >> =E2=80=8B >> >> >> Emil >> >> -- >> https://jitsi.org >> >> >> >> > I am not sure what the following responds to but still ... :) =E2=80=8BMaybe I had some email authoring fail. Sorry about that. =E2=80=8B > > > =E2=80=8BI mostly disagree here. The controlled side is always at the me= rcy of >> the controlling side, and t >> he status-quo is that the controlled side has no way to say anything >> about the networks it finds costly/bad. Being able to communicate >> 0/max/something-in-between is very useful for the controlled side with >> any reasonably implemented controlling side. >> >> But for the values of things in between 0 and max, I agree. =E2=80=8BTh= e >> difference between 100 and 200 are hard to nail down. We tried to nail >> it down according to how we think it would be useful, and we realized >> two things: >> 1. Everyone might not agree with how we were thinking to nail it down. >> 2. We might change our minds 6-12 months from now anyway. >> >> Being able to signal these things is valuable even if we haven't nailed >> down what the difference between 100 and 200 means (if we ever nail it >> down). So I'd prefer standardizing the signaling of these things >> (signaling here includes the STUN attribute) and the range of values, >> and then leave the interpretation of the difference of particular values >> to implementations or future specs once we have more implementation >> experience. >> > > There have been other similar discussions on the IETF. One that I can > remember happened around Dan's draft for Spam score SIP headers. IIRC, wh= at > the authors were suggesting was: we don't know how SPAM scores will be > generated, but we want to standardize how it's signalled. > > There was pretty strong opposition to that. Many people felt that unless > you know exactly what the informations means, it is unreasonable to > standardize it. > > =E2=80=8BThat seems kind of silly to me. If our choices are: A: Standardize all behavior completely. B. Standardize how to exchange information, but not behavior. C. Standardize nothing.=E2=80=8B If A is not possible (and I don't think it is), then our choices are between B and C. And B seems better than C. Otherwise you'll just end up with endpoints using non-standard mechanisms. > I didn't necessarily agree one way or another back then but this does > serve as an IETF precedent. > > I feel it is even more of an argument for ICE. The whole point of > standardizing this is so that Chrome can send that information to other I= CE > implementations and get it back from them. Yet, other ICE implementations > would neither know how to handle it nor how to generate it for you unless > they know exactly what it means. > > =E2=80=8BI think the meaning of "all other things being equal, use this net= work instead of that one" is pretty clear. And a value of 0 meaning "feel free to use this with no restrictions" and a value of max meaning "please don't use this unless your really have to" is all pretty clear. It's just the values in between and their relative weight that don't have clear meaning. But, as I mentioned, we can leave a large range of possibilities for future expansion. =E2=80=8B > Emil > > -- > https://jitsi.org > --001a114661dcdc5ec5053061b759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 12, 2016 at 10:04 PM, Emil Ivov = <emcho@jitsi.org> wrote:
Hey Peter,

On 12.04.16 =D0=B3. 13:42, Peter Thatcher wrote:


On Thu, Apr 7, 2016 at 3:14 PM, Emil Ivov <emcho@jitsi.org
<mailto:emcho@jitsi= .org>> wrote:

=C2=A0 =C2=A0 On 7.04.16 =D0=B3. 16:27, Peter Thatcher wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov <= emcho@jitsi.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 21.03.16 =D0=B3. 19:07, = Peter Thatcher wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As an author = (not a chair), I just submitted a draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for an idea I'd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like to propo= se for ICE: network cost.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here's th= e draft:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The idea is b= asically to allow the controlled side to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tell the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0controlling s= ide which candidates "cost" more than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 others (such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cellular cost= ing more than Wi-Fi).=C2=A0 This is different
=C2=A0 =C2=A0 =C2=A0 =C2=A0 than candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0priority for = reasons explained in the draft.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I see the value here but I = have a few problems with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 current state.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To begin with, I find the &= quot;cost" name overly confusing. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 realize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the draft already says this= is not necessarily real cost but it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0still leaves people with th= e wrong impression (and I've
=C2=A0 =C2=A0 =C2=A0 =C2=A0 confirmed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this in conversations these= days). So let's just go for bias or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something (I also like fond= ness).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8BThere are two question here:=C2=A0 the= name and the direction.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of direction is more important than the name.= =C2=A0 I prefer the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 direction
=C2=A0 =C2=A0 =C2=A0 =C2=A0 where 0 means "free/use-freely" and a= big number means
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "expensive/restrained/last-resort".= =C2=A0 This is because if we ever
=C2=A0 =C2=A0 =C2=A0 =C2=A0 expand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the range, I think it would be better in the di= rection of "I really
=C2=A0 =C2=A0 =C2=A0 =C2=A0 don't want to use this" rather than &q= uot;this is even more free to use".
=C2=A0 =C2=A0 =C2=A0 =C2=A0 You'll note that this direction is the oppo= site of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fondness/preference/priority.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In other words, I think modeling this as "= badness' is better than as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "goodness".


=C2=A0 =C2=A0 OK, this makes sense.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So if we're going to debate names, let'= s debate synonyms of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "badness".
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The best I could come up with is cost.=C2=A0 Bu= t I'd love to hear
=C2=A0 =C2=A0 =C2=A0 =C2=A0 good synonyms.=E2=80=8B


=C2=A0 =C2=A0 Let's go with "handicap" then? (If not we alway= s have aversion and
=C2=A0 =C2=A0 reluctance).


=E2=80=8BI'm not a fan of any of those words.=C2=A0 I'd prefer &quo= t;badness" over those.

And I guess I'd still prefer "handicap" (I can also be talked= into preferring "lousiness" ;) )



"lousiness" is ... lousy :).

=
=E2=80=8BHow about "woe" or "dislike"?

Maybe we should just call it "preference"= ; but then only allow negative (or zero) values.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft is not currently = very explicit about exactly how this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0works in the selection of c= andidates but I assume it basically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0means: "if it's al= l the same to you, I'd much rather you get in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0touch with me here than the= re."


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Close.=C2=A0 0 means "use this freely"= ;.=C2=A0 A small number means "I'd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rather not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use this".=C2=A0 A large number means &quo= t;Only use this if nothing else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 works".=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8B

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The trickiest part here is = how to assign importance to this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new bias
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as opposed to existing metr= ics such as RTT for example. We
=C2=A0 =C2=A0 =C2=A0 =C2=A0 could say
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it's up to implementati= ons or try to come up with some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recommendation for a formul= a.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8BThat's exactly what I think we sho= uld do: standardized how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is conveyed from controlled to controlling, but= then let the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 controlling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 side decided how to select and nominate.=E2=80= =8B


=C2=A0 =C2=A0 The problem here is that unless we give directions about how = it
=C2=A0 =C2=A0 should be used in practice, then we greatly limit the usefuln= ess and
=C2=A0 =C2=A0 interoperability.


=C2=A0 =C2=A0 I actually think we can be very helpful without going into th= e
=C2=A0 =C2=A0 details that much. Like for example:

=C2=A0 =C2=A0 0: use freely as you say.

=C2=A0 =C2=A0 =E2=80=8Bh=E2=80=8B
=C2=A0 =C2=A0 =C2=A0>0: you MAY use if no valid pairs exist where the re= mote candidate
=C2=A0 =C2=A0 has a lower handicap but you SHOULD/MUST switch if such a pai= r
=C2=A0 =C2=A0 becomes valid.


I think such a rule is too restrictive of cost/badness > 0.Perhaps
such a rules for cost/badness =3D=3D MAX would make sense.=C2=A0 Basically,= MAX
would mean "last resort".
It sounds like the algorithm you have in mind basically cares about three s= ets of values: 0, anything, MAX_HANDICAP. If that is the case we might as w= ell go for 0,1 and 2 and not allow other values.

I personally like the idea of allowing all integers but then that has to ha= ve a meaning in order to be useful. Otherwise it would just sloppy.

=E2=80=8BThat was our original design, but = it fails in an important way: if the controlling side wants to do something= more sophisticated, like factor in RTT values into the selection algorithm= , it can't do that if the range of values has such low precision.=C2=A0= In other words, that might work for now, but it doesn't leave any flex= ibility for the future.=E2=80=8B


I think we are talking about different things though. My bad(ness). I was o= nly referring to remote handicap comparison. Here's how the above rule = should look like.

How about this:

0:=C2=A0 =C2=A0user freely
h>0: you MAY use if no valid pairs exist *for the same local candidate* = where the remote candidate has a lower handicap but you SHOULD/MUST switch = if such a pair becomes valid.

=E2=80=8BThat sounds reasonable, except for leaving open the possibili= ty of factoring in things like RTT (which means that SHOULD might be better= than MUST).

Oh, and instead of keying in on the same local candidate, perhap= s just key in on the same local network cost (multiple local candidates mig= ht have the same local network cost).
=E2= =80=8B
=C2=A0

However, we do need to be careful about the case where there are only
two candidate pairs available, one of which is (0, MAX) and the other
(MAX, 0).=C2=A0 In other words, either the controlling side or the controll= ed
side has to end up using a "last resort".=C2=A0 Do we standardize= which is
picked, or leave that up to the controlling side to decide (let it
decide to be gracious or not).

 Agreed. We=C2=A0 don't need to stipulate it, but we can say that (Contr= olling.0, Controlled.MAX) is the most likely outcome.


=E2=80=8BI was thinking that= if we were to write a SHOULD, it should be (Controlling=3DMAX, Controlled= =3D0).=C2=A0 In other words, the controlling side SHOULD be gracious.=E2=80= =8B

=C2=A0
=C2=A0 =C2=A0 Also, unless your nominated pair has
=C2=A0 =C2=A0 pair.remoteCandidate.handicap=3D=3D0, then you MUST continue = running
=C2=A0 =C2=A0 checks until either you run through all of them or at least o= ne pair
=C2=A0 =C2=A0 with zero handicap becomes valid. When that happens you must = switch.

=E2=80=8BSo, basically, don't prune less-bad networks just because a mo= re-bad
network worked first?=C2=A0 That seems reasonable.=C2=A0 I'm not sure i= f it's
MUST-worthy, though.

 As a matter of fact I am wondering whether even SHOULD makes sense. It is v= ery hard to reconcile these things with other constraints such as RTT. I se= e no easy way where application developers could know whether an RTT of 5 s= econds would be preferable to using an LTE interface ..
= =E2=80=8B.=E2=80=8B

You may want to avoid LTE because it would exhaust your 5GB plan (but you&#= 39;d still rather not have to suffer through a 5 second RTT) or you may wan= t to avoid it because you are on roaming in Congo and having an HD call on = it would cost more than your house ...

So maybe we could write all the rules without any 2119 language.


=E2=80=8BYeah, now you see w= here this gets tricky.=C2=A0 We want to be able to balance against RTT and = other metrics, but there's no common unit of network badness that we ca= n use.

=C2=A0
And, again, be careful with the "must switch"=E2=80=8B, since you= need to
remember the case where only two candidate pairs exist: (N, 0) and (0,
N) and the controlling side needs to pick who pays more (and whether to
be gracious or not).

Yes, rectified the rule above.

=C2=A0 =C2=A0 Also if your selected pair has a remoteCandidate with non-zer= o
=C2=A0 =C2=A0 handicap H and another pair becomes valid where the remoteCan= didate
=C2=A0 =C2=A0 has a lower handicap h (i.e., h<H) then you SHOULD switch = to that
=C2=A0 =C2=A0 new pair.


=E2=80=8BWell, as mentioned, the badness of both sides needs to be balanced= .=C2=A0 A
given candidate pair might be slight better for you but a lot worse for me.= =E2=80=8B

 The minute we start comparing local and remote badness we will go into an a= rms race. All ICE implementations will become moody teens that find all can= didates disgusting except for their favourite ones. I think we really shoul= d keep comparisons only for local2local and remote2remote.
=

=E2=80=8BIt's not really an arms race, though, because the control= ling side has all the power.=C2=A0 The controlling side can always just ign= ore what the remote side wants.=C2=A0 It's more like the controlled sid= e saying what it dislikes least and hopes the controlling side will be nice= about it.

But I think you = are right that whatever rules we right (if any) should be in terms of when = the local network cost is fixed/the-same (similar to what you were saying a= bout a fixed local candidate above).

= =C2=A0

In other words, the controlling pick their favourite local candidate L1 and= pick a pair [L1, R.DECENT] such that R.DECENT is the least crappy handicap= that was ever validated against L1. Then they have to continue checks if t= hose checks could lead to validating [L1, R.MIN] where MIN < DECENT

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The other thing is that I c= annot at all see the value of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ID. Why is this necessary?<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8BTechnically, I could make it a separat= e draft, but the kind of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 go well
=C2=A0 =C2=A0 =C2=A0 =C2=A0 together (they both fit in one nice STUN attrib= ute, for example).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The value of network ID is the following:=C2=A0= if the remote side's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interface changes, it's wise to notify your= bandwidth estimator,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 because
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the change may have been drastic (wifi to 2g).= =C2=A0 =E2=80=8B It could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 change either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by TURN mobility, or by continual gathering, or= by the use of backup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate pairs (I realized the last two are no= t yet standardized).


=C2=A0 =C2=A0 I am not a huge fan of this. I think it requires the remote s= ide to
=C2=A0 =C2=A0 know more than it needs to. If you want to reinit your bwe en= gine
=C2=A0 =C2=A0 then we should have a message that says that


=E2=80=8BIt's not as simple as just "reinit the BWE".=C2=A0 T= he BWE wants to know
*why*, and knowing its because the remote network changed is important
information.=E2=80=8B

And we can communicate the *why* just as easily.


And the other problem with message sent from the remote side is that the local/controlling side may switch candidate pairs, and it needs to know
if doing so changes the remote network or not, so it can know if it
should reset or not.=C2=A0 If it had to wait for a message from the remote<= br> side, it would have to wait for the remote side to receive a message
from the local side, and then for the remote side to send back a message saying "by the way, that candidate pair changed my local network"= , which
just adds an extra round trip for no good reason.

 True. Before we go on though ... can you think of many cases out there (oth= er than TURN mobility) where a change of interface is not directly visible = to the remote end through the change of address?
=E2=80= =8B
Yes, continual gathering.=C2=A0 If the selected candi= date pair is over remote wifi, and then the remote wifi goes away and the r= emote side gathers a cellular candidate and then starts pinging from it, an= d it works (hopefully very quickly) the local side needs to know whether th= e remote side is on a different network interface or not.=C2=A0 It's no= t robust to just assume any new candidate is a different network, because t= hen you may over-react, especially if you get a random peer reflexive candi= date.

A similar situation comes up with "backup&q= uot; candidate pairs where if a backup candidate pair is kept alive and the= n either clients switches to that one, the other side needs to know if that= involved a network interface change or not.

I reali= ze that neither continual gathering nor backup candidate pairs aren't e= ven proposed yet (but we plan to propose them), which is why I'm using = TURN mobility as the example for now.=C2=A0 But our real use case is with c= ontinual gathering and backup candidate pairs.


<= /div>
=C2=A0


=C2=A0 =C2=A0 (and it should probably be in RTCP).


=E2=80=8BThat's not going to work for data channels, which also use ICE= .=E2=80=8B

 I agree ... although the rest of the BWE communications today don't see= m to be bothered by that.


=E2=80=8BI think you're = overly assuming that everything will be using RTCP.=C2=A0 ICE is useful out= side of the context of RTCP.=E2=80=8B

=C2=A0
=C2=A0 =C2=A0 There could be other reasons for this that cannot be directly= mapped
=C2=A0 =C2=A0 to changing interfaces.


=E2=80=8BIn which case, the BWE would like to know which case it is, becaus= e it
might behave differently between them. =E2=80=8B

 My point exactly.

=C2=A0 =C2=A0 An interface ID mainly bothers me as it delivers more knowled= ge than
=C2=A0 =C2=A0 one needs

=C2=A0 =C2=A0 for that sort of stuff and it encourages implementers to make=
=C2=A0 =C2=A0 assumptions ... and ICE is all about avoiding them.


=E2=80=8BIt's basically the minimal information to know that the remote= network
path is changing between two candidate pairs.=C2=A0 And the assumption that=
can be made is that if the ID is different, the network is different,
which is exactly the information it is meant to convey.
=E2=80=8B


=C2=A0 =C2=A0 Emil

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 https://jitsi.org




 I am not sure what the following responds to but still ... :)
<= div>
=E2=80=8BMaybe I had some email author= ing fail.=C2=A0 Sorry about that.
=E2=80= =8B
=C2=A0


=E2=80=8BI mostly disagree here.=C2=A0 The controlled side is always at the= mercy of
the controlling side, and t
he status-quo is that the controlled side has no way to say anything
about the networks it finds costly/bad.=C2=A0 Being able to communicate
0/max/something-in-between is very useful for the controlled side with
any reasonably implemented controlling side.

But for the values of things in between 0 and max, I agree.=C2=A0 =E2=80=8B= The
difference between 100 and 200 are hard to nail down.=C2=A0 We tried to nai= l
it down according to how we think it would be useful, and we realized
two things:
1.=C2=A0 Everyone might not agree with how we were thinking to nail it down= .
2.=C2=A0 We might change our minds 6-12 months from now anyway.

Being able to signal these things is valuable even if we haven't nailed=
down what the difference between 100 and 200 means (if we ever nail it
down).=C2=A0 So I'd prefer standardizing the signaling of these things<= br> (signaling here includes the STUN attribute) and the range of values,
and then leave the interpretation of the difference of particular values to implementations or future specs once we have more implementation
experience.

 There have been other similar discussions on the IETF. One that I can remem= ber happened around Dan's draft for Spam score SIP headers. IIRC, what = the authors were suggesting was: we don't know how SPAM scores will be = generated, but we want to standardize how it's signalled.

There was pretty strong opposition to that. Many people felt that unless yo= u know exactly what the informations means, it is unreasonable to standardi= ze it.


=E2=80=8BThat seems kind of silly t= o me.=C2=A0 If our choices are:

A: =C2=A0Standardize a= ll behavior completely.
B.=C2=A0 Standardize how to exchange inform= ation, but not behavior.=C2=A0
C.=C2=A0 Standardize nothing.=E2=80= =8B

If A is not possible (and I don't think it is)= , then our choices are between B and C.=C2=A0 And B seems better than C.=C2= =A0 Otherwise you'll just end up with endpoints using non-standard mech= anisms.

=C2=A0
I didn't necessarily agree one way or another back then but this does s= erve as an IETF precedent.

I feel it is even more of an argument for ICE. The whole point of standardi= zing this is so that Chrome can send that information to other ICE implemen= tations and get it back from them. Yet, other ICE implementations would nei= ther know how to handle it nor how to generate it for you unless they know = exactly what it means.


=E2=80=8BI think the meaning of= "all other things being equal, use this network instead of that one&q= uot; is pretty clear.=C2=A0 And a value of 0 meaning "feel free to use= this with no restrictions" and a value of max meaning "please do= n't use this unless your really have to" is all pretty clear.=C2= =A0 It's just the values in between and their relative weight that don&= #39;t have clear meaning.=C2=A0 But, as I mentioned, we can leave a large r= ange of possibilities for future expansion. =C2=A0

=E2= =80=8B


=C2=A0
Emil

--
https://= jitsi.org

--001a114661dcdc5ec5053061b759-- From nobody Mon Apr 18 04:08:45 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F2112D916 for ; Mon, 18 Apr 2016 04:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AtZA7tct75qt for ; Mon, 18 Apr 2016 04:08:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECFC12D578 for ; Mon, 18 Apr 2016 04:08:42 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-84-5714c0372138 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.36.16963.730C4175; Mon, 18 Apr 2016 13:08:39 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.99]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 13:08:36 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: ICE WG Thread-Topic: Draft ICE WG meeting minutes from IETF 95 Thread-Index: AQHRmWKm/paZhj0ESka+ZXvD+Ku8NA== Date: Mon, 18 Apr 2016 11:08:35 +0000 Message-ID: <371E75CF-DA0E-42D6-86BC-1B72C7E2B291@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9D191DF0A1E47544B70E87D9263E7DA4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbE9XNf8gEi4wc0pehbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlzO99xVbQyFTxsG0LSwPjWcYuRk4OCQETibPn Z7FB2GISF+6tB7K5OIQEjjBK7Pl2lBXCWcwosetINztIFZuAvcTkNR/BukUEJCVa/mxkBbGZ BTQl7p9cCFYjLGAkcX/DHnaIGnOJ/YeWMUPYehJPn1xjAbFZBFQlmpZuAprDwcELNHPfqgiQ MCPQEd9PrWGCGCkucevJfCaI4wQkluw5zwxhi0q8fPyPFcJWklh7eDsLRL2exI2pU9ggbGuJ Y786oWxtiWULX4P18goISpyc+YRlAqPoLCQrZiFpn4WkfRaS9llI2hcwsq5iFC1OLS7OTTcy 0kstykwuLs7P08tLLdnECIydg1t+W+1gPPjc8RCjAAejEg9vArtIuBBrYllxZe4hRgkOZiUR 3t+7gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5cyL/hQkJpCeWpGanphakFsFkmTg4pRoY/TKW 7A6/zCgVOoFV+4GJWe2i3MUpSe2Knb2CskcZzy3wCUzP8Ji+W+p82uay+f/qextq9HJY9IqU Jdh1ntm9izwZ9Cbv2gHDXXuVz7Gzrd9vc0PeMmD1/oVp0u2hfU832IWZbmP87rtueVV0dtLX vh6RZ/IlFryyi6ZZZ4ebcrzM+9h5NEWJpTgj0VCLuag4EQBt1faemQIAAA== Archived-At: Cc: Peter Thatcher Subject: [Ice] Draft ICE WG meeting minutes from IETF 95 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 11:08:44 -0000 WG, The draft meeting minutes from the IETF 95 ICE meeting are now available: https://www.ietf.org/proceedings/95/minutes/minutes-95-ice Please review the minutes and let us know if you have any questions or comm= ents. Thanks, Ari & Peter From nobody Mon Apr 18 04:25:44 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5912D6DA for ; Mon, 18 Apr 2016 04:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YZ6453TjeeJ0 for ; Mon, 18 Apr 2016 04:25:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFF412D6BA for ; Mon, 18 Apr 2016 04:25:42 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-3c-5714c434ca93 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.67.26920.434C4175; Mon, 18 Apr 2016 13:25:40 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.99]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 13:25:39 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: ICE WG Thread-Topic: Confirming consensus on ICE-bis IETF 95 open issues Thread-Index: AQHRmWUIhvYJ6UR8XkG50p59wq70tA== Date: Mon, 18 Apr 2016 11:25:38 +0000 Message-ID: <0F1A7A96-C4A7-46EC-97C7-07C95514FE10@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <6D9A4E584DCA514B835F0BE1FBE788E3@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9StfkiEi4wb51NhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlNGzoYyw4wF+xoNGsgbGHv4uRk0NCwETiQ1sj K4QtJnHh3nq2LkYuDiGBI4wSP2Y+YIdwFjNKTFz2nxGkik3AVuJJ6z6wDhEBSYmWPxvBbGYB TYn7Jxeyg9jCQDWtG9dB1ThJnF/Vxwxh60mcmfYLzGYRUJWY+nIvWA2vgL3EuW0PmEBsRqAr vp9awwQxU1zi1pP5TBDXCUgs2XOeGcIWlXj5+B/U1UoSK7ZfArqNA+yG9bv0IUxriWtLjCCm KEpM6X7IDrFJUOLkzCcsExhFZyFZMAuheRZC8ywkzbOQNC9gZF3FKFqcWlycm25krJdalJlc XJyfp5eXWrKJERgzB7f81t3BuPq14yFGAQ5GJR7eBHaRcCHWxLLiytxDjBIczEoivL93AYV4 UxIrq1KL8uOLSnNSiw8xSnOwKInz5kT+CxMSSE8sSc1OTS1ILYLJMnFwSjUw5rJw39miunPH yccmikWKn3bOFxV4cGhF9KVdNZdXu7y8Z5drZeR1OWo6j/Whx685/lhe6H8ibtdVN/3kK6+H 2vHc+3309JJmTOr4//ffQVXZHFubF9G/T4vwH3/5oPrugcucnLynBTsqZkhPmbdB4M6HLeq/ P3xnzpqnsnv6mRUbs1RU+V1/1yixFGckGmoxFxUnAgBNDBzXlQIAAA== Archived-At: Cc: Peter Thatcher Subject: [Ice] Confirming consensus on ICE-bis IETF 95 open issues X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 11:25:44 -0000 V0csDQoNCkF0IHRoZSBJRVRGIDk1IG1lZXRpbmcgd2UgcmVhY2hlZCB0aGUgZm9sbG93aW5nIGNv bmNsdXNpb25zIHJlZ2FyZGluZyBJQ0ViaXMgKGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtaWNlLTQucGRmKS4gVGhlIHB1cnBvc2Ugb2YgdGhpcyBl LW1haWwgaXMgdG8gdmVyaWZ5IGNvbnNlbnN1cyBvbiB0aGUgbGlzdC4gSWYgeW91IGhhdmUgYW55 IHF1ZXN0aW9ucyBvciBjb21tZW50cywgcGxlYXNlIGNvbW1lbnQgb24gdGhlIGxpc3QgYXMgc29v biBhcyBwb3NzaWJsZS4NCg0KDQpLZWVwLWFsaXZlcyAoc2xpZGUgIzMpDQotIEFncmVlZCB0byBy ZW1vdmUgYWxsIHRleHQgdGFsa2luZyBhYm91dCBrZWVwLWFsaXZlcyB3aGVuIHRoZSByZW1vdGUg cGVlciBkb2VzIG5vdCBzdXBwb3J0IElDRS4gVGhhdCBpbmNsdWRlcyByZW1vdmluZyB0aGUgcmVm ZXJlbmNlIHRvIGRyYWZ0LWlldGYtYXZ0LXJ0cC1uby1vcC4NCg0KDQpDb25uZWN0aXZpdHkgY2hl Y2sgcGFjaW5nIChzbGlkZSAjNCkNCkFncmVlZCB0bzoNCi0gU3BlY2lmeSA1bXMgYXMgdGhlIG1p biBUYSB2YWx1ZS4NCi0gU3BlY2lmeSB0aGF0IGVuZHBvaW50cyBTSE9VTEQgdXNlIDUwbXMgZGVm YXVsdCBUYSB2YWx1ZS4NCi0gUmVtb3ZlIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIFJUUCBhbmQg bm9uLVJUUC4gRW5kcG9pbnRzIGFyZSBzdGlsbCBhbGxvd2VkIHRvIHVzZSBkaWZmZXJlbnQgdmFs dWVzIGUuZy4gZm9yIGxvdyBiYW5kd2lkdGggcHJvdG9jb2xzLg0KDQpUaGUgYWdyZWVkIFRhIHZh bHVlcyBjYW4gYmUgY2hhbmdlZCBpZiBuZXcgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgYmVmb3Jl IHRoZSBwdWJsaWNhdGlvbiByZXF1ZXN0IGlzIGRvbmUuDQoNCiANCkFnZ3Jlc3NpdmUgbm9taW5h dGlvbiAoc2xpZGUgIzUtNikNCi0gSXQgd2FzIGFncmVlZCB0byBhZG9wdCBib3RoIGFsdGVybmF0 aXZlcyBwcmVzZW50ZWQgaW4gdGhlIHNsaWRlczoNCiAgLSBFbmRwb2ludHMgTVVTVCBvbmx5IG5v bWluYXRlIG9uZSBjYW5kaWRhdGUgcGFpciwgYnV0IE1VU1QgYmUgYWJsZSB0byByZWNlaXZlIG11 bHRpcGxlIG5vbWluYXRpb25zIGluIHdoaWNoIGNhc2UgdGhlIGNhbmRpZGF0ZSBwYWlyIHdpdGgg dGhlIGhpZ2hlc3QgcHJpb3JpdHkgTVVTVCBiZSB1c2VkLg0KICAtIEVuZHBvaW50cyB3aWxsIGlu Y2x1ZGUgYSBuZXcgaWNlLW9wdGlvbiwgaW5kaWNhdGluZyB0aGF0IGFnZ3Jlc3NpdmUgbm9taW5h dGlvbiBpcyBub3Qgc3VwcG9ydGVkLiBUaGUgbmVlZCB0byBiZSBhYmxlIHRvIHJlY2VpdmUgbXVs dGlwbGUgbm9taW5hdGlvbnMgKHNlZSBhYm92ZSkgaXMgdG8gYmUgYWJsZSB0byBoYW5kbGUgcmVt b3RlIHBlZXJzIHRoYXQgZG9u4oCZdCBwcm9jZXNzIGljZS1vcHRpb25zIHByb3Blcmx5Lg0KIA0K IA0KQ2hlZXJzLA0KQXJpICYgUGV0ZXI= From nobody Mon Apr 18 23:36:32 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C20112E12C; Mon, 18 Apr 2016 23:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no 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 rWe8ZjWOuv7j; Mon, 18 Apr 2016 23:36:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E4712DEF3; Mon, 18 Apr 2016 23:36:26 -0700 (PDT) Received: from [10.0.1.16] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3J6aPmO002245 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2016 01:36:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.16] From: "Ben Campbell" To: draft-ietf-ice-dualstack-fairness.all@ietf.org, ice@ietf.org Date: Tue, 19 Apr 2016 01:36:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 06:36:31 -0000 Hi, This is my AD Evaluation of draft-ietf-ice-dualstack-fairness-02. I find the draft readable and understandable, but I have some comments and questions. I'd like to resolve the major comments prior to IETF last call. Major: The draft is now informational, but the milestone is for PS. I see the minutes from Prague say the wg agreed to make the change, but that doesn't say why, and I failed to find any discussion of that on the list. Can anyone remind me of the reasoning? (This interacts with my next comment...) I am confused about the relationships among this draft, RFC 5245, 5245bis, and RFC 6724. Section 1 of this draft seems to say that it recommends against following the requirement in 5245 that says dual stack hosts SHOULD follow the precedence in 6724. Normally, that would require this draft to update 5245, which would require it to be standards track. But on the other hand, I am not entirely convinced anything here really changes that SHOULD, since 6724 explicitly says: "The selection rules specified in this document MUST NOT be construed to override an application or upper layer’s explicit choice of a legal destination or source address." Unfortunately, I think this puts things in a grey area, due to ambiguous wording in 5245. So I think this draft either needs to update 5245, or it needs to explain why the guidance here does not conflict with that SHOULD. And in either case: Is there an opportunity to make 5245 more clear in 5245bis? That of course leads to the bombshell question: We are already in the process of updating 5245. Why isn't _this_ draft part of 5245bis? Minor: - 1: The introduction jumps right to saying applications need to deprioritize interfaces without saying what problem it's trying to solve. An initial paragraph that says what goes wrong with current implementations would be extremely helpful. It would also help to define what is meant by "fairness" in this context. (I'm not sure it's quite the same as the conventional use of the term.) - 2: Assuming this stays informational, it's not really using the 2119 keywords quite in the spirit of 2119. Personally, I don't think the current 2119 usage (outside of text directly attributed to other documents, which doesn't really count) adds much. I suggest removing it. But if people are really attached to using 2119 language here, please consider adjusting the boilerplate to say that, while this draft does not include normative requirements, the keywords are used for the sake of clarity. -3, 2nd paragraph: Does the working group believe that one can make reasonable inferences from just the network type? Do you expect these to be configurable? Statically defined in code? (Seems like there may be operational considerations here.) - 7.2: Can this be more specific about what implementations exist? The boilerplate seems a bit heaviweight for something that pretty much says "there are others" :-) Editorial: - 4 , first paragraph: How long is long? (Especially if you stick the 2119 SHOULD). - 5, last paragraph: Doesn't this belong in the "Implementation Status" section? - 7.1 and 7.2 titles: s/Starck/Stack - 7.1, "Level of Maturity": Are there words missing around "Tests"? From nobody Tue Apr 19 04:37:21 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611BC12EDBE; Tue, 19 Apr 2016 04:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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=-0.996, 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 Ko1HEfn3u-ET; Tue, 19 Apr 2016 04:37:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980A312EDBF; Tue, 19 Apr 2016 04:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29950; q=dns/txt; s=iport; t=1461065837; x=1462275437; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZXGYHWIyMUNvz2qIoZO3MMwcEakDAB23Txvj00lHKx4=; b=St6AubiXzy6YH19BdOAx62Bnv6eBYjWkCzi1I8vhBhDj5BHjiA9w+1jg hgpaIrH3hAGXN/95HNb6ikMlQSUQWMs58D+FTJ7E66paUZIpvdpSaEbV0 cop+oAee+C2T+Gilhdiwtudl0HPms3e8BkL8/WeRnlOfURvF7CWmTUtgh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgBDFxZX/4sNJK1dgzhTfQa6FQENg?= =?us-ascii?q?XEkhWoCHIEoOBQBAQEBAQEBZSeEQgEBBCNPBxACAQYCPwMCAgIwFBECBA4FCRK?= =?us-ascii?q?IDg6OI50XkXwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdQiCToc/K4IrBYdxh?= =?us-ascii?q?xSEBhOEcAGGaIcpgWaEToMpeoQ5hiOJBwEeAQFCggQagUpsAYgUfgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,506,1454976000"; d="scan'208,217"; a="93390527" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2016 11:37:16 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3JBbFnD021859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 11:37:16 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 07:37:15 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Tue, 19 Apr 2016 07:37:15 -0400 From: "Pal Martinsen (palmarti)" To: Ben Campbell Thread-Topic: AD Evaluation of draft-ietf-ice-dualstack-fairness-02 Thread-Index: AQHRmgXS7VKNGBrK2EGvlNTtCBMZmp+RbqUA Date: Tue, 19 Apr 2016 11:37:15 +0000 Message-ID: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.70.5] Content-Type: multipart/alternative; boundary="_000_86559E6764124971AB746680D079CAC8ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ice-dualstack-fairness.all@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:37:20 -0000 --_000_86559E6764124971AB746680D079CAC8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxOSBBcHIgMjAxNiwgYXQgMDg6MzYsIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29t PG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PiB3cm90ZToNCg0KSGksDQoNClRoaXMgaXMgbXkgQUQg RXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLWljZS1kdWFsc3RhY2stZmFpcm5lc3MtMDIuIEkgZmlu ZCB0aGUgZHJhZnQgcmVhZGFibGUgYW5kIHVuZGVyc3RhbmRhYmxlLCBidXQgSSBoYXZlIHNvbWUg Y29tbWVudHMgYW5kIHF1ZXN0aW9ucy4gSSdkIGxpa2UgdG8gcmVzb2x2ZSB0aGUgbWFqb3IgY29t bWVudHMgcHJpb3IgdG8gSUVURiBsYXN0IGNhbGwuDQoNCk1ham9yOg0KDQpUaGUgZHJhZnQgaXMg bm93IGluZm9ybWF0aW9uYWwsIGJ1dCB0aGUgbWlsZXN0b25lIGlzIGZvciBQUy4gSSBzZWUgdGhl IG1pbnV0ZXMgZnJvbSBQcmFndWUgc2F5IHRoZSB3ZyBhZ3JlZWQgdG8gbWFrZSB0aGUgY2hhbmdl LCBidXQgdGhhdCBkb2Vzbid0IHNheSB3aHksIGFuZCBJIGZhaWxlZCB0byBmaW5kIGFueSBkaXNj dXNzaW9uIG9mIHRoYXQgb24gdGhlIGxpc3QuIENhbiBhbnlvbmUgcmVtaW5kIG1lIG9mIHRoZSBy ZWFzb25pbmc/IChUaGlzIGludGVyYWN0cyB3aXRoIG15IG5leHQgY29tbWVudOKApikNCg0KSnVz dCBmb3IgY2xhcml0eSBJIHdpbGwgc3VtbWFyaXNlIHdoYXQgSSBzZWUgYXMgdGhlIGtleSDigJxl dmVudHPigJ0gb2YgdGhlIGRyYWZ0LiAoSSBtaWdodCBiZSB3cm9uZyBzbyBvZiBvdGhlcnMgc2Vl IGl0IGRpZmZlcmVudGx5IHBsZWFzZSBjb3JyZWN0IG1lKQ0KDQotIFN0YXJ0ZWQgYXMgYW4gRHVh bFN0YWNrIEhhcHB5IEV5ZWJhbGxzIHNvbHV0aW9uIHRoYXQgd291bGQgZ2l2ZSBJUHY2IGEgaGVh ZCBzdGFydC4NCi0gU2V2ZXJhbCBhdHRlbXB0cyB0byBnZXQgYSBoYXBweSBleWViYWxscyBhbGdv cml0aG0gd29ya2luZyBmYWlsZWQuIEFuZCB3ZSBkaXNjb3ZlcmVkIHRoYXQgaXQgd291bGQgYmUg dmVyeSBkaWZmaWN1bHQgdG8gZ2V0IHJpZ2h0IGluIGFsbCB0aGUgdmFyaW91cyBzY2VuYXJpb3Mu IFRoaW5rIHRoZSDigJxjb25zZW5zdXMgaW4gdGhlIGhhbGx3YXlz4oCdIHdhcyB0byBsZXQgZWFj aCBhcHBsaWNhdGlvbiBkZWFsIHdpdGggaXQgYXMgdGhleSB3b3VsZCBrbm93IG1vcmUgb2Ygd2hh dCB3YXMgaW1wb3J0YW50IHRvIHRoZW0uDQooaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy85Mi9taW51dGVzL21pbnV0ZXMtOTItbW11c2ljI2gudjBqdHd1NXJlOTBmKQ0KPGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvbWludXRlcy9taW51dGVzLTkyLW1tdXNpYyNoLnYw anR3dTVyZTkwZj4tIFNpbmNlIHRoZSBkcmFmdCBvbmx5IGNvbnRhaW5zIGd1aWRlbGluZXMgb24g aG93IGFuIGFwcGxpY2F0aW9uIHNob3VsZCBkZWFsIHdpdGggZHVhbC1zdGFjayBpdCBtYWRlIHNl bnNlIHRvIG1ha2UgaXQgaW5mb3JtYXRpb25hbC4NCihodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzkzL21pbnV0ZXMvbWludXRlcy05My1tbXVzaWMjaC4zNGlseDN5NHZrYmQpDQoNCg0K DQpJIGFtIGNvbmZ1c2VkIGFib3V0IHRoZSByZWxhdGlvbnNoaXBzIGFtb25nIHRoaXMgZHJhZnQs IFJGQyA1MjQ1LCA1MjQ1YmlzLCBhbmQgUkZDIDY3MjQuIFNlY3Rpb24gMSBvZiB0aGlzIGRyYWZ0 IHNlZW1zIHRvIHNheSB0aGF0IGl0IHJlY29tbWVuZHMgYWdhaW5zdCBmb2xsb3dpbmcgdGhlIHJl cXVpcmVtZW50IGluIDUyNDUgdGhhdCBzYXlzIGR1YWwgc3RhY2sgaG9zdHMgU0hPVUxEIGZvbGxv dyB0aGUgcHJlY2VkZW5jZSBpbiA2NzI0LiBOb3JtYWxseSwgdGhhdCB3b3VsZCByZXF1aXJlIHRo aXMgZHJhZnQgdG8gdXBkYXRlIDUyNDUsIHdoaWNoIHdvdWxkIHJlcXVpcmUgaXQgdG8gYmUgc3Rh bmRhcmRzIHRyYWNrLg0KDQpCdXQgb24gdGhlIG90aGVyIGhhbmQsIEkgYW0gbm90IGVudGlyZWx5 IGNvbnZpbmNlZCBhbnl0aGluZyBoZXJlIHJlYWxseSBjaGFuZ2VzIHRoYXQgU0hPVUxELCBzaW5j ZSA2NzI0IGV4cGxpY2l0bHkgc2F5czoNCg0KICJUaGUgc2VsZWN0aW9uIHJ1bGVzIHNwZWNpZmll ZCBpbiB0aGlzIGRvY3VtZW50IE1VU1QgTk9UIGJlIGNvbnN0cnVlZA0KICB0byBvdmVycmlkZSBh biBhcHBsaWNhdGlvbiBvciB1cHBlciBsYXllcuKAmXMgZXhwbGljaXQgY2hvaWNlIG9mIGENCiAg bGVnYWwgZGVzdGluYXRpb24gb3Igc291cmNlIGFkZHJlc3MuIg0KDQpVbmZvcnR1bmF0ZWx5LCBJ IHRoaW5rIHRoaXMgcHV0cyB0aGluZ3MgaW4gYSBncmV5IGFyZWEsIGR1ZSB0byBhbWJpZ3VvdXMg d29yZGluZyBpbiA1MjQ1LiBTbyBJIHRoaW5rIHRoaXMgZHJhZnQgZWl0aGVyIG5lZWRzIHRvIHVw ZGF0ZSA1MjQ1LCBvciBpdCBuZWVkcyB0byBleHBsYWluIHdoeSB0aGUgZ3VpZGFuY2UgaGVyZSBk b2VzIG5vdCBjb25mbGljdCB3aXRoIHRoYXQgU0hPVUxELg0KDQpUaGlzIHdhcyBhdCBsZWFzdCBk aXNjdXNzZWQgaW4gSUVURjkwLCBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkwL21p bnV0ZXMvbWludXRlcy05MC1tbXVzaWMjaC42ZmlqZHB2ZWFuYWENCg0KU28gbm93IG15IG5haXZl IHF1ZXN0aW9uIGlzOyBkbyB3ZSBjYXJlIGFib3V0IDUyNDUgd2l0aCA1MjQ1YmlzIHNvb24gZmlu aXNoZWQ/DQoNCkkgdGhpbmsgd2UgaGF2ZSB0d28gcG9zc2libGUgc29sdXRpb25zLg0KDQoxLiBN YWtlIGR1YWwtc3RhY2sgZmFpcm5lc3MgcmVmZXJlbmNlIG9ubHkgNTI0NWJpcy4gTWFrZSBzdXJl IHRleHQgaW4gYm90aCBkcmFmdCBoYXJtb25pc2UuIFRoZXkgd2lsbCBjcm9zcyByZWZlcmVuY2Ug ZWFjaCBvdGhlciBhbmQgdGh1cyBuZWVkcyB0byBiZSBwdWJsaXNoZWQgYXQgdGhlIHNhbWUgdGlt ZT8NCg0KMi4gRXhwbGFpbiB3aHkgd2UgYXJlIG5vdCBicmFraW5nIHRoZSA1MjQ1IFNIT1VMRCBh bmQga2VlcCBpdCBhcyBpbmZvcm1hdGlvbmFsIC4gVGhpcyBpcyBkb25lIGJ5IHBvaW50aW5nIG91 dCB0aGUgYXBwcm9wcmlhdGUgdGV4dCB5b3UgZm91bmQgaW4gNjcyNC4NCg0KQW5kIGluIGVpdGhl ciBjYXNlOiBJcyB0aGVyZSBhbiBvcHBvcnR1bml0eSB0byBtYWtlIDUyNDUgbW9yZSBjbGVhciBp biA1MjQ1YmlzPw0KDQoNCkFic29sdXRlbHkuIEl0IG11c3QgYWxzbyBwb2ludCBvdXQgdGhhdCB0 aGUgZm9ybXVsYXMgZGVzY3JpYmVkIGluIDUyNDUgc2VjdGlvbiA0LjEuMiBoYXZlIG5vdCBjaGFu Z2VzIHNvIHRoYXQgdGhlIGNvbXBhdGliaWxpdHkgZGlzY3Vzc2lvbiBpbiBzZWN0aW9uIDUgb2Yg dGhlIGR1YWwtc3RhY2sgZmFpcm5lc3MgZHJhZnQgaXMgc3RpbGwgdmFsaWQuDQoNCg0KVGhhdCBv ZiBjb3Vyc2UgbGVhZHMgdG8gdGhlIGJvbWJzaGVsbCBxdWVzdGlvbjogV2UgYXJlIGFscmVhZHkg aW4gdGhlIHByb2Nlc3Mgb2YgdXBkYXRpbmcgNTI0NS4gV2h5IGlzbuKAmXQgX3RoaXNfIGRyYWZ0 IHBhcnQgb2YgNTI0NWJpcz8NCg0KSSB0aGluayB0aGUgbWFpbiBtb3RpdmF0aW9uIGZvciB0aGF0 IHdhcyB0byBrZWVwIHRoZSBJQ0ViaXMgc3BlYyBhcyBzaG9ydCBhcyBwb3NzaWJsZSBhcyB0aGVy ZSBhcmUgc29tZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb2VzIG5vdCBjYXJlIGFib3V0IHRoZSBw cm9ibGVtLiBGb3IgdGhlIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIGNhcmUsIHRoZXkgc2hvdWxk IHJlYWQgdGhlIGRyYWZ0IGFuZCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9ucy4NCg0KTWlub3I6 DQoNCi0gMTogVGhlIGludHJvZHVjdGlvbiBqdW1wcyByaWdodCB0byBzYXlpbmcgYXBwbGljYXRp b25zIG5lZWQgdG8gZGVwcmlvcml0aXplIGludGVyZmFjZXMgd2l0aG91dCBzYXlpbmcgd2hhdCBw cm9ibGVtIGl0J3MgdHJ5aW5nIHRvIHNvbHZlLiBBbiBpbml0aWFsIHBhcmFncmFwaCB0aGF0IHNh eXMgd2hhdCBnb2VzIHdyb25nIHdpdGggY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUg ZXh0cmVtZWx5IGhlbHBmdWwuIEl0IHdvdWxkIGFsc28gaGVscCB0byBkZWZpbmUgd2hhdCBpcyBt ZWFudCBieSAiZmFpcm5lc3MiIGluIHRoaXMgY29udGV4dC4gKEnigJltIG5vdCBzdXJlIGl0J3Mg cXVpdGUgdGhlIHNhbWUgYXMgdGhlIGNvbnZlbnRpb25hbCB1c2Ugb2YgdGhlIHRlcm0uKQ0KDQpI b3cgYWJvdXQ6DQoNCiAgIEluIG11bHRpaG9tZWQgYW5kIElQdjQvSVB2NiBkdWFsLXN0YWNrIGVu dmlyb25tZW50cyBJQ0UgW1JGQzUyNDVdDQogICB3b3VsZCBiZW5lZml0IGJ5IGEgZmFpciBkaXN0 cmlidXRpb24gb2YgaXRzIGNvbm5lY3Rpdml0eSBjaGVja3MNCiAgIGFjcm9zcyBhdmFpbGFibGUg aW50ZXJmYWNlcyBvciBJUCBhZGRyZXNzIHR5cGVzLiAgV2l0aCBhIGZhaXINCiAgIGRpc3RyaWJ1 dGlvbiBvZiB0aGUgY29ubmVjdGl2aXR5IGNoZWNrcywgZXhjZXNzaXZlIGRlbGF5cyBhcmUgYXZv aWRlZA0KICAgaWYgYSBwYXJ0aWN1bGFyIG5ldHdvcmsgcGF0aCBpcyBicm9rZW4gb3Igc2xvdy4g IEl0IHdvdWxkIGFyZ3VhYmxlIGJlDQogICBiZXR0ZXIgdG8gcHV0IHRoZSBpbnRlcmZhY2VzIG9y IGFkZHJlc3MgdHlwZXMga25vdyB0byB0aGUgYXBwbGljYXRpb24NCiAgIGxhc3QgaW4gdGhlIGNo ZWNrbGlzdC4gIEhvd2V2ZXIsIHRoZSBtYWluIG1vdGl2YXRpb24gYnkgSUNFIGlzIHRvDQogICBt YWtlIG5vIGFzc3VtcHRpb25zIHJlZ2FyZGluZyBuZXR3b3JrIHRvcG9sb2d5LCBoZW5jZSBhIGZh aXINCiAgIGRpc3RyaWJ1dGlvbiBvZiB0aGUgY29ubmVjdGl2aXR5IGNoZWNrcyBpcyBtb3JlIGFw cHJvcHJpYXRlLiAgSWYgYW4NCiAgIGFwcGxpY2F0aW9uIG9wZXJhdGVzIGluIGEgd2VsbC1rbm93 biBlbnZpcm9ubWVudCBpcyBjYW4gc2FmZWx5DQogICBvdmVycmlkZSB0aGUgcmVjb21tZW5kYXRp b24gZ2l2ZW4gaW4gdGhpcyBkb2N1bWVudC4NCg0KDQotIDI6IEFzc3VtaW5nIHRoaXMgc3RheXMg aW5mb3JtYXRpb25hbCwgaXQncyBub3QgcmVhbGx5IHVzaW5nIHRoZSAyMTE5IGtleXdvcmRzIHF1 aXRlIGluIHRoZSBzcGlyaXQgb2YgMjExOS4gUGVyc29uYWxseSwgSSBkb24ndCB0aGluayB0aGUg Y3VycmVudCAyMTE5IHVzYWdlIChvdXRzaWRlIG9mIHRleHQgZGlyZWN0bHkgYXR0cmlidXRlZCB0 byBvdGhlciBkb2N1bWVudHMsIHdoaWNoIGRvZXNuJ3QgcmVhbGx5IGNvdW50KSBhZGRzIG11Y2gu IEkgc3VnZ2VzdCByZW1vdmluZyBpdC4NCg0KQnV0IGlmIHBlb3BsZSBhcmUgcmVhbGx5IGF0dGFj aGVkIHRvIHVzaW5nIDIxMTkgbGFuZ3VhZ2UgaGVyZSwgcGxlYXNlIGNvbnNpZGVyIGFkanVzdGlu ZyB0aGUgYm9pbGVycGxhdGUgdG8gc2F5IHRoYXQsIHdoaWxlIHRoaXMgZHJhZnQgZG9lcyBub3Qg aW5jbHVkZSBub3JtYXRpdmUgcmVxdWlyZW1lbnRzLCB0aGUga2V5d29yZHMgYXJlIHVzZWQgZm9y IHRoZSBzYWtlIG9mIGNsYXJpdHkuDQoNCg0KQWdyZWUuIFJlbW92ZWQgZnJvbSBkcmFmdC4gQW5k IGFsbCBjYXBpdGFsIFNIT1VMRCBvY2N1cnJlbmNlcyByZXBsYWNlZCB3aXRoIHNob3VsZC4NCg0K LTMsIDJuZCBwYXJhZ3JhcGg6DQoNCkRvZXMgdGhlIHdvcmtpbmcgZ3JvdXAgYmVsaWV2ZSB0aGF0 IG9uZSBjYW4gbWFrZSByZWFzb25hYmxlIGluZmVyZW5jZXMgZnJvbSBqdXN0IHRoZSBuZXR3b3Jr IHR5cGU/IERvIHlvdSBleHBlY3QgdGhlc2UgdG8gYmUgY29uZmlndXJhYmxlPyBTdGF0aWNhbGx5 IGRlZmluZWQgaW4gY29kZT8gKFNlZW1zIGxpa2UgdGhlcmUgbWF5IGJlIG9wZXJhdGlvbmFsIGNv bnNpZGVyYXRpb25zIGhlcmUuKQ0KDQpUaGUgb3JpZ2luYWwgaW50ZW50IHdpdGggdGhlIHRleHQg d2FzIHRvIHNheTsg4oCcSWYgeW91IHRoaW5rIHlvdSBrbm93IGJldHRlciwgcGxlYXNlIGZlZWwg ZnJlZSB0byBkbyBhcyB5b3UgcGxlYXNl4oCm4oCdLiBCdXQgYmFzaW5nIGl0IGp1c3Qgb24gbmV0 d29yayB0eXBlIHNlZW1zIHRvIGJlIGEgYml0IHRvIGZyYWdpbGUuDQoNClVwZGF0ZWQgdGV4dDoN CiAgVGhlIGFwcGxpY2F0aW9uIGtub3dsZWRnZSByZWdhcmRpbmcgdGhlIHJlbGlhYmlsaXR5IG9m IGFuIGludGVyZmFjZQ0KICAgY2FuIGFsc28gYmUgYmFzZWQgb24gc2ltcGxlIG1ldHJpY3MgbGlr ZSBwcmV2aW91cyBjb25uZWN0aW9uIHN1Y2Nlc3MvDQogICBmYWlsdXJlIHJhdGVzIG9yIGEgbW9y ZSBzdGF0aWMgbW9kZWwgYmFzZWQgb24gaW50ZXJmYWNlIHR5cGVzIGxpa2UNCiAgIHdpcmVkLCB3 aXJlbGVzcywgY2VsbHVsYXIsIHZpcnR1YWwsIHR1bm5lbGVkIGluIGNvbmp1bmN0aW9uIHdpdGgN CiAgIG90aGVyIG9wZXJhdGlvbmFsIG1ldHJpY3MuICBUaGlzIHdvdWxkIHJlcXVpcmUgdGhlIGFw cGxpY2F0aW9uIHRvDQogICBoYXZlIHRoZSByaWdodCBwZXJtaXNzaW9ucyB0byBvYnRhaW4gc3Vj aCBvcGVyYXRpb25hbCBtZXRyaWNzLg0KDQoNCi0gNy4yOiBDYW4gdGhpcyBiZSBtb3JlIHNwZWNp ZmljIGFib3V0IHdoYXQgaW1wbGVtZW50YXRpb25zIGV4aXN0PyBUaGUgYm9pbGVycGxhdGUgc2Vl bXMgYSBiaXQgaGVhdml3ZWlnaHQgZm9yIHNvbWV0aGluZyB0aGF0IHByZXR0eSBtdWNoIHNheXMg 4oCcdGhlcmUgYXJlIG90aGVycyIgOi0pDQoNCg0KVGhlIHNlY3Rpb24gaGFzIGJlZW4gaW4gYW5k IG91dC4gTWFpbiB1c2UgaXMgdG8gaW5mb3JtIFdHIGFuZCBBRCB0aGF0IHRoZXJlIGFyZSBvdGhl cnM/IE90aGVycyBoYXZlIGNvbmZpcm1lZCBkdXJpbmcgV0cgbWVldGluZ3MgdGhhdCB0aGV5IGRv IHRoaW5ncyBzaW1pbGFyIHRvIHdoYXQgaXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCAoQnV0IHNv bWV0aW1lcyB0aGV5IGhhdmUgbW9yZSBvcGVyYXRpb25hbCBrbm93bGVkZ2UgYW5kIGFyZSBhYmxl IHRvIG92ZXJyaWRlIHRoaW5ncyBpbiB0aGUgZHJhZnQpLg0KDQpTYWZlIHRvIHJlbW92ZSB0aGlz IHNlY3Rpb24gbm93Pw0KDQoNCkVkaXRvcmlhbDoNCg0KLSA0ICwgZmlyc3QgcGFyYWdyYXBoOiBI b3cgbG9uZyBpcyBsb25nPyAgKEVzcGVjaWFsbHkgaWYgeW91IHN0aWNrIHRoZSAyMTE5IFNIT1VM RCkuDQoNCkkgdGhpbmsgbG9uZyBjYW4gYmUgZHJvcHBlZC4gSU1ITyBpbnRlcm1pbmdsaW5nIG9m IHRoZSBhZGRyZXNzIHR5cGVzIGlzIGEgZ29vZCB0aGluZyBpZiB5b3Ugd2FudCB0byBiZSB0b3Bv bG9neSBhZ25vc3RpYy4NClRoZSBwYXJhZ3JhcGggc3RpbGwgaGF2ZSDigJx2YWx1ZXPigJ0gIGxp a2UgbWFueSBhbmQgc21hbGwuIEkgdGhpbmsgdGhhdCBpcyBvaz8NCg0KTmV3IHBhcmFncmFwaDoN CiAgIENhbmRpZGF0ZXMgc2hvdWxkIGJlIHByaW9yaXRpemVkIHN1Y2ggdGhhdCBhIHNlcXVlbmNl IG9mIGNhbmRpZGF0ZXMNCiAgIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSB3 aWxsIGJlIGludGVybWluZ2xlZCB3aXRoDQogICBjYW5kaWRhdGVzIGZyb20gYW4gYWx0ZXJuYXRl IElQIGZhbWlseS4gIEZvciBleGFtcGxlLCBwcm9tb3RpbmcgSVB2NA0KICAgY2FuZGlkYXRlcyBp biB0aGUgcHJlc2VuY2Ugb2YgbWFueSBJUHY2IGNhbmRpZGF0ZXMgc3VjaCB0aGF0IGFuIElQdjQN CiAgIGFkZHJlc3MgY2FuZGlkYXRlIGlzIGFsd2F5cyBwcmVzZW50IGFmdGVyIGEgc21hbGwgc2Vx dWVuY2Ugb2YgSVB2Ng0KICAgY2FuZGlkYXRlcywgaS5lLiwgcmVvcmRlcmluZyBjYW5kaWRhdGVz IHN1Y2ggdGhhdCBib3RoIElQdjYgYW5kIElQdjQNCiAgIGNhbmRpZGF0ZXMgZ2V0IGEgZmFpciBj aGFuY2UgZHVyaW5nIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgcGhhc2UuDQogICBUaGlzIG1ha2Vz IElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIG1vcmUgcmVzcG9uc2l2ZSB0byBicm9rZW4gcGF0aA0K ICAgZmFpbHVyZXMgb2YgYW4gYWRkcmVzcyBmYW1pbHkuDQoNCi0gNSwgbGFzdCBwYXJhZ3JhcGg6 IERvZXNu4oCZdCB0aGlzIGJlbG9uZyBpbiB0aGUgIkltcGxlbWVudGF0aW9uIFN0YXR1cyIgc2Vj dGlvbj8NCg0KVGhlIGludGVudCB3YXMgdG8gZ3VpZGUgaW1wbGVtZW50ZXJzIHRvIHNhbXBsZSBj b2RlLiBJZiB0aGF0IGlzIG1vdmVkIHRvIEltcGxlbWVudGF0aW9uIFN0YXR1cyB0aGF0IGluZm9y bWF0aW9uIHdpbGwgYmUgbG9zdCB3aGVuIHB1Ymxpc2hlZCBhcyBhbiBSRkMuDQoNClByZXZpb3Vz IHZlcnNpb25zIGhhZCBhbiBhcHBlbmRpeCB3aXRoIHRoZSBjb2RlIGV4YW1wbGVzLiBUaGUgV0cg ZmVsdCB0aGF0IHRoYXQgd2FzIGEgdG8gc3Ryb25nIGVuY291cmFnZW1lbnQgdG8gaW1wbGVtZW50 IGEgc3BlY2lmaWMgc29sdXRpb24sIHRoaXMgd2FzIHNvbWV0aGluZyB0aGUgV0cgZGlkIG5vdCB3 YW50IHRvIGRvLiBIZW5jZSB0aGUgaW5mb3JtYXRpb25hbCBzdGF0dXMgb2YgdGhlIGRyYWZ0Lg0K DQpJIGFtIGZpbmUgd2l0aCByZW1vdmluZyBpdC4NCg0KDQotIDcuMSBhbmQgNy4yIHRpdGxlczog cy9TdGFyY2svU3RhY2sNCg0KR2FoaC4uIEZpeGVkIGV2ZW4gaWYgcmVtb3ZlZCBsYXRlci4uDQoN Ci0gNy4xLCAiTGV2ZWwgb2YgTWF0dXJpdHkiOiBBcmUgdGhlcmUgd29yZHMgbWlzc2luZyBhcm91 bmQgIlRlc3RzIj8NCg0KQ3V0IGFuZCBwYXN0ZSBlcnJvci4NCg0KDQoNCkRvIHlvdSB3YW50IG1l IHRvIHBvc3QgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgd2l0aCB0aGUgY2hhbmdlcy4gV2Ug c3RpbGwgbmVlZCB0byByZXNvbHZlIHRoZSA1MjQ1LCA1MjQ1YmlzIGFuZCA2NzI0IHByb2JsZW0u IFNpbXBsZSBlbm91Z2ggb25jZSB3ZSBhZ3JlZS4NCg0KLi0uDQpQw6VsLUVyaWsNCg== --_000_86559E6764124971AB746680D079CAC8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5ACCEA1F069F8D4CA7ABA9F39957B156@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxOSBB cHIgMjAxNiwgYXQgMDg6MzYsIEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBu b3N0cnVtLmNvbSIgY2xhc3M9IiI+YmVuQG5vc3RydW0uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+SGksPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBpcyBt eSBBRCBFdmFsdWF0aW9uIG9mIGRyYWZ0LWlldGYtaWNlLWR1YWxzdGFjay1mYWlybmVzcy0wMi4g SSBmaW5kIHRoZSBkcmFmdCByZWFkYWJsZSBhbmQgdW5kZXJzdGFuZGFibGUsIGJ1dCBJIGhhdmUg c29tZSBjb21tZW50cyBhbmQgcXVlc3Rpb25zLiBJJ2QgbGlrZSB0byByZXNvbHZlIHRoZSBtYWpv ciBjb21tZW50cyBwcmlvciB0byBJRVRGIGxhc3QgY2FsbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpNYWpvcjo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgZHJhZnQgaXMg bm93IGluZm9ybWF0aW9uYWwsIGJ1dCB0aGUgbWlsZXN0b25lIGlzIGZvciBQUy4gSSBzZWUgdGhl IG1pbnV0ZXMgZnJvbSBQcmFndWUgc2F5IHRoZSB3ZyBhZ3JlZWQgdG8gbWFrZSB0aGUgY2hhbmdl LCBidXQgdGhhdCBkb2Vzbid0IHNheSB3aHksIGFuZCBJIGZhaWxlZCB0byBmaW5kIGFueSBkaXNj dXNzaW9uIG9mIHRoYXQgb24gdGhlIGxpc3QuIENhbiBhbnlvbmUgcmVtaW5kIG1lIG9mIHRoZSBy ZWFzb25pbmc/IChUaGlzDQogaW50ZXJhY3RzIHdpdGggbXkgbmV4dCBjb21tZW504oCmKTwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5KdXN0IGZvciBjbGFyaXR5IEkgd2lsbCBzdW1tYXJpc2Ugd2hhdCBJIHNlZSBhcyB0aGUga2V5 IOKAnGV2ZW50c+KAnSBvZiB0aGUgZHJhZnQuIChJIG1pZ2h0IGJlIHdyb25nIHNvIG9mIG90aGVy cyBzZWUgaXQgZGlmZmVyZW50bHkgcGxlYXNlIGNvcnJlY3QgbWUpPC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4tIFN0YXJ0ZWQgYXMgYW4gRHVhbFN0YWNrIEhhcHB5IEV5 ZWJhbGxzIHNvbHV0aW9uIHRoYXQgd291bGQgZ2l2ZSBJUHY2IGEgaGVhZCBzdGFydC4mbmJzcDs8 L2Rpdj4NCjxkaXY+LSBTZXZlcmFsIGF0dGVtcHRzIHRvIGdldCBhIGhhcHB5IGV5ZWJhbGxzIGFs Z29yaXRobSB3b3JraW5nIGZhaWxlZC4gQW5kIHdlIGRpc2NvdmVyZWQgdGhhdCBpdCB3b3VsZCBi ZSB2ZXJ5IGRpZmZpY3VsdCB0byBnZXQgcmlnaHQgaW4gYWxsIHRoZSB2YXJpb3VzIHNjZW5hcmlv cy4gVGhpbmsgdGhlIOKAnGNvbnNlbnN1cyBpbiB0aGUgaGFsbHdheXPigJ0gd2FzIHRvIGxldCBl YWNoIGFwcGxpY2F0aW9uIGRlYWwgd2l0aCBpdCBhcyB0aGV5IHdvdWxkDQoga25vdyBtb3JlIG9m IHdoYXQgd2FzIGltcG9ydGFudCB0byB0aGVtLiZuYnNwOzwvZGl2Pg0KPGRpdj4oPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9taW51dGVzL21pbnV0ZXMtOTItbW11 c2ljI2gudjBqdHd1NXJlOTBmIiBjbGFzcz0iIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzkyL21pbnV0ZXMvbWludXRlcy05Mi1tbXVzaWMjaC52MGp0d3U1cmU5MGYpPGJyIGNsYXNz PSIiPg0KPC9hPi0gU2luY2UgdGhlIGRyYWZ0IG9ubHkgY29udGFpbnMgZ3VpZGVsaW5lcyBvbiBo b3cgYW4gYXBwbGljYXRpb24gc2hvdWxkIGRlYWwgd2l0aCBkdWFsLXN0YWNrIGl0IG1hZGUgc2Vu c2UgdG8gbWFrZSBpdCBpbmZvcm1hdGlvbmFsLiZuYnNwOzwvZGl2Pg0KPGRpdj4oPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9taW51dGVzL21pbnV0ZXMtOTMtbW11 c2ljI2guMzRpbHgzeTR2a2JkIiBjbGFzcz0iIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzkzL21pbnV0ZXMvbWludXRlcy05My1tbXVzaWMjaC4zNGlseDN5NHZrYmQ8L2E+KTwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIGFt IGNvbmZ1c2VkIGFib3V0IHRoZSByZWxhdGlvbnNoaXBzIGFtb25nIHRoaXMgZHJhZnQsIFJGQyA1 MjQ1LCA1MjQ1YmlzLCBhbmQgUkZDIDY3MjQuIFNlY3Rpb24gMSBvZiB0aGlzIGRyYWZ0IHNlZW1z IHRvIHNheSB0aGF0IGl0IHJlY29tbWVuZHMgYWdhaW5zdCBmb2xsb3dpbmcgdGhlIHJlcXVpcmVt ZW50IGluIDUyNDUgdGhhdCBzYXlzIGR1YWwgc3RhY2sgaG9zdHMgU0hPVUxEIGZvbGxvdyB0aGUg cHJlY2VkZW5jZQ0KIGluIDY3MjQuIE5vcm1hbGx5LCB0aGF0IHdvdWxkIHJlcXVpcmUgdGhpcyBk cmFmdCB0byB1cGRhdGUgNTI0NSwgd2hpY2ggd291bGQgcmVxdWlyZSBpdCB0byBiZSBzdGFuZGFy ZHMgdHJhY2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnV0IG9uIHRoZSBvdGhlciBo YW5kLCBJIGFtIG5vdCBlbnRpcmVseSBjb252aW5jZWQgYW55dGhpbmcgaGVyZSByZWFsbHkgY2hh bmdlcyB0aGF0IFNIT1VMRCwgc2luY2UgNjcyNCBleHBsaWNpdGx5IHNheXM6PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7JnF1b3Q7VGhlIHNlbGVjdGlvbiBydWxlcyBzcGVjaWZp ZWQgaW4gdGhpcyBkb2N1bWVudCBNVVNUIE5PVCBiZSBjb25zdHJ1ZWQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDt0byBvdmVycmlkZSBhbiBhcHBsaWNhdGlvbiBvciB1cHBlciBsYXllcuKAmXMg ZXhwbGljaXQgY2hvaWNlIG9mIGE8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtsZWdhbCBkZXN0 aW5hdGlvbiBvciBzb3VyY2UgYWRkcmVzcy4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpVbmZvcnR1bmF0ZWx5LCBJIHRoaW5rIHRoaXMgcHV0cyB0aGluZ3MgaW4gYSBncmV5IGFy ZWEsIGR1ZSB0byBhbWJpZ3VvdXMgd29yZGluZyBpbiA1MjQ1LiBTbyBJIHRoaW5rIHRoaXMgZHJh ZnQgZWl0aGVyIG5lZWRzIHRvIHVwZGF0ZSA1MjQ1LCBvciBpdCBuZWVkcyB0byBleHBsYWluIHdo eSB0aGUgZ3VpZGFuY2UgaGVyZSBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoYXQgU0hPVUxELjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2PlRoaXMgd2FzIGF0IGxlYXN0IGRpc2N1c3NlZCBpbiBJRVRGOTAsJm5ic3A7PGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9taW51dGVzL21pbnV0ZXMtOTAt bW11c2ljI2guNmZpamRwdmVhbmFhIiBjbGFzcz0iIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzkwL21pbnV0ZXMvbWludXRlcy05MC1tbXVzaWMjaC42ZmlqZHB2ZWFuYWE8L2E+PC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5TbyBub3cgbXkgbmFpdmUgcXVl c3Rpb24gaXM7IGRvIHdlIGNhcmUgYWJvdXQgNTI0NSB3aXRoIDUyNDViaXMgc29vbiBmaW5pc2hl ZD88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkkgdGhpbmsgd2UgaGF2 ZSB0d28gcG9zc2libGUgc29sdXRpb25zLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+MS4gTWFrZSBkdWFsLXN0YWNrIGZhaXJuZXNzIHJlZmVyZW5jZSBvbmx5IDUyNDVi aXMuIE1ha2Ugc3VyZSB0ZXh0IGluIGJvdGggZHJhZnQgaGFybW9uaXNlLiBUaGV5IHdpbGwgY3Jv c3MgcmVmZXJlbmNlIGVhY2ggb3RoZXIgYW5kIHRodXMgbmVlZHMgdG8gYmUgcHVibGlzaGVkIGF0 IHRoZSBzYW1lIHRpbWU/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4y LiBFeHBsYWluIHdoeSB3ZSBhcmUgbm90IGJyYWtpbmcgdGhlIDUyNDUgU0hPVUxEIGFuZCBrZWVw IGl0IGFzIGluZm9ybWF0aW9uYWwgLiBUaGlzIGlzIGRvbmUgYnkgcG9pbnRpbmcgb3V0IHRoZSBh cHByb3ByaWF0ZSB0ZXh0IHlvdSBmb3VuZCBpbiA2NzI0LjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5BbmQgaW4gZWl0aGVyIGNhc2U6IElzIHRoZXJlIGFuIG9wcG9ydHVuaXR5IHRvIG1h a2UgNTI0NSBtb3JlIGNsZWFyIGluIDUyNDViaXM/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQpBYnNvbHV0ZWx5LiBJdCBtdXN0IGFsc28gcG9pbnQgb3V0IHRoYXQgdGhlIGZvcm11bGFz IGRlc2NyaWJlZCBpbiA1MjQ1IHNlY3Rpb24gNC4xLjIgaGF2ZSBub3QgY2hhbmdlcyBzbyB0aGF0 IHRoZSBjb21wYXRpYmlsaXR5IGRpc2N1c3Npb24gaW4gc2VjdGlvbiA1IG9mIHRoZSBkdWFsLXN0 YWNrIGZhaXJuZXNzIGRyYWZ0IGlzIHN0aWxsIHZhbGlkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGF0IG9mIGNv dXJzZSBsZWFkcyB0byB0aGUgYm9tYnNoZWxsIHF1ZXN0aW9uOiBXZSBhcmUgYWxyZWFkeSBpbiB0 aGUgcHJvY2VzcyBvZiB1cGRhdGluZyA1MjQ1LiBXaHkgaXNu4oCZdCBfdGhpc18gZHJhZnQgcGFy dCBvZiA1MjQ1YmlzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkkgdGhpbmsgdGhlIG1haW4gbW90aXZhdGlvbiBmb3IgdGhh dCB3YXMgdG8ga2VlcCB0aGUgSUNFYmlzIHNwZWMgYXMgc2hvcnQgYXMgcG9zc2libGUgYXMgdGhl cmUgYXJlIHNvbWUgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9lcyBub3QgY2FyZSBhYm91dCB0aGUg cHJvYmxlbS4gRm9yIHRoZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBjYXJlLCB0aGV5IHNob3Vs ZCByZWFkIHRoZSBkcmFmdCBhbmQgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbnMuJm5ic3A7PC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1pbm9yOjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCi0gMTogVGhlIGludHJvZHVjdGlvbiBqdW1wcyByaWdodCB0byBzYXlpbmcgYXBwbGlj YXRpb25zIG5lZWQgdG8gZGVwcmlvcml0aXplIGludGVyZmFjZXMgd2l0aG91dCBzYXlpbmcgd2hh dCBwcm9ibGVtIGl0J3MgdHJ5aW5nIHRvIHNvbHZlLiBBbiBpbml0aWFsIHBhcmFncmFwaCB0aGF0 IHNheXMgd2hhdCBnb2VzIHdyb25nIHdpdGggY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgd291bGQg YmUgZXh0cmVtZWx5IGhlbHBmdWwuIEl0IHdvdWxkIGFsc28NCiBoZWxwIHRvIGRlZmluZSB3aGF0 IGlzIG1lYW50IGJ5ICZxdW90O2ZhaXJuZXNzJnF1b3Q7IGluIHRoaXMgY29udGV4dC4gKEnigJlt IG5vdCBzdXJlIGl0J3MgcXVpdGUgdGhlIHNhbWUgYXMgdGhlIGNvbnZlbnRpb25hbCB1c2Ugb2Yg dGhlIHRlcm0uKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2PkhvdyBhYm91dDo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7SW4gbXVsdGlob21lZCBhbmQgSVB2NC9J UHY2IGR1YWwtc3RhY2sgZW52aXJvbm1lbnRzIElDRSBbUkZDNTI0NV08L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwO3dvdWxkIGJlbmVmaXQgYnkgYSBmYWlyIGRpc3RyaWJ1dGlvbiBvZiBpdHMgY29u bmVjdGl2aXR5IGNoZWNrczwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7YWNyb3NzIGF2YWlsYWJs ZSBpbnRlcmZhY2VzIG9yIElQIGFkZHJlc3MgdHlwZXMuICZuYnNwO1dpdGggYSBmYWlyPC9kaXY+ DQo8ZGl2PiZuYnNwOyAmbmJzcDtkaXN0cmlidXRpb24gb2YgdGhlIGNvbm5lY3Rpdml0eSBjaGVj a3MsIGV4Y2Vzc2l2ZSBkZWxheXMgYXJlIGF2b2lkZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw O2lmIGEgcGFydGljdWxhciBuZXR3b3JrIHBhdGggaXMgYnJva2VuIG9yIHNsb3cuICZuYnNwO0l0 IHdvdWxkIGFyZ3VhYmxlIGJlPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtiZXR0ZXIgdG8gcHV0 IHRoZSBpbnRlcmZhY2VzIG9yIGFkZHJlc3MgdHlwZXMga25vdyB0byB0aGUgYXBwbGljYXRpb248 L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2xhc3QgaW4gdGhlIGNoZWNrbGlzdC4gJm5ic3A7SG93 ZXZlciwgdGhlIG1haW4gbW90aXZhdGlvbiBieSBJQ0UgaXMgdG88L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwO21ha2Ugbm8gYXNzdW1wdGlvbnMgcmVnYXJkaW5nIG5ldHdvcmsgdG9wb2xvZ3ksIGhl bmNlIGEgZmFpcjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ZGlzdHJpYnV0aW9uIG9mIHRoZSBj b25uZWN0aXZpdHkgY2hlY2tzIGlzIG1vcmUgYXBwcm9wcmlhdGUuICZuYnNwO0lmIGFuPC9kaXY+ DQo8ZGl2PiZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbiBvcGVyYXRlcyBpbiBhIHdlbGwta25vd24g ZW52aXJvbm1lbnQgaXMgY2FuIHNhZmVseTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7b3ZlcnJp ZGUgdGhlIHJlY29tbWVuZGF0aW9uIGdpdmVuIGluIHRoaXMgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPi0gMjogQXNzdW1pbmcgdGhpcyBzdGF5cyBpbmZvcm1hdGlvbmFsLCBpdCdzIG5vdCBy ZWFsbHkgdXNpbmcgdGhlIDIxMTkga2V5d29yZHMgcXVpdGUgaW4gdGhlIHNwaXJpdCBvZiAyMTE5 LiBQZXJzb25hbGx5LCBJIGRvbid0IHRoaW5rIHRoZSBjdXJyZW50IDIxMTkgdXNhZ2UgKG91dHNp ZGUgb2YgdGV4dCBkaXJlY3RseSBhdHRyaWJ1dGVkIHRvIG90aGVyIGRvY3VtZW50cywgd2hpY2gg ZG9lc24ndCByZWFsbHkgY291bnQpDQogYWRkcyBtdWNoLiBJIHN1Z2dlc3QgcmVtb3ZpbmcgaXQu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnV0IGlmIHBlb3BsZSBhcmUgcmVhbGx5IGF0 dGFjaGVkIHRvIHVzaW5nIDIxMTkgbGFuZ3VhZ2UgaGVyZSwgcGxlYXNlIGNvbnNpZGVyIGFkanVz dGluZyB0aGUgYm9pbGVycGxhdGUgdG8gc2F5IHRoYXQsIHdoaWxlIHRoaXMgZHJhZnQgZG9lcyBu b3QgaW5jbHVkZSBub3JtYXRpdmUgcmVxdWlyZW1lbnRzLCB0aGUga2V5d29yZHMgYXJlIHVzZWQg Zm9yIHRoZSBzYWtlIG9mIGNsYXJpdHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpB Z3JlZS4gUmVtb3ZlZCBmcm9tIGRyYWZ0LiBBbmQgYWxsIGNhcGl0YWwgU0hPVUxEIG9jY3VycmVu Y2VzIHJlcGxhY2VkIHdpdGggc2hvdWxkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPi0zLCAybmQgcGFyYWdyYXBoOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkRvZXMgdGhlIHdvcmtpbmcgZ3JvdXAgYmVsaWV2ZSB0aGF0IG9uZSBjYW4gbWFrZSByZWFzb25h YmxlIGluZmVyZW5jZXMgZnJvbSBqdXN0IHRoZSBuZXR3b3JrIHR5cGU/IERvIHlvdSBleHBlY3Qg dGhlc2UgdG8gYmUgY29uZmlndXJhYmxlPyBTdGF0aWNhbGx5IGRlZmluZWQgaW4gY29kZT8gKFNl ZW1zIGxpa2UgdGhlcmUgbWF5IGJlIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGhlcmUuKTxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2PlRoZSBvcmlnaW5hbCBpbnRlbnQgd2l0aCB0aGUgdGV4dCB3YXMgdG8gc2F5OyDigJxJ ZiB5b3UgdGhpbmsgeW91IGtub3cgYmV0dGVyLCBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIGFzIHlv dSBwbGVhc2XigKbigJ0uIEJ1dCBiYXNpbmcgaXQganVzdCBvbiBuZXR3b3JrIHR5cGUgc2VlbXMg dG8gYmUgYSBiaXQgdG8gZnJhZ2lsZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PlVwZGF0ZWQgdGV4dDo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNwOyBUaGUgYXBwbGlj YXRpb24ga25vd2xlZGdlIHJlZ2FyZGluZyB0aGUgcmVsaWFiaWxpdHkgb2YgYW4gaW50ZXJmYWNl PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtjYW4gYWxzbyBiZSBiYXNlZCBvbiBzaW1wbGUgbWV0 cmljcyBsaWtlIHByZXZpb3VzIGNvbm5lY3Rpb24gc3VjY2Vzcy88L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwO2ZhaWx1cmUgcmF0ZXMgb3IgYSBtb3JlIHN0YXRpYyBtb2RlbCBiYXNlZCBvbiBpbnRl cmZhY2UgdHlwZXMgbGlrZTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7d2lyZWQsIHdpcmVsZXNz LCBjZWxsdWxhciwgdmlydHVhbCwgdHVubmVsZWQgaW4gY29uanVuY3Rpb24gd2l0aDwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7b3RoZXIgb3BlcmF0aW9uYWwgbWV0cmljcy4gJm5ic3A7VGhpcyB3 b3VsZCByZXF1aXJlIHRoZSBhcHBsaWNhdGlvbiB0bzwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7 aGF2ZSB0aGUgcmlnaHQgcGVybWlzc2lvbnMgdG8gb2J0YWluIHN1Y2ggb3BlcmF0aW9uYWwgbWV0 cmljcy48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+LSA3LjI6IENhbiB0aGlzIGJlIG1vcmUgc3BlY2lmaWMgYWJvdXQgd2hh dCBpbXBsZW1lbnRhdGlvbnMgZXhpc3Q/IFRoZSBib2lsZXJwbGF0ZSBzZWVtcyBhIGJpdCBoZWF2 aXdlaWdodCBmb3Igc29tZXRoaW5nIHRoYXQgcHJldHR5IG11Y2ggc2F5cyDigJx0aGVyZSBhcmUg b3RoZXJzJnF1b3Q7IDotKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGUg c2VjdGlvbiBoYXMgYmVlbiBpbiBhbmQgb3V0LiBNYWluIHVzZSBpcyB0byBpbmZvcm0gV0cgYW5k IEFEIHRoYXQgdGhlcmUgYXJlIG90aGVycz8gT3RoZXJzIGhhdmUgY29uZmlybWVkIGR1cmluZyBX RyBtZWV0aW5ncyB0aGF0IHRoZXkgZG8gdGhpbmdzIHNpbWlsYXIgdG8gd2hhdCBpcyBkZXNjcmli ZWQgaW4gdGhlIGRyYWZ0IChCdXQgc29tZXRpbWVzIHRoZXkgaGF2ZSBtb3JlIG9wZXJhdGlvbmFs IGtub3dsZWRnZSBhbmQgYXJlIGFibGUNCiB0byBvdmVycmlkZSB0aGluZ3MgaW4gdGhlIGRyYWZ0 KS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlNhZmUgdG8g cmVtb3ZlIHRoaXMgc2VjdGlvbiBub3c/PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCkVkaXRvcmlhbDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotIDQg LCBmaXJzdCBwYXJhZ3JhcGg6IEhvdyBsb25nIGlzIGxvbmc/ICZuYnNwOyhFc3BlY2lhbGx5IGlm IHlvdSBzdGljayB0aGUgMjExOSBTSE9VTEQpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkkgdGhpbmsgbG9uZyBjYW4gYmUg ZHJvcHBlZC4gSU1ITyBpbnRlcm1pbmdsaW5nIG9mIHRoZSBhZGRyZXNzIHR5cGVzIGlzIGEgZ29v ZCB0aGluZyBpZiB5b3Ugd2FudCB0byBiZSB0b3BvbG9neSBhZ25vc3RpYy48L2Rpdj4NCjxkaXY+ VGhlIHBhcmFncmFwaCBzdGlsbCBoYXZlIOKAnHZhbHVlc+KAnSAmbmJzcDtsaWtlIG1hbnkgYW5k IHNtYWxsLiBJIHRoaW5rIHRoYXQgaXMgb2s/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5OZXcgcGFyYWdyYXBoOjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7Q2FuZGlk YXRlcyBzaG91bGQgYmUgcHJpb3JpdGl6ZWQgc3VjaCB0aGF0IGEgc2VxdWVuY2Ugb2YgY2FuZGlk YXRlczwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7YmVsb25naW5nIHRvIHRoZSBzYW1lIGFkZHJl c3MgZmFtaWx5IHdpbGwgYmUgaW50ZXJtaW5nbGVkIHdpdGg8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZu YnNwO2NhbmRpZGF0ZXMgZnJvbSBhbiBhbHRlcm5hdGUgSVAgZmFtaWx5LiAmbmJzcDtGb3IgZXhh bXBsZSwgcHJvbW90aW5nIElQdjQ8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2NhbmRpZGF0ZXMg aW4gdGhlIHByZXNlbmNlIG9mIG1hbnkgSVB2NiBjYW5kaWRhdGVzIHN1Y2ggdGhhdCBhbiBJUHY0 PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDthZGRyZXNzIGNhbmRpZGF0ZSBpcyBhbHdheXMgcHJl c2VudCBhZnRlciBhIHNtYWxsIHNlcXVlbmNlIG9mIElQdjY8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZu YnNwO2NhbmRpZGF0ZXMsIGkuZS4sIHJlb3JkZXJpbmcgY2FuZGlkYXRlcyBzdWNoIHRoYXQgYm90 aCBJUHY2IGFuZCBJUHY0PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtjYW5kaWRhdGVzIGdldCBh IGZhaXIgY2hhbmNlIGR1cmluZyB0aGUgY29ubmVjdGl2aXR5IGNoZWNrIHBoYXNlLjwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7VGhpcyBtYWtlcyBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBtb3Jl IHJlc3BvbnNpdmUgdG8gYnJva2VuIHBhdGg8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2ZhaWx1 cmVzIG9mIGFuIGFkZHJlc3MgZmFtaWx5LiZuYnNwOzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4tIDUsIGxhc3QgcGFyYWdyYXBoOiBEb2VzbuKAmXQgdGhpcyBiZWxvbmcgaW4gdGhlICZx dW90O0ltcGxlbWVudGF0aW9uIFN0YXR1cyZxdW90OyBzZWN0aW9uPzxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PlRoZSBpbnRl bnQgd2FzIHRvIGd1aWRlIGltcGxlbWVudGVycyB0byBzYW1wbGUgY29kZS4gSWYgdGhhdCBpcyBt b3ZlZCB0byBJbXBsZW1lbnRhdGlvbiBTdGF0dXMgdGhhdCBpbmZvcm1hdGlvbiB3aWxsIGJlIGxv c3Qgd2hlbiBwdWJsaXNoZWQgYXMgYW4gUkZDLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+UHJldmlvdXMgdmVyc2lvbnMgaGFkIGFuIGFwcGVuZGl4IHdpdGgg dGhlIGNvZGUgZXhhbXBsZXMuIFRoZSBXRyBmZWx0IHRoYXQgdGhhdCB3YXMgYSB0byBzdHJvbmcg ZW5jb3VyYWdlbWVudCB0byBpbXBsZW1lbnQgYSBzcGVjaWZpYyBzb2x1dGlvbiwgdGhpcyB3YXMg c29tZXRoaW5nIHRoZSBXRyBkaWQgbm90IHdhbnQgdG8gZG8uIEhlbmNlIHRoZSBpbmZvcm1hdGlv bmFsIHN0YXR1cyBvZiB0aGUgZHJhZnQuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5JIGFtIGZpbmUgd2l0aCByZW1vdmluZyBpdC4mbmJzcDs8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi0gNy4xIGFu ZCA3LjIgdGl0bGVzOiBzL1N0YXJjay9TdGFjazxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkdhaGguLiBGaXhlZCBldmVuIGlm IHJlbW92ZWQgbGF0ZXIuLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tIDcuMSwgJnF1 b3Q7TGV2ZWwgb2YgTWF0dXJpdHkmcXVvdDs6IEFyZSB0aGVyZSB3b3JkcyBtaXNzaW5nIGFyb3Vu ZCAmcXVvdDtUZXN0cyZxdW90Oz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQpDdXQgYW5kIHBhc3RlIGVycm9yLiZuYnNw Ow0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5EbyB5b3Ugd2FudCBtZSB0byBwb3N0IGEgbmV3IHZlcnNpb24gb2YgdGhl IGRyYWZ0IHdpdGggdGhlIGNoYW5nZXMuIFdlIHN0aWxsIG5lZWQgdG8gcmVzb2x2ZSB0aGUgNTI0 NSwgNTI0NWJpcyBhbmQgNjcyNCBwcm9ibGVtLiBTaW1wbGUgZW5vdWdoIG9uY2Ugd2UgYWdyZWUu Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4uLS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UMOlbC1FcmlrPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_86559E6764124971AB746680D079CAC8ciscocom_--