From nobody Thu Sep 1 06:55:20 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 2443C12DAE6; Thu, 1 Sep 2016 06:55:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147273811795.10100.12966155398442715769.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2016 06:55:17 -0700 Archived-At: Cc: ice-chairs@ietf.org, ari.keranen@ericsson.com, draft-ietf-ice-dualstack-fairness@ietf.org, ice@ietf.org Subject: [Ice] Stephen Farrell's No Objection on draft-ietf-ice-dualstack-fairness-04: (with COMMENT) 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, 01 Sep 2016 13:55:18 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ice-dualstack-fairness-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This already has a fair number of discusses:-) From nobody Fri Sep 2 13:33:46 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 97FCB12D500 for ; Fri, 2 Sep 2016 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 J77Bt4bMRIdg for ; Fri, 2 Sep 2016 13:33:42 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 CCDF912D1C1 for ; Fri, 2 Sep 2016 13:33:42 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id p64so45557912pfb.1 for ; Fri, 02 Sep 2016 13:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:subject:date:message-id:to:mime-version; bh=2jz1PIpEWaazkdtDdQROpQiOF2EybZOTMoZ9uYDvmA0=; b=QRSvyWH3gLrmU0iisDSRyrYko1CsuDEto/vMpbxx98qZINnX7kByEdWCOCwwGTzWEp xDvM5UjFaN3ObH/yNvektpf7ebjBVtoCwl+4D0/nn0jrAeh11bvBHg8iFRNvs54vrcBJ jfmhIHYcgXrrprwi/QqJCickL8TY59/nFrx7U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=2jz1PIpEWaazkdtDdQROpQiOF2EybZOTMoZ9uYDvmA0=; b=SEKk5ElYx1v+qaBGZKOgvGFNX68Yt4hBGQcfkbvfTPqgghqW3kXIM+C0duS3PWs/GN ukNx0Hd9Hk+O/enOQncByjxVp8W/lUi7VBHUeh9dXzqskyLGqB4pPMcvWdCdlmLi4GAY y7rcg3LalfbgCVZ4Ph6lOZBFrqKLUME9xm9MfSZUJ9TKhBRNd0k64Du+osR0Jnj0aJLl cNjI0tfG5uc0zONQvgkyDajWOot4fDbrljlXWR1sSWtsRrUsWGFD6LC2nZAyWLCrJdg6 9/2AC+8H50eyArBXpYX3a8PZjEh52bI8cPa+eGJnXYwC22YCknnas2RuxOrnnuIMxr8W a7qA== X-Gm-Message-State: AE9vXwPCd7Re7ZLSmYLkiPP1PEsQRES/1xlwkEKEwyB/ojfP0GdoNJ7LDBVUebdK3GMSP5LQ X-Received: by 10.98.99.67 with SMTP id x64mr39990049pfb.26.1472848421774; Fri, 02 Sep 2016 13:33:41 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:9d51:da23:727a:f68d? ([2620:101:80fc:224:9d51:da23:727a:f68d]) by smtp.gmail.com with ESMTPSA id 7sm16856181pfk.6.2016.09.02.13.33.39 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 13:33:40 -0700 (PDT) From: Nils Ohlmeier X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_A5A14103-5EEA-4EB5-AFB3-0C9BC2220497"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 2 Sep 2016 13:34:09 -0700 Message-Id: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> To: ice@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Ice] Triggered checks are missing peer reflexive 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, 02 Sep 2016 20:33:44 -0000 --Apple-Mail=_A5A14103-5EEA-4EB5-AFB3-0C9BC2220497 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have identified something which I would be interested to hear the = opinions of the ICE experts about. In RFC 5245 (section 7.2.1.4) and also in bis-04 (section 6.1.3.1.4) = claim the following regarding receiving triggered checks: The local candidate will either be a host candidate (...) or a = relayed candidate (=E2=80=A6). The local candidate can never be a server = reflexive candidate. Which I think is missing the case where the local candidate can also a = be a peer reflexive. And this is actually causing unnecessary extra = checks to be made. Consider the following scenario: - A sits behind symmetric NAT - B is on a publicly routable address with no NAT or firewall - No STUN servers (just makes the scenario less complex) - Host candidates get exchanged and candidate pairs A:B and B:A get = created on both sides - A sends binding request to B - B receives binding request with transport address A=E2=80=99 - B creates a peer reflexive candidate for A=E2=80=99 and the a new pair = B:A=E2=80=99 and puts that new pair into its trigger check queue - B sends binding response to A=E2=80=99 - A receives binding response, learns about A=E2=80=99 and creates = A=E2=80=99:B and marks it as successful - Now B sends a binding request for it trigger check queue entry to A=E2=80= =99 - When A receives this binding request is has no way to match this to = the successful pair A=E2=80=99:B - Because of the wording in the above mentioned sections it will match = the request to the pair A:B - Which then in turn causes another triggered check to be created = because A:B is not in the success state This additional triggered check from A is just waste of time and = resources. It does not hurt. But I=E2=80=99m wondering how this could be = avoided. If people agree I think section 6.1.3.1.4 should at least mention the = scenario that incoming binding requests can also match a peer reflexive = candidate. As the incoming binding request does not contain the destination address = it got send to there is obviously no way for A to clearly distinguish if = the request got send to A or A=E2=80=99. For avoiding the additional triggered check on A=E2=80=99s side the only = solution I see right now is to go through the pairs which have A as = their foundation and if that list contains a pair which is marked as = successful already assume no triggered check is needed. So far I have = not been able to identify a scenario where it hurts to skip this extra = round of triggered checks on A=E2=80=99s side. Best Nils Ohlmeier --Apple-Mail=_A5A14103-5EEA-4EB5-AFB3-0C9BC2220497 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXyeJBAAoJEJ3NnGfOORkke5AP/1XLxXnZJ69ZN6i/g14Ct/VU 4p7KjCuVxWbi3P1zOKAWLiOs8X6n0hMWMpZTpG9uzaadK0482unfZhv3bUgy1mUr d5LjX2Ve+zY+dYsuZ3QTUvDte1mFZjR9XtpdKxJ1E5Wnzvc9nWrLMdd1ViHlB1VA fSfvn6E+sdp+pXXqbJLVbBdh1gZlaURIkeZCb5MujpT7XQa3zxjmt2y+EDXonXHg Klgf+JKutS1FS0jgFdlnhZsKvt8AsnjG71q623c6+aMuN16o3vHpiOgPopIcINyQ xzrB+/V+c3Wr9wffVaBYHvzzoNmrLEcwsX0S1UpGZzDk+BD/AJK8Ty3cxtzZN7z9 HPKwhqj1fiwcefI5V2pNvFh4lTI92/bAsESWCYy1hQ3tf2VZDdExU69l/tRmEn9J mqV1R2VKNCbSHp6qgAgv3e+/FJ7iwuMewJP5evRAS6p3RVgWrv94BDcQSbmlMEFz A23+KIQitZFXgwar/inCaGPZNYUDEeMyGCxui3nulFDojeopM9S3pukeZUIDQxCY bOT5ENHRU0QvDYWB9V73WCKwZbtZlhbRQMnK1ea/i8iJAif3EE+A/mKcEqMgqfLr HMnBUrJJAeMQ/t2Fd6XNxmDhaiJS0GQDUBDGNbYghHQsuNGOQAjuGm26TKuvH6kC KaC5va4GGWxy5v9oTddX =6rWE -----END PGP SIGNATURE----- --Apple-Mail=_A5A14103-5EEA-4EB5-AFB3-0C9BC2220497-- From nobody Mon Sep 5 01:23:08 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 B85FE12B2E5; Mon, 5 Sep 2016 01:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 ovGeFO5oi0F2; Mon, 5 Sep 2016 01:23:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150CC12B2DD; Mon, 5 Sep 2016 01:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4218; q=dns/txt; s=iport; t=1473063784; x=1474273384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4aS3IwVN6EQSU8+j+YnHuHBpmx7dl2kVI3uM0aChg3M=; b=lEe4/C4n1SHaLjc+uG1aazY4Z76bwU4uZozAeeV3eftkS2WJCUe/vLK2 ckfQHcj6t3LVdX/GAnh0S7P4z/HxcY0mLLM0koP1NXQ2l06nSqE4hR7LP IX9upiMYfm/xObpabgP/V5B9m2Ha0b688Mn7I2ENoFbxaz+v7Asa2XVKB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAgBMKs1X/4ENJK1dGgEBAQECAQEBA?= =?us-ascii?q?YMtAQEBAQEeV3wHg0CJZ6ZCgjWCD4ICJIV4AhyBHjgUAQIBAQEBAQEBXieEYQE?= =?us-ascii?q?BAQMBIxFFBQsCAQgOCgICJgICAjAVBQsCBA4FG4gnCA6xHIwcAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHIEFhSqBeAiCToI0hQ4rgi8FiCcHhXeBOIl2AYYgiRWPWYx?= =?us-ascii?q?Mg3kBHjaDEoE1cIVvfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,285,1470700800"; d="scan'208";a="147600281" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2016 08:23:03 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u858N21U028117 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Sep 2016 08:23:03 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.1210.3; Mon, 5 Sep 2016 04:23:02 -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.1210.000; Mon, 5 Sep 2016 04:23:02 -0400 From: "Pal Martinsen (palmarti)" To: Mirja Kuehlewind Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pY2Ut?= =?utf-8?B?ZHVhbHN0YWNrLWZhaXJuZXNzLTA0OiAod2l0aCBESVNDVVNTIGFuZCBDT01N?= =?utf-8?Q?ENT)?= Thread-Index: AQHSA4OZd8oYjU6XmEeoPCSDs9tpp6Bq2XQA Date: Mon, 5 Sep 2016 08:23:02 +0000 Message-ID: <3D60787A-FD67-472D-8787-C5EEA6B8BB9F@cisco.com> References: <147264668629.5913.9417537450161055669.idtracker@ietfa.amsl.com> In-Reply-To: <147264668629.5913.9417537450161055669.idtracker@ietfa.amsl.com> 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.24.127.105] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , Ari Keranen , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-ic?= =?utf-8?q?e-dualstack-fairness-04=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 05 Sep 2016 08:23:06 -0000 DQo+IE9uIDMxIEF1ZyAyMDE2LCBhdCAxNDozMSwgTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVo bGV3aW5kLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90 aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWljZS1kdWFsc3RhY2stZmFpcm5lc3MvDQo+ IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiANCj4gSSdtIHdpbGxpbmcgdG8gcmVzb2x2ZSBteSBkaXNjdXNzIHF1aWNrbHkgYnV0IEkgd291 bGQgbGlrZSB0byBzdGFydCBzb21lDQo+IGRpc2N1c3Npb246DQo+IA0KPiBUbyBtZSB0aGUgcmVj b21tZW5hdGlvbnMgZ2l2ZW4gaW4gdGhpcyBkb2MgYXJlIG5vdCB2ZXJ5IGNsZWFyLiBUbyBteQ0K PiB1bmRlcnN0YW5kaW5nIGFyZSB0aGVyZSB0d28gcmVjb21tZW5hdGlvbnM6DQo+IA0KPiAxKSBp bnRlcm1pbmdsZSBJUHY0IGFuZCBJUHY2IGFkZHJlc3NlcywgYW5kDQo+IDIpIHB1dCBsb3dlciBw cmlvcml0eSBmb3IgYWRyZXNzZXMgdGhhdCBhcmUga25vdyB0byBoYXZlIGNvbm5lY3Rpdml0eQ0K PiBwcm9ibGVtLg0KPiANCkNvcnJlY3QuDQoNCg0KPiBIb3dldmVyLCB0aGF0IGxlYXZlcyB0b25z IG9mIG9wZW4gcXVlc3Rpb25zIHRvIHRoZSBpbXBsZW1lbnRvciwgZS5nLg0KPiAtIEhvdyBtYW55 IElQdjYgYWRkcmVzc2VzIHNob3VsZCBJIGhhdmUgYmVmb3JlIHRoZSBmaXJzdCBJUHY0Pw0KPiAt IEhvdyBkbyBJIG1lYXN1cmUvdHJhY2sgdGhhdCBhbiBpbnRlcmZhY2UgaGFzIGNvbm5lY3RpdGl2 eSBwcm9ibGVtczoNCj4gY29ubmVjdGl2aXR5IGZhaWxlZCBvbmNlLCBvciB0d2ljZSwgb3IgWC10 aW1lcz8gSG93IGxvbmcgZG8gSSBrZWVwIHRoaXMNCj4gdHJhY2s6IDFoLCBvbmUgZGF5LCBvbmUg d2VlaywgZm9yZXZlcj8NCj4gDQo+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGJlIG1vcmUgc3Bl Y2lmaWMgYW5kIGdpdmUgZnVydGhlciBndWlkYW5jZT8gRS5nLg0KPiBob3cgYXJlIHRoZXNlIHBv aW50cyBpbXBsZW1lbnRlZCBpbiB0aGUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zPw0KPiANClRo aXMgd2FzIHRoZSBvcmlnaW5hbCBnb2FsIHdoZW4gd2Ugc3RhcnRlZCB3b3JraW5nIG9uIHRoaXMg ZHJhZnQuIEFzIHdvcmsgcHJvZ3Jlc3NlZCBpdCB3YXMgY2xlYXIgdGhhdCBnZXR0aW5nIGNvbnNl bnN1cyBvbiBhIHNwZWNpZmljIGFsZ29yaXRobSBvciBhbnkgc3BlY2lmaWMgdmFsdWUgcmVjb21t ZW5kYXRpb25zIHdvdWxkIGJlIHZlcnkgaGFyZCB0byBhY2hpZXZlLiBTb21lIHBlb3BsZSBjYXJl IGFib3V0IElQdjQgb3RoZXJzIGFib3V0IElQdjYgYW5kIHNvIG9uLiAgQnV0IEkgZG8gdGhpbmsg c2luY2UgdGhpcyBpcyBJRVRGIHdvcmsgd2UgaGF2ZSBhbiBvYmxpZ2F0aW9uIHRvIHB1c2ggSVB2 NiBmcmllbmRseSBzb2x1dGlvbnMuDQoNClNvIHRoZSBvdXRjb21lIG9mIHRoZSB3b3JrIGluIHRo ZSBXRyB3YXMgYSBCQ1AgdGhhdCBhY2tub3dsZWRnZXMgdGhhdCB0aGVyZSBpcyBhIHByb2JsZW0g dGhhdCBpbXBsZW1lbnRvcnMgc2hvdWxkIGJlIGF3YXJlIG9mIHdpdGggZ3VpZGVsaW5lcyBvbiB3 aGF0IHZhbHVlcyBmcm9tIHRoZSBJQ0UgUkZDIGNvdWxkIHNhZmVseSBiZSBhbHRlcmVkIHRvIGZp eCB0aGUgcHJvYmxlbS4gDQoNCkkgd291bGQgYWxzbyBleHBlY3QgYW55IGV4cGxpY2l0IGd1aWRl bGluZXMgdG8gY2hhbmdlIG92ZXIgdGltZS4gSSB0aGluayBpbXBsZW1lbnRlcnMgYXJlIGdldHRp bmcgdXNlZCB0byB0aGF0IG5vdyBhbmQgYXJlIGNvbGxlY3RpbmcgbWV0cmljcyB0aGF0IHRoZXkg Y2FuIHVzZSB0byBkeW5hbWljYWxseSBjaGFuZ2UgdGhlIHZhbHVlcy4gDQoNCldlIGNhbiBwdXQg d29yZGluZyBsaWtlIOKAnWEgZ29vZCBzdGFydGluZyBwb2ludCBtaWdodCBiZSAuLuKAnSwgYW5k IGFkZCBzb21lIHRleHQgcmVnYXJkaW5nIG1ldHJpY3MgYW5kIGNoYW5naW5nIGNvbmRpdGlvbnMg aW50byB0aGUgZHJhZnQuIA0KDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IEZ1cnRoZXIsIEkgdGhpbmsgdGhlIHRlcm0gJ2ZhaXJuZXNzJyBp cyBqdXN0IHdyb25nIGhlcmUuIFRoZSBnb2FsIGlzIHRvDQo+IGF2b2lkIGRlbGF5IGluIGNhc2Ug dGhlcmUgYXJlIGNvbm5lY3Rpdml0eSBwcm9ibGVtcyB3aXRoIElQdjYgaW4gZ2VuZXJhbCwNCj4g d2hpbGUgc3RpbGwgcHJpb3JpdGl6YXRpbmcgSVB2Ni4gRm9yIG1lLCB0aGF0J3Mgbm90aGluZyBh Ym91dCBmYWlybmVzcy4NCj4gDQo+IA0KVGhhdCBpcyB0aGUgZ29hbCwgYnV0IHRvIGFjaGlldmUg dGhhdCBnb2FsIHdlIG5lZWQgYSDigJxmYWly4oCdIGRpc3RyaWJ1dGlvbiBpZiBJUHY0IGFuZCBJ UHY2IGNhbmRpZGF0ZXMgaW4gdGhlIGNoZWNrbGlzdC4NCk9yIGEgc29sdXRpb24gdGhhdCBpcyDi gJxmcmVlIGZyb20gYmlhcyBvciBpbmp1c3RpY2XigJ0uIChmcm9tIGh0dHA6Ly93d3cuZGljdGlv bmFyeS5jb20vYnJvd3NlL2ZhaXJuZXNzKQ0KDQpCYXNlZCBvbiB0aGF0IChJIGFtIG5vdCBhIG5h dGl2ZSBzcGVha2VyLi4pLCBJIHRob3VnaHQgdGhlIG5hbWUgd2FzIGZpbmUuIEkgZG8gYWdyZWUg dGhhdCBpdCBtaWdodCBub3QgYmUgcGVyZmVjdCBvciBldmVuIGNsb3NlLCBzbyBhbnkgbmV3IHN1 Z2dlc3Rpb25zIHdvdWxkIGJlIG11Y2ggYXBwcmVjaWF0ZWQuIA0KDQoNClRoYW5rcyBmb3IgdGhv cm91Z2ggcmV2aWV3LiBNdWNoIGFwcHJlY2lhdGVkLiANCg0KLi0uDQpQw6VsLUVyaWsNCg0KDQoN Cg0K From nobody Mon Sep 5 03:31: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 A1B8C12B3CD; Mon, 5 Sep 2016 03:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 azt1lwkAkQtW; Mon, 5 Sep 2016 03:31:51 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D3812B3CB; Mon, 5 Sep 2016 03:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6910; q=dns/txt; s=iport; t=1473071511; x=1474281111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=B+YslRtGi1MVI2lw7zFb+nfwPdFxXW1mwX8QOSgdsro=; b=DLy1AZE/A3DqMIxbETVQ6GllFBjgwRWOs8fkhVJlRJMLTLv4b6n6WrnY 8GDA6dfA6pS8ZK+0wIMPQ0rwl/TeZ/Hz6/4/PAAPjXByD9SPdimicXZ27 oa8tHX67nD3FPU9xczhC7Fdd9B6J5lDuJhsIbKyn5D15Qjd9iOkz81jD2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQA/Sc1X/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgy0BAQEBAR5XfAeDQIlnqwWCAhkLhXgCHIEiOBQBAgEBAQEBAQFeJ4RhAQE?= =?us-ascii?q?BAwEBAQEgEToLBQsCAQgYAgIfBwICAiULFRACBA4FiEIIDrEajB0BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXBYEFhSqBeIJWhECDAiuCLwWILotchUkBhiCJFY9ZjEy?= =?us-ascii?q?DeQEeNoJfGxiBNXCFb38BAQE?= X-IronPort-AV: E=Sophos;i="5.30,286,1470700800"; d="scan'208";a="317709880" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2016 10:31:36 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u85AVZbP030083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Sep 2016 10:31:35 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Sep 2016 06:31:34 -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.1210.000; Mon, 5 Sep 2016 06:31:34 -0400 From: "Pal Martinsen (palmarti)" To: Alissa Cooper Thread-Topic: [Ice] Alissa Cooper's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT) Thread-Index: AQHSA7tygnfJ6+ywS0iGdyW2zO9QIKBq/O+A Date: Mon, 5 Sep 2016 10:31:34 +0000 Message-ID: References: <147267066090.31947.11172844437741066353.idtracker@ietfa.amsl.com> In-Reply-To: <147267066090.31947.11172844437741066353.idtracker@ietfa.amsl.com> 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.24.127.105] Content-Type: text/plain; charset="utf-8" Content-ID: <5A70D0CAB37518469D53E34C5620DFE2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ari.keranen@ericsson.com" , "ice@ietf.org" , "ice-chairs@ietf.org" , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] Alissa Cooper's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT) 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, 05 Sep 2016 10:31:52 -0000 DQo+IE9uIDMxIEF1ZyAyMDE2LCBhdCAyMToxMSwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3Bl cncuaW4+IHdyb3RlOg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pY2UtZHVhbHN0YWNrLWZhaXJuZXNzLw0KPiANCj4g DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ ID0gU2VjdGlvbiA0ID0NCj4gDQo+ICJIb3dldmVyLCBtb2RpZnlpbmcgdGhlIGNoZWNrIGxpc3QN Cj4gICBkaXJlY3RseSBjYW4gbGVhZCB0byB1bmNvb3JkaW5hdGVkIGxvY2FsIGFuZCByZW1vdGUg Y2hlY2sgbGlzdHMgdGhhdA0KPiAgIHJlc3VsdCBpbiBJQ0UgdGFraW5nIGxvbmdlciB0byBjb21w bGV0ZSBvciBpbiB0aGUgd29yc3QgY2FzZSBzY2VuYXJpbw0KPiAgIGZhaWwuICBUaGUgYmVzdCBh cHByb2FjaCBpcyB0byBtb2RpZnkgdGhlIGZvcm11bGEgZm9yIGNhbGN1bGF0aW5nIHRoZQ0KPiAg IGNhbmRpZGF0ZSBwcmlvcml0eSB2YWx1ZSBkZXNjcmliZWQgaW4gSUNFIFtJLUQuaWV0Zi1pY2Ut cmZjNTI0NWJpc10NCj4gICBzZWN0aW9uICI0LjEuMi4xIFJlY29tbWVuZGVkIEZvcm11bGEiLiIN Cj4gDQo+IElDRWJpcyBzZWN0aW9uIDQuMS4yLjEgdGhlbiBzYXlzOg0KPiANCj4gIklmIGEgaG9z dCBpcw0KPiAgIG11bHRpaG9tZWQgYmVjYXVzZSBpdCBpcyBkdWFsLXN0YWNrLCB0aGUgbG9jYWwg cHJlZmVyZW5jZSBzaG91bGQgYmUNCj4gICBzZXQgYWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IGJl c3QgcHJhY3RpY2UgZGVzY3JpYmVkIGluDQo+ICAgW0ktRC5pZXRmLWljZS1kdWFsc3RhY2stZmFp cm5lc3NdLiINCj4gDQo+IFNvLCB0aGVyZSBpcyBhIGNpcmN1bGFyIHJlZmVyZW5jZSwgYW5kIG5v d2hlcmUgaXMgaXQgc3BlY2lmaWVkIGhvdyB0aGUNCj4gZm9ybXVsYSBzaG91bGQgYWN0dWFsbHkg Y2hhbmdlLiBJIHRoaW5rIGl0J3MgZmluZSB0byBwdXQgdGhpcyBpbiBJQ0ViaXMsDQo+IGJ1dCBp ZiB0aGlzIGRyYWZ0IGlzIGdvaW5nIHRvIHJlZmVyZW5jZSBpdCB0aGVuIGl0IGFjdHVhbGx5IG5l ZWRzIHRvIGJlDQo+IHNwZWNpZmllZCB0aGVyZS4NCj4gDQo+IEFsdGVybmF0aXZlbHksIGlmIHRo aXMgdGV4dCBpcyBtZWFudCB0byByZWZlcmVuY2UgdGhlIGRpc2N1c3Npb24gZnVydGhlcg0KPiBk b3duIGluIFNlY3Rpb24gNSwgSSB3b3VsZG4ndCBjYWxsIHRoYXQgbW9kaWZ5aW5nIHRoZSBmb3Jt dWxhLCBidXQgcmF0aGVyDQo+IHByb3ZpZGluZyBndWlkYW5jZSBhYm91dCBob3cgdG8gc2V0IGxv Y2FsIHByZWZlcmVuY2VzIHdpdGhpbiB0aGUgZm9ybXVsYS4NCj4gDQpZZXMuIE1vZGlmeWluZyBp cyBiYWQgd29yZGluZy4NCg0KQ2hhbmdlZCB0bzoNCuKAnCAgSG93ZXZlciwgbW9kaWZ5aW5nIHRo ZSBjaGVjayBsaXN0DQogICBkaXJlY3RseSBjYW4gbGVhZCB0byB1bmNvb3JkaW5hdGVkIGxvY2Fs IGFuZCByZW1vdGUgY2hlY2sgbGlzdHMgdGhhdA0KICAgcmVzdWx0IGluIElDRSB0YWtpbmcgbG9u Z2VyIHRvIGNvbXBsZXRlIG9yIGluIHRoZSB3b3JzdCBjYXNlIHNjZW5hcmlvDQogICBmYWlsLiAg VGhlIGJlc3QgYXBwcm9hY2ggaXMgdG8gc2V0IHRoZSBhcHByb3ByaWF0ZSB2YWx1ZSBmb3IgbG9j YWwNCiAgIHByZWZlcmVuY2UgaW4gdGhlIGZvcm11bGEgZm9yIGNhbGN1bGF0aW5nIHRoZSBjYW5k aWRhdGUgcHJpb3JpdHkNCiAgIHZhbHVlIGRlc2NyaWJlZCBpbiBJQ0UgW0ktRC5pZXRmLWljZS1y ZmM1MjQ1YmlzXSBzZWN0aW9uICI0LjEuMi4xDQogICBSZWNvbW1lbmRlZCBGb3JtdWxh4oCdLiIN Cg0KDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+ID0gU2VjdGlvbiAzID0NCj4gDQo+ICJJZiB0aGUgYWdlbnQgaGFzIGFjY2VzcyB0bw0KPiAg IGluZm9ybWF0aW9uIGFib3V0IHRoZSBwaHlzaWNhbCBuZXR3b3JrIGl0IGlzIGNvbm5lY3RlZCB0 byAoTGlrZSBTU0lEDQo+ICAgaW4gYSBXaUZpIE5ldHdvcmspIHRoaXMgY2FuIGJlIHVzZWQgYXMg aW5mb3JtYXRpb24gcmVnYXJkaW5nIGhvdyB0aGF0DQo+ICAgbmV0d29yayBpbnRlcmZhY2Ugc2hv dWxkIGJlIHByaW9yaXRpemVkIGF0IHRoaXMgcG9pbnQgaW4gdGltZS4iDQo+IA0KPiBJIHRoaW5r IHRoaXMgbmVlZHMgZnVydGhlciBlbGFib3JhdGlvbiwgYXMgaXQncyBub3Qgb2J2aW91cyBob3cg a25vd2xlZGdlDQo+IG9mIHRoZSBTU0lEIGNvcnJlbGF0ZXMgdG8ga25vd2xlZGdlIG9mIHRoZSBz dGFiaWxpdHkgb2YgdGhlIG5ldHdvcmsuDQo+IA0KDQpJIHRoaW5rIHRoZSB3aG9sZSBzZW50ZW5j ZSBjb3VsZCBzYWZlbHkgYmUgcmVtb3ZlZC4gVGhlIHByZXZpb3VzIHNlbnRlbmNlLA0KDQrigJwg VG8gYXZvaWQgdW5uZWNlc3NhcnkgZGVsYXkgd2hlbiBwZXJmb3JtaW5nIGNvbm5lY3Rpdml0eSBj aGVja3MgaXQgd291bGQNCiAgIGJlIGJlbmVmaWNpYWwgdG8gcHJpb3JpdGl6ZSBpbnRlcmZhY2Vz IGFuZCBJUCBhZGRyZXNzZXMga25vd24gYnkgdGhlDQogICBhZ2VudCB0byBwcm92aWRlIHN0YWJs ZSBjb25uZWN0aXZpdHku4oCdLA0KDQpkZXNjcmliZXMgdGhlIGludGVudCBmYWlybHkgY2xlYXIu IA0KDQoNCkhvdyB0aGluZ3MgYXJlIOKAnGtub3duIHQgdGhlIGFwcGxpY2F0aW9u4oCdIHdvdWxk IHZhcnkgZnJvbSBPU2VzIGFuZCBlbnZpcm9ubWVudHMgdGhlIGFnZW50IGlzIG9wZXJhdGluZyBp bi4gDQoNCg0KDQo+ICJDYW5kaWRhdGVzIGZyb20gYW4gaW50ZXJmYWNlIGtub3duIHRvIHRoZSBh cHBsaWNhdGlvbiB0byBwcm92aWRlDQo+ICAgdW5yZWxpYWJsZSBjb25uZWN0aXZpdHkgc2hvdWxk IGdldCBhIGxvdyBjYW5kaWRhdGUgcHJpb3JpdHkuICBUaGlzDQo+ICAgZW5zdXJlcyB0aGV5IGFw cGVhciBuZWFyIHRoZSBlbmQgb2YgdGhlIGNhbmRpZGF0ZSBsaXN0LCBhbmQgd291bGQgYmUNCj4g ICB0aGUgbGFzdCB0byBiZSB0ZXN0ZWQgZHVyaW5nIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgcGhh c2UuICBUaGlzDQo+ICAgYWxsb3dzIGNhbmRpZGF0ZSBwYWlycyBtb3JlIGxpa2VseSB0byBzdWNj ZWVkIHRvIGJlIHRlc3RlZCBmaXJzdC4iDQo+IA0KPiBBbGwgdGhyZWUgb2YgdGhlc2Ugc2VudGVu Y2VzIHNheSBtb3JlIG9yIGxlc3MgdGhlIHNhbWUgdGhpbmcsIHNvIHR3byBvZg0KPiB0aGVtIGNv dWxkIGJlIGRyb3BwZWQuDQoNCjotKSANCg0KTmV3IHRleHQ6DQoiQ2FuZGlkYXRlcyBmcm9tIGFu IGludGVyZmFjZSBrbm93biB0byB0aGUgYXBwbGljYXRpb24gdG8gcHJvdmlkZQ0KICAgdW5yZWxp YWJsZSBjb25uZWN0aXZpdHkgc2hvdWxkIGdldCBhIGxvdyBjYW5kaWRhdGUgcHJpb3JpdHku4oCd DQoNCj4gDQo+ID0gU2VjdGlvbiA4ID0NCj4gDQo+IERvZXNuJ3QgZm9sbG93aW5nIHRoZSByZWNv bW1lbmRhdGlvbnMgaW4gU2VjdGlvbiAzIHBvdGVudGlhbGx5IGxlYWsNCj4gaW5mb3JtYXRpb24g dG8gYSByZW1vdGUgcGVlciBhYm91dCB0aGUgcXVhbGl0eSBvZiBhIGxvY2FsIHBlZXIncw0KPiBj b25uZWN0aXZpdHkgb24gZGlmZmVyZW50IGludGVyZmFjZXM/IFRoYXQgaXMsIGlmIHRoZSByZW1v dGUgcGVlcg0KPiBtYWludGFpbnMgc29tZSBzdGF0ZSBhYm91dCBwYXN0IElDRSBpbnRlcmFjdGlv bnMsIHdvdWxkIGl0IGJlIGFibGUgdG8NCj4gZGV0ZWN0IGEgY2hhbmdlIG9mIHByaW9yaXR5IHRo YXQgY291bGQgaW5kaWNhdGUgYSBjaGFuZ2UgaW4gY29ubmVjdGl2aXR5DQo+IHF1YWxpdHk/IElm IHNvLCB0aGlzIHNlZW1zIHdvcnRoIG1lbnRpb25pbmcuDQo+IA0KPiANClNvcnQgb2YuIFRoZSBw YXNzaXZlIGF0dGFja2VyIGNvdWxkIHBvc3NpYmxlIGxlYXJuIHRoZSBzYW1lIGluZm9ybWF0aW9u IGJ5IGxvb2tpbmcgYXQgdGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgaW4gdGhlIHdpdGhvdXQgdGhp cyBhcyB3ZWxsLg0KDQpCdXQgdGhpcyBsZWFrcyBob3cgdGhlIGN1cnJlbnQgYWdlbnQgcHJpb3Jp dGllcyB0aGUgZGlmZmVyZW50IG5ldHdvcmsgaW50ZXJmYWNlcyAoUmVhbGx5IElQIGFkZHJlc3Nl cywgYmVjYXVzZSB0aGUgcmVtb3RlIHBlZXIgd291bGQgbm90IGtub3cgd2hhdCBpbnRlcmZhY2Ug aGFzIHdoYXQgSVAgYWRkcmVzcywgYXQgbGVhc3Qgbm90IHdpdGggSVB2Ni4pDQoNCk5ldyBTZWN1 cml0eSBTZWN0aW9uOg0KIlRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4g W0ktRC5pZXRmLWljZS1yZmM1MjQ1YmlzXQ0KICAgYXJlIHN0aWxsIHZhbGlkLiAgSXQgY2hhbmdl cyByZWNvbW1lbmRlZCB2YWx1ZXMgYW5kIGRlc2NyaWJlcyBob3cgYW4NCiAgIGFnZW50IGNvdWxk IGNob29zZSB0aG9zZSB2YWx1ZXMgaW4gYSBzYWZlIHdheS4gIEluIHNlY3Rpb24gU2VjdGlvbiAz DQogICB0aGUgYWdlbnQgY2FuIHByaW9yaXRpemUgdGhlIG5ldHdvcmsgaW50ZXJmYWNlIGJhc2Vk IG9uIHByZXZpb3VzDQogICBuZXR3b3JrIGtub3dsZWRnZS4gIFRoaXMgY2FuIHBvdGVudGlhbGx5 IGJlIHVud2FudGVkIGluZm9ybWF0aW9uDQogICBsZWFrYWdlIHRvd2FyZHMgdGhlIHJlbW90ZSBh Z2VudC7igJ0NCg0KDQpUaGFua3MgZm9yIHRoZSB0aG9yb3VnaCByZXZpZXchDQoNCi4tLg0KUMOl bC1FcmlrDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBJY2UgbWFpbGluZyBsaXN0DQo+IEljZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQo= From nobody Mon Sep 5 03:54: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 7A93C12B1A2; Mon, 5 Sep 2016 03:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 4OJKlYh9mbd7; Mon, 5 Sep 2016 03:54:23 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCE312B005; Mon, 5 Sep 2016 03:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2960; q=dns/txt; s=iport; t=1473072862; x=1474282462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=II94NjjiNq0Mn9U30f1oZCTCap+x61fZiiSBfbOkn88=; b=cXv9lmuMVOsTFrh9EBMf9LO3f8UcMlCGw8a76Ky99qvL6PFk1ikNDmD3 ffmmGTfpPJZjTn6cCXABgIA286b1l2c4iGZd+vgWPgQH2WurYjP3jW3nr Kd0/Rja17qb7H8FCKiagHG4F9zmlDZF8DB9412ao6Tyjpjk8VIqWUp682 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQBgTs1X/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgy0BAQEBAR5XfAeDQIlnqHaCD4ICJIV4AhyBIjgUAQIBAQEBAQEBXieEYQE?= =?us-ascii?q?BAQMBIxFFBQsCAQgYAgImAgICMBUQAgQOBYhCCA6xHIwdAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWBBYUqgXiCVoQSEQGDHiuCLwWILotchUkBhiCJFYFuhF6JDYx?= =?us-ascii?q?Mg3kBHjaDEoE1cAGEToEgfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,286,1470700800"; d="scan'208";a="319601924" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2016 10:54:13 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u85AsDiX004723 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Sep 2016 10:54:13 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Sep 2016 06:54:12 -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.1210.000; Mon, 5 Sep 2016 06:54:12 -0400 From: "Pal Martinsen (palmarti)" To: Suresh Krishnan Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT) Thread-Index: AQHSBBBaOj7GZs7qpUeiAr+w0Q47EKBrApkA Date: Mon, 5 Sep 2016 10:54:12 +0000 Message-ID: <752F4956-B4ED-43AA-AAA3-19B9ADE2498D@cisco.com> References: <147270713819.31873.6764477510963743918.idtracker@ietfa.amsl.com> In-Reply-To: <147270713819.31873.6764477510963743918.idtracker@ietfa.amsl.com> 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.24.127.105] Content-Type: text/plain; charset="utf-8" Content-ID: <8C30B2BA017EF44D8D127E1C4944F2C4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , Ari Keranen , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT) 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, 05 Sep 2016 10:54:24 -0000 DQo+IE9uIDAxIFNlcCAyMDE2LCBhdCAwNzoxOCwgU3VyZXNoIEtyaXNobmFuIDxzdXJlc2gua3Jp c2huYW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IFN1cmVzaCBLcmlzaG5hbiBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1pY2Ut ZHVhbHN0YWNrLWZhaXJuZXNzLTA0OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiAN Cj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pY2UtZHVhbHN0YWNrLWZh aXJuZXNzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+ICogU2VjdGlvbiA0DQo+IA0KPiBJIGFtIHRyeWluZyB0byBzZWUgaWYg dGhlcmUgaXMgYW55IGJhY2tncm91bmQgZm9yIHRoZSBmb2xsb3dpbmcNCj4gc3RhdGVtZW50DQo+ IA0KPiAiSXQgaXMgd29ydGggbm90aW5nIHRoYXQgdGhlIHRpbWluZyByZWNvbW1lbmRhdGlvbnMg aW4gW1JGQzY1NTVdIGFyZSBub3QNCj4gb3B0aW1hbCBmb3IgSUNFIHVzYWdlLuKAnQ0KPiANCj4g V2h5IGlzIGl0IG5vdCBvcHRpbWFsPyBEbyB5b3Ugd2FudCBzbWFsbGVyIG9yIGxhcmdlciB0aW1p bmdzPyBTb21lDQo+IGV4cGxhbmF0aW9ucyBoZXJlIHdvdWxkIGJlIGdvb2QuIEFkZGl0aW9uYWxs eSwgaXQgbWlnaHQgYmUgd29ydGh3aGlsZSBmb3INCj4gdGhpcyBkb2N1bWVudCB0byBwcm92aWRl IGFsdGVybmF0ZSB0aW1pbmcgcmVjb21tZW5kYXRpb25zIHRoYXQgKmFyZSoNCj4gb3B0aW1hbC4N Cj4gDQpSZXdvcmRlZCB0bzoNCiJJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCB0aGUgdGltaW5nIHJl Y29tbWVuZGF0aW9ucyBpbiBbUkZDNjU1NV0gd2lsbA0KICAgYmUgb3ZlcnJ1bGVkIGJ5IGhvdyBJ Q0UgcGFjZXMgb3V0IGl0cyBjb25uZWN0aXZpdHkgY2hlY2tzLuKAnQ0KDQpIb3cgZmFzdCBJQ0Ug Y2FuIGFjdHVhbGx5IHNlbmQgdGhvc2UgY29ubmVjdGl2aXR5IGNoZWNrcyB3aXRob3V0IGJyZWFr aW5nIE5BVHMgYW5kIG5vdCBjb25zdW1lIHRvIG11Y2ggYmFuZHdpZHRoIGlzIHN0aWxsIGRpc2N1 c3NlZCBpbiB0aGUgSUNFIHdnLiANCkJ1dCB0aGlzIG1pZ2h0IGJlIHNpZ25pZmljYW50bHkgZmFz dGVyIHRoYXQgd2hhdCBpcyBkZXNjcmliZWQgaW4gdGhlIEhFIFJGQy4gDQoNCg0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAqIEFncmVlIHdp dGggQWxpc3NhJ3MgRElTQ1VTUyBwb2ludC4gSSByYW4gaW50byB0aGUgc2FtZSBjaXJjdWxhcg0K PiByZWZlcmVuY2UNCg0KVHJpZWQgdG8gZml4Lg0KPiAqIEFncmVlIHdpdGggTWlyamHigJlzIGNv bW1lbnQgYWJvdXQgZmFpcm5lc3MgYmVpbmcgdGhlIHdyb25nIHRlcm0gdG8gdXNlDQo+IA0KVGVu ZCB0byBhZ3JlZSBhcyB3ZWxsLCBidXQgaGF2ZSBubyBvdGhlciBzdWdnZXN0aW9ucy4NCg0KDQpU aGFua3MgZm9yIHRoZSB0aG9yb3VnaCByZXZpZXchDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0K From nobody Mon Sep 5 06:11:00 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 300F212B27F; Mon, 5 Sep 2016 06:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 C87-8QcIxtst; Mon, 5 Sep 2016 06:10:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E3812B279; Mon, 5 Sep 2016 06:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2752; q=dns/txt; s=iport; t=1473081050; x=1474290650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ikW3y7y39F6D2AvnuticZM6mnJYpPI8PnpLaBpouvgA=; b=DkrDnre47djbyBM3NkF+3xf0zEOWAFH0jQfc8OvqJGvEMq6O1NCuN1Xr rMcWwNBoLJK607QrxtNiq1UgToAOpjHj5a10wBnY7tHTc6xjQHgRggq1w R7DBKle/RzDrOz9yRWP4kSaRfC5E53ceA2tAtFx1IPB8BuR5PJCAEU6qK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQDUbc1X/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgy0BAQEBAR5XfAeDQIlnnlCKJoIPggIkhXgCHIElOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwEjEUUFCwIBCBgCAiYCAgIfERUQAgQOBYgwAw8IDrEViHcNgxsBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEXBYEFhSqBeAiBS4EDgkOBTxEBgx4rgi8FiC6LXIU?= =?us-ascii?q?VNAGGIIY+glcKgWSEXokNiEKECoN5AR42gxKBNXABhDyBIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,286,1470700800"; d="scan'208";a="145494141" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2016 13:10:49 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u85DAnm8029122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Sep 2016 13:10:49 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Sep 2016 09:10:48 -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.1210.000; Mon, 5 Sep 2016 09:10:48 -0400 From: "Pal Martinsen (palmarti)" To: Spencer Dawkins Thread-Topic: Spencer Dawkins' Yes on draft-ietf-ice-dualstack-fairness-04: (with COMMENT) Thread-Index: AQHSAsYQPZ7CkOQm3Ue1ShWujb62s6BrK1gA Date: Mon, 5 Sep 2016 13:10:48 +0000 Message-ID: References: <147256527848.23813.11022595025051147184.idtracker@ietfa.amsl.com> In-Reply-To: <147256527848.23813.11022595025051147184.idtracker@ietfa.amsl.com> 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.24.54.135] Content-Type: text/plain; charset="utf-8" Content-ID: <04FCB88BB9D7D745A95D3A27D18D4449@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , Ari Keranen , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] Spencer Dawkins' Yes on draft-ietf-ice-dualstack-fairness-04: (with COMMENT) 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, 05 Sep 2016 13:10:53 -0000 DQo+IE9uIDMwIEF1ZyAyMDE2LCBhdCAxNTo1NCwgU3BlbmNlciBEYXdraW5zIDxzcGVuY2VyZGF3 a2lucy5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBTcGVuY2VyIERhd2tpbnMgaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtaWNl LWR1YWxzdGFjay1mYWlybmVzcy0wNDogWWVzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4g UGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1 c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pY2UtZHVhbHN0YWNrLWZhaXJu ZXNzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IFRoYW5rcyBmb3IgZG9pbmcgdGhpcyB3b3JrLg0KPiANCj4gVGhlIGRvY3Vt ZW50IHRoaW5rcyBpdCdzIGdvaW5nIGZvciBCZXN0IEN1cnJlbnQgUHJhY3RpY2UsIGJ1dCB0aGUN Cj4gc2hlcGhlcmQgd3JpdGUtdXAgYW5kIGRhdGF0cmFja2VyIHRoaW5rIGl0J3MgZ29pbmcgZm9y IEluZm9ybWF0aW9uYWwuIEl0DQo+IHdvdWxkIGJlIGdvb2QgZm9yIHRoYXQgdG8gbWF0Y2ggLi4u DQo+IA0KPiBJJ20gYSBsaXR0bGUgY29uZnVzZWQgYnkgDQo+IA0KPiAgIFRoZXNlIHJlY29tbWVu ZGF0aW9ucyBhcmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGEgc3RhbmRhcmQgSUNFDQo+ICAg aW1wbGVtZW50YXRpb24uICBUaGUgcmVzdWx0aW5nIGxvY2FsIGFuZCByZW1vdGUgY2hlY2tsaXN0 IHdpbGwgc3RpbGwNCj4gICBiZSBzeW5jaHJvbml6ZWQuICBUaGUgaW50cm9kdWNlZCBmYWlybmVz cyBtaWdodCBiZSBiZXR0ZXIsIGJ1dCBub3QNCj4gICB3b3JzZSB0aGFuIHdoYXQgZXhpc3RzIHRv ZGF5DQo+IA0KPiBJcyB0aGUgcG9pbnQgdGhhdCB0aGUgaW50cm9kdWNlZCBmYWlybmVzcyANCj4g LSBtaWdodCBiZSBiZXR0ZXIsIG9yIA0KPiAtIG1pZ2h0IGJlIHRoZSBzYW1lIGFzLCBidXQNCj4g LSB3b24ndCBiZSB3b3JzZT8NCj4gDQo+IElmIHNvLCB0aGF0IHdhc24ndCBjbGVhciB0byBtZSBv biBmaXJzdCAob3Igc2Vjb25kKSByZWFkaW5nLg0KPiANCg0KSG93IGFib3V0Og0KIlRoZXNlIHJl Y29tbWVuZGF0aW9ucyBhcmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGEgc3RhbmRhcmQgSUNF DQogICBpbXBsZW1lbnRhdGlvbi4gIFRoZSByZXN1bHRpbmcgbG9jYWwgYW5kIHJlbW90ZSBjaGVj a2xpc3Qgd2lsbCBzdGlsbA0KICAgYmUgc3luY2hyb25pemVkLiAgVGhlIGludHJvZHVjZWQgZmFp cm5lc3MgbWlnaHQgYmUgYmV0dGVyIG9yIGVxdWFsLCANCiAgIGJ1dCBub3Qgd29yc2UgdGhhbiB3 aGF0IGV4aXN0cyB0b2RheS7igJ0NCg0KU3RpbGwgc29tZXRoaW5nIHdlaXJkIGFib3V0IHRoZSBs YW5ndWFnZeKApg0KDQoNCj4gKE5pdDogbWlzc2luZyBwZXJpb2QgYXQgdGhlIGVuZCBvZiAid2hh dCBleGlzdHMgdG9kYXkiKQ0KPiANCj4gDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4NCg0KLi0u DQpQw6VsLUVyaWsNCg0K From nobody Mon Sep 5 12:29: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 F2C3812B461; Mon, 5 Sep 2016 12:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 st1h5A_vSJHJ; Mon, 5 Sep 2016 12:29:34 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002: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 9E9C212B058; Mon, 5 Sep 2016 12:29:34 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id x93so62804292ybh.1; Mon, 05 Sep 2016 12:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b9StSOCUrSmIs4qHwSDxJDJVibZ9ZByulQUUHmf0FJQ=; b=w9Z63rmQfCy1bUMesgTMjYlyUU8JXx+/svAQJJoaB3p2lGEfYURPymbOi+sq5FvnpT YHtrE1RakoAeQDqgl7JnPHrNKuibFydcKnTYbm4QijPme/IdCOLi75HwHY3s8/E+oKJq F40dv554TsxaJuX2Nnpko4B6JXCTEAdZxYhz1UXyTDTC8P1rK+YMr5bdSW3v/HrtcnWy n6LzOxkizf1u8q49VosvZV1TWZkuSJTYETUBVN9sUBcLuX3Wq+qvrkUPT3I6q6RZL6mk RwGNqSupPGl3SIBG+t7Eb79ZNB3o31RCFrADQt5sqmnKMgLX+O7j7DAMMJoSjRNn/zT/ ktgw== 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=b9StSOCUrSmIs4qHwSDxJDJVibZ9ZByulQUUHmf0FJQ=; b=VHzk75hS87NFZBY+rxkLrn7pI+k1r2UjtC7Hp7Z1To96Pv4FjLpwY6YnMyxMYhtCPI sTPcmJCzot5SRkER5saZrOBxcOSd26BE/1CJTS9yW4gba+twut8mXtU5J8Rnz2QDWImI ztz4TFZdB17ykCOwQKwwnDUP2aS2jvcMOlJZObp5ag8Q1cCg6+bzy+X2jL7pPazZ7elU D6jv87l9tKwq9Nr3liXHSppZ5cYgmAJvhWiwHAv9Zb7cT/7mutSo4UUrJLWMBlwWLzp+ +D+rDlX8bQg6RYkRNnRXopAzRRwgToeXaJa2Eca6zodOY6eZAq7lSVAfQOGbuwD0VNGg ORgg== X-Gm-Message-State: AE9vXwPXw61QMCKGb4h5gRpW6v+w1UzJzH8GLn3U1gerIdiSNQw+a5E/Xz99RK+8lqQDWxCPuOeJYJNsKdgGxA== X-Received: by 10.37.221.129 with SMTP id u123mr29036795ybg.61.1473103773730; Mon, 05 Sep 2016 12:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Mon, 5 Sep 2016 12:29:33 -0700 (PDT) In-Reply-To: <3D60787A-FD67-472D-8787-C5EEA6B8BB9F@cisco.com> References: <147264668629.5913.9417537450161055669.idtracker@ietfa.amsl.com> <3D60787A-FD67-472D-8787-C5EEA6B8BB9F@cisco.com> From: Spencer Dawkins at IETF Date: Mon, 5 Sep 2016 14:29:33 -0500 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=94eb2c0337d4268d27053bc7b344 Archived-At: Cc: Ari Keranen , "draft-ietf-ice-dualstack-fairness@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , Mirja Kuehlewind , The IESG Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-ic?= =?utf-8?q?e-dualstack-fairness-04=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 05 Sep 2016 19:29:37 -0000 --94eb2c0337d4268d27053bc7b344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Pal, On Mon, Sep 5, 2016 at 3:23 AM, Pal Martinsen (palmarti) wrote: > > > On 31 Aug 2016, at 14:31, Mirja Kuehlewind wrote: > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I'm willing to resolve my discuss quickly but I would like to start som= e > > discussion: > > > > To me the recommenations given in this doc are not very clear. To my > > understanding are there two recommenations: > > > > 1) intermingle IPv4 and IPv6 addresses, and > > 2) put lower priority for adresses that are know to have connectivity > > problem. > > > Correct. > > > > However, that leaves tons of open questions to the implementor, e.g. > > - How many IPv6 addresses should I have before the first IPv4? > > - How do I measure/track that an interface has connectitivy problems: > > connectivity failed once, or twice, or X-times? How long do I keep this > > track: 1h, one day, one week, forever? > > > > Would it be possible to be more specific and give further guidance? E.g= . > > how are these points implemented in the existing implementations? > > > This was the original goal when we started working on this draft. As work > progressed it was clear that getting consensus on a specific algorithm or > any specific value recommendations would be very hard to achieve. Some > people care about IPv4 others about IPv6 and so on. But I do think since > this is IETF work we have an obligation to push IPv6 friendly solutions. > > So the outcome of the work in the WG was a BCP that acknowledges that > there is a problem that implementors should be aware of with guidelines o= n > what values from the ICE RFC could safely be altered to fix the problem. > > I would also expect any explicit guidelines to change over time. I think > implementers are getting used to that now and are collecting metrics that > they can use to dynamically change the values. > > We can put wording like =E2=80=9Da good starting point might be ..=E2=80= =9D, and add some > text regarding metrics and changing conditions into the draft. This isn't my Discuss, so please focus on Mirja's feedback, but I find this explanation very helpful, and think your suggestion in this paragraph ( ^^ ) is a good one. Mirja and I did talk about this aspect of the draft during IESG evaluation, and I thought her Discuss was pointed in the right direction. So, thank you. Spencer > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Further, I think the term 'fairness' is just wrong here. The goal is to > > avoid delay in case there are connectivity problems with IPv6 in genera= l, > > while still prioritizating IPv6. For me, that's nothing about fairness. > > > > > That is the goal, but to achieve that goal we need a =E2=80=9Cfair=E2=80= =9D distribution > if IPv4 and IPv6 candidates in the checklist. > Or a solution that is =E2=80=9Cfree from bias or injustice=E2=80=9D. (fro= m > http://www.dictionary.com/browse/fairness) > > Based on that (I am not a native speaker..), I thought the name was fine. > I do agree that it might not be perfect or even close, so any new > suggestions would be much appreciated. > > > Thanks for thorough review. Much appreciated. > > .-. > P=C3=A5l-Erik > > > > > --94eb2c0337d4268d27053bc7b344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Pal,

On Mon, Sep 5, 2016 at 3:23 AM, Pal Martinsen (palmarti) <palmar= ti@cisco.com> wrote:

> On 31 Aug 2016, at 14:31, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org= /doc/draft-ietf-ice-dualstack-fairness/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> I'm willing to resolve my discuss quickly but I would like to star= t some
> discussion:
>
> To me the recommenations given in this doc are not very clear. To my > understanding are there two recommenations:
>
> 1) intermingle IPv4 and IPv6 addresses, and
> 2) put lower priority for adresses that are know to have connectivity<= br> > problem.
>
Correct.


> However, that leaves tons of open questions to the implementor, e.g. > - How many IPv6 addresses should I have before the first IPv4?
> - How do I measure/track that an interface has connectitivy problems:<= br> > connectivity failed once, or twice, or X-times? How long do I keep thi= s
> track: 1h, one day, one week, forever?
>
> Would it be possible to be more specific and give further guidance? E.= g.
> how are these points implemented in the existing implementations?
>
This was the original goal when we started working on this draft. As= work progressed it was clear that getting consensus on a specific algorith= m or any specific value recommendations would be very hard to achieve. Some= people care about IPv4 others about IPv6 and so on.=C2=A0 But I do think s= ince this is IETF work we have an obligation to push IPv6 friendly solution= s.

So the outcome of the work in the WG was a BCP that acknowledges that there= is a problem that implementors should be aware of with guidelines on what = values from the ICE RFC could safely be altered to fix the problem.

I would also expect any explicit guidelines to change over time. I think im= plementers are getting used to that now and are collecting metrics that the= y can use to dynamically change the values.

We can put wording like =E2=80=9Da good starting point might be ..=E2=80=9D= , and add some text regarding metrics and changing conditions into the draf= t.

This isn't my Discuss, so please foc= us on Mirja's feedback, but I find this explanation very helpful, and t= hink your suggestion in this paragraph ( ^^ ) is a good one. Mirja and I di= d talk about this aspect of the draft during IESG evaluation, and I thought= her Discuss was pointed in the right direction.=C2=A0

=
So, thank you.

Spencer
=C2=A0
=
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Further, I think the term 'fairness' is just wrong here. The g= oal is to
> avoid delay in case there are connectivity problems with IPv6 in gener= al,
> while still prioritizating IPv6. For me, that's nothing about fair= ness.
>
>
That is the goal, but to achieve that goal we need a =E2=80=9Cfair= =E2=80=9D distribution if IPv4 and IPv6 candidates in the checklist.
Or a solution that is =E2=80=9Cfree from bias or injustice=E2=80=9D. (from = http://www.dictionary.com/browse/fairness)

Based on that (I am not a native speaker..), I thought the name was fine. I= do agree that it might not be perfect or even close, so any new suggestion= s would be much appreciated.


Thanks for thorough review. Much appreciated.

.-.
P=C3=A5l-Erik





--94eb2c0337d4268d27053bc7b344-- From nobody Mon Sep 5 12:48:05 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 EF52912B283; Mon, 5 Sep 2016 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=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 xkI4l6ugRsWG; Mon, 5 Sep 2016 12:47:57 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 DE9CF12B0B0; Mon, 5 Sep 2016 12:47:56 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id s85so13575563ywg.3; Mon, 05 Sep 2016 12:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKgkT6ZRwTTKx5flZv+EJudA3CgOk790aE5PnjinAhg=; b=Cc3GCgiAUDX61M3H9OTVNuYpwagNaD6E8+jXJV6fV3GM7bKFF9P0Kp9DHEK+zoQaOM I3V89BezcparmrpT2Cx71t+qAqdfZ+co5TVAKj0mZj2QdvTzSEHsouQB50EDPCxIsyfH zHXbRUd722SeO3phcVFsgpJkYxCTSPKUoJeth9lvXMLzc8y04D3nPdQApyb0/dG1sEUr cHokKA62zlOH/Sd6tMqlIMRHhon9JlmkkqZTMPxOuAmAUwzQgJ+0fmO/fCaqwpHOVMhx FkbBnEChsNfGk/heaVCpLsELuXBax2PjOMTqeFx0d1R7N/GosmbJpaX7YJg63nUhgzxq s40w== 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=DKgkT6ZRwTTKx5flZv+EJudA3CgOk790aE5PnjinAhg=; b=BBmz4tgKFeUSTTBlJirpmtlKbnC5BddLIULPiR64kIS3JhRQO3ocijArN4MI2x4420 iP3aD1/CdEcH04iQetgdGutPv/SBSskkFYVCUjQTOyMA9B4j5IG0AqJvUfVhdhjYVYIq 1dxeP12xUGZONvvwj1oLnJb1OUMVTgGnbxJKbIgRb+54h8KWWBykuyPME0ZoWl/Oh4pK FdU1DQ/iOPHjh7nHb9ak3vjAyu9nAleZHJS/oSQoBDqIgH0YWIibhpE9fXkFECrbYIJQ N8KJCQdsKzX1miY8+MJ2wmcQxwK2iL0N+0Ro38WIQ2u0KSvO8eHUI8JC2n4LGvh8b8lY 2AbA== X-Gm-Message-State: AE9vXwPfBHR3uWx3m6je0Z0ShhGxMRyoO/pV+l0GlUp3Gx/4zSaDsqNu6At2WVh8iNS9o9HLuWwYCXgE+VaJuQ== X-Received: by 10.13.200.5 with SMTP id k5mr30463912ywd.23.1473104876172; Mon, 05 Sep 2016 12:47:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Mon, 5 Sep 2016 12:47:55 -0700 (PDT) In-Reply-To: References: <147256527848.23813.11022595025051147184.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 5 Sep 2016 14:47:55 -0500 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a114e5624dc7ce5053bc7f4b9 Archived-At: Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , Ari Keranen , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] Spencer Dawkins' Yes on draft-ietf-ice-dualstack-fairness-04: (with COMMENT) 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, 05 Sep 2016 19:47:59 -0000 --001a114e5624dc7ce5053bc7f4b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Pal, On Mon, Sep 5, 2016 at 8:10 AM, Pal Martinsen (palmarti) wrote: > > > On 30 Aug 2016, at 15:54, Spencer Dawkins > wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-ice-dualstack-fairness-04: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for doing this work. > > > > The document thinks it's going for Best Current Practice, but the > > shepherd write-up and datatracker think it's going for Informational. I= t > > would be good for that to match ... > > > > I'm a little confused by > > > > These recommendations are backward compatible with a standard ICE > > implementation. The resulting local and remote checklist will still > > be synchronized. The introduced fairness might be better, but not > > worse than what exists today > > > > Is the point that the introduced fairness > > - might be better, or > > - might be the same as, but > > - won't be worse? > > > > If so, that wasn't clear to me on first (or second) reading. > > > > How about: > "These recommendations are backward compatible with a standard ICE > implementation. The resulting local and remote checklist will still > be synchronized. The introduced fairness might be better or equal, > but not worse than what exists today.=E2=80=9D > > Still something weird about the language=E2=80=A6 > Your suggested text works for me. The RFC Editor might be able to suggest improvements if the language still looks TOO weird, but the text is clear enough for that to be OK! Thanks, Spencer > > (Nit: missing period at the end of "what exists today") > > > > > > Thanks for the review. > > .-. > P=C3=A5l-Erik > > --001a114e5624dc7ce5053bc7f4b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Pal,

On Mon, Sep 5, 2016 at 8:10 AM, Pal Martinsen (palmarti) <palmar= ti@cisco.com> wrote:

> On 30 Aug 2016, at 15:54, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:<= br> >
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ice-dualstack-fairness-04: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org= /doc/draft-ietf-ice-dualstack-fairness/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Thanks for doing this work.
>
> The document thinks it's going for Best Current Practice, but the<= br> > shepherd write-up and datatracker think it's going for Information= al. It
> would be good for that to match ...
>
> I'm a little confused by
>
>=C2=A0 =C2=A0These recommendations are backward compatible with a stand= ard ICE
>=C2=A0 =C2=A0implementation.=C2=A0 The resulting local and remote check= list will still
>=C2=A0 =C2=A0be synchronized.=C2=A0 The introduced fairness might be be= tter, but not
>=C2=A0 =C2=A0worse than what exists today
>
> Is the point that the introduced fairness
> - might be better, or
> - might be the same as, but
> - won't be worse?
>
> If so, that wasn't clear to me on first (or second) reading.
>

How about:
"These recommendations are backward compatible with a= standard ICE
=C2=A0 =C2=A0implementation.=C2=A0 The resulting local and remote checklist= will still
=C2=A0 =C2=A0be synchronized.=C2=A0 The introduced fairness might be= better or equal,
=C2=A0 =C2=A0but not worse than what exists today.=E2=80=9D

Still something weird about the language=E2=80=A6

=
Your suggested text works for me. The RFC Editor might be able t= o suggest improvements if the language still looks TOO weird, but the text = is clear enough for that to be OK!

Thanks,

Spencer
=C2=A0
> (Nit: missing period at the end of "what exi= sts today")
>
>

Thanks for the review.

.-.
P=C3=A5l-Erik


--001a114e5624dc7ce5053bc7f4b9-- From nobody Tue Sep 6 01:57: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 B9A6D12B19C for ; Tue, 6 Sep 2016 01:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 jKvyjlPtnLLW for ; Tue, 6 Sep 2016 01:57:39 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B42212B171 for ; Tue, 6 Sep 2016 01:57:38 -0700 (PDT) Received: (qmail 7497 invoked from network); 6 Sep 2016 10:57:36 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 6 Sep 2016 10:57:35 +0200 To: "Pal Martinsen (palmarti)" References: <147264668629.5913.9417537450161055669.idtracker@ietfa.amsl.com> <3D60787A-FD67-472D-8787-C5EEA6B8BB9F@cisco.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <9567c025-993f-d69f-f79f-29ced36f9749@kuehlewind.net> Date: Tue, 6 Sep 2016 10:57:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3D60787A-FD67-472D-8787-C5EEA6B8BB9F@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , Ari Keranen , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-ic?= =?utf-8?q?e-dualstack-fairness-04=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 06 Sep 2016 08:57:41 -0000 Hi, I don't think this document must provide specific algorithms but at least the recommendations given should be clear. Currently they are quite lost in explanation text. Maybe have a new section that clearly spells out the guidelines? (And maybe also check for redundancy because bringing it more to the point can also help clarity.) Fairness is a problematic term because there are various aspects of fairness where it can easily happen that different people have different ideas about what that means. As I said I also think this has nothing to do with fairness because the goal is still to slightly favor IPv6 but reduce delay. Why don't you just call it guidelines as done in the abstract? Mirja On 05.09.2016 10:23, Pal Martinsen (palmarti) wrote: > >> On 31 Aug 2016, at 14:31, Mirja Kuehlewind wrote: >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I'm willing to resolve my discuss quickly but I would like to start some >> discussion: >> >> To me the recommenations given in this doc are not very clear. To my >> understanding are there two recommenations: >> >> 1) intermingle IPv4 and IPv6 addresses, and >> 2) put lower priority for adresses that are know to have connectivity >> problem. >> > Correct. > > >> However, that leaves tons of open questions to the implementor, e.g. >> - How many IPv6 addresses should I have before the first IPv4? >> - How do I measure/track that an interface has connectitivy problems: >> connectivity failed once, or twice, or X-times? How long do I keep this >> track: 1h, one day, one week, forever? >> >> Would it be possible to be more specific and give further guidance? E.g. >> how are these points implemented in the existing implementations? >> > This was the original goal when we started working on this draft. As work progressed it was clear that getting consensus on a specific algorithm or any specific value recommendations would be very hard to achieve. Some people care about IPv4 others about IPv6 and so on. But I do think since this is IETF work we have an obligation to push IPv6 friendly solutions. > > So the outcome of the work in the WG was a BCP that acknowledges that there is a problem that implementors should be aware of with guidelines on what values from the ICE RFC could safely be altered to fix the problem. > > I would also expect any explicit guidelines to change over time. I think implementers are getting used to that now and are collecting metrics that they can use to dynamically change the values. > > We can put wording like ”a good starting point might be ..”, and add some text regarding metrics and changing conditions into the draft. > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Further, I think the term 'fairness' is just wrong here. The goal is to >> avoid delay in case there are connectivity problems with IPv6 in general, >> while still prioritizating IPv6. For me, that's nothing about fairness. >> >> > That is the goal, but to achieve that goal we need a “fair” distribution if IPv4 and IPv6 candidates in the checklist. > Or a solution that is “free from bias or injustice”. (from http://www.dictionary.com/browse/fairness) > > Based on that (I am not a native speaker..), I thought the name was fine. I do agree that it might not be perfect or even close, so any new suggestions would be much appreciated. > > > Thanks for thorough review. Much appreciated. > > .-. > Pål-Erik > > > > From nobody Tue Sep 6 20:59: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 8942512B128; Tue, 6 Sep 2016 20:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 M8Q17-bnYzpF; Tue, 6 Sep 2016 20:59:34 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1B012B110; Tue, 6 Sep 2016 20:59:33 -0700 (PDT) X-AuditID: c618062d-72fff700000009b8-b1-57cf924f1616 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 9B.D4.02488.0529FC75; Wed, 7 Sep 2016 06:06:42 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0301.000; Tue, 6 Sep 2016 23:59:29 -0400 From: Suresh Krishnan To: "Pal Martinsen (palmarti)" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT) Thread-Index: AQHSBBBb9axPRyzmYEGe3DmndCknFw== Date: Wed, 7 Sep 2016 03:59:29 +0000 Message-ID: References: <147270713819.31873.6764477510963743918.idtracker@ietfa.amsl.com> <752F4956-B4ED-43AA-AAA3-19B9ADE2498D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPrG7QpPPhBvuPGlgsOLyZ1eLirMls Ft8u1FrM+DOR2eL99ZUsDqweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfG08Mz2Qu2i1Y8 edjO3sD4WrCLkYNDQsBE4tqnlC5GLg4hgQ2MEp/fPmXrYuQEcpYxSmw5GARiswHVbNj5mQnE FhEwlmg+cpQdpIFZoI1J4nLnJbAGYYEciRM/l0MV5UrcfXkIytaT2DCjhRHEZhFQkdjZdp4d xOYV8JWYebOVFWJzA6PEqaXPwBKMAmIS30+tAWtmFhCXuPVkPpgtISAgsWTPeWYIW1Ti5eN/ rBC2ksTH3/PZIeoNJN6fm88MYWtLLFv4mhlimaDEyZlPWCYwisxCMnYWkpZZSFpmIWlZwMiy ipGjtLggJzfdyGATIzAmjkmw6e5gvD/d8xCjAAejEg/vg9PnwoVYE8uKK3MPMUpwMCuJ8DL2 nw8X4k1JrKxKLcqPLyrNSS0+xCjNwaIkziv2SDFcSCA9sSQ1OzW1ILUIJsvEwSnVwLhv8V5e qUAnhygn1Xud7PMFL/ZYnjj/8WaG0C/We1tXv8sX/CAZwRqzw+zp+592s3T4cngdf83PP6Xx IMCWNV5myeSymxwXFiUsCPdILwxqnjbLfVrEvMfPyv++ytl5JE+xeGnxWsVWIdPvuclfS68e 2eLMILJMd/bnzJXdD5X+M2bfniM3basSS3FGoqEWc1FxIgCSvgSFhQIAAA== Archived-At: Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , =?Windows-1252?Q?Ari_Ker=E4nen?= , The IESG , "draft-ietf-ice-dualstack-fairness@ietf.org" Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT) 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, 07 Sep 2016 03:59:35 -0000 Thanks Pal. That change clarifies the intent a lot better. I will clear whe= n =0A= you post the new rev.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 09/05/2016 06:54 AM, Pal Martinsen (palmarti) wrote:=0A= >=0A= >> On 01 Sep 2016, at 07:18, Suresh Krishnan = wrote:=0A= >>=0A= >> Suresh Krishnan has entered the following ballot position for=0A= >> draft-ietf-ice-dualstack-fairness-04: Discuss=0A= >>=0A= >> When responding, please keep the subject line intact and reply to all=0A= >> email addresses included in the To and CC lines. (Feel free to cut this= =0A= >> introductory paragraph, however.)=0A= >>=0A= >>=0A= >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l=0A= >> for more information about IESG DISCUSS and COMMENT positions.=0A= >>=0A= >>=0A= >> The document, along with other ballot positions, can be found here:=0A= >> https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/=0A= >>=0A= >>=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> DISCUSS:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> * Section 4=0A= >>=0A= >> I am trying to see if there is any background for the following=0A= >> statement=0A= >>=0A= >> "It is worth noting that the timing recommendations in [RFC6555] are not= =0A= >> optimal for ICE usage.=94=0A= >>=0A= >> Why is it not optimal? Do you want smaller or larger timings? Some=0A= >> explanations here would be good. Additionally, it might be worthwhile fo= r=0A= >> this document to provide alternate timing recommendations that *are*=0A= >> optimal.=0A= >>=0A= > Reworded to:=0A= > "It is worth noting that the timing recommendations in [RFC6555] will=0A= > be overruled by how ICE paces out its connectivity checks.=94=0A= >=0A= > How fast ICE can actually send those connectivity checks without breaking= NATs and not consume to much bandwidth is still discussed in the ICE wg.= =0A= > But this might be significantly faster that what is described in the HE R= FC.=0A= >=0A= >=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> COMMENT:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> * Agree with Alissa's DISCUSS point. I ran into the same circular=0A= >> reference=0A= >=0A= > Tried to fix.=0A= >> * Agree with Mirja=92s comment about fairness being the wrong term to us= e=0A= >>=0A= > Tend to agree as well, but have no other suggestions.=0A= >=0A= >=0A= > Thanks for the thorough review!=0A= >=0A= > .-.=0A= > P=E5l-Erik=0A= >=0A= >=0A= >=0A= =0A= From nobody Wed Sep 7 19:45:17 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 3492412B0A7 for ; Wed, 7 Sep 2016 19:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 4kctweq5SJWb for ; Wed, 7 Sep 2016 19:45:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D165512B012 for ; Wed, 7 Sep 2016 19:45:14 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B6674F0793; Wed, 7 Sep 2016 20:45:38 -0600 (MDT) To: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> Date: Wed, 7 Sep 2016 20:45:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 02:45:17 -0000 At IETF 96 [1], the WG discussed the topic of signaling the ufrag to differentiate candidates between ICE restarts. To address this issue, I propose that we add the following text after the ufrag examples in Section 8: Note: It is the responsiblity of the signaling protocol to properly indicate which ICE negotiation session is in force (i.e., by communicating the relevant ufrag) so that both parties have a consistent view of which candidates are paired. This is especially important in the case of ICE restarts (see Section 13). Peter [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice From nobody Wed Sep 7 19:48:13 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 101D912B405 for ; Wed, 7 Sep 2016 19:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 CEmw3OFcvUdm for ; Wed, 7 Sep 2016 19:48:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0920412B3FD for ; Wed, 7 Sep 2016 19:48:11 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3556CF0793; Wed, 7 Sep 2016 20:48:35 -0600 (MDT) To: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <722b9fd3-f783-288e-af4f-dd2cbf59523a@stpeter.im> Date: Wed, 7 Sep 2016 20:48:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ice] trickle: replacing candidates 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, 08 Sep 2016 02:48:12 -0000 At IETF 96 [1], the WG discussed the topic of clarify what "replacing candidate" means (i.e., updating the priority and re-sorting the check list). To address this issue, I propose the following change to Section 8.1: OLD Once this is done, the agent examines the check list looking for another pair that would be redundant with the new one. If such a pair exists and its type is not peer reflexive, the pair with the higher priority is kept and the one with the lower priority is discarded. If, on the other hand, the type of the pre-existing pair is peer reflexive, the agent MUST replace it with the new candidate it received, regardless of their priorities. NEW Once this is done, the agent examines the check list looking for another pair that would be redundant with the new one. If such a pair exists and its type is not peer reflexive, the pair with the higher priority is kept and the one with the lower priority is discarded. If, on the other hand, the type of the pre-existing pair is peer reflexive, the agent MUST replace it with the new candidate it received (regardless of their respective priorities); this is done by setting the priority of the new candidate to the priority of the pre-existing candidate and then re-sorting the check list. Peter [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice From nobody Thu Sep 8 08:45: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 0290412B4A3 for ; Thu, 8 Sep 2016 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 t6YcYBZP_-CX for ; Thu, 8 Sep 2016 08:45:03 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D285412B49E for ; Thu, 8 Sep 2016 08:40:44 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u88FXZ4N008721; Thu, 8 Sep 2016 11:40:43 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 257s9542gd-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 08 Sep 2016 11:40:43 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 8 Sep 2016 10:40:43 -0500 From: Jonathan Lennox To: Peter Saint-Andre Thread-Topic: [Ice] trickle: ufrag signaling Thread-Index: AQHSCdhd81cvZIeQz0Svh00JkFUqkKBwDtcA Date: Thu, 8 Sep 2016 15:40:42 +0000 Message-ID: References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> In-Reply-To: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_FC29700BFA9F45259963098D6F7D3A7Fvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609080228 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 15:45:05 -0000 --_000_FC29700BFA9F45259963098D6F7D3A7Fvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBTZXAgNywgMjAxNiwgYXQgMTA6NDUgUE0sIFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVy QHN0cGV0ZXIuaW08bWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbT4+IHdyb3RlOg0KDQpBdCBJRVRG IDk2IFsxXSwgdGhlIFdHIGRpc2N1c3NlZCB0aGUgdG9waWMgb2Ygc2lnbmFsaW5nIHRoZSB1ZnJh ZyB0byBkaWZmZXJlbnRpYXRlIGNhbmRpZGF0ZXMgYmV0d2VlbiBJQ0UgcmVzdGFydHMuIFRvIGFk ZHJlc3MgdGhpcyBpc3N1ZSwgSSBwcm9wb3NlIHRoYXQgd2UgYWRkIHRoZSBmb2xsb3dpbmcgdGV4 dCBhZnRlciB0aGUgdWZyYWcgZXhhbXBsZXMgaW4gU2VjdGlvbiA4Og0KDQogIE5vdGU6IEl0IGlz IHRoZSByZXNwb25zaWJsaXR5IG9mIHRoZSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJvcGVybHkN CiAgaW5kaWNhdGUgd2hpY2ggSUNFIG5lZ290aWF0aW9uIHNlc3Npb24gaXMgaW4gZm9yY2UgKGku ZS4sIGJ5DQogIGNvbW11bmljYXRpbmcgdGhlIHJlbGV2YW50IHVmcmFnKSBzbyB0aGF0IGJvdGgg cGFydGllcyBoYXZlIGENCiAgY29uc2lzdGVudCB2aWV3IG9mIHdoaWNoIGNhbmRpZGF0ZXMgYXJl IHBhaXJlZC4gIFRoaXMgaXMgZXNwZWNpYWxseQ0KICBpbXBvcnRhbnQgaW4gdGhlIGNhc2Ugb2Yg SUNFIHJlc3RhcnRzIChzZWUgU2VjdGlvbiAxMykuDQoNClBldGVyDQoNClsxXSBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9taW51dGVzL21pbnV0ZXMtOTYtaWNlDQoNCkkgdGhp bmsgdGhpcyBpcyBnb29kLCBleGNlcHQgdGhhdCB0aGUgaS5lLiBjbGF1c2UgaXMgaW5zdWZmaWNp ZW50Lg0KDQpJdCBpcyBhbHNvIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgc2lnbmFsaW5nIHBy b3RvY29sIHRvIG1ha2Ugc3VyZSB0aGF0IGl04oCZcyBjbGVhciB3aGljaCBzZXQgb2YgbG9jYWwg Y2FuZGlkYXRlcyBwYWlyIHdpdGggd2hpY2ggc2V0IG9mIHJlbW90ZSBjYW5kaWRhdGVzLg0KDQoo SmluZ2xlIGN1cnJlbnRseSBpcyBicm9rZW4gaGVyZSwgZXZlbiB3aXRoIFhFUC0wMzcxLikNCg== --_000_FC29700BFA9F45259963098D6F7D3A7Fvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6ED794E3DDC8924CA1177F91200864B8@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAg NywgMjAxNiwgYXQgMTA6NDUgUE0sIFBldGVyIFNhaW50LUFuZHJlICZsdDs8YSBocmVmPSJtYWls dG86c3RwZXRlckBzdHBldGVyLmltIiBjbGFzcz0iIj5zdHBldGVyQHN0cGV0ZXIuaW08L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPkF0IElFVEYgOTYgWzFdLCB0aGUgV0cgZGlzY3Vzc2VkIHRoZSB0b3BpYyBv ZiBzaWduYWxpbmcgdGhlIHVmcmFnIHRvIGRpZmZlcmVudGlhdGUgY2FuZGlkYXRlcyBiZXR3ZWVu IElDRSByZXN0YXJ0cy4gVG8gYWRkcmVzcyB0aGlzIGlzc3VlLCBJIHByb3Bvc2UgdGhhdCB3ZSBh ZGQgdGhlIGZvbGxvd2luZyB0ZXh0IGFmdGVyIHRoZSB1ZnJhZyBleGFtcGxlcyBpbiBTZWN0aW9u IDg6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Tm90ZTogSXQgaXMg dGhlIHJlc3BvbnNpYmxpdHkgb2YgdGhlIHNpZ25hbGluZyBwcm90b2NvbCB0byBwcm9wZXJseTxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2luZGljYXRlIHdoaWNoIElDRSBuZWdvdGlhdGlvbiBz ZXNzaW9uIGlzIGluIGZvcmNlIChpLmUuLCBieTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2Nv bW11bmljYXRpbmcgdGhlIHJlbGV2YW50IHVmcmFnKSBzbyB0aGF0IGJvdGggcGFydGllcyBoYXZl IGE8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtjb25zaXN0ZW50IHZpZXcgb2Ygd2hpY2ggY2Fu ZGlkYXRlcyBhcmUgcGFpcmVkLiAmbmJzcDtUaGlzIGlzIGVzcGVjaWFsbHk8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtpbXBvcnRhbnQgaW4gdGhlIGNhc2Ugb2YgSUNFIHJlc3RhcnRzIChzZWUg U2VjdGlvbiAxMykuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGV0ZXI8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTYvbWludXRlcy9taW51dGVzLTk2LWljZSIgY2xhc3M9IiI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9taW51dGVzL21pbnV0ZXMtOTYtaWNlPC9hPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PkkgdGhpbmsgdGhpcyBpcyBnb29kLCBleGNlcHQgdGhhdCB0aGUgaS5lLiBjbGF1c2UgaXMg aW5zdWZmaWNpZW50LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SXQg aXMgYWxzbyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIHNpZ25hbGluZyBwcm90b2NvbCB0byBt YWtlIHN1cmUgdGhhdCBpdOKAmXMgY2xlYXIgd2hpY2ggc2V0IG9mIGxvY2FsIGNhbmRpZGF0ZXMg cGFpciB3aXRoIHdoaWNoIHNldCBvZiByZW1vdGUgY2FuZGlkYXRlcy48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PihKaW5nbGUgY3VycmVudGx5IGlzIGJyb2tlbiBoZXJl LCBldmVuIHdpdGggWEVQLTAzNzEuKTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FC29700BFA9F45259963098D6F7D3A7Fvidyocom_-- From nobody Thu Sep 8 08:52:00 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 495C512B4E4 for ; Thu, 8 Sep 2016 08:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 jOwurae_Lz3L for ; Thu, 8 Sep 2016 08:51:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 226AE12B4F8 for ; Thu, 8 Sep 2016 08:46:54 -0700 (PDT) Received: from aither.local (unknown [65.152.252.50]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 76AFCF0799; Thu, 8 Sep 2016 09:47:20 -0600 (MDT) To: Jonathan Lennox References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Thu, 8 Sep 2016 09:46:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 15:51:58 -0000 On 9/8/16 9:40 AM, Jonathan Lennox wrote: > >> On Sep 7, 2016, at 10:45 PM, Peter Saint-Andre > > wrote: >> >> At IETF 96 [1], the WG discussed the topic of signaling the ufrag to >> differentiate candidates between ICE restarts. To address this issue, >> I propose that we add the following text after the ufrag examples in >> Section 8: >> >> Note: It is the responsiblity of the signaling protocol to properly >> indicate which ICE negotiation session is in force (i.e., by >> communicating the relevant ufrag) so that both parties have a >> consistent view of which candidates are paired. This is especially >> important in the case of ICE restarts (see Section 13). >> >> Peter >> >> [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice > > I think this is good, except that the i.e. clause is insufficient. > > It is also the responsibility of the signaling protocol to make sure > that its clear which set of local candidates pair with which set of > remote candidates. Does communicating and agreeing on the ufrag-in-force not accomplish that? > (Jingle currently is broken here, even with XEP-0371.) I plan to look at that next, but feedback is welcome on the appropriate lists or directly to the authors. Peter From nobody Thu Sep 8 08:58: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 26EC512B512 for ; Thu, 8 Sep 2016 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 b-u3UITR00PU for ; Thu, 8 Sep 2016 08:58:27 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097DB12B0C0 for ; Thu, 8 Sep 2016 08:54:50 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u88FrpMj029717; Thu, 8 Sep 2016 11:54:49 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 257s95435h-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 08 Sep 2016 11:54:49 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 8 Sep 2016 10:54:49 -0500 From: Jonathan Lennox To: Peter Saint-Andre Thread-Topic: [Ice] trickle: ufrag signaling Thread-Index: AQHSCdhd81cvZIeQz0Svh00JkFUqkKBwDtcAgAABuQCAAAI3AA== Date: Thu, 8 Sep 2016 15:54:48 +0000 Message-ID: <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <83AFF1ED65EDA64FB872D5B8E10B446E@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609080231 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 15:58:29 -0000 > On Sep 8, 2016, at 11:46 AM, Peter Saint-Andre wrote= : >=20 > On 9/8/16 9:40 AM, Jonathan Lennox wrote: >>=20 >>> On Sep 7, 2016, at 10:45 PM, Peter Saint-Andre >> > wrote: >>>=20 >>> At IETF 96 [1], the WG discussed the topic of signaling the ufrag to >>> differentiate candidates between ICE restarts. To address this issue, >>> I propose that we add the following text after the ufrag examples in >>> Section 8: >>>=20 >>> Note: It is the responsiblity of the signaling protocol to properly >>> indicate which ICE negotiation session is in force (i.e., by >>> communicating the relevant ufrag) so that both parties have a >>> consistent view of which candidates are paired. This is especially >>> important in the case of ICE restarts (see Section 13). >>>=20 >>> Peter >>>=20 >>> [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice >>=20 >> I think this is good, except that the i.e. clause is insufficient. >>=20 >> It is also the responsibility of the signaling protocol to make sure >> that it=92s clear which set of local candidates pair with which set of >> remote candidates. >=20 > Does communicating and agreeing on the ufrag-in-force not accomplish that= ? Communicating no, agreeing yes. But you need to establish both the local an= d the remote ufrag (or generation or whatever). The problem is this: Romeo=92s IP address changes, so he sends an ICE restart (ufrag B) His IP address then changes again, so he sends another ICE restart (ufrag C= ). Juliet then replies with a new set of her own candidates (ufrag X). In Jingle, Romeo doesn=92t know whether Juliet intended to pair her ufrag-X= candidates with his ufrag-B candidates or his ufrag-C candidates. In SIP and SDP offer/answer, this problem doesn=92t arise, because Juliet= =92s reply would have explicitly been carried an answer to the ufrag B or u= frag C offer. (And indeed, Romeo probably wouldn=92t have been allowed to = send the ufrag-C offer at all until an answer came in to the ufrag-B offer.= ) But Jingle=92s transport-info messages are unilateral, and don=92t carry= this semantic. >=20 >> (Jingle currently is broken here, even with XEP-0371.) >=20 > I plan to look at that next, but feedback is welcome on the appropriate l= ists or directly to the authors. >=20 > Peter >=20 >=20 From nobody Thu Sep 8 13:24:28 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 4D72B12B1C5 for ; Thu, 8 Sep 2016 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 g0oOK9E0Wksl for ; Thu, 8 Sep 2016 13:24:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9A12B117 for ; Thu, 8 Sep 2016 13:24:24 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 93ECBF079B; Thu, 8 Sep 2016 14:24:51 -0600 (MDT) To: Jonathan Lennox References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> From: Peter Saint-Andre Message-ID: <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> Date: Thu, 8 Sep 2016 14:24:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 20:24:26 -0000 On 9/8/16 9:54 AM, Jonathan Lennox wrote: > >> On Sep 8, 2016, at 11:46 AM, Peter Saint-Andre wrote: >> >> On 9/8/16 9:40 AM, Jonathan Lennox wrote: >>> >>>> On Sep 7, 2016, at 10:45 PM, Peter Saint-Andre >>> > wrote: >>>> >>>> At IETF 96 [1], the WG discussed the topic of signaling the ufrag to >>>> differentiate candidates between ICE restarts. To address this issue, >>>> I propose that we add the following text after the ufrag examples in >>>> Section 8: >>>> >>>> Note: It is the responsiblity of the signaling protocol to properly >>>> indicate which ICE negotiation session is in force (i.e., by >>>> communicating the relevant ufrag) so that both parties have a >>>> consistent view of which candidates are paired. This is especially >>>> important in the case of ICE restarts (see Section 13). >>>> >>>> Peter >>>> >>>> [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice >>> >>> I think this is good, except that the i.e. clause is insufficient. >>> >>> It is also the responsibility of the signaling protocol to make sure >>> that its clear which set of local candidates pair with which set of >>> remote candidates. >> >> Does communicating and agreeing on the ufrag-in-force not accomplish that? > > Communicating no, agreeing yes. But you need to establish both the local and the remote ufrag (or generation or whatever). > > The problem is this: > > Romeos IP address changes, so he sends an ICE restart (ufrag B) > > His IP address then changes again, so he sends another ICE restart (ufrag C). > > Juliet then replies with a new set of her own candidates (ufrag X). > > In Jingle, Romeo doesnt know whether Juliet intended to pair her ufrag-X candidates with his ufrag-B candidates or his ufrag-C candidates. > > In SIP and SDP offer/answer, this problem doesnt arise, because Juliets reply would have explicitly been carried an answer to the ufrag B or ufrag C offer. (And indeed, Romeo probably wouldnt have been allowed to send the ufrag-C offer at all until an answer came in to the ufrag-B offer.) But Jingles transport-info messages are unilateral, and dont carry this semantic. Yes, I see the problem (and, outside of this WG, we'll fix it in Jingle). Would this text be better in the Trickle ICE spec? Note: The signaling protocol needs to provide a mechanism for both parties to indicate and agree on the ICE negotiation session (ufrag) in force so that they have a consistent view of which candidates are to be paired. This is especially important in the case of ICE restarts (see Section 13). Thanks! Peter From nobody Thu Sep 8 13:26:58 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 5C239128B38 for ; Thu, 8 Sep 2016 13:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 B7vFYzws22XP for ; Thu, 8 Sep 2016 13:26:56 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D677127077 for ; Thu, 8 Sep 2016 13:26:56 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u88KJCNm015308; Thu, 8 Sep 2016 16:26:55 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 25bc2p05tf-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 08 Sep 2016 16:26:55 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 8 Sep 2016 15:26:54 -0500 From: Jonathan Lennox To: Peter Saint-Andre Thread-Topic: [Ice] trickle: ufrag signaling Thread-Index: AQHSCdhd81cvZIeQz0Svh00JkFUqkKBwDtcAgAABuQCAAAI3AIAAS1OAgAAAtAA= Date: Thu, 8 Sep 2016 20:26:54 +0000 Message-ID: <99EAF858-9368-4C1F-9268-527F5588CB0B@vidyo.com> References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> In-Reply-To: <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7498F2C02F68234DAC0B0440C2DC7E78@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609080292 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 20:26:57 -0000 > On Sep 8, 2016, at 4:24 PM, Peter Saint-Andre wrote: >=20 > On 9/8/16 9:54 AM, Jonathan Lennox wrote: >>=20 >>> On Sep 8, 2016, at 11:46 AM, Peter Saint-Andre wro= te: >>>=20 >>> On 9/8/16 9:40 AM, Jonathan Lennox wrote: >>>>=20 >>>>> On Sep 7, 2016, at 10:45 PM, Peter Saint-Andre >>>> > wrote: >>>>>=20 >>>>> At IETF 96 [1], the WG discussed the topic of signaling the ufrag to >>>>> differentiate candidates between ICE restarts. To address this issue, >>>>> I propose that we add the following text after the ufrag examples in >>>>> Section 8: >>>>>=20 >>>>> Note: It is the responsiblity of the signaling protocol to properly >>>>> indicate which ICE negotiation session is in force (i.e., by >>>>> communicating the relevant ufrag) so that both parties have a >>>>> consistent view of which candidates are paired. This is especially >>>>> important in the case of ICE restarts (see Section 13). >>>>>=20 >>>>> Peter >>>>>=20 >>>>> [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice >>>>=20 >>>> I think this is good, except that the i.e. clause is insufficient. >>>>=20 >>>> It is also the responsibility of the signaling protocol to make sure >>>> that it=92s clear which set of local candidates pair with which set of >>>> remote candidates. >>>=20 >>> Does communicating and agreeing on the ufrag-in-force not accomplish th= at? >>=20 >> Communicating no, agreeing yes. But you need to establish both the local= and the remote ufrag (or generation or whatever). >>=20 >> The problem is this: >>=20 >> Romeo=92s IP address changes, so he sends an ICE restart (ufrag B) >>=20 >> His IP address then changes again, so he sends another ICE restart (ufra= g C). >>=20 >> Juliet then replies with a new set of her own candidates (ufrag X). >>=20 >> In Jingle, Romeo doesn=92t know whether Juliet intended to pair her ufra= g-X candidates with his ufrag-B candidates or his ufrag-C candidates. >>=20 >> In SIP and SDP offer/answer, this problem doesn=92t arise, because Julie= t=92s reply would have explicitly been carried an answer to the ufrag B or = ufrag C offer. (And indeed, Romeo probably wouldn=92t have been allowed to= send the ufrag-C offer at all until an answer came in to the ufrag-B offer= .) But Jingle=92s transport-info messages are unilateral, and don=92t carr= y this semantic. >=20 > Yes, I see the problem (and, outside of this WG, we'll fix it in Jingle). >=20 > Would this text be better in the Trickle ICE spec? >=20 > Note: The signaling protocol needs to provide a mechanism for both > parties to indicate and agree on the ICE negotiation session (ufrag) > in force so that they have a consistent view of which candidates are > to be paired. This is especially important in the case of ICE > restarts (see Section 13). >=20 > Thanks! Yes, that text seems good to me. Thanks! From nobody Thu Sep 8 13:42:16 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 DBEF512B249 for ; Thu, 8 Sep 2016 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 tqLKosrJAKCD for ; Thu, 8 Sep 2016 13:42:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82E0812B1C2 for ; Thu, 8 Sep 2016 13:42:13 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9B9AEF079B; Thu, 8 Sep 2016 14:42:40 -0600 (MDT) To: Jonathan Lennox References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> <99EAF858-9368-4C1F-9268-527F5588CB0B@vidyo.com> From: Peter Saint-Andre Message-ID: Date: Thu, 8 Sep 2016 14:42:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <99EAF858-9368-4C1F-9268-527F5588CB0B@vidyo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 08 Sep 2016 20:42:15 -0000 On 9/8/16 2:26 PM, Jonathan Lennox wrote: > >> On Sep 8, 2016, at 4:24 PM, Peter Saint-Andre wrote: >> >> On 9/8/16 9:54 AM, Jonathan Lennox wrote: >>> >>>> On Sep 8, 2016, at 11:46 AM, Peter Saint-Andre wrote: >>>> >>>> On 9/8/16 9:40 AM, Jonathan Lennox wrote: >>>>> >>>>>> On Sep 7, 2016, at 10:45 PM, Peter Saint-Andre >>>>> > wrote: >>>>>> >>>>>> At IETF 96 [1], the WG discussed the topic of signaling the ufrag to >>>>>> differentiate candidates between ICE restarts. To address this issue, >>>>>> I propose that we add the following text after the ufrag examples in >>>>>> Section 8: >>>>>> >>>>>> Note: It is the responsiblity of the signaling protocol to properly >>>>>> indicate which ICE negotiation session is in force (i.e., by >>>>>> communicating the relevant ufrag) so that both parties have a >>>>>> consistent view of which candidates are paired. This is especially >>>>>> important in the case of ICE restarts (see Section 13). >>>>>> >>>>>> Peter >>>>>> >>>>>> [1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice >>>>> >>>>> I think this is good, except that the i.e. clause is insufficient. >>>>> >>>>> It is also the responsibility of the signaling protocol to make sure >>>>> that its clear which set of local candidates pair with which set of >>>>> remote candidates. >>>> >>>> Does communicating and agreeing on the ufrag-in-force not accomplish that? >>> >>> Communicating no, agreeing yes. But you need to establish both the local and the remote ufrag (or generation or whatever). >>> >>> The problem is this: >>> >>> Romeos IP address changes, so he sends an ICE restart (ufrag B) >>> >>> His IP address then changes again, so he sends another ICE restart (ufrag C). >>> >>> Juliet then replies with a new set of her own candidates (ufrag X). >>> >>> In Jingle, Romeo doesnt know whether Juliet intended to pair her ufrag-X candidates with his ufrag-B candidates or his ufrag-C candidates. >>> >>> In SIP and SDP offer/answer, this problem doesnt arise, because Juliets reply would have explicitly been carried an answer to the ufrag B or ufrag C offer. (And indeed, Romeo probably wouldnt have been allowed to send the ufrag-C offer at all until an answer came in to the ufrag-B offer.) But Jingles transport-info messages are unilateral, and dont carry this semantic. >> >> Yes, I see the problem (and, outside of this WG, we'll fix it in Jingle). >> >> Would this text be better in the Trickle ICE spec? >> >> Note: The signaling protocol needs to provide a mechanism for both >> parties to indicate and agree on the ICE negotiation session (ufrag) >> in force so that they have a consistent view of which candidates are >> to be paired. This is especially important in the case of ICE >> restarts (see Section 13). >> >> Thanks! > > Yes, that text seems good to me. Thanks! OK, I'll submit an updated version later today. Peter From nobody Thu Sep 8 19:08:24 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 70B7B12B053; Thu, 8 Sep 2016 19:08:23 -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.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147338690342.21865.13555001100273083598.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 19:08:23 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-trickle-04.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: Fri, 09 Sep 2016 02:08:23 -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 : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-04.txt Pages : 26 Date : 2016-09-08 Abstract: This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. This mechanism is called "Trickle ICE". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-04 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 Sep 8 21:41:57 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 0275812B0AE for ; Thu, 8 Sep 2016 21:41:56 -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 G1RN0XMoPEom for ; Thu, 8 Sep 2016 21:41:54 -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 8AC3D12B046 for ; Thu, 8 Sep 2016 21:41:54 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 1so11307469wmz.1 for ; Thu, 08 Sep 2016 21:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LhKjAW+pfKsQ2jDXXrMXDYqkcTAoIgwkET7UQV4YC3A=; b=opLJmeM9idL3djMnhDz3FbU/OGlOvsVSCaerfHTnVR15NLfdQf9/ljmRj/dGR3puQu umUS21nAPyBp7tjSUafwHJEBIFcIWz8KQVA1vestJjdXEIcb8LCjDeMWkX0yW6A8zWxk 8RE1ziwQ7xkq8Uv7P1E8Z32rT1gdZcwrJYpZp1bBJKOdaPEPt2TvLgpaCrvbW6kh8uww cprjqufJMosY+mk9b/RZ0iyynwe8/ieUtxruXw963tI1nKkyU0QZvZn3auvZkW/qHBhD O7Pp5sbG7ewDLEXCi+GLo2WOONmeu+vPtJRjoPNl3UcdoYUxJHMkCAKY95gu7z7aZsUk zoaw== 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=LhKjAW+pfKsQ2jDXXrMXDYqkcTAoIgwkET7UQV4YC3A=; b=Behd5hGVLa59t6XTcimDtOAbRGPQik0G94bVmLXaGeRGZ5iJlmLTjWMou9+4C2booX 1IAXFaUq3wCNDUmtPwgmmUTCw6C67vXg4SxeMMR9AACZtwjV7PwAMyGzuwyWD42TIQmg QAs8grnsZdLli+u7pva9akkgY3HHZ7qnABDZH7qumTxwqG8ZNdQjiuuozLMJA8e1Fc1n ke64PZ+9q8/eQlqAtmyzqD3Z0g5rZ02zmmmJTl6HRq75izdqrnqBgiBJCTEJEobOZtKM Nlh7pPHutMfL6Bm1EAGrtbHHWpG9d0UgZt0NUWgPVuIvJCsL74r2Fr1nYrtylvfcTi1a PzpA== X-Gm-Message-State: AE9vXwOqBjHaMNCSAi21Ls4+Wz6LlvnpctkB+5g8r3xEDcjGj8fq8AVNIE2fufNN25n6y3BrZW9sVv0BUSwXZA== X-Received: by 10.194.172.42 with SMTP id az10mr963016wjc.178.1473396113090; Thu, 08 Sep 2016 21:41:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.197.207 with HTTP; Thu, 8 Sep 2016 21:41:52 -0700 (PDT) In-Reply-To: <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> From: Martin Thomson Date: Fri, 9 Sep 2016 14:41:52 +1000 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 09 Sep 2016 04:41:56 -0000 On 9 September 2016 at 06:24, Peter Saint-Andre wrote: > Note: The signaling protocol needs to provide a mechanism for both > parties to indicate and agree on the ICE negotiation session (ufrag) > in force so that they have a consistent view of which candidates are > to be paired. This is especially important in the case of ICE > restarts (see Section 13). Are we separately clear that ufrag needs to be different for each ICE negotiation session that an endpoint instantiates? BTW, I find the parenthetical useless. "(as identified by ufrag)" might be better. From nobody Wed Sep 14 08:16:05 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 450D012BBDE for ; Wed, 14 Sep 2016 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 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=-1.508, 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 FBofbbYqV0MX for ; Wed, 14 Sep 2016 08:16:02 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 0E72212B95C for ; Wed, 14 Sep 2016 07:41:15 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id i129so23461812ywb.0 for ; Wed, 14 Sep 2016 07:41:15 -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=Gi+/hBvv9N5N4fNRGQR49VeWm9TrTkyk6xiNYd3ffkQ=; b=iGBIJyXwujTrW6QZwXeQB5ZMXOa1fhn8yA/6ooXawLiJhB9pChtQb3yDiV8KD7FsRe HetUvwzhAP1sCimy2odaoLtNN2op4uctsH1/jmnC8x7X0WIU2i9Fpikc4+4hMBow5lPp FdjZnSSEbvZDbey4Cu8s++t5gwLAVtzKiHSsH5q9oOWa6OAr4aaYi0y2ReVtnlHzV4az 9VgFcrh4NKjqIcc+WuabWMKdqQHsPinn2woYAby5eDBtPKbbH/rKiN50lCMp4rYhtBRL 2qPlO/JHntuppcXcBfLAixNNk95cEA56mNkX8RYqgMG6GNsr/vz2xifAbAdEF0O/dQHI dvlw== 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=Gi+/hBvv9N5N4fNRGQR49VeWm9TrTkyk6xiNYd3ffkQ=; b=GQ+YE+taGl5eGShIq4zzF43FDm6AFu8sntV+JbvY2PsmVXUpm5jbXygSAoABH/nQqH vF0VdbWZnFXcEW2NR3FGzIuQLKtm8h2u2AwRVaUsBqAVsyuqM41x9bJDue1Wdd1tTelF 8o0ogPWZllgswKVPbkO0E2PWbokpilsseG0grOiWjLfIj4zDhjWS/s8nuNaEeTC2utuy 4yYYtBRxMFj1jHqivqpQ8qu9l0d/acjTJ73apPyPVu9rIoK1lxPmaLoH6krGAMYUMczj 9nPQu6VET5I6s4hMlRvFU7ETeyuT0pF+KOh75/uUgKzJg1zrR8/oKS4rQts8hNorpzs9 Ad5g== X-Gm-Message-State: AE9vXwORxP61kUgRHP3JRbqUhL+tC0Dg2HGABXxaVwCH7dKcYI8yNu7efwMEbTNHHN3t7fOdh5SiCSu7optIwCff X-Received: by 10.129.153.215 with SMTP id q206mr3130766ywg.107.1473864073055; Wed, 14 Sep 2016 07:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.196 with HTTP; Wed, 14 Sep 2016 07:40:32 -0700 (PDT) From: Peter Thatcher Date: Wed, 14 Sep 2016 07:40:32 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0b8084865087053c78b8dd Archived-At: Subject: [Ice] Continue discussion of global pacing based on feedback from "transport guys" 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, 14 Sep 2016 15:16:04 -0000 --94eb2c0b8084865087053c78b8dd Content-Type: text/plain; charset=UTF-8 At the WG meeting in Berlin, we agreed to take our plan for global pacing to the "transport guys" and see what they say. They responded with a design different than the one we had come up with (a bitrate limit). Instead, they proposed this: 1. A maximum number of outstanding request packets, call it MaxPackets which SHOULD be 10. 2. A timeout for request packets, call it handshake timeout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise. 3. A global pacing rate of 5ms (like a global Ta). If all packets are dropped and the RTT is not known, then 1+2 are effectively 20 packets per second, well below what you would get with the bitrate limits we were asking for. However, they feel that these should be SHOULD values, not MUST values, and allow implementations to choose lower values of HTO and higher values of MaxPackets. So, the question for the WG: Do we find the MaxPackets+HTO+pacing an appropriate solution for a global limit? If so, we can begin writing text for it. --94eb2c0b8084865087053c78b8dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the WG meeting in Berlin, we agreed to take our plan= for global pacing to the "transport guys" and see what they say.= =C2=A0 They responded with a design different than the one we had come up w= ith (a bitrate limit).=C2=A0 Instead, they proposed this:

1= .=C2=A0 A maximum number of outstanding request packets, call it MaxPackets= which SHOULD be 10.

2.=C2=A0 A timeout for request = packets, call it handshake timeout or HTO which SHOULD be 2*RTT if the RTT = is known and 500ms otherwise.=C2=A0

3.=C2=A0 A global = pacing rate of 5ms (like a global Ta).

If all packets = are dropped and the RTT is not known, then 1+2 are effectively 20 packets p= er second, well below what you would get with the bitrate limits we were as= king for.=C2=A0 However, they feel that these should be SHOULD values, not = MUST values, and allow implementations to choose lower values of HTO and hi= gher values of MaxPackets.



=
So, the question for the WG: Do we find the MaxPackets+HTO+pacing an app= ropriate solution for a global limit? =C2=A0 If so, we can begin writing te= xt for it. =C2=A0




=



--94eb2c0b8084865087053c78b8dd-- From nobody Wed Sep 14 09:11:38 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 791FD12B38E for ; Wed, 14 Sep 2016 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 DeTZvdJMD_Ji for ; Wed, 14 Sep 2016 09:11:35 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 97E8812B483 for ; Wed, 14 Sep 2016 08:56:56 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id g202so7007024pfb.0 for ; Wed, 14 Sep 2016 08:56:56 -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=BPVZNx+TgXFfh3DCftobWhnXjYHkzYFA4btkzHoCxjM=; b=pP94HwcRf3H5uRJ8TJ9Fq47np9eYA4pXYvePnGZlzGGSSBhrvakcYmn18bRxX5jsGK anF9EUCeRhLR/ZVj1KiuIBY3HaoiX3E9quENjhd/mYQEeBUTJHF8SD4otGVPfRAClcO5 Ixsxjd5NBKRVDMqjq01p9IyPn1cytYUg7JnZtp/xEojpLQnJTzwvCkmKwYvwMmU8Kewn mZ8D0pX7er/bALgghimFlh3fMiK58YGtXAmX1PClypF62UjLSuYSSHJnAu2w+kEy8G8R VlTA+d/Kp+2betnPSe01x3cFiNUC9drBeNWouzGpcMzmvIIjpe6JR32vZh/GUO0jR6cV YA5A== 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=BPVZNx+TgXFfh3DCftobWhnXjYHkzYFA4btkzHoCxjM=; b=SUG07XPB6fU0sIWvZokUFxOcekLxLw82N9aflbNTl5AJFEv3qsiB4cKSYsz2xmd1w4 juoK328zFGKg6KjgkHR3nRaENdINUIYTHC/VgkJSjsdiNW4xmR+Md5fmIPu/qVuqQGWx aOi6ECtfQ3yceV2xYZ4KCvaeEP0xVyehsebr8gih9pfav8E/QoMnvy2eKo+ONPXhE7Xg oIoLoCThQaPIo/xNSBh6oypojQPtQNLDvKEeyB/F2aXaGRYPft3kz3HuIJs2geNMcgQL wnb74uPLMwrhTqDyA0B6S2OQPQ2+iIRhCbDa+KoEL3FrxcnOVDNo3B/7E93RAoBM9gc7 qWvw== X-Gm-Message-State: AE9vXwNQMP4g/q5xbDPONh7XYPEy2hnxTGN40jS9WEuiNtbWV3pqlQNo8fOiXD+YTse7OA== X-Received: by 10.98.135.134 with SMTP id i128mr5838397pfe.144.1473868616075; Wed, 14 Sep 2016 08:56:56 -0700 (PDT) Received: from [10.104.92.20] ([167.220.56.193]) by smtp.gmail.com with ESMTPSA id g90sm39160099pfe.96.2016.09.14.08.56.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Sep 2016 08:56:55 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-4EAE43FD-AAD7-4E91-8DB7-D67528349E75 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14A403) In-Reply-To: Date: Wed, 14 Sep 2016 08:56:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: <24D429A5-D113-4256-9CB6-5A8CE0EE67A5@gmail.com> References: To: Peter Thatcher Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" 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, 14 Sep 2016 16:11:37 -0000 --Apple-Mail-4EAE43FD-AAD7-4E91-8DB7-D67528349E75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Sep 14, 2016, at 7:40 AM, Peter Thatcher wrote: >=20 > 2. A timeout for request packets, call it handshake timeout or HTO which S= HOULD be 2*RTT if the RTT is known and 500ms otherwise.=20 [BA] Since there is detailed existing text in RFC 5389 Section 7.2.1 (see be= low) I would prefer to start from that and make modifications where necessar= y. Does this just come down to recommending an initial RTO of 500 ms for all= links (not just wired)? =46rom RFC 5389 Section 7.2.1: A client SHOULD retransmit a STUN request message starting with an interval o= f RTO ("Retransmission TimeOut"), doubling after each retransmission. The RT= O is an estimate of the round-trip time (RTT), and is computed as described i= n RFC 2988 [RFC2988], with two exceptions. First, the initial value for RTO S= HOULD be configurable (rather than the 3 s recommended in RFC 2988) and SHOU= LD be greater than 500 ms. The exception cases for this "SHOULD" are when ot= her mechanisms are used to derive congestion thresholds (such as the ones = defined in ICE for fixed rate streams), or when STUN is used in non- Intern= et environments with known network capacities. In fixed-line access links, a= value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT be roun= ded up to the nearest second. Rather, a 1 ms accuracy SHOULD be maintained. A= s with TCP, the usage of Karn's algorithm is RECOMMENDED [KARN87]. When appl= ied to STUN, it means that RTT estimates SHOULD NOT be computed from STUN tr= ansactions that result in the retransmission of a request.= --Apple-Mail-4EAE43FD-AAD7-4E91-8DB7-D67528349E75 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sep 14, 2016, at 7:40 AM, Peter Thatcher <pthatcher@google.com> wrote:

2.  A timeout for request packets,= call it handshake timeout or HTO which SHOULD be 2*RTT if the RTT is known a= nd 500ms otherwise. 

[BA] Since there is de= tailed existing text in RFC 5389 Section 7.2.1 (see below) I would prefer to= start from that and make modifications where necessary. Does this just come= down to recommending an initial RTO of 500 ms for all links (not just wired= )?

=46rom RFC 5389 Section 7.2.1:

   A client SHOULD retransmit a STUN re=
quest message starting with an
   interval of RTO ("Retransmission TimeOut"), doubling after each
   retransmission.  The RTO is an estimate of the round-trip time (RTT),
   and is computed as described in RFC 2988 [RFC2988], with two
   exceptions.  First, the initial value for RTO SHOULD be configurable
   (rather than the 3 s recommended in RFC 2988) and SHOULD be greater
   than 500 ms.  The exception cases for this "SHOULD" are when other
   mechanisms are used to derive congestion thresholds (such as the ones
   defined in ICE for fixed rate streams), or when STUN is used in non-
   Internet environments with known network capacities.  In fixed-line
   access links, a value of 500 ms is RECOMMENDED.  Second, the value of
   RTO SHOULD NOT be rounded up to the nearest second.  Rather, a 1 ms
   accuracy SHOULD be maintained.  As with TCP, the usage of Karn's
   algorithm is RECOMMENDED [KARN87].  When applied to STUN, it means
   that RTT estimates SHOULD NOT be computed from STUN transactions that
   result in the retransmission of a request.
= --Apple-Mail-4EAE43FD-AAD7-4E91-8DB7-D67528349E75-- From nobody Wed Sep 14 19:51: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 837C212B145 for ; Wed, 14 Sep 2016 19:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 z7UHj7-E2QK5 for ; Wed, 14 Sep 2016 19:51:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95B12B128 for ; Wed, 14 Sep 2016 19:51:45 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9602741707; Wed, 14 Sep 2016 20:52:37 -0600 (MDT) To: Martin Thomson References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Wed, 14 Sep 2016 20:51:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jonathan Lennox , "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 15 Sep 2016 02:51:46 -0000 On 9/8/16 10:41 PM, Martin Thomson wrote: > On 9 September 2016 at 06:24, Peter Saint-Andre wrote: >> Note: The signaling protocol needs to provide a mechanism for both >> parties to indicate and agree on the ICE negotiation session (ufrag) >> in force so that they have a consistent view of which candidates are >> to be paired. This is especially important in the case of ICE >> restarts (see Section 13). > > Are we separately clear that ufrag needs to be different for each ICE > negotiation session that an endpoint instantiates? That appears to be the general understanding, but I'm not sure if it is exactly specified anywhere. Do think it belongs in the trickle spec or the core ICE spec? (IMHO the latter is more appropriate.) > BTW, I find the parenthetical useless. "(as identified by ufrag)" > might be better. Seems like an improvement, yes. Peter From nobody Mon Sep 19 20:37: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 80EAF12B02C for ; Mon, 19 Sep 2016 20:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 oaR5SH1QarFL for ; Mon, 19 Sep 2016 20:37:53 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 1CC7D12B185 for ; Mon, 19 Sep 2016 20:29:38 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id q2so2157428pfj.3 for ; Mon, 19 Sep 2016 20:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=JtHPRhRZk85A7CmZ5L/dA0fr299ouOKXoKqVHa8WhcI=; b=McjRT4R1dx5CChlwWb2WCFoBszQaFBlL6fmlfQsJGsYXZHSk0KYFAf8mxaFZ7vEEc6 zPDWCE/mz/oMjGUUzego7xBGypCIpfe71RmdmJP7FSIA1F5C7KDjxekkx2cXm8jN/HN4 akwvCatQqrv3bsRC4+PtebLRz4h/GobaMQaGM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=JtHPRhRZk85A7CmZ5L/dA0fr299ouOKXoKqVHa8WhcI=; b=XwyV2/jVJIlzMRUA91zeFIaJpX7SBmgPylEfCn1LpBUpirzDkK58kspueo5l2v+trV TgM0OiGRYSp6fDrWXfLDqyi7IXmM6yNbYglWd8WtQREP1QffkNNNPi8HYlXPtwmor8mf LAtMEPsTJRVNY88eVd215JGCDi+d5ctmFMKM6cUH0MzzuoXj+dAjtDBxKecAjmZOq0wl cc/ljze2qGSTg7FfYHedf5MW1LoQsNCu5vkACxjpYSLYqG9oaVrRIgg74QGIJRIeU16B D7xRMBwWGPqvJc/qFJOwR5FodeQt2Iev/3NO8n9dljXZI265NAmLVdIJNujwMI8mrvFn +WZw== X-Gm-Message-State: AE9vXwM0krc9iFU0qiqDtfgk4scSUI3XVZe4zQ6hP4k0YlLoqLelKknbFvSlcQHasXjMC/4P X-Received: by 10.98.62.4 with SMTP id l4mr24553091pfa.13.1474342177437; Mon, 19 Sep 2016 20:29:37 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:8057:324f:7acc:e08? ([2601:647:4601:ec84:8057:324f:7acc:e08]) by smtp.gmail.com with ESMTPSA id 70sm41750178pfn.46.2016.09.19.20.29.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 20:29:35 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C3DF44FF-0E16-45EE-9E18-A59D6A68243E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Nils Ohlmeier In-Reply-To: <722b9fd3-f783-288e-af4f-dd2cbf59523a@stpeter.im> Date: Mon, 19 Sep 2016 20:29:35 -0700 Message-Id: <5AB69686-C4F4-4298-AA51-77826C2B38C1@mozilla.com> References: <722b9fd3-f783-288e-af4f-dd2cbf59523a@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] trickle: replacing candidates 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, 20 Sep 2016 03:37:55 -0000 --Apple-Mail=_C3DF44FF-0E16-45EE-9E18-A59D6A68243E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 7, 2016, at 19:48, Peter Saint-Andre = wrote: >=20 > NEW >=20 > Once this is done, the agent examines the check list looking for > another pair that would be redundant with the new one. If such a > pair exists and its type is not peer reflexive, the pair with the > higher priority is kept and the one with the lower priority is > discarded. If, on the other hand, the type of the pre-existing pair > is peer reflexive, the agent MUST replace it with the new candidate > it received (regardless of their respective priorities); this is = done > by setting the priority of the new candidate to the priority of the > pre-existing candidate and then re-sorting the check list. Could someone please explain to me what the "type of a pair" means? According to 5245 https://tools.ietf.org/html/rfc5245#page-33 candidate = have types, but pairs don=E2=80=99t. I think I have an idea of what is = meant by this, but I think this should be clarified in the text. Further more I think that the paragraph above in section 8.1 kind of = contradicts section 11 saying =E2=80=9C...it does not require any change = in processing.=E2=80=9D I think an update of section 11 is due. I can try to provide new paragraphs if that helps. Best Nils Ohlmeier --Apple-Mail=_C3DF44FF-0E16-45EE-9E18-A59D6A68243E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJX4K0gAAoJEJ3NnGfOORkkCJgP/iAcUoVrTWolL0nY8JUlUMrd D1aCX474Y+u6wTxJ6USriXclmIZMFQKA/NdxwuXAun3XYC6/RLE4X084DfL/eAas HEUUGsoiHhjk0AszULZaopHVaboi61ffELoorPNfXuyrE1cPqNeh+bEoCCttzjc4 PbVUIKSkOwpJzLdOVkZqh718zmg+G4OLWjOLXjjTybK0uXHeBFLg3+yfP7lr2TQ5 K6WvtJa3CUyBwFbs/ocTSOvxjtn+gbocZgyLH+vTgquwm+lgdi5/hui9gPdcIaQd jZj3r/agWWtObLxtCkarJoOnUaDlFPz528SRBtyuYS3+KVdgPEB100vGBkg2u94R CfyjLE82YJF7kd7fnCT7kSviNmdJHIaBnODaHlLbVXXyFw2sBRgd7n240agLhRq5 XYamzIEz+p5YWjiv4kS3LuoS8qkMk9wsopU90Upn95Td9qmZefc0XqFmU8r54yKQ OFm8X7NRpZ1nIWUM/dzHnkk13sVioGNY7Ol3UntASwmloPSxcL5Y1NsijoC59KR0 /gQJYNoS5wbVf5/MP3zdsUEOAlRrHB6mqFkcBuYrb5FJLR1Dwe1ZmUIwHMvCP3kg OOg6K8wkgroD9LGH9Q5Vc0KJev6piofzHkjUUoAldMFsE40LRgE4/q53m9Y5SVKx nubJNX7MDkuU1YfZ7GtP =IUzf -----END PGP SIGNATURE----- --Apple-Mail=_C3DF44FF-0E16-45EE-9E18-A59D6A68243E-- From nobody Mon Sep 19 20:46: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 0F6A112B5FE for ; Mon, 19 Sep 2016 20:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 iLfvRJnQXhxJ for ; Mon, 19 Sep 2016 20:46:20 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 8C00512B5FA for ; Mon, 19 Sep 2016 20:46:20 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id 21so2353731pfy.0 for ; Mon, 19 Sep 2016 20:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:message-id:references:to; bh=9UH70+B5l6f1IDs912KS28psdwAdbCaPzK7znLNX0FE=; b=T+CltouU21vj7Drnor3ADUCdp+MGjNiSYqXZEzwWCrozfHMLqGCwx82tgJTRDoVJew 2htKwTwwk5qI+SADbAxea2FaR68wcJ1PHCSMUVFiZkulXiFbtFcDK0B1VTD8tgEVgx3O hD4Q4ZBKwUYYUSXATsfpOavmI9n9x9MWsk3XY= 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 :message-id:references:to; bh=9UH70+B5l6f1IDs912KS28psdwAdbCaPzK7znLNX0FE=; b=HVR+wyEfjWZY0sM5GpP4VrW4E6lDRYG6Iwp+qyfYtDQVGYq/l6AXb+DUk1nT2xkGWS 6iKbR6r11r+yAneEYF72eBJjZIPidfJIwhER5wLKqgUC/ryn9VYaBffqFJeAwnV4f4Vt 46yhCzYSfzoAPdTT5hGahmEEr5eXWujOF3ztV0uhuxjpEvCGVnbegJeVSXusSpLp1mVF g1yF8vrKxMrO4mmx1ABwPMxKDh8f6ocgjBBJfxfTvI6zIZ03nXesRGGnxJwQJKI+8Rci 5MBgLgR9GU8cfxnxNM8J3pyDkntmO2rIirDILcXIMCM6GyXa5o7pBFSwcZLG2k4XugnW syKw== X-Gm-Message-State: AE9vXwNmyDJcn5YJxTcWUFHiQAcfQnF94LoKc3encytym12XVlEDXBUo3nqG7VlVd7ovsPI+ X-Received: by 10.98.149.149 with SMTP id c21mr31988510pfk.33.1474343179643; Mon, 19 Sep 2016 20:46:19 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:8057:324f:7acc:e08? ([2601:647:4601:ec84:8057:324f:7acc:e08]) by smtp.gmail.com with ESMTPSA id n3sm34657659paf.13.2016.09.19.20.46.18 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 20:46:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_11F49DA7-0EB8-43C9-AE72-83D0A0D9FB17"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Nils Ohlmeier In-Reply-To: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> Date: Mon, 19 Sep 2016 20:46:18 -0700 Message-Id: <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> To: ice@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Ice] Triggered checks are missing peer reflexive 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, 20 Sep 2016 03:46:24 -0000 --Apple-Mail=_11F49DA7-0EB8-43C9-AE72-83D0A0D9FB17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 After reading up on how the current Trickle ICE draft proposes to handle = peer reflexive candidates it appears to me that my scenario below is = relevant for ICE 5245bis if there is no STUN server. And if there is a STUN server then it should only happen if B has = trickled his public host candidate to A already. And A receives its = binding response from B before it discovers his own server reflexive by = receiving a binding response from the STUN server. Even if we don=E2=80=99t bother do try to optimize the useless/redundant = trigger check away I think we should: - include peer reflexive candidates into the paragraph of 5245 which = talks about trigger checks - extend the paragraph in the trickle draft to not only mention = discovering peer reflexive candidates via STUN binding request, but also = from binding responses. I would appreciate some feedback on this before trying to propose = improved wording for both specs. Best Nils Ohlmeier > On Sep 2, 2016, at 13:34, Nils Ohlmeier wrote: >=20 > Hello, >=20 > I have identified something which I would be interested to hear the = opinions of the ICE experts about. >=20 > In RFC 5245 (section 7.2.1.4) and also in bis-04 (section 6.1.3.1.4) = claim the following regarding receiving triggered checks: > The local candidate will either be a host candidate (...) or a = relayed candidate (=E2=80=A6). The local candidate can never be a server = reflexive candidate. >=20 > Which I think is missing the case where the local candidate can also a = be a peer reflexive. And this is actually causing unnecessary extra = checks to be made. >=20 > Consider the following scenario: >=20 > - A sits behind symmetric NAT > - B is on a publicly routable address with no NAT or firewall > - No STUN servers (just makes the scenario less complex) > - Host candidates get exchanged and candidate pairs A:B and B:A get = created on both sides > - A sends binding request to B > - B receives binding request with transport address A=E2=80=99 > - B creates a peer reflexive candidate for A=E2=80=99 and the a new = pair B:A=E2=80=99 and puts that new pair into its trigger check queue > - B sends binding response to A=E2=80=99 > - A receives binding response, learns about A=E2=80=99 and creates = A=E2=80=99:B and marks it as successful > - Now B sends a binding request for it trigger check queue entry to = A=E2=80=99 > - When A receives this binding request is has no way to match this to = the successful pair A=E2=80=99:B > - Because of the wording in the above mentioned sections it will match = the request to the pair A:B > - Which then in turn causes another triggered check to be created = because A:B is not in the success state >=20 > This additional triggered check from A is just waste of time and = resources. It does not hurt. But I=E2=80=99m wondering how this could be = avoided. >=20 > If people agree I think section 6.1.3.1.4 should at least mention the = scenario that incoming binding requests can also match a peer reflexive = candidate. >=20 > As the incoming binding request does not contain the destination = address it got send to there is obviously no way for A to clearly = distinguish if the request got send to A or A=E2=80=99. >=20 > For avoiding the additional triggered check on A=E2=80=99s side the = only solution I see right now is to go through the pairs which have A as = their foundation and if that list contains a pair which is marked as = successful already assume no triggered check is needed. So far I have = not been able to identify a scenario where it hurts to skip this extra = round of triggered checks on A=E2=80=99s side. >=20 > Best > Nils Ohlmeier >=20 --Apple-Mail=_11F49DA7-0EB8-43C9-AE72-83D0A0D9FB17 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJX4LEKAAoJEJ3NnGfOORkkRDUP/RmieUhmc3NJ1DKvynnp+lpy KYwdJtm4Bcf4Dm0fhTGwSPEszt4uiqovm+KoZGpX10IfPfHgE12kJsp6AUxPmR3b bxN7PVeXI8RA9DvaKNG4Z0+nbgo5dzpP5d3B1oIaw2Ha4QacMtrz5e2lzoWGJEp2 93LJnfpb2m4C1xJJ6HRHtt/ilTx3y6yNJYKMbomMqaOh5+bnHpVJH8KYO4hBMhFR 7ITAEIbeU9BrprjMBnIYfaSv17fxCz8xOcOtReXT3+obgbuKULqWIqfYEonx+FNo vBBuE09AMofgWl1DrS5RD3n2u1bahSj+YfaqiAFlLw/fN9eSjTgd36Hl5WAycFfV Z85ectXeMW7qaq0AGAAUneF43JqqOLGypoQpHakF2qAVGXAMzoRArx2b7S2/3SUg 2cS+mq/3jCUjKeiPY7pZeFEf0G+uGD8J+QDWkavzatKvlglpZAhIxIFBch2Y4LWe tIMCBY0yxhupkcSFkEiEKmC+RbOk+nBSh1XqiKaJbGMpw53vDngdaDOjQvpAS4DI 8PL1c+13+kEi1CuU0GW8yo2jrYut3GLQY1M0mvpi7AlfW23Pgd6h+SqnLVDQe2Th 5zGPQOKFbtujGkH+rjC0LWbvA0GHxSkq+wzqh9Om0r7vsRzDEQWjIWurS2BoB4QS sH1Ky0YkUYmDYoDeqjHM =Uu72 -----END PGP SIGNATURE----- --Apple-Mail=_11F49DA7-0EB8-43C9-AE72-83D0A0D9FB17-- From nobody Tue Sep 20 05:14:40 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 8481712B2CC; Tue, 20 Sep 2016 05:14:34 -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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147437367453.29128.5009738601797231116.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 05:14:34 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-05.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: Tue, 20 Sep 2016 12:14:34 -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-05.txt Pages : 10 Date : 2016-09-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. 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-dualstack-fairness-05 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 Tue Sep 20 05:31:16 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 A147012B2E4 for ; Tue, 20 Sep 2016 05:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 a4LZ064IFQYD for ; Tue, 20 Sep 2016 05:31:10 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E4B12B2FB for ; Tue, 20 Sep 2016 05:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4312; q=dns/txt; s=iport; t=1474374670; x=1475584270; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NJlZ9S5Su7RDYIqnUA3ZSkEvoTl1wb5l/KtU2hP7qHo=; b=U7WtWGsEJbfV0HQZlRB7SJTIDp00shMMyO/QRfjlAzGicX9EmE7MHXnJ U9xLK5KR4NFFIb5sogrk0yCnQvp/mn2WrgThKJZrESg8TCkC2GDxgnLky ZotMs4639A38tdSTzlN8ac5/oriUMIXM1z2PTIMCa7eQwrb5zVQ0nSOlb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AQDtKuFX/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAR5XfAeNLKtCggQZDYV4AhyBRTgUAQIBAQEBAQEBXhw?= =?us-ascii?q?LhGEBAQEDAQEBASAROhALAgEIGAICJgICAiULFRACBBOIQggOsBOMRwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARyBBoUxgXwIglCERIMCK4IvBYgthz+KBQGGJYk4gW5?= =?us-ascii?q?OhBWJGoxkg3oBHjaFA3KGI38BAQE?= X-IronPort-AV: E=Sophos;i="5.30,368,1470700800"; d="scan'208";a="325657185" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Sep 2016 12:31:09 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u8KCV9D1015383 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Sep 2016 12:31:09 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Sep 2016 08:31:08 -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.1210.000; Tue, 20 Sep 2016 08:31:08 -0400 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" Thread-Topic: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-05.txt Thread-Index: AQHSEziRgHtxq4EGY02AlC4OFmN1GKCCklYA Date: Tue, 20 Sep 2016 12:31:08 +0000 Message-ID: References: <147437367453.29128.5009738601797231116.idtracker@ietfa.amsl.com> In-Reply-To: <147437367453.29128.5009738601797231116.idtracker@ietfa.amsl.com> 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.24.40.210] Content-Type: text/plain; charset="utf-8" Content-ID: <1E094C4E6B361142AA0493F37E44CDBC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-05.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: Tue, 20 Sep 2016 12:31:15 -0000 SGkgYWxsLA0KDQpUaGlzIGFkZHJlc3NlcyBhbG1vc3QgYWxsIHRoZSBkaXNjdXNzZXMgZnJvbTog aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pY2UtZHVhbHN0YWNr LWZhaXJuZXNzL2JhbGxvdC8NCg0KTWlyamEgS8O8aGxld2luZHMgRElTQ1VTUyBpcyBvbmx5IHBh cnRseSBhZGRyZXNzZWQuIFRoZSBtaXNzaW5nIHBvaW50IGlzOg0KIi0gSG93IGRvIEkgbWVhc3Vy ZS90cmFjayB0aGF0IGFuIGludGVyZmFjZSBoYXMgY29ubmVjdGl0aXZ5IHByb2JsZW1zOiBjb25u ZWN0aXZpdHkgZmFpbGVkIG9uY2UsIG9yIHR3aWNlLCBvciBYLXRpbWVzPyBIb3cgbG9uZyBkbyBJ IGtlZXAgdGhpcyB0cmFjazogMWgsIG9uZSBkYXksIG9uZSB3ZWVrLCBmb3JldmVyP+KAnQ0KDQpJ IHRoaW5rIHRoaXMgc2hvdWxkIHJlbWFpbiBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuIEkgaGF2 ZSBubyBhZHZpc2Ugb3IgcmVjb21tZW5kYXRpb24gdG8gcHJvdmlkZSwgYW5kIG15IGd1ZXNzIGl0 IHRoYXQgaXQgd2lsbCBiZSB2ZXJ5IGltcGxlbWVudGF0aW9uIGRlcGVuZGFudCBhbnl3YXkuIFRo aXMgd2lsbCBjYXVzZSBubyBpdGVyb3AgcHJvYmxlbXMuIElucHV0IGZyb20gdGhlIFdHIGlzIG11 Y2ggYXBwcmVjaWF0ZWQuIA0KDQpDaGFuZ2VzOg0KDQpSZW5hbWVkIGRyYWZ0IHRvOiBJQ0UgTXVs dGlob21lZCBhbmQgRHVhbFN0YWNrIEd1aWRlbGluZXMgICAgIChBIGdsaXRjaCBpbiB0aGUgWE1M IGZpbGUsIEkgZWRpdGVkIHRoZSBhYmJyZXYgaW5zdGVhZCBvZiB0aGUgcmVhbCB0aXRsZSwgd2ls bCBiZSBmaXhlZCBpbiAtMDYpDQpGaXhlZCB3b3JkaW5nIGluIGRvY3VtZW50IHRvIGFjY29tbW9k YXRlIHRoZSB0aXRsZSBjaGFuZ2UuIA0KDQpBZGRlZCB0ZXh0IHRvIHNlY3Rpb24gNDoNCiJBIHNp bXBsZSBmb3JtdWxhIHRvIGNhbGN1bGF0ZSBob3cgbWFueSBJUHY2IGFkZHJlc3NlcyB0byBwdXQg YmVmb3JlDQphbnkgSVB2NCBhZGRyZXNzZXMgY291bGQgbG9vayBsaWtlOg0KDQogICAgICAgICAg ICAgICAgSGkgPSAoTl80ICsgTl82KSAvIE5fNA0KDQogICAgICAgICAgICAgICAgV2hlcmUgSGkg ID0gSGVhZCBzdGFydCBiZWZvcmUgaW50ZXJtaW5nbGluZyBzdGFydHMNCiAgICAgICAgICAgICAg ICAgICAgICAgICBOXzQgPSBOdW1iZXIgb2YgSVB2NCBhZGRyZXNzZXMNCiAgICAgICAgICAgICAg ICAgICAgICAgIE5fNiA9IE51bWJlciBvZiBJUHY2IGFkZHJlc3Nlcw0KDQpJZiBhIGhvc3QgaGF2 ZSAyIElQdjQgYWRkcmVzc2VzIGFuZCA2IElQdjYgYWRkcmVzc2VzLCBpdCB3aWxsIGluc2VydA0K YW4gSVA0IGFkZHJlc3MgYWZ0ZXIgNCBJUHY2IGFkZHJlc3NlcyBieSBjaG9vc2luZyB0aGUgYXBw cm9wcmlhdGUNCmxvY2FsIHByZWZlcmVuY2UgdmFsdWVzIHdoZW4gY2FsY3VsYXRpbmcgdGhlIHBh aXIgcHJpb3JpdGllcy7igJ0NCg0KDQouLS4NClDDpWwtRXJpaw0KDQoNCj4gT24gMjAgU2VwIDIw MTYsIGF0IDE0OjE0LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0KPiANCj4g QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCBvZiB0aGUgSUVURi4NCj4g DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBJQ0UgTXVsdGlob21lZCBhbmQgSVB2NC9JUHY2 IER1YWwgU3RhY2sgRmFpcm5lc3MNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFBhYWwtRXJp ayBNYXJ0aW5zZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFRpcnVtYWxlc3dhciBSZWRk eQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgUHJhc2hhbnRoIFBhdGlsDQo+IAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLWljZS1kdWFsc3RhY2stZmFpcm5lc3MtMDUudHh0DQo+IAlQ YWdlcyAgICAgICAgICAgOiAxMA0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNi0wOS0yMA0KPiAN Cj4gQWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBndWlkZWxpbmVzIG9uIGhv dyB0byBtYWtlIEludGVyYWN0aXZlDQo+ICAgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElD RSkgY29uY2x1ZGUgZmFzdGVyIGluIG11bHRpaG9tZWQgYW5kDQo+ICAgSVB2NC9JUHY2IGR1YWwt c3RhY2sgc2NlbmFyaW9zIHdoZXJlIGJyb2tlbiBwYXRocyBleGlzdC4gIFRoZQ0KPiAgIHByb3Zp ZGVkIGd1aWRlbGluZXMgYXJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggdGhlIG9yaWdpbmFs IElDRQ0KPiAgIHNwZWNpZmljYXRpb24uDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWNlLWR1YWxzdGFjay1mYWlybmVzcy8NCj4gDQo+IFRoZXJl J3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pY2UtZHVhbHN0YWNrLWZhaXJuZXNzLTA1DQo+IA0K PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWljZS1kdWFsc3RhY2st ZmFpcm5lc3MtMDUNCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJY2UgbWFpbGlu ZyBsaXN0DQo+IEljZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ljZQ0KDQo= From nobody Wed Sep 21 09:15: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 F22C712B58C for ; Wed, 21 Sep 2016 09:15:36 -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 ngoQx98NqjKk for ; Wed, 21 Sep 2016 09:15:35 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89DCD12B587 for ; Wed, 21 Sep 2016 09:15:34 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-1b-57e2b2246a1f Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id BB.FC.31035.422B2E75; Wed, 21 Sep 2016 18:15:32 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.213]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Wed, 21 Sep 2016 18:15:31 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Peter Saint-Andre , Martin Thomson Thread-Topic: [Ice] trickle: ufrag signaling Thread-Index: AQHSCXsKTrwBW8QyMUi9OqYMiS0htqBvmjkAgAABuQCAAAI3AIAAS1KAgACK/wCACU83gIAKTpAA Date: Wed, 21 Sep 2016 16:15:30 +0000 Message-ID: References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> 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.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7C843E7E443F584580BCAA44643DDBFC@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7nK7KpkfhBjdvWFt8u1BrsX/xeWaL a2f+MVoc29PP7MDisXPWXXaPJUt+MnnM3fOC2aPt2R32AJYoLpuU1JzMstQifbsErowHRxay FpzjqvjyZwJrA+Muji5GTg4JAROJpWe2snUxcnEICaxnlGi5/JQZwlnCKHF83SVGkCo2AXuJ yWs+gtkiAuESc94tArOZBdwlXhzfwgJiCwtoS+xdupAZokZHYu32f0wQdpTEusYWNhCbRUBV 4uuG7awgNi/QzKPf17NCLGtjlpi15zXYUE4BO4lThzrBmhkFxCS+n1rDBLFMXOLWk/lMEGcL SCzZc54ZwhaVePn4HyuErSTRuOQJK0S9nsSNqVPYIGxriTt7mtghbG2JZQtfM0McIShxcuYT lgmMYrOQrJiFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwAg9u +a26g/HyG8dDjAIcjEo8vAmTHoULsSaWFVfmHmKU4GBWEuHtWwsU4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgVH1tMbkcLabDHcFGBpfi7ss6e20fXj2 2qmZ538/lteebDU1wmaRe3uZmufazVVHO1o4f/vIPFpy8sWfktB1589feydcaMzgpGj3YKLD k8P/jCzmM9dMkcjo5WuTWflmyxdTboZJbyzTqrbtOKS8pqDmeqVmbPmmTq2uSQYeDh6PfPrm XMneaKnEUpyRaKjFXFScCACId+ALvAIAAA== Archived-At: Cc: Jonathan Lennox , "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 21 Sep 2016 16:15:37 -0000 > On 15 Sep 2016, at 03:51, Peter Saint-Andre wrote: >=20 > On 9/8/16 10:41 PM, Martin Thomson wrote: >> On 9 September 2016 at 06:24, Peter Saint-Andre wro= te: >>> Note: The signaling protocol needs to provide a mechanism for both >>> parties to indicate and agree on the ICE negotiation session (ufrag) >>> in force so that they have a consistent view of which candidates are >>> to be paired. This is especially important in the case of ICE >>> restarts (see Section 13). >>=20 >> Are we separately clear that ufrag needs to be different for each ICE >> negotiation session that an endpoint instantiates? >=20 > That appears to be the general understanding, but I'm not sure if it is e= xactly specified anywhere. Do think it belongs in the trickle spec or the c= ore ICE spec? (IMHO the latter is more appropriate.) (hats off) Seems like core ICE thing to me. ICE-bis says (https://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-05#s= ection-9): > To restart ICE, an agent MUST change both the password and the user > name fragment for the media stream in an offer. Do you think we need something more there? >> BTW, I find the parenthetical useless. "(as identified by ufrag)" >> might be better. >=20 > Seems like an improvement, yes. +1 Cheers, Ari= From nobody Wed Sep 21 18:12: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 13F4912C089 for ; Wed, 21 Sep 2016 18:12:44 -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 d05MIrUAZtgM for ; Wed, 21 Sep 2016 18:12:42 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 130F712C07B for ; Wed, 21 Sep 2016 18:12:42 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 93so31349017qtg.2 for ; Wed, 21 Sep 2016 18:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e/EZpvAml/Kj0OtvW2A/099e5m7U8BKNnEzogW3Rtpk=; b=YrmmvVCxI2gs3/zn5i8JcJ7h85jxqN4eK7TftTMZTGqHjdyFwc2fbjgdGgg/b2jA8e I2gboHga+/YDSECYQKmj1PzTp1nmJzrRcXqGAypS6HbtBnYpjh4TGmWKvtD+3gneD/5i 9VqvAJIO8+qy7ti1QGMVTp+HDM9yjFTclKFGpMs59ROVnD37gwplLK/ylyVC09DMz9r/ uvfNeLpX3AmpQHJm218qvQvSH8JOhqId284uIuUULno4dT68F2sAwTiex0rH/fv6BM04 CrzpdxOvuII60fHL+6q9nRIm83rMafMB41UEKDyEkZtQNcjbXaEWJWEZdzo86hUipIh3 46dA== 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:content-transfer-encoding; bh=e/EZpvAml/Kj0OtvW2A/099e5m7U8BKNnEzogW3Rtpk=; b=Ex8BXTFFZGuCJW5ePk51dl9m2zrAVCe+nCIvEz6efAFIxZfpU2aYox5cXIObUx0dCz fSu5ezcjPYsZ9+4HNcJt2jZniskS2vTi891jBwrx53oyRxL4EyH+A5uxEzfEtuds4P4v 1ZlWjw96Hp9darjvJr6ZEGyCeWKRacVqA8pQxhCHPZrgv+qnH9L9QqFX8uS9ZMLJr1bY GopRMCvd32nolPQbEkwWNGT6wTB+G6osMtynCcV58zHuyRTs+YNwnZ6jCnNg5xJeaKy4 AAO3gN5icAbDLlT5sWM4Ahdamioh5U+eXP75lg26dL8iKsLeIh+JpPlLu84LJ2ZE+Alq +2kQ== X-Gm-Message-State: AE9vXwNNvfeEA4dppi/iiGkwwByMmyVLePRjCI0bRfrMIFi07tdJZkXd0blGuFad/8o9u1T+wtMjoAQleMjoFA== X-Received: by 10.200.39.201 with SMTP id x9mr45151856qtx.3.1474506761281; Wed, 21 Sep 2016 18:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Wed, 21 Sep 2016 18:12:40 -0700 (PDT) In-Reply-To: References: <9dcda98b-2df8-bd12-d842-7ee83e9795e4@stpeter.im> <77E3BE4F-CF41-4907-8DC4-C21F501574E7@vidyo.com> <216f3be1-4156-b66b-a90a-23dcfedb0857@stpeter.im> From: Martin Thomson Date: Thu, 22 Sep 2016 11:12:40 +1000 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] trickle: ufrag signaling 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, 22 Sep 2016 01:12:44 -0000 On 22 September 2016 at 02:15, Ari Ker=C3=A4nen = wrote: > Seems like core ICE thing to me. > > ICE-bis says (https://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-05= #section-9): >> To restart ICE, an agent MUST change both the password and the user >> name fragment for the media stream in an offer. > > Do you think we need something more there? Probably. We need to say that the ufrag needs to be unique across all ICE restarts (do we have a better name for this? Peter uses "generation", I think) within a session. It probably also needs to be unique across all sessions that are terminated by the same hosts. From nobody Fri Sep 23 05:47:13 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 78B4312BD1B for ; Fri, 23 Sep 2016 05:47:11 -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 juVtbGuw1LAO for ; Fri, 23 Sep 2016 05:47:10 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 403FE12BD28 for ; Fri, 23 Sep 2016 05:47:09 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id w84so29719636wmg.1 for ; Fri, 23 Sep 2016 05:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=FMXi6CW9StY06eCCvEXHUIA0e0Z2WFSpy1gT6wixkcQ=; b=vgIUHm+T6iCxY5Fppziifg6yUhFuH6LDXJQjr942hFqLkRXpi1HFDidGnXbWH5eu3B PBEhzo7sus50sVkSR0xGMr005xThcndz4WlUTpMRMeMO6aEQ4qZfWQVbqG07ZMg+USdq JEiWWccjOELxXi/0zudBRV/qrhDFSAtwP4i+HFNJRwwV0WLvm1RGobKooG42iVxazybP /3OaCXv2/4Q02/3iuZMlB2dsVnqj66KXxh2f2LNor3ylI9zjmbLdy+9yJQ02muLWFhjE SCotr/27ogEErLW7diyQDC8I7bDsVZ+8UVuQhU9RZH66Mfw7/gFjueShS/B9bg5WCIyQ DaOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=FMXi6CW9StY06eCCvEXHUIA0e0Z2WFSpy1gT6wixkcQ=; b=Kgyk10vknvm4qpuL8lWnSkeQAo5qL3Dn7+8BDNj58sSgQL5eHeIuvVnBaBNzW7UzMB aDPqMgiC52jjYM76/fR6tZtsdgo/lB+qFC7T2/ax4uEU8OVySSU+wk2jeTKOtCVfe/I2 PsylGelsaeVlpK92tji1kI6i1cDzWy2UFnSLntwj9W/2DFaXVeckQjTLHp2TFkt+jypB VZdgTAcvZ3jMDAlHOg2GqbveousEf/vJTUImi5zN66UI5kFJsjUa9MDDH1R8KsM/FBHn 1EhVRvwJ678VrH49/7ENESyrXiHzR+mjpFisrju2YXs7LWNH9KDFLXWkyYM1sjMpHoJt gE9w== X-Gm-Message-State: AA6/9RlDtB8LfxbtYFr19w1ChUfqZEYX0jEU8YlQ2DzOXfsO4RZ5evJl6s/SvbCXUubKsg== X-Received: by 10.28.143.82 with SMTP id r79mr2543625wmd.7.1474634827562; Fri, 23 Sep 2016 05:47:07 -0700 (PDT) Received: from [192.168.2.114] (d91-130-3-225.cust.tele2.at. [91.130.3.225]) by smtp.googlemail.com with ESMTPSA id bk7sm7084035wjc.36.2016.09.23.05.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Sep 2016 05:47:06 -0700 (PDT) From: Thomas Stach To: ice@ietf.org Message-ID: Date: Fri, 23 Sep 2016 14:47:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , Christer Holmberg Subject: [Ice] Do we currently need functionality for removing candidates? 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, 23 Sep 2016 12:47:11 -0000 All, in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a question came up, if we need functionality for removing candidates. From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in draft-ietf-ice-trickle-04, I have the impression that this is currently not in scope of the Trickle ICE work. Could anybody confirm that this impression is correct? If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-sip. Regards Thomas From nobody Fri Sep 23 15:52:57 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 F006112B8F2 for ; Fri, 23 Sep 2016 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 U4ohY-Q_Kmya for ; Fri, 23 Sep 2016 15:52:54 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 54C9712B500 for ; Fri, 23 Sep 2016 15:52:54 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 197so9388696wmk.1 for ; Fri, 23 Sep 2016 15:52:54 -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=47x3t1IdnhCBabCG3O6m0WVAZ2j8qFNXk+eX+Kh7Ybk=; b=uxYxUSKyPW90tkQtqG48HiDPn9gFhMpdmEjVGgAbwqCCXFKbAuXLrxYJXQBZpy3rKY E8L+wf733BFpMBl5SV6XiA8iiNi3592FHjt3DxNqCDZYLKhTrTNtTm7VjVYXoLY17k/s ODpK7fZ9UdnZ+rNibCCI1Kr+uwJ5ox8roI9H+Zl85knjL8WRZxZKha9jNy2FYqPXRSIj EgDhMVxvhvvkhtalyiFT7OSLqtAZ9JkR0lJbp/+tTbJTRIyXlrTB1e9DREaxibtuBDC/ /1f493skuQhq/gmAlvEQfMFzk8Cru7kQp2OxpQSivEovKbR2e551AFIi5KNQ5a2QLgut Gn3w== 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=47x3t1IdnhCBabCG3O6m0WVAZ2j8qFNXk+eX+Kh7Ybk=; b=YYzTlrm0Xz8ZH0ZMt5YrCVOB5qKE0nQtzo5eYzWkJ2Xvsg+dxVgGJJvEzX9SmQvW2F 7pMRiJZpgq8V+43Rf09fCwfsXbc3QuOEhNTPicFZY2rsjH1pWHhTSEjd6DWW3t6W8K9x /y1ZdJABfhNj4du4OwNC8QLmr3PTU6AXgW1P1ydBTkFvA9TOlMes8mr88hvrjHbgOND1 BqzIWUSvDfiK8EutU0QpqSZjD9dWAFR8JIWGWv0ttb309WuDZJvzYlWi6JfuOd9cJ1i9 Tac8kDtE7zrNZjvIUskauQK2MrHBMFgfF/wYO0h9vTM7Wsnoi8t0xoq7o8mvu8keiszG WZZg== X-Gm-Message-State: AE9vXwOax94/FrWY7Vf5jsmbQxT/LjKaXcT/9FisER7blVzcor80UQeu/98bT2uewUbyzA== X-Received: by 10.194.105.37 with SMTP id gj5mr10534421wjb.113.1474671172884; Fri, 23 Sep 2016 15:52:52 -0700 (PDT) Received: from [10.0.2.99] ([88.157.213.130]) by smtp.gmail.com with ESMTPSA id p144sm5240018wme.0.2016.09.23.15.52.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Sep 2016 15:52:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-39BD6250-019D-4292-B06E-A4F15E498CB3 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14A403) In-Reply-To: Date: Fri, 23 Sep 2016 23:52:51 +0100 Content-Transfer-Encoding: 7bit Message-Id: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> References: To: Thomas Stach Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , Christer Holmberg , ice@ietf.org Subject: Re: [Ice] Do we currently need functionality for removing candidates? 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, 23 Sep 2016 22:52:57 -0000 --Apple-Mail-39BD6250-019D-4292-B06E-A4F15E498CB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I believe that removing candidates is very useful. Let me give an example. W= ith TURN mobility, it is possible to retain pairs involving TURN candidates a= cross interface changes. So if you leave a building and WLAN host candidates= become unavailable, if you have cellular connectivity you can use TURN mobi= lity to keep media flowing while looking for a better candidate pair. To avo= id loss of consent that would invalidate Pairs involving the WLAN candidates= , it is desirable to remove (and perhaps later, renominate) the WLAN host an= d srvflx candidates. The package of TURN mobility, removal, renomination and aspects of passive-a= ggressive nomination therefore enables efficient and effective ICE mobility.= Code is available for inspection in ORTC Lib (http://ortclib.org/) > On Sep 23, 2016, at 1:47 PM, Thomas Stach wrote:= >=20 > All, >=20 > in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a q= uestion came up, if we need functionality for removing candidates. >=20 > =46rom list discussion in ICE, the minutes of the Berlin IETF and due to t= he lack of corresponding text in draft-ietf-ice-trickle-04, I have the impre= ssion that this is currently not in scope of the Trickle ICE work. >=20 > Could anybody confirm that this impression is correct? >=20 > If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-= sip. >=20 >=20 > Regards >=20 > Thomas >=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --Apple-Mail-39BD6250-019D-4292-B06E-A4F15E498CB3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I believe that removing candidates is very useful. Let me give an example= . With TURN mobility, it is possible to retain pairs involving TURN candidat= es across interface changes. So if you leave a building and WLAN host candid= ates become unavailable, if you have cellular connectivity you can use TURN m= obility to keep media flowing while looking for a better candidate pair. To a= void loss of consent that would invalidate Pairs involving the WLAN candidat= es, it is desirable to remove (and perhaps later, renominate) the WLAN host a= nd srvflx candidates.

The package of TURN mobility, removal, renomi= nation and aspects of passive-aggressive nomination therefore enables effici= ent and effective ICE mobility.

=
Code is available for inspection in= ORTC Lib (http://ortclib.org/)

On Sep 23, 2016, at 1:47 PM, Thomas Stach <thomass.stach@gmail.com> wrote:

All,

in pre= paration of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a question c= ame up, if we need functionality for removing candidates.

=46rom list discussion in ICE, the minutes of the Berlin IETF= and due to the lack of corresponding text in draft-ietf-ice-trickle-04, I h= ave the impression that this is currently not in scope of the Trickle ICE wo= rk.

Could anybody confirm that this impress= ion is correct?

If yes, we would be about r= eady for WGLC of draft-ietf-mmusic-trickle-ice-sip.
<= br>
Regards

Thomas



___________= ____________________________________
Ice mailing list=
Ice@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/ice">https://www.ietf.org/ma= ilman/listinfo/ice
= --Apple-Mail-39BD6250-019D-4292-B06E-A4F15E498CB3-- From nobody Sat Sep 24 13:52:07 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 0049A12B040; Sat, 24 Sep 2016 13:52:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147475032594.7877.12833504581024998514.idtracker@ietfa.amsl.com> Date: Sat, 24 Sep 2016 13:52:05 -0700 Archived-At: Cc: ben@nostrum.com, ari.keranen@ericsson.com, ice@ietf.org, ice-chairs@ietf.org Subject: [Ice] ice - New Meeting Session Request for IETF 97 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: Sat, 24 Sep 2016 20:52:06 -0000 A new meeting session request has just been submitted by Ari Keranen, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keränen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm Second Priority: netvc rmcat httpbis perc Third Priority: ace 6lo lwig clue xrblock sipcore Special Requests: --------------------------------------------------------- From nobody Mon Sep 26 10:31:07 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 C3F5712B2F5 for ; Mon, 26 Sep 2016 10:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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=-2.316, 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 nmcxpQ6Ipo0N for ; Mon, 26 Sep 2016 10:31:05 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 ECC0612B2F0 for ; Mon, 26 Sep 2016 10:31:04 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id z190so171578640qkc.3 for ; Mon, 26 Sep 2016 10:31:04 -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=QIc2N3voM29inB2YMuquCfXHKKaV8MX9CCyq5tA3LXg=; b=NrsjwuFwID8faorpXWz+EHPlFkBew4xCQca/jpQuLnRFf++oFq2yPpv6zY5Vp6O9pI a3Vy4hyJAUUQAoMKLwrlsSdxMsTzDtV7SdpJ8HsuOa/TohNtIdpKcvdX7ieaeytQaIur IZOOdUe+7R1kmxkqmw0Wk82st/9/sjT+FHFOU+w3i93si7I2wAJmZVtqq/r9bf4WWl4Q 2V66y/QmclP4icUi5jLGQO1ENpcYsl3C3Nv24QGw6YShkl2dG93+eUFAyw9NuQS1i+QM 1yWEckS2cRbs0/2wTJ1RbzUWAdZ9eQdK+hS11P2WiJp79d1CmmODWg5ZsetZTtdIfC2g U2mg== 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=QIc2N3voM29inB2YMuquCfXHKKaV8MX9CCyq5tA3LXg=; b=hjWQ8AVe5odXmq5DOlScpIhL6d597qLwhsD4YKREOTXwZ7QnIgpnWV6tHKuluDEKog MEOBzfWtiMcOSusSiCqlN8gof0OZG37v63XA/JS+CeUady6GpWjAFgBQKvIXJu9YjWKc H9k4oaQMPUU8cu9NA7Req07VrwtG2ekubgFRkKcBLjTw4Z/rIeMLl5oPxcIUT1hYBk69 vo+KxHmDPZIkdjWd+54dW/sENrCPhknh1/s4T+GzTRJi2oMvm+aRyitnbmMfP9e+sw8d Zi30lel8CKjVRRfBkIdFv6fbFOzSlTWRHaquq/N9+jFfU9ACT4vD3zw+bHsXyqZ5mBC6 mQgg== X-Gm-Message-State: AA6/9RnLy8MpHcRIqnvfuHwqdyyeMmWPkssW9i42WLB/609/IjYpbtInSS6nG/Jp7lDqEH0b4wlTOHzC0sHkCwgF X-Received: by 10.55.64.21 with SMTP id n21mr20657247qka.137.1474911063983; Mon, 26 Sep 2016 10:31:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.33 with HTTP; Mon, 26 Sep 2016 10:31:03 -0700 (PDT) In-Reply-To: <5AB69686-C4F4-4298-AA51-77826C2B38C1@mozilla.com> References: <722b9fd3-f783-288e-af4f-dd2cbf59523a@stpeter.im> <5AB69686-C4F4-4298-AA51-77826C2B38C1@mozilla.com> From: Taylor Brandstetter Date: Mon, 26 Sep 2016 10:31:03 -0700 Message-ID: To: Nils Ohlmeier Content-Type: multipart/alternative; boundary=001a11489f5e0b90fd053d6c7ef6 Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] trickle: replacing candidates 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, 26 Sep 2016 17:31:07 -0000 --001a11489f5e0b90fd053d6c7ef6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The intended meaning of "type of a pair" was definitely "type of the remote candidate of a pair". It just needs to be spelled out. But what I'm a little confused about is "this is done by setting the priority of the new candidate to the priority of the pre-existing candidate." Isn't it the reverse? The pre-existing prflx candidate's priority should be lowered to that of the signaled candidate. On Mon, Sep 19, 2016 at 8:29 PM, Nils Ohlmeier wrote: > > > On Sep 7, 2016, at 19:48, Peter Saint-Andre wrote: > > > > NEW > > > > Once this is done, the agent examines the check list looking for > > another pair that would be redundant with the new one. If such a > > pair exists and its type is not peer reflexive, the pair with the > > higher priority is kept and the one with the lower priority is > > discarded. If, on the other hand, the type of the pre-existing pair > > is peer reflexive, the agent MUST replace it with the new candidate > > it received (regardless of their respective priorities); this is done > > by setting the priority of the new candidate to the priority of the > > pre-existing candidate and then re-sorting the check list. > > Could someone please explain to me what the "type of a pair" means? > > According to 5245 https://tools.ietf.org/html/rfc5245#page-33 candidate > have types, but pairs don=E2=80=99t. I think I have an idea of what is me= ant by > this, but I think this should be clarified in the text. > > Further more I think that the paragraph above in section 8.1 kind of > contradicts section 11 saying =E2=80=9C...it does not require any change = in > processing.=E2=80=9D I think an update of section 11 is due. > > I can try to provide new paragraphs if that helps. > > Best > Nils Ohlmeier > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a11489f5e0b90fd053d6c7ef6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The intended meaning of "type of a pair" was def= initely "type of the remote candidate of a pair". It just needs t= o be spelled out.

But what I'm a little confused about is "this is done=C2=A0by setting the priority of the new candidat= e to the priority of the=C2=A0pre-existing candidate." Isn't it the reverse? The pre= -existing prflx candidate's priority should be lowered to that of the s= ignaled candidate.

On Mon, Sep 19, 2016 at 8:29 PM, Nils Ohlmeier <no= hlmeier@mozilla.com> wrote:

> On Sep 7, 2016, at 19:48, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>
> NEW
>
>=C2=A0 =C2=A0Once this is done, the agent examines the check list looki= ng for
>=C2=A0 =C2=A0another pair that would be redundant with the new one.=C2= =A0 If such a
>=C2=A0 =C2=A0pair exists and its type is not peer reflexive, the pair w= ith the
>=C2=A0 =C2=A0higher priority is kept and the one with the lower priorit= y is
>=C2=A0 =C2=A0discarded.=C2=A0 If, on the other hand, the type of the pr= e-existing pair
>=C2=A0 =C2=A0is peer reflexive, the agent MUST replace it with the new = candidate
>=C2=A0 =C2=A0it received (regardless of their respective priorities); t= his is done
>=C2=A0 =C2=A0by setting the priority of the new candidate to the priori= ty of the
>=C2=A0 =C2=A0pre-existing candidate and then re-sorting the check list.=

Could someone please explain to me what the "type of a pair&quo= t; means?

According to 5245 https://tools.ietf.org/html/rfc524= 5#page-33 candidate have types, but pairs don=E2=80=99t. I think I have= an idea of what is meant by this, but I think this should be clarified in = the text.

Further more I think that the paragraph above in section 8.1 kind of contra= dicts section 11 saying =E2=80=9C...it does not require any change in proce= ssing.=E2=80=9D I think an update of section 11 is due.

I can try to provide new paragraphs if that helps.

Best
=C2=A0 Nils Ohlmeier


_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice


--001a11489f5e0b90fd053d6c7ef6-- From nobody Wed Sep 28 08:45: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 D940D12B1D6 for ; Wed, 28 Sep 2016 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=b6ZXb6EV; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=bgZJM6qZ 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 bmblxODSN8HQ for ; Wed, 28 Sep 2016 08:45:40 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D233312B1D9 for ; Wed, 28 Sep 2016 08:45:27 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=dhmxWGuYi2i8GAO9C8jtHX0pCqn6cPkeSQRuDO9ihhDN2ssrWizcvkhf VEenkQRWxZEIGQ2Ls8cg09vJITIUMud0C0CkVSFFD5+T9Yh1JpNlMVfhW jSj/RMiT47FCy5d9PcfD/ixnTEnPPCrbqXThCSwWas8bqL9coGAkVKwwr g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1475077527; x=1506613527; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=tTY/53CxvztQaBkCnsUWf89AbJIYGWToD7E310oRpo0=; b=b6ZXb6EV6DM0NnPaSxESvBVAiWV43CRmn8MJrC097wjJwAI1uLcjH2J4 AXSrMXMFBjQhcMpHKVS8Pv5VKUy5k1qWNIFiH0ixmp2h/4FmM9F3mO36B grGKSrstzDrX7IOHW7CN10+3F2AV715LxTaSxUAUJIy9tDnBc/yg/Z4Zl E=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2016 10:45:27 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2016 21:45:26 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8SFjPND029721 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 28 Sep 2016 11:45:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u8SFjPND029721 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1475077526; bh=Sio0cPjUcBdMRutqC7y+Ldq+q7k=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bgZJM6qZVlcDdiiUuIapyVbcZwsXiEOHWJRYm5qLLPWDmrddKfFKqRtwhkqbWRdSu wkaZHZgJYKhW0EhyGPv3zaJXR0ll3Wb60hgCZxNJaANMOl5QE0z5EKkN8FGjlDswN1 T5liALLd0pWkBBbsZcPoOuWaId39UEcIOQlqi+RY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u8SFjPND029721 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Wed, 28 Sep 2016 11:45:04 -0400 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8SFjHii004931 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 28 Sep 2016 11:45:17 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0266.001; Wed, 28 Sep 2016 11:45:16 -0400 To: "ice@ietf.org" Thread-Topic: Re: Continue discussion of global pacing based on feedback from "transport guys" Thread-Index: AdIZn0w0rTSbKKnYS/edYVNC+EY2Gg== Date: Wed, 28 Sep 2016 15:45:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" 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, 28 Sep 2016 15:45:44 -0000 I'm apparently one of the "transport guys" referred to in the subject line = ;-). In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter T= hatcher described the current proposal: ---------------------- 1. A maximum number of outstanding request packets, call it MaxPackets whi= ch SHOULD be 10. 2. A timeout for request packets, call it handshake timeout or HTO which S= HOULD be 2*RTT if the RTT is known and 500ms otherwise.=20 3. A global pacing rate of 5ms (like a global Ta). If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second, well below what you would get with the bitrate limits we were asking for. ---------------------- There's been some further discussion with the "transport guys" about packet= size and bit rate. In essence, the rationale for 10 as the maximum numbe= r of outstanding request packets (item 1 above) is based on the typical TCP= segment size of about 1500 bytes. ICE request packets tend to be much sma= ller, 100 bytes or less, which suggests that a factor of 15 could be availa= ble if bit rate matters but packet count doesn't. That may well be the c= ase ... RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible). That RFC effectively asserts that= the current Internet is bit-congestible only: https://tools.ietf.org/html/= rfc7141 That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets. A possible= area of concern (based on ICE use by Web RTC) is residential gateway/NAT b= oxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid ove= rrunning them. What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning? Thanks, --David From nobody Thu Sep 29 12:35:18 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 21AC812B178 for ; Thu, 29 Sep 2016 12:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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=-2.316, 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 eZPoxVIRUifH for ; Thu, 29 Sep 2016 12:35:15 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 21F2312B233 for ; Thu, 29 Sep 2016 12:35:14 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id t7so87710305qkh.2 for ; Thu, 29 Sep 2016 12:35:14 -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=znqMLaEUQiftZhSKVbbp/hlRFDReJtW5cMqghq5NupY=; b=B5MNlraUIOEi7GFNa3yIINP6nTiLaZWa25Eik/xUSkMduyn1Tc+9Ghv3XiNc1syXXS aCL6eLZzp1Jm9g2TdZvPP9aVDMRqzSOCGH2Kmb3Bwo+AyspaGXNW5+o6PjOZskoYodmq 7U1ILaorHlH6sU1AGUTIpk4C9y1AsEdNusrdqCFz6Ht4Xh6VYzN3sfA0tMKS7V4XP7mR Tv/6xjBMTpxXUkSrwQZ4I9CjM0jCnyVceiAz+CoiBeuRRamxDsZvCe4UsXqzriHIifdh uQBi6knx2WXB1fEsoxuHc9HXqCg0pTJpzGv8mfrL/xpTax1QnuY9oZ2RcJn+RJzHzF44 7HHg== 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=znqMLaEUQiftZhSKVbbp/hlRFDReJtW5cMqghq5NupY=; b=AbGL/ZiOQM+MxlpPFGDChTZdYSJYCycI9GRT9JHdtfbpQWxRJzz9hXgsQArVNPOLrS SbH5ANF5rkl92vDhokhqSHMSb5vcdPbv9NwKbT+lorAuEebOrmpDaX4y6qLWKupJpleq 2kmlHJjXPAkv2i6rQfdqfNWQexF9qfmXOltLWHM95kf7C9t1181pCJObYfB1OOSfawBJ hQcHtvTh6t1W7v3AsSSgeoZqc7IFvuskbfId8WB7JgIaYdQzvbOvRL16M+mjwhp7fd6V 669+Y7Dps48uYEMkdouDLdI2BhZJ2uisyUDeKX8buKGx0mrOHXL+EMxOYlR3n7B4TWoN 2OlA== X-Gm-Message-State: AA6/9RmPFwnOWLVBU+m4ST0ejoi7MIgv3TCiaQo8+AowiaCVmEe5AcKhY7pq0DXpTpyeqQh9WSWquXxGBQ5h0rdC X-Received: by 10.55.97.13 with SMTP id v13mr3246067qkb.158.1475177712880; Thu, 29 Sep 2016 12:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.33 with HTTP; Thu, 29 Sep 2016 12:35:12 -0700 (PDT) From: Taylor Brandstetter Date: Thu, 29 Sep 2016 12:35:12 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0576068eeb4e053daa9374 Archived-At: Subject: [Ice] Contradiction regarding when an ICE agent is allowed to send media 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, 29 Sep 2016 19:35:17 -0000 --94eb2c0576068eeb4e053daa9374 Content-Type: text/plain; charset=UTF-8 Section 6.2.1.1 of draft-ietf-ice-rfc5245bis-04 states: Before the agent has received Binding responses > associated with the [nominated] candidiate pair, the agent can send media on any > candidiate for which it has received Binding responses. > > To me, this would imply that until a pair is nominated, the ICE agent can send media on any pair with a local candidate that has received a binding response. However, section 9.1.1 states: If the selected pair for at least one component of a media stream is > empty, an agent MUST NOT send media for any component of that media stream. And the selected pair is empty until a pair is nominated, which means you can't send media until a pair is nominated. The examples at the end of Section 12 seems to reiterate this. So, which is it? I was under the impression that aggressive nomination was being removed because you could accomplish essentially the same thing with regular nomination, by sending media before a pair is nominated (the so called "passive aggressive" nomination). But that doesn't seem to be allowed by section 9.1.1. --94eb2c0576068eeb4e053daa9374 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 6.2.1.= 1 of=C2=A0draft-ietf-ice-rfc5245bis-04 states:

Before the agent has received Binding responses
associated with the [nominated] candidiate pair, the agent can send media o=
n any
candidiate for which it has received Binding responses.

To me, this would imply that= until a pair is nominated, the ICE agent can send media on any pair with a= local candidate that has received a binding response.

However, section 9.1.1 states:

If the s= elected pair for at least one component of a media stream is
empty, an agent MUST NO= T send media for any component of that media
stream.

An= d the selected pair is empty until a pair is nominated, which means you can= 't send media until a pair is nominated. The examples at the end of Sec= tion 12 seems to reiterate this.

So, which is it? = I was under the impression that aggressive nomination was being removed bec= ause you could accomplish essentially the same thing with regular nominatio= n, by sending media before a pair is nominated (the so called "passive= aggressive" nomination). But that doesn't seem to be allowed by s= ection 9.1.1.=C2=A0
--94eb2c0576068eeb4e053daa9374-- From nobody Thu Sep 29 14:06:33 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 EBCEB12B272 for ; Thu, 29 Sep 2016 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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=-2.316, 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 vIBOHEZpJ7QI for ; Thu, 29 Sep 2016 14:06:30 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 DBF1F12B2A2 for ; Thu, 29 Sep 2016 14:06:29 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id t7so90116143qkh.2 for ; Thu, 29 Sep 2016 14:06:29 -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; bh=PAoLKnJMgmFMKMoYJxWjwzIWTD142hsuQ9DRkT8ig5A=; b=V1qDuYuXT9PgpJ2fRXqrYWUoYc3YYaYxRxsyonDbM0zpCPU/Bz3OBap7505K4Azq5H 7XlxZq6uCKzhJJbBug+KMuW2jIXEMO1J6/zhZJ6pNIvSfzVe5VAHoYOSAY76KZbC8jbk jpSq7fQokABtMKOgXRwrAOCh0DnbQzLY9oXO6+OzY/Nfn25KvNMsrhYDYcbm+ny2aF4Y ycsMqZg5SKeyC6NYVApMcLa7sBddWPs+pLAlUDtjqU/+On7k7ouV601eXBXnYVnIGgN0 AU9E9RLVhNxl8vSGez6W0yDcXhziFqckfa2T6TK9U7q0Jrt9YjGS0bHV7ufRL94+DCM9 BzJw== 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; bh=PAoLKnJMgmFMKMoYJxWjwzIWTD142hsuQ9DRkT8ig5A=; b=RYDZG0tT1RaEDYh/e1IHITajXEedmr9+QGgpXJuY1JvqjiiTRL3gzGv2J6O6HP3p92 dtHoOjVIy4ZexVgSDlK+CRG4TWSqWHMOUPpTAfz12y9PnCm6G1HDIiA1eorc9aJfdCcQ dPG/Opbi9Rn1QAAgHZ1x9/QNGozCjbFDgfiNDYQp8XfiMrgydzXeW/NsmXivL4i5tHgx VFnlMiVTQ+d3M4+XcNoaWOXiNmJfhHxFLZhiTzkNl0OvDA/U1GwngJZ8DjRwClsYEdL8 dDBc9Ws+irZIjzHrRh20JZLtkhlZMnYrzuSd0nK3O/nPQD1/JtW4G5JtfTHsE3UmVHLj ZgOA== X-Gm-Message-State: AA6/9RmX3YxTBmGPPlBCyXOXL70dZfL2JtVynNk1BmzOmhKK6aVkJjpE9ehq+ugozHUywennKDkKsj62u0gi6hiM X-Received: by 10.55.123.198 with SMTP id w189mr3813376qkc.107.1475183188657; Thu, 29 Sep 2016 14:06:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.33 with HTTP; Thu, 29 Sep 2016 14:06:28 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 29 Sep 2016 14:06:28 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c065dbaf0a02c053dabd9b9 Archived-At: Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to send media 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, 29 Sep 2016 21:06:32 -0000 --94eb2c065dbaf0a02c053dabd9b9 Content-Type: text/plain; charset=UTF-8 I created an issue for this: https://github.com/ice-wg/rfc5245bis/issues/18 On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstetter wrote: > Section 6.2.1.1 of draft-ietf-ice-rfc5245bis-04 states: > > Before the agent has received Binding responses >> associated with the [nominated] candidiate pair, the agent can send media on any >> candidiate for which it has received Binding responses. >> >> > To me, this would imply that until a pair is nominated, the ICE agent can > send media on any pair with a local candidate that has received a binding > response. > > However, section 9.1.1 states: > > If the selected pair for at least one component of a media stream is >> > empty, an agent MUST NOT send media for any component of that media > > stream. > > > And the selected pair is empty until a pair is nominated, which means you > can't send media until a pair is nominated. The examples at the end of > Section 12 seems to reiterate this. > > So, which is it? I was under the impression that aggressive nomination was > being removed because you could accomplish essentially the same thing with > regular nomination, by sending media before a pair is nominated (the so > called "passive aggressive" nomination). But that doesn't seem to be > allowed by section 9.1.1. > --94eb2c065dbaf0a02c053dabd9b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I created an issue for this:=C2=A0https://github.com/ice-wg/rfc5245bis/iss= ues/18

O= n Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstetter <= deadbeef@google.co= m> wrote:
= Section 6.2.1.1 of=C2=A0draft-i= etf-ice-rfc5245bis-04 states:

Before the agent has received Binding respon=
ses
associated with the [nominated] candidiate pair, the agent can send media o=
n any
candidiate for which it has received Binding responses.

To me, this would imply that= until a pair is nominated, the ICE agent can send media on any pair with a= local candidate that has received a binding response.

However, section 9.1.1 states:

If the s= elected pair for at least one component of a media stream is
empty, an agent MUST NO= T send media for any component of that media
stream.

An= d the selected pair is empty until a pair is nominated, which means you can= 't send media until a pair is nominated. The examples at the end of Sec= tion 12 seems to reiterate this.

So, which is it? = I was under the impression that aggressive nomination was being removed bec= ause you could accomplish essentially the same thing with regular nominatio= n, by sending media before a pair is nominated (the so called "passive= aggressive" nomination). But that doesn't seem to be allowed by s= ection 9.1.1.=C2=A0

--94eb2c065dbaf0a02c053dabd9b9-- From nobody Thu Sep 29 15:57: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 CBFE012B0C5 for ; Thu, 29 Sep 2016 15:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=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 rdq6IULErDEK for ; Thu, 29 Sep 2016 15:57:47 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 29D2812B20B for ; Thu, 29 Sep 2016 15:57:47 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id 192so88935009vkl.2 for ; Thu, 29 Sep 2016 15:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5gga1OC30+M0rea4/2UDG+q+ERZotPCmioh5WyAwmQs=; b=j0MeGdcZ0uE1vRZAWbw3VWyIW39g92cxhukFBqtSGfaKZUrsga+2xHxs/kQlu9iJs0 bhCmPihU4o1uO87gEHMarKAdavWCsFWCip7J874tlBMXqJM8412+MrWPSQ71IrknmnH3 u2fuxYru48zxxtbRNV1AUSb6xa7KoTuMr3GkfaIuFBBSY2Mq6cCqdIHpqmZ//IRzJu5H ipt/1lCgOm/1CZgJmD5kKrC7Q/XqpzgnnEqW4Oh+Tut1SRDS2PqRLh50cY/lexz4sCsg EZBbAExcXtkT2QlHDOS2kgRoOJ7PUPJmFgPU8/KdwjsUaqGcQtDMUot4sW0QaKfjexUj 0vGg== 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=5gga1OC30+M0rea4/2UDG+q+ERZotPCmioh5WyAwmQs=; b=cxFAORW5K1YO2jR60MuUx0VBbLP22yTpVONjepVhympueFHDta7doHiGLakzziQoUK huKkymnYAVSuOCuX0wWyX/SAmxUjkZHOD9dFLD3DwkeRmNSYomixiZNx9tNVXF68RbvD yz07R634OMnw63kWsT2h8PZ0mCi3CruBpIgbUmubERF86GCVFLeUavL3NBfci/7xXaJs QFdUIBxcSfgCHtT+R+/eFwl56o3uuCz7SDV9H2mX56ZztOmOBMAixyUIt9Z3i4Ym+gmq 5oMavEQYMOuQPtuJntluT5JCeYz+lbJ7hcK7IZfZUI4OuNiWihEYaKrbiolub2i8HX57 5yOA== X-Gm-Message-State: AA6/9RmwRhDWY44d+kTBO1K4MbBzFNZzGnGbdmj57O3O5IahwC+fvmiBuIEYXgYAt7BLyALyLpwIx6BS/wTnQg== X-Received: by 10.31.173.18 with SMTP id w18mr3560339vke.57.1475189866165; Thu, 29 Sep 2016 15:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.198 with HTTP; Thu, 29 Sep 2016 15:57:25 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 29 Sep 2016 15:57:25 -0700 Message-ID: To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a1143f394f2fe31053dad67b8 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to send media 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, 29 Sep 2016 22:57:50 -0000 --001a1143f394f2fe31053dad67b8 Content-Type: text/plain; charset=UTF-8 There is a contradiction in draft-ietf-rfc5245bis because aggressive nomination was removed without making all the required changes to regular nomination to allow sending of media before a pair is nominated. So the text in draft-ietf-rfc5245bis Section 9.1.1 was carried over verbatim from RFC 5245 Section 11.1.1 instead of being adapted. IMHO, the requirement for sending media in draft-ietf-rfc5245bis Section 9.1.2 (which currently only applies to a lite implementation) should be applied to all implementations (lite or full): A lite implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream. Once that happens, the agent MAY begin sending media packets. Making this change should not impact an RFC 5245-compliant implementation since RFC 5245 Section 11.2 says: ICE implementations MUST be prepared to receive media on each component on any candidates provided for that component in the most recent offer/answer exchange (in the case of RTP, this would include both RTP and RTCP if candidates were provided for both). On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstetter wrote: > Section 6.2.1.1 of draft-ietf-ice-rfc5245bis-04 states: > > Before the agent has received Binding responses >> associated with the [nominated] candidiate pair, the agent can send media on any >> candidiate for which it has received Binding responses. >> >> > To me, this would imply that until a pair is nominated, the ICE agent can > send media on any pair with a local candidate that has received a binding > response. > > However, section 9.1.1 states: > > If the selected pair for at least one component of a media stream is >> > empty, an agent MUST NOT send media for any component of that media > > stream. > > > And the selected pair is empty until a pair is nominated, which means you > can't send media until a pair is nominated. The examples at the end of > Section 12 seems to reiterate this. > > So, which is it? I was under the impression that aggressive nomination was > being removed because you could accomplish essentially the same thing with > regular nomination, by sending media before a pair is nominated (the so > called "passive aggressive" nomination). But that doesn't seem to be > allowed by section 9.1.1. > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a1143f394f2fe31053dad67b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is a contradiction in draft-ietf-rfc5245bis because = aggressive nomination was removed without making all the required changes t= o regular nomination to allow sending of media before a pair is nominated. = So the text in=C2=A0draft-ietf-rfc5245bis=C2=A0Section 9.1.1 was carried ov= er verbatim from RFC 5245 Section 11.1.1 instead of being adapted.=C2=A0 IM= HO, the requirement for sending media in=C2=A0draft-ietf-rfc5245bis=C2=A0Se= ction 9.1.2 (which currently only applies to a lite implementation) should = be applied to all implementations (lite or full):=C2=A0

= 
   A lite implementation MUST NOT send me=
dia until it has a Valid list
   that contains a candidate pair for each component of that media
   stream.  Once that happens, the agent MAY begin sending media
   packets.

Making this change should not imp= act an RFC 5245-compliant implementation since RFC 5245 Section 11.2 says:= =C2=A0

   ICE im=
plementations MUST be prepared to receive media on each
   component on any candidates provided for that component in the most
   recent offer/answer exchange (in the case of RTP, this would include
   both RTP and RTCP if candidates were provided for both).




On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brands= tetter <deadbeef@google.com> wrote:
= Section 6.2.1.1 of=C2=A0draft-ietf-ice-rfc5245bis-04 states:
Before the agent has received Binding responses
associated with the [nominated] candidiate pair, the agent can send media o=
n any
candidiate for which it has received Binding responses.

To me, this would imply that= until a pair is nominated, the ICE agent can send media on any pair with a= local candidate that has received a binding response.

However, section 9.1.1 states:

If the s= elected pair for at least one component of a media stream is
empty, an agent MUST NO= T send media for any component of that media
stream.

An= d the selected pair is empty until a pair is nominated, which means you can= 't send media until a pair is nominated. The examples at the end of Sec= tion 12 seems to reiterate this.

So, which is it? = I was under the impression that aggressive nomination was being removed bec= ause you could accomplish essentially the same thing with regular nominatio= n, by sending media before a pair is nominated (the so called "passive= aggressive" nomination). But that doesn't seem to be allowed by s= ection 9.1.1.=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice


--001a1143f394f2fe31053dad67b8-- From nobody Thu Sep 29 16:20:53 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 9327C12B16F for ; Thu, 29 Sep 2016 16:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=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 f_vBsEl_UzEr for ; Thu, 29 Sep 2016 16:20:50 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 6808412B323 for ; Thu, 29 Sep 2016 16:20:37 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id 192so89316323vkl.2 for ; Thu, 29 Sep 2016 16:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9knmGDyUrgs10BZQLLKF/VikI76bi9M+Ju4si0J5cFo=; b=n41xM/FXUMQsr9X+fPvogHlpV7CpUTChTTRv9NzyqLVcjcf1mfI3NkrCkn3eXbdbv9 vyB9lt9uDU8++PKHVGHtLqj8J7ie0xyDR0VQvmKOrkkTFLu3L+Zx/fOPlQ5d3UBuINuD ZY+Jf0iliIQOYd6od7AKd1tlLwshwsxos4ox0r5IMiK2HPE3h6Dp2NXYN5JQKkgQCCYI 17JRDIUm7cfCGNhy/c0qTFOrIQplxgSXzFQQY9NTtgPf8BOjab+2H77wZH6dOqDb/nK7 UP07FdnrqvVWlR1cqHdh7qbNC2RXTlSzicsdSGyyf+aLeM7NgalaTu3iCgkN63oKVXIK zB5A== 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=9knmGDyUrgs10BZQLLKF/VikI76bi9M+Ju4si0J5cFo=; b=XUwDybuDOGtwdD9MvOXsaye9N0ns0VIfuavWx8aRij1pVdAS1LPNqjWBObjbNfcNJN tE+eQb6o64v/wrum6dPqLljCwUIdLDRFEJ9c754NkxAsBUuOofa6NO1Y7ahD6g3c3uKE JUhNKCcS6K02GpL93mEOpqQ2gTleoQu977z9BmnE155hjXMn0yhtQgaIp8q3JlER0DUd zNen1NhoS4FgIfB7aobgeaDvUhTZhvM1HcNOiW+2BolNq8lmZb8NIqyGgm7N3M9qq/n2 i5SGmZG+orK/qAazZ51P517vUcy6mDZcHONTPneLuQRrEHeHGrv/icvy2s6GIVMtKX77 5k1w== X-Gm-Message-State: AA6/9Rkc7YAphW9pBmPtwGVzKxqHsc27iSNI1dnhl1OH0r41AGJYW+eH3E4a7DGrirqOtjA6/B34p8S6idVCJg== X-Received: by 10.31.224.132 with SMTP id x126mr3125220vkg.63.1475191236484; Thu, 29 Sep 2016 16:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.198 with HTTP; Thu, 29 Sep 2016 16:20:16 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 29 Sep 2016 16:20:16 -0700 Message-ID: To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=94eb2c07e246a06366053dadb926 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to send media 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, 29 Sep 2016 23:20:52 -0000 --94eb2c07e246a06366053dadb926 Content-Type: text/plain; charset=UTF-8 Looking over RFC 5245bis, there are a number of places in the text that should have been updated to allow passive-aggressive nomination that were instead left as is. There are issues in Section 2.6 (which says "ICE will now send media using this pair"), Section 3 (which defines "selected pair" as "The candidate pair selected by ICE for sending and receiving media"), Section 6.2.3.1 (which still mentions aggressive nomination!) and Section 9.1.1. A potential rewrite of Section 9.1.1 might look like this: "9.1.1. Procedures for Full Implementations A full implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream. Once that happens, the agent MAY begin sending media packets. An agent will send media to the remote candidate (setting the destination address and port of the packet equal to that remote candidate), and will send it from the local candidate. When the local candidate is server or peer reflexive, media is originated from the base. Media sent from a relayed candidate is sent from the base through that TURN server, using procedures defined in [RFC5766]. If the local candidate is a relayed candidate, it is RECOMMENDED that an agent create a channel on the TURN server towards the remote candidate. This is done using the procedures for channel creation as defined in Section 11 of [RFC5766]." If those changes are made, it looks to me like the rest of the text from Section 9.1.1 could be deleted: "The selected pair for a component of a media stream is: o empty if the state of the check list for that media stream is Running, and there is no previous selected pair for that component due to an ICE restart o equal to the previous selected pair for a component of a media stream if the state of the check list for that media stream is Running, and there was a previous selected pair for that component due to an ICE restart o equal to the highest-priority nominated pair for that component in the valid list if the state of the check list is Completed" On Thu, Sep 29, 2016 at 3:57 PM, Bernard Aboba wrote: > There is a contradiction in draft-ietf-rfc5245bis because aggressive > nomination was removed without making all the required changes to regular > nomination to allow sending of media before a pair is nominated. So the > text in draft-ietf-rfc5245bis Section 9.1.1 was carried over verbatim > from RFC 5245 Section 11.1.1 instead of being adapted. IMHO, the > requirement for sending media in draft-ietf-rfc5245bis Section 9.1.2 > (which currently only applies to a lite implementation) should be applied > to all implementations (lite or full): > > A lite implementation MUST NOT send media until it has a Valid list > that contains a candidate pair for each component of that media > stream. Once that happens, the agent MAY begin sending media > packets. > > > Making this change should not impact an RFC 5245-compliant implementation > since RFC 5245 Section 11.2 says: > > ICE implementations MUST be prepared to receive media on each > component on any candidates provided for that component in the most > recent offer/answer exchange (in the case of RTP, this would include > both RTP and RTCP if candidates were provided for both). > > > > > > > On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstetter > wrote: > >> Section 6.2.1.1 of draft-ietf-ice-rfc5245bis-04 states: >> >> Before the agent has received Binding responses >>> associated with the [nominated] candidiate pair, the agent can send media on any >>> candidiate for which it has received Binding responses. >>> >>> >> To me, this would imply that until a pair is nominated, the ICE agent can >> send media on any pair with a local candidate that has received a binding >> response. >> >> However, section 9.1.1 states: >> >> If the selected pair for at least one component of a media stream is >>> >> empty, an agent MUST NOT send media for any component of that media >> >> stream. >> >> >> And the selected pair is empty until a pair is nominated, which means you >> can't send media until a pair is nominated. The examples at the end of >> Section 12 seems to reiterate this. >> >> So, which is it? I was under the impression that aggressive nomination >> was being removed because you could accomplish essentially the same thing >> with regular nomination, by sending media before a pair is nominated (the >> so called "passive aggressive" nomination). But that doesn't seem to be >> allowed by section 9.1.1. >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --94eb2c07e246a06366053dadb926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looking over RFC 5245bis, there are a number of place= s in the text that should have been updated to allow passive-aggressive nom= ination that were instead left as is.=C2=A0 There are issues in Section 2.6= (which says "ICE will now send media using this pair"), Section = 3 (which defines "selected pair" as "The candidate pair sele= cted by ICE for sending and receiving media"), Section 6.2.3.1 (which = still mentions aggressive nomination!) and Section 9.1.1.=C2=A0
<= br>
A potential rewrite of Section 9.1.1 might look like this:=C2= =A0

"9.1.1.=C2=A0 Procedures for Full Impleme= ntations

=C2=A0 =C2=A0A full implementation MUST N= OT send media until it has a Valid list
=C2=A0 =C2=A0that contain= s a candidate pair for each component of that media
=C2=A0 =C2=A0= stream.=C2=A0 Once that happens, the agent MAY begin sending media
=C2=A0 =C2=A0packets.

=C2=A0 =C2=A0An agent will= send media to the remote candidate (setting the=C2=A0
=C2=A0 =C2= =A0destination address and port of the packet equal to that remote candidat= e),=C2=A0
=C2=A0 =C2=A0and will send it from the local candidate.= =C2=A0 When the local candidate is
=C2=A0 =C2=A0server or peer re= flexive, media is originated from the base.=C2=A0 Media
=C2=A0 = =C2=A0sent from a relayed candidate is sent from the base through that TURN=
=C2=A0 =C2=A0server, using procedures defined in [RFC5766].

=C2=A0 =C2=A0If the local candidate is a relayed candi= date, it is RECOMMENDED that
=C2=A0 =C2=A0an agent create a chann= el on the TURN server towards the remote
=C2=A0 =C2=A0candidate.= =C2=A0 This is done using the procedures for channel creation as
= =C2=A0 =C2=A0defined in Section 11 of [RFC5766]."

=
If those changes are made, it looks to me like the rest of the text fr= om Section 9.1.1 could be deleted:

=C2=A0 =C2=A0&q= uot;The selected pair for a component of a media stream is:

<= /div>
=C2=A0 =C2=A0o =C2=A0empty if the state of the check list for tha= t media stream is
=C2=A0 =C2=A0 =C2=A0 Running, and there is no p= revious selected pair for that component
=C2=A0 =C2=A0 =C2=A0 due= to an ICE restart

=C2=A0 =C2=A0o =C2=A0equal to t= he previous selected pair for a component of a media
=C2=A0 =C2= =A0 =C2=A0 stream if the state of the check list for that media stream is
=C2=A0 =C2=A0 =C2=A0 Running, and there was a previous selected pa= ir for that component
=C2=A0 =C2=A0 =C2=A0 due to an ICE restart<= /div>

=C2=A0 =C2=A0o =C2=A0equal to the highest-priority= nominated pair for that component in
=C2=A0 =C2=A0 =C2=A0 the va= lid list if the state of the check list is Completed"

On Thu, Sep 29, 2016 a= t 3:57 PM, Bernard Aboba <bernard.aboba@gmail.com> wro= te:
There is a contradic= tion in draft-ietf-rfc5245bis because aggressive nomination was removed wit= hout making all the required changes to regular nomination to allow sending= of media before a pair is nominated. So the text in=C2=A0draft-ietf-rfc524= 5bis=C2=A0Section 9.1.1 was carried over verbatim from RFC 5245 Sectio= n 11.1.1 instead of being adapted.=C2=A0 IMHO, the requirement for sending = media in=C2=A0draft-ietf-rfc5245bis=C2=A0Section 9.1.2 (which currentl= y only applies to a lite implementation) should be applied to all implement= ations (lite or full):=C2=A0

   A lite impleme=
ntation MUST NOT send media until it has a Valid list
   that contains a candidate pair for each component of that media
   stream.  Once that happens, the agent MAY begin sending media
   packets.

Making this change should not imp= act an RFC 5245-compliant implementation since RFC 5245 Section 11.2 says:= =C2=A0

   ICE implementations MUST be pr=
epared to receive media on each
   component on any candidates provided for that component in the most
   recent offer/answer exchange (in the case of RTP, this would include
   both RTP and RTCP if candidates were provided for both).




=

On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstett= er <deadbeef@google.com> wrote:
Section 6.2.1.1 of=C2=A0draft-ietf-ice-rfc5245bis-0= 4 states:

<= /font>
Before the agent has received Bind=
ing responses
associated with the [nominated] candidiate pair, the agent can send media o=
n any
candidiate for which it has received Binding responses.

To me, this would imply that= until a pair is nominated, the ICE agent can send media on any pair with a= local candidate that has received a binding response.

However, section 9.1.1 states:

If the s= elected pair for at least one component of a media stream is
empty, an agent MUST NO= T send media for any component of that media
stream.

An= d the selected pair is empty until a pair is nominated, which means you can= 't send media until a pair is nominated. The examples at the end of Sec= tion 12 seems to reiterate this.

So, which is it? = I was under the impression that aggressive nomination was being removed bec= ause you could accomplish essentially the same thing with regular nominatio= n, by sending media before a pair is nominated (the so called "passive= aggressive" nomination). But that doesn't seem to be allowed by s= ection 9.1.1.=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice



--94eb2c07e246a06366053dadb926-- From nobody Thu Sep 29 21:57: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 B740E12B047; Thu, 29 Sep 2016 21:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.836 X-Spam-Level: X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 UG9Gnup1hg-u; Thu, 29 Sep 2016 21:57:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2BA12B032; Thu, 29 Sep 2016 21:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13083; q=dns/txt; s=iport; t=1475211427; x=1476421027; h=from:to:cc:subject:date:message-id:references: mime-version; bh=ZZ4s4/r+awJQinkSY3NrzLAGcmXoBx4TXVPvT871aBw=; b=fFtHnqd5FDiijWRks1Mz1Jli7y82lxG5gg4SzzX38sWHMVGYLN6yJmNB jamkEuemmruP0ROTKIBo9EgFYW4dj3pSKHogEmSoXDTEQ+oHZDeW11HSt +hFIyKUfnRA+auZjWtPZn98EDZ4IFTG1iDH7iVbdO9FWlVlRSwoztbmoP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQB28O1X/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR5XfAeNK5Z/jxGFEoIGGQEKhXoCgWI4FAECAQEBAQE?= =?us-ascii?q?BAV4nhGEBAQEEAQEBSyALEAIBGQMBAg0XBAcnCgEUBwIIAgQBDQUUBwIEiCwOv?= =?us-ascii?q?hEBAQEBAQEBAQEBAQEBAQEBAQEBAQEchjeBfYJYgTyCaT8WCIJxgi8FlCCFWAG?= =?us-ascii?q?GJolJgW6EZokchwqFY4N8AQ8PNoMqJ4E4cgGEUoEggQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,418,1473120000"; d="scan'208,217";a="157581336" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Sep 2016 04:56:48 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u8U4umlh028782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Sep 2016 04:56:48 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Sep 2016 23:56:47 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Thu, 29 Sep 2016 23:56:48 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "tls@ietf.org" , tram mailing list , "mmusic (E-mail)" , "ice@ietf.org" Thread-Topic: [rfc-dist] RFC 7983 on Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) Thread-Index: AQHSGtcMkIgOG8WjjUyLYahvQZrBPA== Date: Fri, 30 Sep 2016 04:56:48 +0000 Message-ID: <8BBC2CED-70E8-4EB7-8D44-11054856AB7B@cisco.com> References: <20160929234041.C84C0B81109@rfc-editor.org> 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.82.169.55] Content-Type: multipart/alternative; boundary="_000_8BBC2CED70E84EB78D4411054856AB7Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: IETF AVTCore WG Subject: [Ice] Fwd: [rfc-dist] RFC 7983 on Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) 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, 30 Sep 2016 04:57:10 -0000 --_000_8BBC2CED70E84EB78D4411054856AB7Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarding for awareness to the other relevant WGs. Thanks to all who helpe= d get this done. Cheers, Gonzalo Begin forwarded message: From: > Subject: [rfc-dist] RFC 7983 on Multiplexing Scheme Updates for Secure Real= -time Transport Protocol (SRTP) Extension for Datagram Transport Layer Secu= rity (DTLS) Date: September 29, 2016 at 7:40:41 PM EDT To: >, > Cc: >, >, > A new Request for Comments is now available in online RFC libraries. RFC 7983 Title: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) Author: M. Petit-Huguenin, G. Salgueiro Status: Standards Track Stream: IETF Date: September 2016 Mailbox: marc@petit-huguenin.org, gsalguei@cisco.com Pages: 13 Characters: 24894 Updates: RFC 5764 I-D Tag: draft-ietf-avtcore-rfc5764-mux-fixes-11.txt URL: https://www.rfc-editor.org/info/rfc7983 DOI: http://dx.doi.org/10.17487/RFC7983 This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document. This document updates RFC 5764. This document is a product of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestion= s for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist@rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org --_000_8BBC2CED70E84EB78D4411054856AB7Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4286A44DF83DD04997FF9238A01E5991@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Forwarding for awareness to the other relevant WGs. Thanks to all who helpe= d get this done.

Cheers,

Gonzalo

Begin forwarded message:

From: <rfc-editor@rfc-editor.org>
Subject: [rfc-dist] RFC 7983 on Mu= ltiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Ex= tension for Datagram Transport Layer Security (DTLS)
Date: September 29, 2016 at 7:40:41 PM EDT
To: <ietf-announce@ietf.org>, <rfc-dist@rfc-editor.org>
Cc: <drafts-update-ref@iana.org>, <avt@ietf.org>, <rfc-editor@rfc-editor.org>

A new Request for Comments is now available in online RFC l= ibraries.


       RFC 7983

       Title:     &n= bsp;Multiplexing Scheme Updates for Secure
            &nb= sp;      Real-time Transport Protocol (SRTP) = Extension for
            &nb= sp;      Datagram Transport Layer Security (D= TLS)
       Author:     M= . Petit-Huguenin, G. Salgueiro
       Status:     S= tandards Track
       Stream:     I= ETF
       Date:     &nb= sp; September 2016
       Mailbox:    marc@petit-huguenin.org= ,
            &nb= sp;      gsalguei@cisco.com
       Pages:     &n= bsp;13
       Characters: 24894
       Updates:    RFC 57= 64

       I-D Tag:    draft-= ietf-avtcore-rfc5764-mux-fixes-11.txt

       URL:     &nbs= p;  https://www.rfc-editor.org/info/rfc7983

       DOI:     &nbs= p;  htt= p://dx.doi.org/10.17487/RFC7983

This document defines how Datagram Transport Layer Security (DTLS),
Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),
Session Traversal Utilities for NAT (STUN), Traversal Using Relays
around NAT (TURN), and ZRTP packets are multiplexed on a single
receiving socket.  It overrides the guidance from RFC 5764 ("SRTP=
Extension for DTLS"), which suffered from four issues described and fixed in this document.

This document updates RFC 5764.

This document is a product of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.  Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of th= is
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
rfc-dist@rfc-editor.o= rg
https://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org

--_000_8BBC2CED70E84EB78D4411054856AB7Bciscocom_-- From nobody Fri Sep 30 08:15:00 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 9D5BA12B03A; Fri, 30 Sep 2016 08:14:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147524849860.20364.12616961910897320057.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 08:14:58 -0700 Archived-At: Cc: ben@nostrum.com, ari.keranen@ericsson.com, ice@ietf.org, ice-chairs@ietf.org Subject: [Ice] ice - Update to a Meeting Session Request for IETF 97 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: Fri, 30 Sep 2016 15:14:58 -0000 An update to a meeting session request has just been submitted by Ari Keranen, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keränen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm Second Priority: netvc rmcat httpbis perc sipbrandy Third Priority: ace 6lo lwig clue xrblock sipcore Special Requests: --------------------------------------------------------- From nobody Fri Sep 30 08:22: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 DBCA612B165; Fri, 30 Sep 2016 08:22:27 -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 bAxh4pIg_S6A; Fri, 30 Sep 2016 08:22:26 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E808B12B171; Fri, 30 Sep 2016 08:22:22 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-36-57ee832ba7cd Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 42.32.02458.B238EE75; Fri, 30 Sep 2016 17:22:21 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.213]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Fri, 30 Sep 2016 17:22:19 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "ice@ietf.org" Thread-Topic: ice - Update to a Meeting Session Request for IETF 97 Thread-Index: AQHSGy1p18S1Hzt+Ck2tsgAnRD0vOKCSBPmA Date: Fri, 30 Sep 2016 15:22:19 +0000 Message-ID: <89A981EF-F2BB-4E3C-BE52-050195EAEB66@ericsson.com> References: <147524849860.20364.12616961910897320057.idtracker@ietfa.amsl.com> In-Reply-To: <147524849860.20364.12616961910897320057.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.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7t65u87twg0PrOSzmd55mt7g4azKb xbcLtQ7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXxozm4IJ5XBV7Zx1kbmD8w9nFyMkh IWAi8evVdpYuRi4OIYH1jBIXOvuZIZwljBKn+ucyglSxCdhKPGndxwpiiwgoSsxsecYMYjML BErsm3KWDcQWFnCS2Hf4AjtEjbPEm7+nWCBsI4m3PYfB4iwCqhIXuheAzeEVsJdofdHLBGIL CfhJnLrdDDaHU8BfYv6t/2D1jAJiEt9PrWGC2CUucevJfCaIqwUkluw5zwxhi0q8fPyPFcJW klix/RLQzRxA9ZoS63fpQ5jWElOvx0BMUZSY0v2QHeICQYmTM5+wTGAUm4VkwSyE5lkIzbOQ NM9C0ryAkXUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmBcHdzy22oH48HnjocYBTgYlXh4 H+S/CxdiTSwrrsw9xCjBwawkwvuuASjEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTE ktTs1NSC1CKYLBMHp1QDo3iD+CsBHbmnq998LFr15MHR2ao38t/lXRBltZrw4+y7suhdjjPX vVsSKLbl5aaXPdIdj4K/rZe5VH5JrDZwlbqefsWrJftNGsXz1/uwOPNvfrNoza4Nh+NfLDFP Sjlcfq5+ZpjCI/O+johoxwrD3KYQcTN/+c9h/7iOPf/pPVnvNb87288jRUosxRmJhlrMRcWJ ADyVh2enAgAA Archived-At: Cc: Ben Campbell , "ice-chairs@ietf.org" Subject: Re: [Ice] ice - Update to a Meeting Session Request for IETF 97 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, 30 Sep 2016 15:22:28 -0000 SSBhZGRlZCBzaXBicmFuZHkgdG8gdGhlIGxpc3Qgb2YgY29uZmxpY3RzLiBObyBvdGhlciB1cGRh dGVzLg0KDQpDaGVlcnMsDQpBcmkNCg0KPiBPbiAzMCBTZXAgMjAxNiwgYXQgMTg6MTQsIElFVEYg TWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCA8c2Vzc2lvbl9yZXF1ZXN0X2RldmVsb3BlcnNA aWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBBbiB1cGRhdGUgdG8gYSBtZWV0aW5nIHNl c3Npb24gcmVxdWVzdCBoYXMganVzdCBiZWVuIHN1Ym1pdHRlZCBieSBBcmkgS2VyYW5lbiwgYSBD aGFpciBvZiB0aGUgaWNlIHdvcmtpbmcgZ3JvdXAuDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFdvcmtpbmcgR3Jv dXAgTmFtZTogSW50ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQNCj4gQXJlYSBO YW1lOiBBcHBsaWNhdGlvbnMgYW5kIFJlYWwtVGltZSBBcmVhDQo+IFNlc3Npb24gUmVxdWVzdGVy OiBBcmkgS2Vyw6RuZW4NCj4gDQo+IE51bWJlciBvZiBTZXNzaW9uczogMQ0KPiBMZW5ndGggb2Yg U2Vzc2lvbihzKTogIDIgSG91cnMNCj4gTnVtYmVyIG9mIEF0dGVuZGVlczogNDUNCj4gQ29uZmxp Y3RzIHRvIEF2b2lkOiANCj4gRmlyc3QgUHJpb3JpdHk6IHBheWxvYWQgY29yZSBydGN3ZWIgYXZ0 ZXh0IGF2dGNvcmUgdDJ0cmcgdGxzIHRzdmFyZWEgdHN2d2cgdHJhbSBtbXVzaWMgZGlzcGF0Y2gg dGNwbQ0KPiBTZWNvbmQgUHJpb3JpdHk6IG5ldHZjIHJtY2F0IGh0dHBiaXMgcGVyYyBzaXBicmFu ZHkNCj4gVGhpcmQgUHJpb3JpdHk6IGFjZSA2bG8gbHdpZyBjbHVlIHhyYmxvY2sgc2lwY29yZQ0K PiANCj4gDQo+IFNwZWNpYWwgUmVxdWVzdHM6DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQoNCg== From nobody Fri Sep 30 08:25: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 1641112B176; Fri, 30 Sep 2016 08:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 1N6qIwDaZgGT; Fri, 30 Sep 2016 08:25:22 -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 2573612B265; Fri, 30 Sep 2016 08:25:22 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8UFOxRt011168 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 30 Sep 2016 10:25:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Ari =?utf-8?q?Ker=C3=A4nen?=" Date: Fri, 30 Sep 2016 10:25:19 -0500 Message-ID: In-Reply-To: <89A981EF-F2BB-4E3C-BE52-050195EAEB66@ericsson.com> References: <147524849860.20364.12616961910897320057.idtracker@ietfa.amsl.com> <89A981EF-F2BB-4E3C-BE52-050195EAEB66@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "ice-chairs@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] ice - Update to a Meeting Session Request for IETF 97 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, 30 Sep 2016 15:25:24 -0000 Thanks! On 30 Sep 2016, at 10:22, Ari Keränen wrote: > I added sipbrandy to the list of conflicts. No other updates. > > Cheers, > Ari > >> On 30 Sep 2016, at 18:14, IETF Meeting Session Request Tool >> wrote: >> >> >> >> An update to a meeting session request has just been submitted by Ari >> Keranen, a Chair of the ice working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Interactive Connectivity Establishment >> Area Name: Applications and Real-Time Area >> Session Requester: Ari Keränen >> >> Number of Sessions: 1 >> Length of Session(s): 2 Hours >> Number of Attendees: 45 >> Conflicts to Avoid: >> First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea >> tsvwg tram mmusic dispatch tcpm >> Second Priority: netvc rmcat httpbis perc sipbrandy >> Third Priority: ace 6lo lwig clue xrblock sipcore >> >> >> Special Requests: >> >> --------------------------------------------------------- >> >