From nobody Tue Jul 5 09:28: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 EB96F12D635; Tue, 5 Jul 2016 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SXP8wdB6a9VF; Tue, 5 Jul 2016 09:27:56 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC31C12D640; Tue, 5 Jul 2016 09:27:49 -0700 (PDT) Received: from [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3] (unknown [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 57672207C7; Tue, 5 Jul 2016 18:27:47 +0200 (CEST) To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> From: Marc Petit-Huguenin Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Date: Tue, 5 Jul 2016 09:27:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd" Archived-At: Subject: Re: [Ice] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 16:27:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd Content-Type: multipart/mixed; boundary="kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i" From: Marc Petit-Huguenin To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, We just published version -10. See below for some comments. On 06/28/2016 07:35 AM, Magnus Westerlund wrote: > Authors and WGs, >=20 > In my review for the publication writeup I did spot some issues in the = draft. Please consider the following issues: >=20 > 1. Abstract: With the addition of the ZRTP the abstract should benefit = from being updated. The ZRTP protocol being possible to multiplex is miss= ing as well as that there are now 4 issues. Fixed. >=20 > 2. Abstract contains [ref] to RFC 5764. This is an ID nit. Fixed. >=20 > 3. Section 1. The introduction is not explicitly saying that it updates= RFC 5764. I think that can be put as a sentence after: >=20 > This is achieved by > modifying the IANA registries with instructions for coordination > between the protocols at risk. We incorporated this in that sentence and also added it into the abstract= =2E >=20 > 4. Reference ID-nits: >=20 > =3D=3D Outdated reference: A later version (-31) exists of > draft-ietf-mmusic-sdp-bundle-negotiation-23 Fixed. >=20 > 5. Section 2: >=20 > ID-nits complains about the modified boilerplate for the RFC2119 text. = First of all one usually don't cut down the list to only the used ones. T= he requirement on all caps ones I am very divided about. I do have a pref= erence for unmodified boilerplate, this as I otherwise have to explain in= the write-up the ID-nit. Fixed. >=20 > 6. Section 6: >=20 > In order to prevent future documents from assigning values from the > unused range to a new protocol, this document modifies the RFC 5764 > demultiplexing algorithm to properly account for TURN channels by > allocating the values from 64 to 79 for this purpose. >=20 > I think this text fails to be explicit about that this restricts the TU= RN Channel space to a more limited set of possible channels when the TURN= client does the channel binding request. Thus affecting the TURN channel= allocation algorithm in the client implementations, at least when used i= n combination of muxing. Fixed. >=20 > Based on this and the fact that this specification changes the IANA reg= istrations performed by RFC5766, I think this document to have "Updates" = for RFC5766 also. So please add that in header, abstract and introduction= =2E Based on our understanding and looking at other RFCs, just updating an IA= NA registry does not imply a update to the core specification, so we did = not made that change. >=20 > 7. Updates RFC5389: >=20 > Looking at the impact also on the STUN protocol I would also think that= this requires and "Updates" also for RFC 5389. >=20 Based on the argument above, we do not think that this warrants an "Updat= es" status. >=20 > 8. Section 10.3: >=20 > The IANA registry name is not the correct one. The IANA page says that = the registry name is: >=20 > Traversal Using Relays around NAT (TURN) Channel Numbers > http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#t= urn-channel >=20 > Please update. Fixed. >=20 > 9. Section 12.2: >=20 > The reference to ZRTP [RFC6189] is likely in the wrong category, at the= same time moving this to a normative one creates a downref. I guess it o= ne that has to be accepted in this case. I suggest that you move it to th= e normative references. We are keeping it informative for now, but we will forward the discussion= with the AD to the mailing-list as requested. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i-- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXe9/6AAoJECnERZXWan7E8JwQAMkUHV3c2Q1MK8TWsMTs/q5q r4eb5gLyaoxSV6x9ufYs42lJ3j6hr7t3GabA5ANFFI1tOx+eN3iMwTgH/2ylugoE fnyGgbal/vZ6pEj01goPALATYSk0m6KtFwS7+QPVvNoEan6oHbLA5iH5oc73FY8x B5cBFq89Do1ATeTKEX0a0FeSZmE5r4N4xrsjZpnMBXt1Unm+1SG0Ku24PJHCbEWN Tx68bmLODh+65pTVUzewDOo3urSlwjxStVqf/jQHh4fx/tDnxGH8c8cGMSW18jl/ PuanYrAv7pg0rMdhQMkeEs5Y6UaInE3B3zADdXEET0QSw6U4oiXVvzP8GH/QC8Ml z4zNDEcDn+wlPMWcmwOhrVtqbuUAcdHlMB4oynOzcVZpKciXvIpDlKKWJXdo9ERU l4/GCog8yq0HgQ2Mv5mGLHO3x5CIs+zgKFvAz6uWK3Qq4i12Wgxga+aJt3OFgwAn qvaMVuAr4ajUkYzF8iHJpXqUD15E48MvYHm4ps6ExtHhXcWqBUv8FxxGixTDZWAX lj5K6jpYdSddwY6nMc3BMS1XZrCX2TBmTaCm9MZWQjqRao0IEdVehfAh4+D1eeUb nUgIzFjjyQ73kZ2FHkyXBm6FYxAuXSI5MU9H1kjh78KDvUlGTStjb0azCrBNWG0c 0hmVb/kE0WTHDCIYklcY =qxAO -----END PGP SIGNATURE----- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd-- From nobody Wed Jul 6 01:47: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 657FD12D0FB; Wed, 6 Jul 2016 01:47:29 -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 qFpXJPbtanj1; Wed, 6 Jul 2016 01:47:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F54C12D0A4; Wed, 6 Jul 2016 01:47:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ea-577cc59ce276 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.00.18043.C95CC775; Wed, 6 Jul 2016 10:47:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.294.0; Wed, 6 Jul 2016 10:47:23 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: From: Magnus Westerlund Message-ID: Date: Wed, 6 Jul 2016 10:47:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM2K7lu6cozXhBu86tCxe9qxktzjwcSqz xbcLtRZTlz9msfh0vovR4sPaC2wObB5LlvxkCmCM4rJJSc3JLEst0rdL4Mp4vWQLa8Fa4Yq5 X7uZGxhv83cxcnJICJhIPFvxgR3CFpO4cG89WxcjF4eQwBFGibcL1kA5yxglbvX9Aari4BAW CJE4vj8JJC4i8I9R4uPGmywg3UIC9hK/djYyg9hsAhYSN380soHYvEDxnZMmgNksAioSE1cf AbNFBWIkGm8fZoeoEZQ4OfMJ2BxOAQeJ4z83sIDsYgbqfbC1DCTMLCAv0bx1NjPEKm2JhqYO 1gmMArOQdM9C6JiFpGMBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMCAPbjlt9UOxoPP HQ8xCnAwKvHwLvhaHS7EmlhWXJl7iFGCg1lJhFfwUE24EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsbk35xzJsUsUmXvqnhYwLbwa8nSCSl/ebr+cWSG nXkre/3qfvc7sQlOm4/pzJLdtszO+Lzdttccrg7LFn6NZTb/MDcwtXun2uyIsBlsLHHra8JV f5iaZlY+iGZ4sYsnBhhnirbz9BsbefaqOGhfYmVl6/h0Lu7c7SNxN344TA5++HvZJ/uV35VY ijMSDbWYi4oTAU6aP69UAgAA Archived-At: Subject: Re: [Ice] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 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, 06 Jul 2016 08:47:29 -0000 Hi, The call has now ended. The authors have updated the document to address the issues I raised. The writeup has been uploaded and I have requested publication. If anyone has late feedback, please provide it. We will address it at the latest at the end of the IETF last call, most likely earlier. Cheers Magnus Westerlund Chair AVTCORE WG and Document Shepherd. Den 2016-06-28 kl. 15:04, skrev Magnus Westerlund: > WGs, > > I as WG chair earlier made a mistake in failing to include the relevant > WGs in our previous WG last call. Thus I would like to make a one week > confirmation call on the content of > draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request. > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > > TRAM WG: Please check that you are okay with the restrictions and > updates to the TURN channel allocations as well as STUN Method > restrictions. > > TLS WG: I believe you are satisfied with the impact on the TLS IANA > registry after previous discussions, but you are welcome to confirm this. > > ICE: For your information as this impacts protocol mechanism your are > dependent on. > > MMUSIC: For your information due to some notes in regards to BUNDLE and > RFC7345. > > Please provide any feedback by 5th of July. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jul 7 07:47:44 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2289A12D090 for ; Thu, 7 Jul 2016 07:47:43 -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 vdzZhKkoLh_Q for ; Thu, 7 Jul 2016 07:47:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0892D12D767 for ; Thu, 7 Jul 2016 07:47:40 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-14-577e6b8a594e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.85.12516.A8B6E775; Thu, 7 Jul 2016 16:47:38 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.140]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Thu, 7 Jul 2016 16:47:38 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ice@ietf.org" Thread-Topic: ICE WG draft agenda for IETF #96 Thread-Index: AQHR2F6BTxpxipsC/0CpMsSaoYxVFg== Date: Thu, 7 Jul 2016 14:47:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbE9Srcruy7cYFeHkcW3C7UW15a/ZnVg 8liwqdRjyZKfTAFMUVw2Kak5mWWpRfp2CVwZPbtPsBbMYqp4+34/awPjfcYuRg4OCQETiTft PF2MnECmmMSFe+vZuhi5OIQEjjBKTH78jBHCWcwosePeViaQKjYBe4nJaz4ygtgiAooSM1ue MYPYzAKaEvdPLmQHsYWB7OY9LawQNXoSU3+8Yoex1z+4A9bLIqAisWX/SbA4L9DMY819YPWM QFd8P7WGCWKmuMStJ/OZIK4TkFiy5zwzhC0q8fLxP1YIW0li0e3PUPV6EjemTmGDsK0ltr04 BBXXlli28DUzxC5BiZMzn7BMYBSdhWTFLCTts5C0z0LSPgtJ+wJG1lWMosWpxcW56UbGeqlF mcnFxfl5enmpJZsYgbFzcMtv3R2Mq187HmIU4GBU4uFNqK8NF2JNLCuuzD3EKMHBrCTCa5Ja Fy7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBUXOHa2dN 2P7jvirbrm7rNX8SHZzf4Tuj53v4zone8ipNMyVfbVUt/99X4bFo2rMrZw/9uRvmIlDpE3Nz /Ssm87eLQqcG6xrtrjNtCX0Xca8x45V1KvP0+xWPCtx9mP5PYevmkLKUX35dQZaFm7/SX4uh 6sAjc68nF3Iff05+IbpVq9bwTpWCEktxRqKhFnNRcSIAvCmZDpkCAAA= Archived-At: Cc: Peter Thatcher Subject: [Ice] ICE WG draft agenda for IETF #96 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:47:43 -0000 Hi all, Draft agenda for the ICE WG meeting at the IETF #96 is available here: https://www.ietf.org/proceedings/96/agenda/agenda-96-ice Please have a look at the agenda and let us know if you have any questions = or comments. Thanks, Ari & Peter (ICE WG co-chairs)= From nobody Sun Jul 10 18:47: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 C707012B060 for ; Sun, 10 Jul 2016 18:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6FW0yhtDHXU8 for ; Sun, 10 Jul 2016 18:47:53 -0700 (PDT) Received: from smtp112.iad3a.emailsrvr.com (smtp112.iad3a.emailsrvr.com [173.203.187.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84AB12B046 for ; Sun, 10 Jul 2016 18:47:52 -0700 (PDT) Received: from smtp15.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 434463805EF for ; Sun, 10 Jul 2016 21:47:52 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp15.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id DD2843805EB for ; Sun, 10 Jul 2016 21:47:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.10.46] ([UNAVAILABLE]. [128.107.241.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sun, 10 Jul 2016 21:47:52 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <1F541F0A-F666-4A10-AFD7-76E6974C8291@ericsson.com> Date: Sun, 10 Jul 2016 21:47:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99649BCA-0A18-482A-AE2E-A17CD14F28E1@iii.ca> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> <1F541F0A-F666-4A10-AFD7-76E6974C8291@ericsson.com> To: "ice@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Ice] Removing ICE frozen algorithm X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 01:47:57 -0000 If you are not doing bundle, it looks to me like you still need it.=20 > On Apr 1, 2016, at 2:26 PM, Ari Ker=C3=A4nen = wrote: >=20 > All, >=20 > What do you think about removing requirement for implementing frozen = algorithm altogether from ICE-bis? >=20 > This would obviously be a bigger change than what we originally = planned for ICE-bis work, but based on the discussion so far there could = be merit to it. >=20 > Frozen algorithm is essentially an optimisation that allows one to not = check high-priority candidate pairs that are likely not to work (e.g., = host-host candidate for more than one stream/component). If agent has = only one one stream and component, or uses RTCP-mux and Bundles all = streams, frozen algorithm is not even used today. And current draft says = you don't have to implement it for usages with only one stream and = component. However, with multiple streams and/or components, it makes a = difference. >=20 > Apparently even if one endpoint does not implement the frozen = algorithm, it would still interoperate with one that does. The checks = would be slightly out of sync (one endpoint is doing checks for the = candidate pairs that are frozen on the other), but if we reduce the STUN = pacing value, this will be less of a problem since the NAT bindings = should be alive and the whole process is likely to end in reasonable = time. And if one cares about minimising amount of sent checks, one could = still implement the algorithm. >=20 > What is your opinion? Should we keep or remove the frozen algorithm = requirement from ICE bis? >=20 >=20 > Cheers, > Ari >=20 >> On 17 Mar 2016, at 16:32, Peter Thatcher = wrote: >>=20 >>=20 >>=20 >> On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg = wrote: >> Hi, >>=20 >>>> I was thinking that we wouldn't care if candidates share the same = foundation or not - we deal with all candidates in the same way. >>>=20 >>> For trickle ICE specifically or for 5245bis? =E2=80=8B >>>=20 >>> I'm all for simplification and removing things we don't need. I = just want to understand the scope of which you are proposing we do so. >>=20 >> I was thinking 5245bis: remove everything that talks about frozen = candidates. >>=20 >>=20 >> Sounds good to me, if we feel like the downsides of not having = freezing are such that we can simply say "if you care about these = downsides, use rtcp-mux". I'd like to hear from everyone else if feels = the same.=E2=80=8B=E2=80=8B >>=20 >>=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Mon Jul 11 01:45: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 DD79712B05D for ; Mon, 11 Jul 2016 01:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 g3DjWKca9OKP for ; Mon, 11 Jul 2016 01:45:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FB212B061 for ; Mon, 11 Jul 2016 01:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4368; q=dns/txt; s=iport; t=1468226706; x=1469436306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vmG4u7+NWCO7JqWngaIC/MpIJM4jfD3Jh4mpz7sn8pA=; b=ZedttdToRc6fxRww01E8TZQeXxe5RvqpG9aQ2sTEB1usE5xYhzctJISU y7asZKt49GV6kh45oEgLnzXztSRg94QnuS8WBeTb86njKaTIU17HHcH8Q ElVBFvu67aiGHaqv8+MEyvebvACU3gvzbzq7/MYubuqXwqCfEhxd1zgJN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AgA2W4NX/5hdJa1cgz5WfLkXgXoih?= =?us-ascii?q?XYCHIEJOBQBAQEBAQEBZSeEXAEBBAEBASEROgsFCwIBBgIOCgICJgICAiULFRA?= =?us-ascii?q?CBA4FiCgIDpMGnR2OUAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFJoF4glWEQ?= =?us-ascii?q?YMBK4IvBZhRRwGOUY8skA4BHjaDcW6JPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,345,1464652800"; d="scan'208";a="295574096" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2016 08:45:05 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6B8j4e7014451 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 08:45:05 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 04:45:04 -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, 11 Jul 2016 04:45:04 -0400 From: "Pal Martinsen (palmarti)" To: Cullen Jennings Thread-Topic: [Ice] Removing ICE frozen algorithm Thread-Index: AQHRjEQHKN51vUazcEC0S4O3tQ5onKATVv2AgAAxhMQ= Date: Mon, 11 Jul 2016 08:45:04 +0000 Message-ID: <889416E0-5BF3-462F-AC7A-D4BC5B5D7BD7@cisco.com> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> <1F541F0A-F666-4A10-AFD7-76E6974C8291@ericsson.com>, <99649BCA-0A18-482A-AE2E-A17CD14F28E1@iii.ca> In-Reply-To: <99649BCA-0A18-482A-AE2E-A17CD14F28E1@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Removing ICE frozen algorithm X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 08:45:08 -0000 SSBhbHNvIHRoaW5rIGl0IGlzIG5lZWRlZCBmb3Igbm9uIGJ1bmRlbGVkIHNjZW5hcmlvcy4NCg0K QnV0IGl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIGRlc2NyaWJlZCBpbiBhIHNlcGFyYXRlIGRyYWZ0 LiBKdXN0IGxpa2Ugd2Ugc29ydCBvZiBpcyBkb2luZyB3aXQgdGhlIHJlbm9taW5hdGlvbiBkcmFm dC4gUmVtb3ZpbmcgYWdncmVzc2l2ZSBub21pbmF0aW9uIHRvIG1ha2UgdGhlIHNwZWMgc2ltcGxl ciwgYW5kIGFkZGluZyBhIHNlcGFyYXRlIGRyYWZ0IHRoYXQgYWRkcyBhIGJldHRlciBzZXQgb2Yg ZnVuY3Rpb25hbGl0eS4NCg0KUMOlbC1FcmlrDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24g MTEgSnVsIDIwMTYsIGF0IDAzOjQ4LCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E+IHdy b3RlOg0KPiANCj4gDQo+IElmIHlvdSBhcmUgbm90IGRvaW5nIGJ1bmRsZSwgaXQgbG9va3MgdG8g bWUgbGlrZSB5b3Ugc3RpbGwgbmVlZCBpdC4gDQo+IA0KPiANCj4+IE9uIEFwciAxLCAyMDE2LCBh dCAyOjI2IFBNLCBBcmkgS2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQo+PiANCj4+IEFsbCwNCj4+IA0KPj4gV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgcmVtb3Zpbmcg cmVxdWlyZW1lbnQgZm9yIGltcGxlbWVudGluZyBmcm96ZW4gYWxnb3JpdGhtIGFsdG9nZXRoZXIg ZnJvbSBJQ0UtYmlzPw0KPj4gDQo+PiBUaGlzIHdvdWxkIG9idmlvdXNseSBiZSBhIGJpZ2dlciBj aGFuZ2UgdGhhbiB3aGF0IHdlIG9yaWdpbmFsbHkgcGxhbm5lZCBmb3IgSUNFLWJpcyB3b3JrLCBi dXQgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gc28gZmFyIHRoZXJlIGNvdWxkIGJlIG1lcml0IHRv IGl0Lg0KPj4gDQo+PiBGcm96ZW4gYWxnb3JpdGhtIGlzIGVzc2VudGlhbGx5IGFuIG9wdGltaXNh dGlvbiB0aGF0IGFsbG93cyBvbmUgdG8gbm90IGNoZWNrIGhpZ2gtcHJpb3JpdHkgY2FuZGlkYXRl IHBhaXJzIHRoYXQgYXJlIGxpa2VseSBub3QgdG8gd29yayAoZS5nLiwgaG9zdC1ob3N0IGNhbmRp ZGF0ZSBmb3IgbW9yZSB0aGFuIG9uZSBzdHJlYW0vY29tcG9uZW50KS4gSWYgYWdlbnQgaGFzIG9u bHkgb25lIG9uZSBzdHJlYW0gYW5kIGNvbXBvbmVudCwgb3IgdXNlcyBSVENQLW11eCBhbmQgQnVu ZGxlcyBhbGwgc3RyZWFtcywgZnJvemVuIGFsZ29yaXRobSBpcyBub3QgZXZlbiB1c2VkIHRvZGF5 LiBBbmQgY3VycmVudCBkcmFmdCBzYXlzIHlvdSBkb24ndCBoYXZlIHRvIGltcGxlbWVudCBpdCBm b3IgdXNhZ2VzIHdpdGggb25seSBvbmUgc3RyZWFtIGFuZCBjb21wb25lbnQuIEhvd2V2ZXIsIHdp dGggbXVsdGlwbGUgc3RyZWFtcyBhbmQvb3IgY29tcG9uZW50cywgaXQgbWFrZXMgYSBkaWZmZXJl bmNlLg0KPj4gDQo+PiBBcHBhcmVudGx5IGV2ZW4gaWYgb25lIGVuZHBvaW50IGRvZXMgbm90IGlt cGxlbWVudCB0aGUgZnJvemVuIGFsZ29yaXRobSwgaXQgd291bGQgc3RpbGwgaW50ZXJvcGVyYXRl IHdpdGggb25lIHRoYXQgZG9lcy4gVGhlIGNoZWNrcyB3b3VsZCBiZSBzbGlnaHRseSBvdXQgb2Yg c3luYyAob25lIGVuZHBvaW50IGlzIGRvaW5nIGNoZWNrcyBmb3IgdGhlIGNhbmRpZGF0ZSBwYWly cyB0aGF0IGFyZSBmcm96ZW4gb24gdGhlIG90aGVyKSwgYnV0IGlmIHdlIHJlZHVjZSB0aGUgU1RV TiBwYWNpbmcgdmFsdWUsIHRoaXMgd2lsbCBiZSBsZXNzIG9mIGEgcHJvYmxlbSBzaW5jZSB0aGUg TkFUIGJpbmRpbmdzIHNob3VsZCBiZSBhbGl2ZSBhbmQgdGhlIHdob2xlIHByb2Nlc3MgaXMgbGlr ZWx5IHRvIGVuZCBpbiByZWFzb25hYmxlIHRpbWUuIEFuZCBpZiBvbmUgY2FyZXMgYWJvdXQgbWlu aW1pc2luZyBhbW91bnQgb2Ygc2VudCBjaGVja3MsIG9uZSBjb3VsZCBzdGlsbCBpbXBsZW1lbnQg dGhlIGFsZ29yaXRobS4NCj4+IA0KPj4gV2hhdCBpcyB5b3VyIG9waW5pb24/IFNob3VsZCB3ZSBr ZWVwIG9yIHJlbW92ZSB0aGUgZnJvemVuIGFsZ29yaXRobSByZXF1aXJlbWVudCBmcm9tIElDRSBi aXM/DQo+PiANCj4+IA0KPj4gQ2hlZXJzLA0KPj4gQXJpDQo+PiANCj4+PiBPbiAxNyBNYXIgMjAx NiwgYXQgMTY6MzIsIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT4gd3JvdGU6 DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gT24gVGh1LCBNYXIgMTcsIDIwMTYgYXQgMTI6MjIgUE0s IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3Rl Og0KPj4+IEhpLA0KPj4+IA0KPj4+Pj4gSSB3YXMgdGhpbmtpbmcgdGhhdCB3ZSB3b3VsZG4ndCBj YXJlIGlmIGNhbmRpZGF0ZXMgc2hhcmUgdGhlIHNhbWUgZm91bmRhdGlvbiBvciBub3QgLSB3ZSBk ZWFsIHdpdGggYWxsIGNhbmRpZGF0ZXMgaW4gdGhlIHNhbWUgd2F5Lg0KPj4+PiANCj4+Pj4gRm9y IHRyaWNrbGUgSUNFIHNwZWNpZmljYWxseSBvciBmb3IgNTI0NWJpcz8gIOKAiw0KPj4+PiANCj4+ Pj4gSSdtIGFsbCBmb3Igc2ltcGxpZmljYXRpb24gYW5kIHJlbW92aW5nIHRoaW5ncyB3ZSBkb24n dCBuZWVkLiAgSSBqdXN0IHdhbnQgdG8gdW5kZXJzdGFuZCB0aGUgc2NvcGUgb2Ygd2hpY2ggeW91 IGFyZSBwcm9wb3Npbmcgd2UgZG8gc28uDQo+Pj4gDQo+Pj4gSSB3YXMgdGhpbmtpbmcgNTI0NWJp czogcmVtb3ZlIGV2ZXJ5dGhpbmcgdGhhdCB0YWxrcyBhYm91dCBmcm96ZW4gY2FuZGlkYXRlcy4N Cj4+PiANCj4+PiANCj4+PiBTb3VuZHMgZ29vZCB0byBtZSwgaWYgd2UgZmVlbCBsaWtlIHRoZSBk b3duc2lkZXMgb2Ygbm90IGhhdmluZyBmcmVlemluZyBhcmUgc3VjaCB0aGF0IHdlIGNhbiBzaW1w bHkgc2F5ICJpZiB5b3UgY2FyZSBhYm91dCB0aGVzZSBkb3duc2lkZXMsIHVzZSBydGNwLW11eCIu ICBJJ2QgbGlrZSB0byBoZWFyIGZyb20gZXZlcnlvbmUgZWxzZSBpZiBmZWVscyB0aGUgc2FtZS7i gIvigIsNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IEljZSBtYWlsaW5nIGxpc3QNCj4+IEljZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEljZSBtYWlsaW5nIGxpc3QNCj4gSWNl QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQo= From nobody Tue Jul 12 08:06:14 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 C812D12D96A for ; Tue, 12 Jul 2016 08:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 T5-pOmqhped0 for ; Tue, 12 Jul 2016 08:06:11 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 98AC712DB7B for ; Tue, 12 Jul 2016 07:35:49 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id s63so15443515qkb.2 for ; Tue, 12 Jul 2016 07:35:49 -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=H9StQZbHyvnl3TTzgOnLZc4YOKkXdmPE3sAbN1UgrUY=; b=TSiz43dD5X9juFodwF15CPeu65Ej3TI5lkc9HwmaGagtR/+fCu/+o7UcRO5x/UV0Mx wdoKYeDohBXUNaARcmnV92gy03IgXmgyX+H4HFlhUxEIaE9KxBNp1x+eyDsqjjojhPZn g9IfEKz4nTmV+CpZndaRbN2YEg4PDJdhOjifHsLRkBfZy0x1jbCzo8Xke4lH9WIckC4E 6+6Fet1iY0U6PH5u7tA8YzrJrCUy5WMZwDrsMTI0fJnKoafNJr/AliQFHJwb+r9fHc2B FgyozDMfUl8dDYA1x4kQ/xwvscJxzY3iY4lUMPVjpq3R7aV33NM9UCcjO1/wM3+D2zEL Bwcg== 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=H9StQZbHyvnl3TTzgOnLZc4YOKkXdmPE3sAbN1UgrUY=; b=J5P8tbXndeyvQ6Ir2uA2xo3hkJt7/YIHjUKfHQnQMhpG0MS+laFqTGgSFEtTuj/RCP ZDf+kYF80HySMl9hVZM6T4uoIsegBObnmsnq+9JbfT7k9FrPgp1goEuaHw8XZYQquf0m 2OfJTCS8uEmCNFu/oYUemTJdwpG2zfxhEsF8dUtOi9brJ9tVZ4n4/8a8fdEqkYBLSukr Qnrlyi9sZ8ZOF7Alf+r6S2gEN/+5p3h/dbByGDlj7K3oOdI+ivhqepO5aY9fGLSParJz PIBEN1iqzYmQtH1vIN4DegM53yzbiqbPYgtp/k5HmCstm6Z6EWYCAs/pBfyl04UkBMNq GGNA== X-Gm-Message-State: ALyK8tIjgxCwDDpYIStTBBSEDyKGNyuFUts0+y4ZkUnHTsU2ostvARrxupjKQIE2Nsi7np+Y+tGvb+fasgxF2QHd X-Received: by 10.55.4.133 with SMTP id 127mr3432607qke.207.1468334148416; Tue, 12 Jul 2016 07:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Tue, 12 Jul 2016 07:35:08 -0700 (PDT) From: Peter Thatcher Date: Tue, 12 Jul 2016 07:35:08 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114c950c544e150537712f49 Archived-At: Subject: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:06:13 -0000 --001a114c950c544e150537712f49 Content-Type: text/plain; charset=UTF-8 I submitted draft-thatcher-ice-remove-candidate and would like to speak about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination. It's a very simple draft. Basically it says you can "remove" candidates just like trickle-ice allows you to add candidates. You could probably read it in 3 minutes. Please do so: https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt Thanks, Peter (Chair hat off) --001a114c950c544e150537712f49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I submitted draft-thatcher-ice-remove-candidate and wou= ld like to speak about in my allotted time on the agenda when I will also b= e speaking about=C2=A0draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination.

It's a very simple draft. Basically it says you can &qu= ot;remove" candidates just like trickle-ice allows you to add candidat= es. You could probably read it in 3 minutes. Please do so:

https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt
Thanks,
Peter (Chair hat off)
--001a114c950c544e150537712f49-- From nobody Tue Jul 12 09:39: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 ED73812D56C for ; Tue, 12 Jul 2016 09:39:36 -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 rb6mC5LKjZyZ for ; Tue, 12 Jul 2016 09:39:35 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 F10B112D559 for ; Tue, 12 Jul 2016 09:39:34 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id o63so29784791vkg.1 for ; Tue, 12 Jul 2016 09:39: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=7wdKuRvQqj+CTGfjd2tO1eBNYvSCDnafLAR+uSbRdfg=; b=HwhAjf1jywZQGouQFm2meP7TfrhSd514YeNgzuFopfCMUCw92+DFzCBCN5i1E8I194 xxoHcx02pxz3zWplulp+46IdrMBQSXia+4rWLN+TNs/J37rTRt81XVS/gu9XiW95/Yzl 2gsh2+d3m4gqtA5Anin6g7QHtLNthfH1mkcI71SYsHPgagKSxo7rZ6aYUe1T1qWYG6N+ IPLDLyUAkKpvanQQUuamaHShIAvScsrRtwBC+KOPKuvRKuzHTGc3Ux+CVn5fJuA7iU/Y 6OdcspWutK/vjDU8eN6DMWdj13K5o9UL7P/5CrCjxW5Yl516RI46ksywruysmoMJL2t6 BhvA== 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=7wdKuRvQqj+CTGfjd2tO1eBNYvSCDnafLAR+uSbRdfg=; b=O9qaLkbUpF+yhYyxlJbltJ60jwFdiqUS7vvuYda+yEYCjO5/YqrW/kRVRuvJ6z8XpO OQMtXf9q63AHvLlnjYDUEQ/b4+Foo0/OIfUmMJ1w0ze8YNIHeKtFrcHM4F9CYjvL/dR3 sHjvb+YYFywgVIOnPLkOKanDdWxvpKK51DH+A7fZ2DMIAnhfAqTzkfSqhQggO7tcLlIU 8WrXR45ZX5LVSSgrI9RjrG6jr0HPVHHpNgsiEQspOmF/kmYRRkM7JMfMZnLQ7ynYI+f5 sBhRsHgoy7lp9JUrTkMnknXILn2dT8HoMTJqEkghXGsmv+vgEhPpJ8hum40U5Ly4VLdd q4cg== X-Gm-Message-State: ALyK8tKMmltqyW2/LpnFMz/PpyNSaEapTJTxaG4xKXgALa9cUZTeZOi78qjnrhDtwd7a9xYwoHo8ta7iT/RxCg== X-Received: by 10.159.32.66 with SMTP id 60mr1720394uam.100.1468341574062; Tue, 12 Jul 2016 09:39:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Tue, 12 Jul 2016 09:39:14 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Tue, 12 Jul 2016 09:39:14 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=94eb2c04d756ee596d053772e90d Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 16:39:37 -0000 --94eb2c04d756ee596d053772e90d Content-Type: text/plain; charset=UTF-8 "Removal" and "Renomination" have both come up as implementation issues, so these drafts seem useful to me. In the "removal" draft, I had questions about these paragraphs: When a removal signal [is received], the Receiving Agent MUST NOT pair the Removed Candi[d]ates with any future candidates gathered by the Receiving Agent. The Receiving Agent MAY keep the existing candidate pairs that use the Removed Candidates and behave as though the Removed Candidates had not been removed for those candidate pairs. Why would an Receiving Agent choose not to immediately remove existing candidate pairs? Because the Removing Agent MAY choose to keep the Removed Candidate capable of receiving ICE checks and sending responses so that any ICE checks already sent by the Receiving Agent may continue to work briefly so that media can flow as quickly as possible, even if over a candidate pair that will soon be discarded. [BA] When an interface is "going down", having the Receiving Agent not immediately remove existing candidate pairs can avoid a media glitch. However there are consequences to not removing the pair immediately because when the interface goes down, consent checks will subsequently fail and RFC 7675 Section 5.1 indicates that the pair cannot be used with the same ICE credentials, even if the interface comes up again: After consent is lost, the same ICE credentials MUST NOT be used on the affected 5-tuple again. That means that a new session, or an ICE restart, is needed to obtain consent to send on the affected candidate pair. One way to deal with this would be for the removing party to revoke consent before bringing the interface down. However, that would only work if consent revocation was not considered the same as "consent is lost" in the above paragraph from RFC 7675. On Tue, Jul 12, 2016 at 7:35 AM, Peter Thatcher wrote: > I submitted draft-thatcher-ice-remove-candidate and would like to speak > about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost > and draft-thatcher-ice-renomination. > > It's a very simple draft. Basically it says you can "remove" candidates > just like trickle-ice allows you to add candidates. You could probably > read it in 3 minutes. Please do so: > > https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > > Thanks, > Peter (Chair hat off) > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --94eb2c04d756ee596d053772e90d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Removal" and "Renomination" have both= come up as implementation issues, so these drafts seem useful to me.
<= div>
In the "removal" draft, I had questions about = these paragraphs:
   When a removal signal [is received], the =
Receiving Agent MUST NOT pair the Removed
   Candi[d]ates with any future candidates gathered by the Receiving Agent.
   The Receiving Agent MAY keep the existing candidate pairs that use
   the Removed Candidates and behave as though the Removed Candidates
   had not been removed for those candidate pairs.

   Why would an Receiving Agent choose not to immediately remove
   existing candidate pairs?  Because the Removing Agent MAY choose to
   keep the Removed Candidate capable of receiving ICE checks and
   sending responses so that any ICE checks already sent by the
   Receiving Agent may continue to work briefly so that media can flow
   as quickly as possible, even if over a candidate pair that will soon
   be discarded.
[BA] When an interface is "going down", havi=
ng the Receiving Agent not immediately remove existing candidate pairs can =
avoid a media glitch. 
However there are consequences to not removing t=
he pair immediately because when the interface goes down, consent checks wi=
ll subsequently fail and RFC 7675 Section 5.1 indicates that the pair canno=
t be used with the same ICE credentials, even if the interface comes up aga=
in: 
   After consent is lost, the same ICE credentials MUST NOT be=
 used on
   the affected 5-tuple again.  That means that a new session, or an ICE
   restart, is needed to obtain consent to send on the affected
   candidate pair.
One way to deal with this would be for the rem=
oving party to revoke consent before bringing the interface down.  However,=
 that would only work if consent revocation was not considered the same as =
"consent is lost" in the above paragraph from RFC 7675.

On = Tue, Jul 12, 2016 at 7:35 AM, Peter Thatcher <pthatcher@google.com= > wrote:
I = submitted draft-thatcher-ice-remove-candidate and would like to speak about= in my allotted time on the agenda when I will also be speaking about=C2=A0= draft-thatcher-ice-network-cost and draft-thatcher-i= ce-renomination.

It'= s a very simple draft. Basically it says you can "remove" candid= ates just like trickle-ice allows you to add candidates. Y= ou could probably read it in 3 minutes. Please do so:

ht= tps://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt=

Thanks,
Peter (Chair hat off)

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


--94eb2c04d756ee596d053772e90d-- From nobody Tue Jul 12 10:07:23 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 ED0E712D576 for ; Tue, 12 Jul 2016 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XUrrmxvklukh for ; Tue, 12 Jul 2016 10:07:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EBF12D1B7 for ; Tue, 12 Jul 2016 10:07:18 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-d2-578523c46f06 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.2D.18043.4C325875; Tue, 12 Jul 2016 19:07:16 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0294.000; Tue, 12 Jul 2016 19:07:15 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin Thread-Index: AQHR3E7wTOX/sYPHwEWR8hqn03AC16AVBe6Q Date: Tue, 12 Jul 2016 17:07:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476A0A52@ESESSMB208.ericsson.se> References: 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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B476A0A52ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7se4R5dZwg239+hbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlnGv5x14wL65i0d8VLA2MV6K7GDk5JARMJJ5c amKBsMUkLtxbz9bFyMUhJHCEUaK7+SgThLOYUWLj9G7GLkYODjYBC4nuf9ogDSICHhKb3yxn AwkLCyRJHG7IgggnS6xcuY4RwjaSuPpqNjOIzSKgKtHX9YIVxOYV8JVYOr8NLC4kECCxvPUE 2A2cAoESS7c+AIszAt3z/dQaJhCbWUBc4taT+UwQdwpILNlznhnCFpV4+fgfK4StJLFi+yVG iPp8iZfbDzBC7BKUODnzCcsERpFZSEbNQlI2C0nZLKBvmAU0Jdbv0ocoUZSY0v2QHcLWkGid M5cdWXwBI/sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMB4Orjlt9UOxoPPHQ8xCnAwKvHw LrjXHC7EmlhWXJl7iFGCg1lJhPegQmu4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLp iSWp2ampBalFMFkmDk6pBsZFf7dYeB1yZjVUc3EQ6d7Y/fA4O+OpbZ722UWtl726W29o/317 yfzzZ2vLKraamZNc3Prkt504eydfWffsvNoFD2xYT8zsFlU/5nRFe/GFBUYf3bQttbevO7ep QUagduP+lL1iIkFfDA8l303i3jj5P0fx1gO/52y3ORHAkb/t4ImSyJZ9B4KVWIozEg21mIuK EwEhWSqJowIAAA== Archived-At: Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:07:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476A0A52ESESSMB208erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSB0ZXh0IHNheXM6DQoNCuKAnFRoZSBSZWNlaXZpbmcgQWdlbnQgTUFZIGtlZXAg dGhlIGV4aXN0aW5nIGNhbmRpZGF0ZSBwYWlycyB0aGF0IHVzZQ0KICAgICAgICAgICAgICB0aGUg UmVtb3ZlZCBDYW5kaWRhdGVzIGFuZCBiZWhhdmUgYXMgdGhvdWdoIHRoZSBSZW1vdmVkIENhbmRp ZGF0ZXMNCiAgICAgICAgICAgICAgaGFkIG5vdCBiZWVuIHJlbW92ZWQgZm9yIHRob3NlIGNhbmRp ZGF0ZSBwYWlycy7igJ0NCg0KV2hhdCBpcyBtZWFudCBieSDigJxiZWhhdmXigJ0/IFNlbmRpbmcg a2VlcC1hbGl2ZXM/IFNlbmRpbmcgbWVkaWE/IFRoYXQgd2lsbCBvYnZpb3VzbHkgbm90IHdvcmsu DQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBzdGF0ZSB3ZXRoZXIgdGhlIHVzYWdlL3N1 cHBvcnQgb2YgdGhlIG1lY2hhbmlzbSBtdXN0IGJlIG5lZ290aWF0ZWQgYmVmb3JlIGl0IGlzIHVz ZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBJY2UgW21haWx0bzppY2Ut Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVyIFRoYXRjaGVyDQpTZW50OiAxMiBK dWx5IDIwMTYgMTc6MzUNClRvOiBpY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtJY2VdIEkgc3VibWl0 dGVkIGFuZCBwbGFuIHRvIHByZXNlbnQgZHJhZnQtdGhhdGNoZXItaWNlLXJlbW92ZS1jYW5kaWRh dGUgaW4gQmVybGluDQoNCkkgc3VibWl0dGVkIGRyYWZ0LXRoYXRjaGVyLWljZS1yZW1vdmUtY2Fu ZGlkYXRlIGFuZCB3b3VsZCBsaWtlIHRvIHNwZWFrIGFib3V0IGluIG15IGFsbG90dGVkIHRpbWUg b24gdGhlIGFnZW5kYSB3aGVuIEkgd2lsbCBhbHNvIGJlIHNwZWFraW5nIGFib3V0IGRyYWZ0LXRo YXRjaGVyLWljZS1uZXR3b3JrLWNvc3QgYW5kIGRyYWZ0LXRoYXRjaGVyLWljZS1yZW5vbWluYXRp b24uDQoNCkl0J3MgYSB2ZXJ5IHNpbXBsZSBkcmFmdC4gQmFzaWNhbGx5IGl0IHNheXMgeW91IGNh biAicmVtb3ZlIiBjYW5kaWRhdGVzIGp1c3QgbGlrZSB0cmlja2xlLWljZSBhbGxvd3MgeW91IHRv IGFkZCBjYW5kaWRhdGVzLiBZb3UgY291bGQgcHJvYmFibHkgcmVhZCBpdCBpbiAzIG1pbnV0ZXMu IFBsZWFzZSBkbyBzbzoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdGhhdGNoZXIt aWNlLXJlbW92ZS1jYW5kaWRhdGUtMDAudHh0DQoNClRoYW5rcywNClBldGVyIChDaGFpciBoYXQg b2ZmKQ0K --_000_7594FB04B1934943A5C02806D1A2204B476A0A52ESESSMB208erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSB0ZXh0IHNh eXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj7igJxUaGUgUmVjZWl2aW5nIEFnZW50IE1BWSBrZWVwIHRoZSBleGlzdGlu ZyBjYW5kaWRhdGUgcGFpcnMgdGhhdCB1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgUmVtb3ZlZCBDYW5kaWRhdGVzIGFu ZCBiZWhhdmUgYXMgdGhvdWdoIHRoZSBSZW1vdmVkIENhbmRpZGF0ZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYWQgbm90IGJl ZW4gcmVtb3ZlZCBmb3IgdGhvc2UgY2FuZGlkYXRlIHBhaXJzLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBpcyBtZWFudCBieSDigJxiZWhhdmXigJ0/IFNl bmRpbmcga2VlcC1hbGl2ZXM/IFNlbmRpbmcgbWVkaWE/IFRoYXQgd2lsbCBvYnZpb3VzbHkgbm90 IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIGl0 IHdvdWxkIGJlIGdvb2QgdG8gc3RhdGUgd2V0aGVyIHRoZSB1c2FnZS9zdXBwb3J0IG9mIHRoZSBt ZWNoYW5pc20gbXVzdCBiZSBuZWdvdGlhdGVkIGJlZm9yZSBpdCBpcyB1c2VkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEljZSBbbWFpbHRvOmljZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Q ZXRlciBUaGF0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBKdWx5IDIwMTYgMTc6MzU8YnI+DQo8 Yj5Ubzo8L2I+IGljZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbSWNlXSBJIHN1Ym1p dHRlZCBhbmQgcGxhbiB0byBwcmVzZW50IGRyYWZ0LXRoYXRjaGVyLWljZS1yZW1vdmUtY2FuZGlk YXRlIGluIEJlcmxpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ SSBzdWJtaXR0ZWQgZHJhZnQtdGhhdGNoZXItaWNlLXJlbW92ZS1jYW5kaWRhdGUgYW5kIHdvdWxk IGxpa2UgdG8gc3BlYWsgYWJvdXQgaW4gbXkgYWxsb3R0ZWQgdGltZSBvbiB0aGUgYWdlbmRhIHdo ZW4gSSB3aWxsIGFsc28gYmUgc3BlYWtpbmcgYWJvdXQmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPmRyYWZ0LXRoYXRjaGVyLWljZS1uZXR3b3JrLWNvc3QNCiBhbmQgZHJhZnQtdGhhdGNo ZXItaWNlLXJlbm9taW5hdGlvbi48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JdCdzIGEgdmVy eSBzaW1wbGUgZHJhZnQuIEJhc2ljYWxseSBpdCBzYXlzIHlvdSBjYW4gJnF1b3Q7cmVtb3ZlJnF1 b3Q7IGNhbmRpZGF0ZXMganVzdCBsaWtlIHRyaWNrbGUtaWNlIGFsbG93cyB5b3UgdG8gYWRkIGNh bmRpZGF0ZXMuIFlvdSBjb3VsZCBwcm9iYWJseSByZWFkIGl0IGluIDMgbWludXRlcy4gUGxlYXNl IGRvIHNvOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdGhhdGNoZXItaWNlLXJlbW92ZS1jYW5kaWRh dGUtMDAudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC10aGF0Y2hlci1pY2UtcmVt b3ZlLWNhbmRpZGF0ZS0wMC50eHQ8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+UGV0ZXIgKENoYWlyIGhhdCBvZmYpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B476A0A52ESESSMB208erics_-- From nobody Tue Jul 12 10:15:21 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03112D764 for ; Tue, 12 Jul 2016 10:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 O-P7n9MuBDQw for ; Tue, 12 Jul 2016 10:15:08 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 3B62C12D58E for ; Tue, 12 Jul 2016 10:15:06 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 52so11708247qtq.3 for ; Tue, 12 Jul 2016 10:15:06 -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=luC07hZKLfn5/c9b/R0xTS0TOlYKUigNjWnd8UBO84E=; b=azbiRRq4sP2G7CWKVCSDIP7ASwda+4YqXWB7PtTHqKwZfTPgqfkDLepCP+hDKK4V8H MFpkq5jDYCb44DRovmMEAnIcxpJzOFf+c3JACNBXXrrdXUre+l6dbezaaZ3AeY0SDhYl oMKLVvlCNPPWjBlpsG8JTfT9Cx8URok1Oo0tl23/6EZxuowkUpdZlWqrkJM8onlbTX4K AMrqCDLa+HnfsfzcOAvGVhrQHsApyA/Ude2aCAscKUsf5AUTbAvq1I5wGdbfkhbAwV+3 6voRQHMZQ2tdiWLHKqN4Z0QxIgcM7bWXAG2pYE4vXel1ce1MHkm6ixlYAhuJcK4M1mDA mS0A== 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=luC07hZKLfn5/c9b/R0xTS0TOlYKUigNjWnd8UBO84E=; b=hrm4bS6hI1Tp2ZDfcoD2TcLamAbGyR7jNPlKoMe585RAQTrd4pzCHui0pFXlwp4fFe GHoOTZTk+cwBGPKv0gYAENk67QoC6XdScCj5dCJYAq3wfkVGx2iK7BCAkv5CWo5/L1Nu 77dJdwv1OyX2KUkCq9i04lZdxcBqxxp4vTaFgaLNz9VnxqIOZaY7CdI7I/iZ4g5tdwNm yiFe3DEjt5G9KBQ7LZQ1SS2x1Uy2dj8WrRrMUnBB0pSW4C/8T/iZfxhBHkJ9ES1GbVUz +yqV8DT7v0KOqFFuoGwOz4RaNzYLdKa6DnZoutx7nq7VpIXjrA3lF8YcvYDljgrbYJ6Y iPSw== X-Gm-Message-State: ALyK8tKb42/UFk5p/kSxJvP1/Min1Oowe4UDg8Jl9MwHGI5x9uAQ5KAZMHfga5wyRlUfv3c4GJBcGaIbjO33SLWi X-Received: by 10.237.36.38 with SMTP id r35mr5185755qtc.3.1468343705205; Tue, 12 Jul 2016 10:15:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Tue, 12 Jul 2016 10:14:25 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Tue, 12 Jul 2016 10:14:25 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a113d3aacf55f0105377368e3 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:15:14 -0000 --001a113d3aacf55f0105377368e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the grammar/spelling fixes. I'll update those with quickly with a new draft version. On Tue, Jul 12, 2016 at 9:39 AM, Bernard Aboba wrote: > "Removal" and "Renomination" have both come up as implementation issues, > so these drafts seem useful to me. > > In the "removal" draft, I had questions about these paragraphs: > > When a removal signal [is received], the Receiving Agent MUST NOT pair= the Removed > Candi[d]ates with any future candidates gathered by the Receiving Agen= t. > The Receiving Agent MAY keep the existing candidate pairs that use > the Removed Candidates and behave as though the Removed Candidates > had not been removed for those candidate pairs. > > Why would an Receiving Agent choose not to immediately remove > existing candidate pairs? Because the Removing Agent MAY choose to > keep the Removed Candidate capable of receiving ICE checks and > sending responses so that any ICE checks already sent by the > Receiving Agent may continue to work briefly so that media can flow > as quickly as possible, even if over a candidate pair that will soon > be discarded. > > [BA] When an interface is "going down", having the Receiving Agent not im= mediately remove existing candidate pairs can avoid a media glitch. > > However there are consequences to not removing the pair immediately becau= se when the interface goes down, consent checks will subsequently fail and = RFC 7675 Section 5.1 indicates that the pair cannot be used with the same I= CE credentials, even if the interface comes up again: > > After consent is lost, the same ICE credentials MUST NOT be used on > the affected 5-tuple again. That means that a new session, or an ICE > restart, is needed to obtain consent to send on the affected > candidate pair. > > One way to deal with this would be for the removing party to revoke conse= nt before bringing the interface down. However, that would only work if co= nsent revocation was not considered the same as "consent is lost" in the ab= ove paragraph from RFC 7675. > > =E2=80=8BIf the interface comes back after consent is lost (after many se= conds), then I think either an ICE restart or gathering new candidates (if gathering isn't already complete) would be the right thing to do. Do you see a problem with that? > > On Tue, Jul 12, 2016 at 7:35 AM, Peter Thatcher > wrote: > >> I submitted draft-thatcher-ice-remove-candidate and would like to speak >> about in my allotted time on the agenda when I will also be speaking abo= ut draft-thatcher-ice-network-cost >> and draft-thatcher-ice-renomination. >> >> It's a very simple draft. Basically it says you can "remove" candidates >> just like trickle-ice allows you to add candidates. You could probably >> read it in 3 minutes. Please do so: >> >> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >> >> Thanks, >> Peter (Chair hat off) >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --001a113d3aacf55f0105377368e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the grammar/spelling fixes.=C2=A0 I'll u= pdate those with quickly with a new draft version.

On Tue, Jul 12, 2016 at 9:39 AM, Ber= nard Aboba <bernard.aboba@gmail.com> wrote:
"Removal" and "Reno= mination" have both come up as implementation issues, so these drafts = seem useful to me.

In the "removal" draft= , I had questions about these paragraphs:
   When a removal si=
gnal [is received], the Receiving Agent MUST NOT pair the Removed
   Candi[d]ates with any future candidates gathered by the Receiving Agent.
   The Receiving Agent MAY keep the existing candidate pairs that use
   the Removed Candidates and behave as though the Removed Candidates
   had not been removed for those candidate pairs.

   Why would an Receiving Agent choose not to immediately remove
   existing candidate pairs?  Because the Removing Agent MAY choose to
   keep the Removed Candidate capable of receiving ICE checks and
   sending responses so that any ICE checks already sent by the
   Receiving Agent may continue to work briefly so that media can flow
   as quickly as possible, even if over a candidate pair that will soon
   be discarded.
[BA] When an interface is "going down", havi=
ng the Receiving Agent not immediately remove existing candidate pairs can =
avoid a media glitch. 
However there are consequences to not removing t=
he pair immediately because when the interface goes down, consent checks wi=
ll subsequently fail and RFC 7675 Section 5.1 indicates that the pair canno=
t be used with the same ICE credentials, even if the interface comes up aga=
in: 
   After consent is lost, the same ICE credentials MUST NOT be used on
   the affected 5-tuple again.  That means that a new session, or an ICE
   restart, is needed to obtain consent to send on the affected
   candidate pair.
One way to deal with this would be for the rem=
oving party to revoke consent before bringing the interface down.  However,=
 that would only work if consent revocation was not considered the same as =
"consent is lost" in the above paragraph from RFC 7675.
=E2=80=8BIf the interface comes back aft= er consent is lost (after many seconds), then I think either an ICE restart= or gathering new candidates (if gathering isn't already complete) woul= d be the right thing to do.=C2=A0 Do you see a problem with that?
=C2=A0

On Tue, Jul 12, 201= 6 at 7:35 AM, Peter Thatcher <pthatcher@google.com> wrote= :
I submit= ted draft-thatcher-ice-remove-candidate and would like to speak about in my= allotted time on the agenda when I will also be speaking about=C2=A0draft-thatcher-ice-network-cost and draft-thatcher-ice-ren= omination.

It's a very simple draft. Basically it says you can &quo= t;remove" candidates just like trickle-ice allows you to add candidate= s. You could probably read it in 3 minutes. Please do so:


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



--001a113d3aacf55f0105377368e3-- From nobody Tue Jul 12 10:21: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 BB7E612D594 for ; Tue, 12 Jul 2016 10:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 s9RD5LliqtEN for ; Tue, 12 Jul 2016 10:21:47 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 C040C12D536 for ; Tue, 12 Jul 2016 10:21:46 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o67so20265536qke.1 for ; Tue, 12 Jul 2016 10:21:46 -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=szl/QchXaKLJHuJIfR/uvTNn+/uy5+r74DRUSPkqA4Q=; b=XC82tiYCu6CRtFEWQMq9u6DjP/4H2umE7Nnxo9+VlUhldgzDSFloHiP9moIFgAs42I 55ryzxtgqIAQl60q0X3P3WAJ+qQ8vHA5TqtVVnAaq1GhbvbOJDUilj2T9/uSt3X+nDq7 R6zeVSGH2Rz8DJqHrK56zBj9HKQq+ZSd4fnU7+OdnoAJxZr3LLsYibX5FQJ/5QWY3e79 RJc00AXJtwdvmSMF8TVDSRoyb2XB60Zv8EVkWF97KIdqJi/HTh14W1HFhGt8jkVTv5Ac 7w9Plq4MVFnUWe3iC7Ulc/gnsYRtUQPLiYxuGFlYGQO5Buie2Z7atsYkhHa5sfS2LWIk hH0w== 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=szl/QchXaKLJHuJIfR/uvTNn+/uy5+r74DRUSPkqA4Q=; b=EuHS5LJT5EZnpoq14aHnnRUo3pu0sdvFFdxN/fBneGj3lbX9N1LyGSpaS2pUasxbFV ZYeZdq9qyZZOHFAhKOODrUxY6uf1VW/2lblKxd7TbFCFcr48lsoZH9JvViZpJ+PoBJFB sTstVozqt52cJwfjvl9VyQi3kmOwFfkYOHHRazPgVhegymGyWeKhBzwCJRIFXPty+knQ s2vBxA7Y0xrqv2NYTUz7qJ+1oTA3ZtgLc3IbqMd8GvpuDS6OyQnTzxVZTKRjw3eGPpkg +enPbQ+budeP7haDBlDbt+wFOLOP+kL4caOjklJt+TVaWYYFZQpA+d7p+QRAtmREvm+E jjRw== X-Gm-Message-State: ALyK8tJFI9Czs2F35PYNhvCpwIbzIlH4Y7P32rrdBlpAsUeWlgjhkQVTF3Zxb+ZeKvNRkpJjKl55oqpPLtnkr6Iz X-Received: by 10.55.73.148 with SMTP id w142mr4444950qka.77.1468344105851; Tue, 12 Jul 2016 10:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Tue, 12 Jul 2016 10:21:06 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476A0A52@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B476A0A52@ESESSMB208.ericsson.se> From: Peter Thatcher Date: Tue, 12 Jul 2016 10:21:06 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114a8808d6a8710537738005 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:21:50 -0000 --001a114a8808d6a8710537738005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2016 at 10:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > The text says: > > > > =E2=80=9CThe Receiving Agent MAY keep the existing candidate pairs that u= se > > the Removed Candidates and behave as though the Removed > Candidates > > had not been removed for those candidate pairs.=E2=80=9D > > > > What is meant by =E2=80=9Cbehave=E2=80=9D? Sending keep-alives? Sending m= edia? That will > obviously not work. > =E2=80=8BBoth keep-alives and media. If the removed candidate is a TURN ca= ndidate that the removing agent wishes to deallocate, it may work for a short period of time before the removing agent actually deallocates it. So the Receiving Agent may choose to keep sending media until it finds a different candidate pair to use instead. Or it may not. > > > I think it would be good to state wether the usage/support of the > mechanism must be negotiated before it is used. > =E2=80=8B =E2=80=8B =E2=80=8BSignaling the removal of candidate never does any harm, so I don't= see a need in negotiating that your going to signal removal (modulo a specific signaling protocol needing to figure out how to send new messages if it chooses to do so). The real question is whether the removing agent needs to know whether the receiving agent is going to do anything with the signal. And since everything will continue to work even if the receiving =E2=80=8Bagent ignores the signal (simply with some perhaps wasted resource= s), then it's not necessary for negotiation at all. You are correct that this should be clear in the draft. I will add it. > > > Regards, > > > > Christer > > > > > > > > *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter Thatcher > *Sent:* 12 July 2016 17:35 > *To:* ice@ietf.org > *Subject:* [Ice] I submitted and plan to present > draft-thatcher-ice-remove-candidate in Berlin > > > > I submitted draft-thatcher-ice-remove-candidate and would like to speak > about in my allotted time on the agenda when I will also be speaking abou= t draft-thatcher-ice-network-cost > and draft-thatcher-ice-renomination. > > > > It's a very simple draft. Basically it says you can "remove" candidates > just like trickle-ice allows you to add candidates. You could probably re= ad > it in 3 minutes. Please do so: > > > > https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > > > > Thanks, > > Peter (Chair hat off) > --001a114a8808d6a8710537738005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 10:07 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

The text says:

=C2=A0

=E2=80= =9CThe Receiving Agent MAY keep the existing candidate pairs that use

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Removed Candidates and behave as t= hough the Removed Candidates

=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 had not been removed for thos= e candidate pairs.=E2=80=9D

=C2=A0

What is meant by =E2=80=9Cbehave=E2= =80=9D? Sending keep-alives? Sending media? That will obviously not work.


=E2=80=8BBoth keep= -alives and media.=C2=A0 If the removed candidate is a TURN candidate that = the removing agent wishes to deallocate, it may work for a short period of = time before the removing agent actually deallocates it.=C2=A0 So the Receiv= ing Agent may choose to keep sending media until it finds a different candi= date pair to use instead. =C2=A0 Or it may not. =C2=A0
=C2= =A0

=C2=A0

I think it would be good to state wet= her the usage/support of the mechanism must be negotiated before it is used= .

=E2=80=8B
= =E2=80=8B
=
=E2=80=8BSignaling the removal of candidate never does any ha= rm, so I don't see a need in negotiating that your going to signal remo= val (modulo a specific signaling protocol needing to figure out how to send= new messages if it chooses to do so).=C2=A0 The real question is whether t= he removing agent needs to know whether the receiving agent is going to do = anything with the signal.=C2=A0 And since everything will continue to work = even if the receiving =E2=80=8Bagent ignores the signal (simply with some p= erhaps wasted resources), then it's not necessary for negotiation at al= l.

You are correct that this should be clear in the dr= aft.=C2=A0 I will add it.

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Peter Thatcher
Sent: 12 July 2016 17:35
To: ice@ietf.org
Subject: [Ice] I submitted and plan to present draft-thatcher-ice-re= move-candidate in Berlin


--001a114a8808d6a8710537738005-- From nobody Tue Jul 12 10:38: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 4682912D511 for ; Tue, 12 Jul 2016 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1r5tw9jV1bx for ; Tue, 12 Jul 2016 10:38:34 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1969912D5B7 for ; Tue, 12 Jul 2016 10:38:33 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id w127so20595825ywf.3 for ; Tue, 12 Jul 2016 10:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zHLDcC7DFBVzrzkIA4py8aZCf2IzMzijx8BjEXm0FXg=; b=ZX5SzbTbUhTasMcU++BMz2VY7cAUfGVYEH6mI3jcx5RaR14ixHrp3d77AqSKmQ/KgJ qYGxCOFRUArdjCkI7mTL1BJLOd8irSTq5kmacqY9P9+wuZMS62DFDfoxtnijtybvs8lk FCaB7Mrd3lUXPOY5b2ttUP7bQ3WYEw9U5CH3/bnYZeU5QudypoWUgWrlxsyykAf+gJsp czv7HQolUkjoGt6ACHHy7isgfo21cISmTtSjHLTAOKa2v1enbVGgN+HmVCKuF9NsuUS6 LMrZVkSRIawxySafZUq2VaZPanU3ZeKw3xgqBP4sYaWLTt7D0YTnW24RlISMNyw+HVLD qLwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=zHLDcC7DFBVzrzkIA4py8aZCf2IzMzijx8BjEXm0FXg=; b=RRQy9i/XRBLqQMIPdfxXgML7q4qUeUk6NDY1FXYn04IK56kaPZGNEbtFFxu4jkMBND 4kZtHoymV1zyJZMWi3YiTikoOuJ//zDWMuXiRxawZht7RSVzWVdjTGSd4d2zyt/BvX8O knBA/Mm/1Ap/UyFTJRJm+/iaOzTfv3hXidIuyDef3MS9rPTtXcmWhx3xHo3tiRNHHDaK GND0A8nlP5TKOyfhdxlt6BV0AvMe8bPVVpXUZYA6WPpatjpjm6YZoFwdzqM9oWJ4RWys EkfDebw8imFomO/OBZqbgCZyufa+LW6JESW7b9WrMYfmZzr9n9yr50Nc7d2UqNenJJsX /bwg== X-Gm-Message-State: ALyK8tIJwCbpzAjYvJNHqh7h+9bz9GaS/cnW4CHtGJrjtFfvTy4of8BiYFaNhAFgso9wNg== X-Received: by 10.129.40.7 with SMTP id o7mr2833624ywo.221.1468345112219; Tue, 12 Jul 2016 10:38:32 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com. [209.85.161.174]) by smtp.gmail.com with ESMTPSA id s78sm108776ywg.26.2016.07.12.10.38.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jul 2016 10:38:32 -0700 (PDT) Received: by mail-yw0-f174.google.com with SMTP id j17so20709124ywg.0 for ; Tue, 12 Jul 2016 10:38:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.169.132 with SMTP id g126mr2790669ywh.179.1468345111378; Tue, 12 Jul 2016 10:38:31 -0700 (PDT) Received: by 10.83.17.204 with HTTP; Tue, 12 Jul 2016 10:38:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jul 2016 20:38:31 +0300 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: Peter Thatcher Content-Type: multipart/alternative; boundary=94eb2c145a6ac5df70053773bcbb Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:38:36 -0000 --94eb2c145a6ac5df70053773bcbb Content-Type: text/plain; charset=UTF-8 Are there any cases where you think this would be useful other than abetter connection with a server? If all that is changing is the connection with the server then it sounds to me like we should rather come up with a way to update the local side of the binding and not bother the remote agent with it. Emil On Tuesday, 12 July 2016, Peter Thatcher wrote: > I submitted draft-thatcher-ice-remove-candidate and would like to speak > about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost > and draft-thatcher-ice-renomination. > > It's a very simple draft. Basically it says you can "remove" candidates > just like trickle-ice allows you to add candidates. You could probably > read it in 3 minutes. Please do so: > > https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > > Thanks, > Peter (Chair hat off) > -- sent from my mobile --94eb2c145a6ac5df70053773bcbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are there any cases where you think this would be useful other than abetter= connection with a server?=C2=A0

If all tha= t is changing is the connection with the server then it sounds to me like w= e should rather come up with a way to update the local side of the binding = and not bother the remote agent with it.

Emil=C2=A0
<= br>On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
I submitted draft-thatcher-ice-remove-candidate= and would like to speak about in my allotted time on the agenda when I wil= l also be speaking about=C2=A0draft-thatcher-ice-network-cost and <= /span>draft-thatcher-ice-renomination.
It's a very simple draft. Basically it says y= ou can "remove" candidates just like trickle-ice allows you to ad= d candidates. You could probably read it in 3 minutes. <= /span>Please do so:


Thanks,
Peter (Chair ha= t off)


--
sent from my mobile
--94eb2c145a6ac5df70053773bcbb-- From nobody Tue Jul 12 11:14: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 92D4112D093 for ; Tue, 12 Jul 2016 11:14:05 -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 TTPG6G0TLruK for ; Tue, 12 Jul 2016 11:14:04 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 AE45612B016 for ; Tue, 12 Jul 2016 11:14:03 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id x130so33592110vkc.0 for ; Tue, 12 Jul 2016 11:14:03 -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=wgaB9Uf6cX+osnbKDbIFB0c2vIPt1YfkR0Et7LwqzRg=; b=k2lw8FTSOWzKICEuNZRzuh1NP9CYnFf9HUoeQOUMWNMXVGamyd56iLYo+k2Oc9qAY6 E90s3r3GA0Om9/jQ0fluJ+PmgmOb7mZ2WPExSP92J40ATkDuG1rQmjPyZsJL0bsAlsgu Wdb6XHuCx8v9Z89GADOJdihgLDSI788zvkAxosYxLutXj9x1Re+9AIJEP4l+K3eVqdCo 95fBTHpZBjd/LTN7yfTobtWFqkRKA5uCORc1nxERJFdbNHqiWIOXy1nktkalQNWfRpUR 17v7B/2o2lWGeKoaGtTpkJQR4zvg4Vw5QAc4UHr9HeOCTQgPszpi24f8BLWRfz3SGfJr f8gw== 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=wgaB9Uf6cX+osnbKDbIFB0c2vIPt1YfkR0Et7LwqzRg=; b=AQhaDym5siO/8AxXzrKa7Q5BBpKMbR7x2xwiBnyHQBF9VIuNkhTLpnGoew/sUv7BsZ diXnp73r1L+NWHPVj1btX3o/yyJZpH+ngz0PxQDmF+l9SpbKY9utzqdeUSoP/jKXob8v 8CXnQXUhiK4Nwn4+9gJbOwieEHa/nvy7elInVC/yymC7uOP6bghD23dQy6+6M35u4M2W 2IH6Gx9wFpYXLQdoCd5//w358Jm7Sr0K29MDt4dBcb1Iv47qKvYwcUyzj83wt8n8293r HqJz+pwmppqZQt8wIEylpiuWU/2E1Qa8WkoLPI6k/Rv7SjBptVIICwdPRU802lw9wLt9 Ls5g== X-Gm-Message-State: ALyK8tKRho9mflov7eGm8bJ1pseJDr6ePqfIGnCqOTbcAd+JiwYOQQAaXJWDBXLGeqXWV0ZnsQ1dusNky6POeQ== X-Received: by 10.31.9.65 with SMTP id 62mr1839210vkj.89.1468347242754; Tue, 12 Jul 2016 11:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Tue, 12 Jul 2016 11:13:43 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Tue, 12 Jul 2016 11:13:43 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11440b64cfb8e90537743be6 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 18:14:05 -0000 --001a11440b64cfb8e90537743be6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Thatcher said: "=E2=80=8BIf the interface comes back after consent is lost (after many sec= onds), then I think either an ICE restart or gathering new candidates (if gathering isn't already complete) would be the right thing to do. Do you see a problem with that?" [BA] What is in RFC 7675 seems ok. But if a candidate is "removed" both peers should have the same understanding of whether the same ICE credentials can ever be used on the 5-tuple again. Based on what is in RFC 7675, it appears that an immediate removal would not automatically require new ICE credentials if the pair is subsequently to be used. However, if the receiving agent chose not to immediately remove the pair and consent subsequently failed this would leave the receiving agent believing that the pair was no longer usable without a restart, while the sending side might believe it could be added back without new ICE credentials. It is not clear to me whether the situation would be different if the sending side revoked consent on the pair before taking the interface down (e.g. whether consent revocation is equivalent to consent loss in RFC 7675). On Tue, Jul 12, 2016 at 10:14 AM, Peter Thatcher wrote: > Thanks for the grammar/spelling fixes. I'll update those with quickly > with a new draft version. > > On Tue, Jul 12, 2016 at 9:39 AM, Bernard Aboba > wrote: > >> "Removal" and "Renomination" have both come up as implementation issues, >> so these drafts seem useful to me. >> >> In the "removal" draft, I had questions about these paragraphs: >> >> When a removal signal [is received], the Receiving Agent MUST NOT pai= r the Removed >> Candi[d]ates with any future candidates gathered by the Receiving Age= nt. >> The Receiving Agent MAY keep the existing candidate pairs that use >> the Removed Candidates and behave as though the Removed Candidates >> had not been removed for those candidate pairs. >> >> Why would an Receiving Agent choose not to immediately remove >> existing candidate pairs? Because the Removing Agent MAY choose to >> keep the Removed Candidate capable of receiving ICE checks and >> sending responses so that any ICE checks already sent by the >> Receiving Agent may continue to work briefly so that media can flow >> as quickly as possible, even if over a candidate pair that will soon >> be discarded. >> >> [BA] When an interface is "going down", having the Receiving Agent not i= mmediately remove existing candidate pairs can avoid a media glitch. >> >> However there are consequences to not removing the pair immediately beca= use when the interface goes down, consent checks will subsequently fail and= RFC 7675 Section 5.1 indicates that the pair cannot be used with the same = ICE credentials, even if the interface comes up again: >> >> After consent is lost, the same ICE credentials MUST NOT be used on >> the affected 5-tuple again. That means that a new session, or an ICE >> restart, is needed to obtain consent to send on the affected >> candidate pair. >> >> One way to deal with this would be for the removing party to revoke cons= ent before bringing the interface down. However, that would only work if c= onsent revocation was not considered the same as "consent is lost" in the a= bove paragraph from RFC 7675. >> >> =E2=80=8BIf the interface comes back after consent is lost (after many s= econds), > then I think either an ICE restart or gathering new candidates (if > gathering isn't already complete) would be the right thing to do. Do you > see a problem with that? > > >> >> On Tue, Jul 12, 2016 at 7:35 AM, Peter Thatcher >> wrote: >> >>> I submitted draft-thatcher-ice-remove-candidate and would like to speak >>> about in my allotted time on the agenda when I will also be speaking ab= out draft-thatcher-ice-network-cost >>> and draft-thatcher-ice-renomination. >>> >>> It's a very simple draft. Basically it says you can "remove" candidates >>> just like trickle-ice allows you to add candidates. You could probably >>> read it in 3 minutes. Please do so: >>> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >>> >>> Thanks, >>> Peter (Chair hat off) >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >> > --001a11440b64cfb8e90537743be6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter Thatcher said:=C2=A0

"=E2=80=8B= If the interface comes back after consent is lost (after many seconds), the= n I think either an ICE restart or gathering new candidates (if gathering i= sn't already complete) would be the right thing to do.=C2=A0 Do you see= a problem with that?"

[BA] What is in= RFC 7675 seems ok.=C2=A0 But if a candidate is "removed" both pe= ers should have the same understanding of whether the same ICE credentials = can ever be used on the 5-tuple again.

Based on wh= at is in RFC 7675, it appears that an immediate removal would not automatic= ally require new ICE credentials if the pair is subsequently to be used.=C2= =A0 However, if the receiving agent chose not to immediately remove the pai= r and consent subsequently failed this would leave the receiving agent beli= eving that the pair was no longer usable without a restart, while the sendi= ng side might believe it could be added back without new ICE credentials. I= t is not clear to me whether the situation would be different if the sendin= g side revoked consent on the pair before taking the interface down (e.g. w= hether consent revocation is equivalent to consent loss in RFC 7675).=C2=A0=



On Tue, Jul 12, 2016 at 10:14 AM, Peter Thatcher <= span dir=3D"ltr"><pthatcher@google.com> wrote:
Thanks for the grammar/spelling fixes.=C2=A0 I= 9;ll update those with quickly with a new draft version.

On Tue, Jul 1= 2, 2016 at 9:39 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
"Remov= al" and "Renomination" have both come up as implementation i= ssues, so these drafts seem useful to me.

In the &q= uot;removal" draft, I had questions about these paragraphs:
<= div>
   When a removal signal [is received], the Receiving Agent MUST NOT pai=
r the Removed
   Candi[d]ates with any future candidates gathered by the Receiving Agent.
   The Receiving Agent MAY keep the existing candidate pairs that use
   the Removed Candidates and behave as though the Removed Candidates
   had not been removed for those candidate pairs.

   Why would an Receiving Agent choose not to immediately remove
   existing candidate pairs?  Because the Removing Agent MAY choose to
   keep the Removed Candidate capable of receiving ICE checks and
   sending responses so that any ICE checks already sent by the
   Receiving Agent may continue to work briefly so that media can flow
   as quickly as possible, even if over a candidate pair that will soon
   be discarded.
[BA] When an interface is "going down", havi=
ng the Receiving Agent not immediately remove existing candidate pairs can =
avoid a media glitch. 
However there are consequences to not removing t=
he pair immediately because when the interface goes down, consent checks wi=
ll subsequently fail and RFC 7675 Section 5.1 indicates that the pair canno=
t be used with the same ICE credentials, even if the interface comes up aga=
in: 
   After consent is lost, the same ICE credentials MUST NOT be used on
   the affected 5-tuple again.  That means that a new session, or an ICE
   restart, is needed to obtain consent to send on the affected
   candidate pair.
One way to deal with this would be for the rem=
oving party to revoke consent before bringing the interface down.  However,=
 that would only work if consent revocation was not considered the same as =
"consent is lost" in the above paragraph from RFC 7675.
=E2=80=8BIf the interface comes= back after consent is lost (after many seconds), then I think either an IC= E restart or gathering new candidates (if gathering isn't already compl= ete) would be the right thing to do.=C2=A0 Do you see a problem with that?<= /div>
=C2=A0

On Tue= , Jul 12, 2016 at 7:35 AM, Peter Thatcher <pthatcher@google.com>= wrote:
I submit= ted draft-thatcher-ice-remove-candidate and would like to speak about in my= allotted time on the agenda when I will also be speaking about=C2=A0draft-thatcher-ice-network-cost and draft-thatcher-ice-ren= omination.

It's a very simple draft. Basically it says you can &quo= t;remove" candidates just like trickle-ice allows you to add candidate= s. You could probably read it in 3 minutes. Please do so:


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




--001a11440b64cfb8e90537743be6-- From nobody Tue Jul 12 14:20:49 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 5C81C12D960 for ; Tue, 12 Jul 2016 14:20:48 -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 2eNB3UYMQWBR for ; Tue, 12 Jul 2016 14:20:46 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC2B12D968 for ; Tue, 12 Jul 2016 14:20:41 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id v6so40280053vkb.2 for ; Tue, 12 Jul 2016 14:20:41 -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=hk5Vs5rcIv5sOVAq1YHD4xGyhCsBl0OAsOWlrDOwmSI=; b=uBUL5JuJ1kbBC4of3MmVCm1QHEZEc911pyUVIl+IKv2eSl/9zEVNcqBMf3FWzooD9L Xplt3981wmCt0LZngS6a3peDK7Og7fbiYeQ9rGIyAFSia4mxlsGlOw4Db736oQrcIm9V Z8MqanZg3D8Yw+bv8gl34xjhsWTHL0tybfrr2aWCwbcaZsV7HgIFh/WZNXfsWF00G/U6 8txme7GJarpdSAQNhYfqv8c6z48AH0BBmD6ctVuoOCwzM+4zosaf8m8rvAp8StQ+zqW6 kylbS+VfhT2DmDicYqaUYcSLUJsf3ZxV9qOvFHxeno/DSVyOGdm9veeR1iD4kyh/hVWP NMpg== 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=hk5Vs5rcIv5sOVAq1YHD4xGyhCsBl0OAsOWlrDOwmSI=; b=gfyyjXWUqXrnxvh1NV8juyudK1AdPHt4azsl3jeGBLAwKNkCk8UhvWAMa+oZUizBHt ZL5L5mojWBGgZq84AisaKwQE2h9gJwuAizGX8GR4ex3lkQc6kCKYqj6CXkLzr/yxd4VF b89BUsIsv2avj5qykknHHwbTj+xyxd4MDUSitCPm5iF03Ie7vNz+uvXcQKVoaqaZVk2b I8UqUryIJ+plR8UXCNj3FrGeGhqG5pHy2HZe8vROE0zFJgMzs85+I36JXcuchGnN2tcA HZ9n4aocUzJJbw5ZhYbn3YPpGnGkDdZRystOgTv8TuhvV1jIZ45FlrSbe6buEMBHqPdV fHHQ== X-Gm-Message-State: ALyK8tLvrsceerC4yseCUFKP8seF0ZcXPWr0Gef8duKIu2xgeQea3f0xJnkvhi+cfNVySvogx3r0iTRmzL4jAQ== X-Received: by 10.159.40.74 with SMTP id c68mr2275366uac.9.1468358440396; Tue, 12 Jul 2016 14:20:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Tue, 12 Jul 2016 14:20:20 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B476A0A52@ESESSMB208.ericsson.se> From: Bernard Aboba Date: Tue, 12 Jul 2016 14:20:20 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=94eb2c04486a3e2d13053776d723 Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 21:20:48 -0000 --94eb2c04486a3e2d13053776d723 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter said: "The real question is whether the removing agent needs to know whether the receiving agent is going to do anything with the signal. And since everything will continue to work even if the receiving =E2=80=8Bagent ignor= es the signal (simply with some perhaps wasted resources), then it's not necessary for negotiation at all." [BA] The removing agent only needs to know if the receiving agent understands removal if that will make a difference in subsequent behavior. If a removed candidate will never be re-added, I don't think it matters, because a receiving agent not understanding removal will eventually figure out that the removed candidate is inactive, and that pairs involving the removed candidate are unusable. But if it is desired to be able to re-add a removed candidate without an ICE restart, then it might make a difference. On Tue, Jul 12, 2016 at 10:21 AM, Peter Thatcher wrote: > > > On Tue, Jul 12, 2016 at 10:07 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> The text says: >> >> >> >> =E2=80=9CThe Receiving Agent MAY keep the existing candidate pairs that = use >> >> the Removed Candidates and behave as though the Removed >> Candidates >> >> had not been removed for those candidate pairs.=E2=80=9D >> >> >> >> What is meant by =E2=80=9Cbehave=E2=80=9D? Sending keep-alives? Sending = media? That will >> obviously not work. >> > > =E2=80=8BBoth keep-alives and media. If the removed candidate is a TURN = candidate > that the removing agent wishes to deallocate, it may work for a short > period of time before the removing agent actually deallocates it. So the > Receiving Agent may choose to keep sending media until it finds a differe= nt > candidate pair to use instead. Or it may not. > > >> >> >> I think it would be good to state wether the usage/support of the >> mechanism must be negotiated before it is used. >> > =E2=80=8B > =E2=80=8B > =E2=80=8BSignaling the removal of candidate never does any harm, so I don= 't see a > need in negotiating that your going to signal removal (modulo a specific > signaling protocol needing to figure out how to send new messages if it > chooses to do so). The real question is whether the removing agent needs > to know whether the receiving agent is going to do anything with the > signal. And since everything will continue to work even if the receiving > =E2=80=8Bagent ignores the signal (simply with some perhaps wasted resour= ces), then > it's not necessary for negotiation at all. > > You are correct that this should be clear in the draft. I will add it. > > > >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter Thatcher >> *Sent:* 12 July 2016 17:35 >> *To:* ice@ietf.org >> *Subject:* [Ice] I submitted and plan to present >> draft-thatcher-ice-remove-candidate in Berlin >> >> >> >> I submitted draft-thatcher-ice-remove-candidate and would like to speak >> about in my allotted time on the agenda when I will also be speaking abo= ut draft-thatcher-ice-network-cost >> and draft-thatcher-ice-renomination. >> >> >> >> It's a very simple draft. Basically it says you can "remove" candidates >> just like trickle-ice allows you to add candidates. You could probably r= ead >> it in 3 minutes. Please do so: >> >> >> >> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >> >> >> >> Thanks, >> >> Peter (Chair hat off) >> > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --94eb2c04486a3e2d13053776d723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter said:=C2=A0

"The real question = is whether the removing agent needs to know whether the receiving agent is = going to do anything with the signal.=C2=A0 And since everything will conti= nue to work even if the receiving =E2=80=8Bagent ignores the signal (simply= with some perhaps wasted resources), then it's not necessary for negot= iation at all."

[BA] = The removing agent only needs to know if the receiving agent understands re= moval if that will make a difference in subsequent behavior. If a removed c= andidate will never be re-added, I don't think it matters, because a re= ceiving agent not understanding removal will eventually figure out that the= removed candidate is inactive, and that pairs involving the removed candid= ate are unusable. But if it is desired to be able to re-add a removed candi= date without an ICE restart, then it might make a difference.=

On Tu= e, Jul 12, 2016 at 10:21 AM, Peter Thatcher <pthatcher@google.com= > wrote:

On Tue, Jul 12, 2016 at 10:07 AM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

The text says:

=C2=A0

=E2=80= =9CThe Receiving Agent MAY keep the existing candidate pairs that use

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Removed Candidates and behave as t= hough the Removed Candidates

=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 had not been removed for thos= e candidate pairs.=E2=80=9D

=C2=A0

What is meant by =E2=80=9Cbehave=E2= =80=9D? Sending keep-alives? Sending media? That will obviously not work.


=E2=80=8BBo= th keep-alives and media.=C2=A0 If the removed candidate is a TURN candidat= e that the removing agent wishes to deallocate, it may work for a short per= iod of time before the removing agent actually deallocates it.=C2=A0 So the= Receiving Agent may choose to keep sending media until it finds a differen= t candidate pair to use instead. =C2=A0 Or it may not. =C2=A0
=C2=A0

=C2=A0

I think it would be good to state wet= her the usage/support of the mechanism must be negotiated before it is used= .

=E2=80=8B
= =E2=80=8B
=
=E2=80=8BSignaling the removal of candidate never does= any harm, so I don't see a need in negotiating that your going to sign= al removal (modulo a specific signaling protocol needing to figure out how = to send new messages if it chooses to do so).=C2=A0 The real question is wh= ether the removing agent needs to know whether the receiving agent is going= to do anything with the signal.=C2=A0 And since everything will continue t= o work even if the receiving =E2=80=8Bagent ignores the signal (simply with= some perhaps wasted resources), then it's not necessary for negotiatio= n at all.

You are correct that this should be clear in= the draft.=C2=A0 I will add it.

=C2= =A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Peter Thatcher
Sent: 12 July 2016 17:35
To: ice@ietf.org
Subject: [Ice] I submitted and plan to present draft-thatcher-ice-re= move-candidate in Berlin



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


--94eb2c04486a3e2d13053776d723-- From nobody Wed Jul 13 12:22: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 78D6712B05C for ; Wed, 13 Jul 2016 12:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 LBD1tIc77Cgl for ; Wed, 13 Jul 2016 12:22:53 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 8290F12B043 for ; Wed, 13 Jul 2016 12:22:53 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id j35so31343817qtj.2 for ; Wed, 13 Jul 2016 12:22:53 -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=PcZ9YFFAxlTDiD/mL49Mqc9wk+z+QuwUMU64jPJO1HM=; b=Joju6vFRcNuFLU4XG019GBmLdRw8mrpJe7Oetx88CJGnn4M1vnDC5qBIo4631nfI3f 6C6qzY9KsXRWgwPkUbK17iWtC38n9/AOATZJalF+EuAp8RoRp2mcaVUSTt9n+gJQZdkk 3/0rgGF+x6N3+ZHwOfNGVzwh2Jh/OoXRZbjH4z4pTNaxvG/BS7Y1Ol/ze1VRs5F2rtzf 69FVr7kc3ka0+idI+JvkV9P6Qn4Bxpf8sgdVfRtcNqISHPyyvAR98AY8CDHc9ay9BdjP 5/7NM4MQRsWZk6wCP6NWJyBzGh+KJphdlsxZG1bdMRNoKTxVXjjvAJjfKGDhAPEhH3yq oPOA== 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=PcZ9YFFAxlTDiD/mL49Mqc9wk+z+QuwUMU64jPJO1HM=; b=EApIZKwal7DdE5BwRM9oREDJCkJubFm4WkpRqdaoiE8FpabxixWcctTH6Le/q6YyRm 6CiNwIbOovCrahn0TkTj55Ejm91dFknShipbe2oydfhQ9kuavfQ7uDmgwXIT1y2JKXep gwySeRH4m/qDf+yY2+xodGyNNf2h+hE/JzaWUMNqlYXEejeXzRpg8fotDmz71761NyM3 CAtHsqcoN0kQcpuap8mN7EjhhRvhImNac8jM2HQutr7eMKZV35AVyV++TuG8lUjARbtZ 7Na9jV7kAtIb65RGk5et0jFEuu2bFaBclK3UZ2a5wssMP0g09WHTXpNLDwG2uxfNcOKH dVaA== X-Gm-Message-State: ALyK8tJ+dZtmqiziv+XDODO50Sh3iMW1SNdL9I4ozoguHAZM6UPunHoynR8CvTa4cmyFEm+Hc9B1lGfAHhytD8xH X-Received: by 10.200.34.19 with SMTP id o19mr14414514qto.97.1468437772465; Wed, 13 Jul 2016 12:22:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Wed, 13 Jul 2016 12:22:12 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 13 Jul 2016 12:22:12 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11394dbecdc6770537894fe7 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:22:55 -0000 --001a11394dbecdc6770537894fe7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: > Are there any cases where you think this would be useful other than > abetter connection with a server? > > =E2=80=8BYes: continual gathering (aka continuous nomination) would benefit= from this.=E2=80=8B > If all that is changing is the connection with the server then it sounds > to me like we should rather come up with a way to update the local side o= f > the binding and not bother the remote agent with it. > =E2=80=8BThat would be TURN mobility, or some new equivalent (=E2=80=8B =E2=80=8B =E2=80=8Bthe TURN mobility draft has expired). That is an option that we'd= like to explore implementing, but it's much more work to standardize, implement, and deploy (both on client and server). Whereas this is a simply mechanism that is quick to standardize, implement, and deply, and it's useful for other things (as mentioned above). > > Emil > > > On Tuesday, 12 July 2016, Peter Thatcher wrote: > >> I submitted draft-thatcher-ice-remove-candidate and would like to speak >> about in my allotted time on the agenda when I will also be speaking abo= ut draft-thatcher-ice-network-cost >> and draft-thatcher-ice-renomination. >> >> It's a very simple draft. Basically it says you can "remove" candidates >> just like trickle-ice allows you to add candidates. You could probably >> read it in 3 minutes. Please do so: >> >> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >> >> Thanks, >> Peter (Chair hat off) >> > > > -- > sent from my mobile > --001a11394dbecdc6770537894fe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov = <emcho@jitsi.org> wrote:
Are there any cases w= here you think this would be useful other than abetter connection with a se= rver?=C2=A0


=E2=80=8BYes: continual gathering (aka continuous nomination) would benef= it from this.=E2=80=8B
=C2=A0

=C2=A0
If all that is cha= nging is the connection with the server then it sounds to me like we should= rather come up with a way to update the local side of the binding and not = bother the remote agent with it.

=E2=80=8BThat would= be TURN mobility, or some new equivalent (=E2=80=8B
=E2=80=8B
=E2=80=8Bthe TURN mobility draft has expired).=C2=A0 That is an o= ption that we'd like to explore implementing, but it's much more wo= rk to standardize, implement, and deploy (both on client and server).=C2=A0= Whereas this is a simply mechanism that is quick to standardize, implement= , and deply, and it's useful for other things (as mentioned above).

=C2=A0

Emil=C2=A0


On= Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
I submitted draft-thatcher-ice-remove-candidate and would = like to speak about in my allotted time on the agenda when I will also be s= peaking about=C2=A0draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination.

It's a very simple draft. Basic= ally it says you can "remove" candidates just like trickle-ice al= lows you to add candidates. You could probably read it in = 3 minutes. Please do so:


Tha= nks,
Peter (Chair hat off)


--
sent from my mobile

--001a11394dbecdc6770537894fe7-- From nobody Wed Jul 13 12:27:49 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 D695912D568 for ; Wed, 13 Jul 2016 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 aiLzd0kdgV_j for ; Wed, 13 Jul 2016 12:27:44 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 59D9E12B05C for ; Wed, 13 Jul 2016 12:27:44 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id s63so53549017qkb.2 for ; Wed, 13 Jul 2016 12:27:44 -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=FAlaXjzZjlPuALLtNgDuie8ZTKkX5TFCj7R5Ca/wz9E=; b=CSgaXPlNubyz8IDdOD1niT/DoozAlWEC+U9SyyatwD6lK056zGNY7osg8i8+csj4NJ xVcYXkZvA2J0Nzql2LiJ+NJvHgQHqR8iKUTjYFMqMD+QZ3RfdAMSIwTKsbvEc4sYbP15 Rq3kZgdXNCapAmbMlEItDhIazHRljP/Ua5/l0eCA103g2KPAI9UrtXtUSvSqKW0fNP1U OKPlBNGBvla2G2dqGvsBVhVLX5J9fTh+WV3U5bVs5s7UzGLmT4zE4WMpmmMe1wfF/x9L kllxvHWK5ufeUHi4kL5EGScIGHycWrJ8JR9K1ZwvHR/q83d0Fm59qBbAkuNBDcVuELyM +AIw== 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=FAlaXjzZjlPuALLtNgDuie8ZTKkX5TFCj7R5Ca/wz9E=; b=W9W/8AKI7VupXDSmtLkoDtojgdYyNHLD/ag1tEW0Nqcy5XlvMgNvUPjkzBe+Qdd0Md m1pSREnGK+c78ote6suorWE7yczESileK9cWqOEjjWgY0gDaD1ZOpPVxtqN/vxWRe8Cg hDUjwsH65ivvlgLxvPzG7ZPXt5Sm3ZDvwTEI0OqBznPfePyLbeGqOzEd4CvHZgJuNRjp zlDAUOvb1cIdwyO0Rv7QsMW6s1fAqGfCOPpBW0KR+f8+QK2uv3Vywb3xT5hDgRt2LXhw IAtdNaRpFjGQH6xKqvTvqGh2ruCKTj3KGioadz2rBmaRNHx4oEfC5d8ld4Wv1Wyw92cZ TGvw== X-Gm-Message-State: ALyK8tI0aHVWdpcyxIoTDzpV1jGmZkTl2OYJNZToww1AtxX4v2vHbU+HA6aL9vy91gi+7/4XxLN20TKYf5r1ZT4Q X-Received: by 10.55.192.88 with SMTP id o85mr12060754qki.15.1468438063444; Wed, 13 Jul 2016 12:27:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Wed, 13 Jul 2016 12:27:03 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B476A0A52@ESESSMB208.ericsson.se> From: Peter Thatcher Date: Wed, 13 Jul 2016 12:27:03 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11498e4025d9e60537896175 Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:27:47 -0000 --001a11498e4025d9e60537896175 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2016 at 2:20 PM, Bernard Aboba wrote: > Peter said: > > "The real question is whether the removing agent needs to know whether > the receiving agent is going to do anything with the signal. And since > everything will continue to work even if the receiving =E2=80=8Bagent ign= ores the > signal (simply with some perhaps wasted resources), then it's not necessa= ry > for negotiation at all." > > [BA] The removing agent only needs to know if the receiving agent > understands removal if that will make a difference in subsequent behavior= . > If a removed candidate will never be re-added, I don't think it matters, > because a receiving agent not understanding removal will eventually figur= e > out that the removed candidate is inactive, and that pairs involving the > removed candidate are unusable. But if it is desired to be able to re-add= a > removed candidate without an ICE restart, then it might make a difference= . > =E2=80=8BThat's a good point about re-adding a candidate. But isn't the qu= estion of re-adding a candidate also relevant to normal trickle, independent of removal? For example, what happens if I re-trickle a candidate to you after you lose consent for a candidate pair with that candidate? Does that allow you to re-establish consent? =E2=80=8B > > On Tue, Jul 12, 2016 at 10:21 AM, Peter Thatcher > wrote: > >> >> >> On Tue, Jul 12, 2016 at 10:07 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >>> >>> The text says: >>> >>> >>> >>> =E2=80=9CThe Receiving Agent MAY keep the existing candidate pairs that= use >>> >>> the Removed Candidates and behave as though the Removed >>> Candidates >>> >>> had not been removed for those candidate pairs.=E2=80=9D >>> >>> >>> >>> What is meant by =E2=80=9Cbehave=E2=80=9D? Sending keep-alives? Sending= media? That will >>> obviously not work. >>> >> >> =E2=80=8BBoth keep-alives and media. If the removed candidate is a TURN >> candidate that the removing agent wishes to deallocate, it may work for = a >> short period of time before the removing agent actually deallocates it. = So >> the Receiving Agent may choose to keep sending media until it finds a >> different candidate pair to use instead. Or it may not. >> >> >>> >>> >>> I think it would be good to state wether the usage/support of the >>> mechanism must be negotiated before it is used. >>> >> =E2=80=8B >> =E2=80=8B >> =E2=80=8BSignaling the removal of candidate never does any harm, so I do= n't see a >> need in negotiating that your going to signal removal (modulo a specific >> signaling protocol needing to figure out how to send new messages if it >> chooses to do so). The real question is whether the removing agent need= s >> to know whether the receiving agent is going to do anything with the >> signal. And since everything will continue to work even if the receivin= g >> =E2=80=8Bagent ignores the signal (simply with some perhaps wasted resou= rces), then >> it's not necessary for negotiation at all. >> >> You are correct that this should be clear in the draft. I will add it. >> >> >> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter Thatcher >>> *Sent:* 12 July 2016 17:35 >>> *To:* ice@ietf.org >>> *Subject:* [Ice] I submitted and plan to present >>> draft-thatcher-ice-remove-candidate in Berlin >>> >>> >>> >>> I submitted draft-thatcher-ice-remove-candidate and would like to speak >>> about in my allotted time on the agenda when I will also be speaking ab= out draft-thatcher-ice-network-cost >>> and draft-thatcher-ice-renomination. >>> >>> >>> >>> It's a very simple draft. Basically it says you can "remove" candidates >>> just like trickle-ice allows you to add candidates. You could probably = read >>> it in 3 minutes. Please do so: >>> >>> >>> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >>> >>> >>> >>> Thanks, >>> >>> Peter (Chair hat off) >>> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --001a11498e4025d9e60537896175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 2:20 PM, Bernard Aboba <bernard= .aboba@gmail.com> wrote:
Peter said:=C2=A0

"= The= real question is whether the removing agent needs to know whether the rece= iving agent is going to do anything with the signal.=C2=A0 And since everyt= hing will continue to work even if the receiving =E2=80=8Bagent ignores the= signal (simply with some perhaps wasted resources), then it's not nece= ssary for negotiation at all."

[BA] Th= e removing agent only needs to know if the receiving agent understands remo= val if that will make a difference in subsequent behavior. If a removed can= didate will never be re-added, I don't think it matters, because a rece= iving agent not understanding removal will eventually figure out that the r= emoved candidate is inactive, and that pairs involving the removed candidat= e are unusable. But if it is desired to be able to re-add a removed candida= te without an ICE restart, then it might make a difference.

=E2=80=8BThat&= #39;s a good point about re-adding a candidate.=C2=A0 But isn't the que= stion of re-adding a candidate also relevant to normal trickle, independent= of removal?=C2=A0 For example, what happens if I re-trickle a candidate to= you after you lose consent for a candidate pair with that candidate?=C2=A0= Does that allow you to re-establish consent?

=E2=80=8B
=C2=A0

On Tue, Jul 12, 2016 at 10:21 AM, Peter Th= atcher <pthatcher@google.com> wrote:


On Tue, Jul 12, 2016 at 10:07 A= M, Christer Holmberg <christer.holmberg@ericsson.com><= /span> wrote:

Hi,

=C2=A0

The text says:

=C2=A0

=E2=80= =9CThe Receiving Agent MAY keep the existing candidate pairs that use

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Removed Candidates and behave as t= hough the Removed Candidates

=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 had not been removed for thos= e candidate pairs.=E2=80=9D

=C2=A0

What is meant by =E2=80=9Cbehave=E2= =80=9D? Sending keep-alives? Sending media? That will obviously not work.


=E2=80=8BBoth keep-alives and media= .=C2=A0 If the removed candidate is a TURN candidate that the removing agen= t wishes to deallocate, it may work for a short period of time before the r= emoving agent actually deallocates it.=C2=A0 So the Receiving Agent may cho= ose to keep sending media until it finds a different candidate pair to use = instead. =C2=A0 Or it may not. =C2=A0
=C2=A0

=C2=A0

I think it would be good to state wet= her the usage/support of the mechanism must be negotiated before it is used= .

=E2=80=8B
=E2=80=8B
=E2=80=8BSignaling the remo= val of candidate never does any harm, so I don't see a need in negotiat= ing that your going to signal removal (modulo a specific signaling protocol= needing to figure out how to send new messages if it chooses to do so).=C2= =A0 The real question is whether the removing agent needs to know whether t= he receiving agent is going to do anything with the signal.=C2=A0 And since= everything will continue to work even if the receiving =E2=80=8Bagent igno= res the signal (simply with some perhaps wasted resources), then it's n= ot necessary for negotiation at all.

You are correct that this should be clear in the draft.=C2=A0 I w= ill add it.

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0<= /u>

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Peter Thatcher
Sent: 12 July 2016 17:35
To: ice@ietf.org
Subject: [Ice] I submitted and plan to present draft-thatcher-ice-re= move-candidate in Berlin



__________________________________________= _____
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice



--001a11498e4025d9e60537896175-- From nobody Wed Jul 13 12:45:32 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA38112D1AC for ; Wed, 13 Jul 2016 12:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4xVI1Yxb-tu for ; Wed, 13 Jul 2016 12:45:28 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 9450B12D19E for ; Wed, 13 Jul 2016 12:45:28 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id w127so53705588ywf.3 for ; Wed, 13 Jul 2016 12:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4SAzjC8PrDFPT0heFCNwLTQnBl3+C/lHuX6hxSDaqo0=; b=UI/EvbAHGOp59IecYFk3M7uH807kLahxAe6w3FMskeW+vi+Ht2o9rwN9y01WbWLWpx bly3ugupHQg73ZwaqnJJpFl/6j+gDa76y3uj+oBLbx5yvsGtRNRQN4eu2QMlcZli5+qv ZZtPc5NRRkZXdx/nU27XS4UXE0iYOVJkbmkNTXk4Hityu+yDoGyx59PR4dS4V5g6dzs3 5L6+fjm0/hxBkO15yjNvYDjvA8jmyAWXDaF+sbXmQluxV/mK9zrJmQDsHRxbt5jxMzXP gf8+FcO0ZsVLVPEckAUas3j2oAeiqz6OsP2leTZotAC+u8hGoaHGV+VdjyI/mDzZcT5Q ittA== 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=4SAzjC8PrDFPT0heFCNwLTQnBl3+C/lHuX6hxSDaqo0=; b=YqnmtKCD06Jao+ZhaOR3AFaXva83DkHNm9GfaUTLFAxTbj0zGt1ScrWJO1dzcod4d3 biSWXjG3H7XuHYwcqIR6+4DGBWaJj3MR5CxhPtuThDa62pKWeF6ILTG3a7K0yaQ8onYJ Y8NuEJ3ha32Cd0Eecq781IVYLp/D4SXm7cPBgma8hDcR9KarRnshrc2PVjM5GDNYLIe4 cDku8iroLVi3eroo+8w/YdjBeKHgHpmsSD2BIZBMgnIvstVL16HX0Vv5ACDSHyGYd4yi DSXngDEHuk8MQB0L05Lwx2Qrq+QxfBZps/zUMe7phijX/aIMTleA//fVZEa78OtXGZ20 0PJg== X-Gm-Message-State: ALyK8tI8M+nbMViQwf/3ssHlaK/u3lsoGJtNFVjcPgWcVDb4fEVOCKCbGvjlM8AIjJI9tQ== X-Received: by 10.129.130.196 with SMTP id s187mr7799500ywf.215.1468439127710; Wed, 13 Jul 2016 12:45:27 -0700 (PDT) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com. [209.85.161.175]) by smtp.gmail.com with ESMTPSA id u62sm1433999ywg.55.2016.07.13.12.45.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 12:45:27 -0700 (PDT) Received: by mail-yw0-f175.google.com with SMTP id j17so53832956ywg.0 for ; Wed, 13 Jul 2016 12:45:27 -0700 (PDT) X-Received: by 10.129.159.131 with SMTP id w125mr3891775ywg.168.1468439127131; Wed, 13 Jul 2016 12:45:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Wed, 13 Jul 2016 12:45:07 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Wed, 13 Jul 2016 22:45:07 +0300 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:45:31 -0000 On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher wrote: > > > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: >> >> Are there any cases where you think this would be useful other than >> abetter connection with a server? > > Yes: continual gathering (aka continuous nomination) would benefit from > this. Last time we discussed continuous nomination (in Prague last year) it sounded to me that there were no arguments about what it was bringing on top of simple ICE restarts. It is my understanding that optimizing those (if at all necessary) was a more acceptable direction. So I don't think continuous nomination is a good argument here even if we keep waving it all over the place :) . >> If all that is changing is the connection with the server then it sounds >> to me like we should rather come up with a way to update the local side of >> the binding and not bother the remote agent with it. > > That would be TURN mobility, or some new equivalent ( > the TURN mobility draft has expired). Something like that yes. > That is an option that we'd like to > explore implementing, but it's much more work to standardize, implement, and > deploy (both on client and server). Whereas this is a simply mechanism that > is quick to standardize, implement, and deply, and it's useful for other > things (as mentioned above). On a first glance the whole ICE idea is very simple and easy to standardise, implement and deploy: gather and try everything. pick what works. I think 13 years after the initial idea was being floated on the IETF we know better. In other words: First I don't think it's that simple at all. I am particularly concerned about potential race conditions with the ICE state machine and the trickling itself. Same for interactions with aggressive nomination. Second, while we may be able to solve the above, I am worried that the increased complexity will not justify something that is a very limited solution to a more general problem. So we are setting the stage for redundancy and that's not something we need with ICE. Also, have you done any measurements or estimates on exactly what we are trying to optimize here? Some several hundred milliseconds of streaming over TCP rather than UDP? Emil >> Emil >> >> >> On Tuesday, 12 July 2016, Peter Thatcher wrote: >>> >>> I submitted draft-thatcher-ice-remove-candidate and would like to speak >>> about in my allotted time on the agenda when I will also be speaking about >>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination. >>> >>> It's a very simple draft. Basically it says you can "remove" candidates >>> just like trickle-ice allows you to add candidates. You could probably read >>> it in 3 minutes. Please do so: >>> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >>> >>> Thanks, >>> Peter (Chair hat off) >> >> >> >> -- >> sent from my mobile > > -- https://jitsi.org From nobody Wed Jul 13 14:18:52 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 2DFEA12D8F7 for ; Wed, 13 Jul 2016 14:18:51 -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 S2zibbFthkfm for ; Wed, 13 Jul 2016 14:18:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58AF012D8CD for ; Wed, 13 Jul 2016 14:18:46 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-4e-5786b03414b7 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B3.41.12516.430B6875; Wed, 13 Jul 2016 23:18:44 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 23:18:24 +0200 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin Thread-Index: AQHR3E7wTOX/sYPHwEWR8hqn03AC16AVBe6Q///jeACAAfEHgA== Date: Wed, 13 Jul 2016 21:18:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476A7EA1@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B476A0A52@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdVddkQ1u4wbwWbYtvF2otri1/zerA 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyHuy6xF6wQq5i8pU1TA2MR2S7GDk4JARMJFY3 CnQxcgKZYhIX7q1nA7GFBI4wSuzZy97FyAVkL2aUON55mRGknk3AQqL7nzZIjYiApsTkyc2s IGFmAUWJl3vVQExhgSSJww1ZEBXJEitXrmOEsJ0k2tcfYAexWQRUJdb/WABm8wr4Sty4uIkV YtNtRolHC++BNXAKBErs+3qeFcRmBDrt+6k1TCA2s4C4xK0n85kgThaQWLLnPDOELSrx8vE/ VghbSWLF9kuMEKdpSqzfpQ/Rqigxpfsh1F5BiZMzn7BMYBSbhWTqLISOWUg6ZiHpWMDIsopR tDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMGIObvmtu4Nx9WvHQ4wCHIxKPLwLGtvChVgTy4or cw8xSnAwK4nw7loHFOJNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbL xMEp1cBo5LgmvyXoyNnIR0U1z1NjLItPbg178XePVU2qyf5bi5wfJTseWFbZnnpFf9VGXuvZ b6o2bcnO2PZTT/NGBuu3TTci3zWazquf/+567vGi8r7Dyj9c+IN1jueJP11Y+N9u8sJT9Q7i r4NWNJyQ51u38eAP6cNGWmeFE1rkYjbs2bdyglT8nHQ/JZbijERDLeai4kQAlic1zpQCAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:18:51 -0000 SGksDQoNCj4+IFRoZSB0ZXh0IHNheXM6DQo+PsKgDQo+PiAgICAgICDigJxUaGUgUmVjZWl2aW5n IEFnZW50IE1BWSBrZWVwIHRoZSBleGlzdGluZyBjYW5kaWRhdGUgcGFpcnMgdGhhdCB1c2UNCj4+ wqDCoCDCoMKgwqDCoMKgwqB0aGUgUmVtb3ZlZCBDYW5kaWRhdGVzIGFuZCBiZWhhdmUgYXMgdGhv dWdoIHRoZSBSZW1vdmVkIENhbmRpZGF0ZXMNCj4+wqDCoCDCoMKgwqDCoMKgwqBoYWQgbm90IGJl ZW4gcmVtb3ZlZCBmb3IgdGhvc2UgY2FuZGlkYXRlIHBhaXJzLuKAnQ0KPj7CoA0KPj4gV2hhdCBp cyBtZWFudCBieSDigJxiZWhhdmXigJ0/IFNlbmRpbmcga2VlcC1hbGl2ZXM/IFNlbmRpbmcgbWVk aWE/IFRoYXQgd2lsbCBvYnZpb3VzbHkgbm90IHdvcmsuDQo+DQrigIs+IEJvdGgga2VlcC1hbGl2 ZXMgYW5kIG1lZGlhLsKgIElmIHRoZSByZW1vdmVkIGNhbmRpZGF0ZSBpcyBhIFRVUk4gY2FuZGlk YXRlIHRoYXQgdGhlIHJlbW92aW5nIGFnZW50IHdpc2hlcyB0byBkZWFsbG9jYXRlLCBpdCBtYXkg d29yayBmb3IgYSBzaG9ydCBwZXJpb2QgDQo+IG9mIHRpbWUgYmVmb3JlIHRoZSByZW1vdmluZyBh Z2VudCBhY3R1YWxseSA+IGRlYWxsb2NhdGVzIGl0LsKgIFNvIHRoZSBSZWNlaXZpbmcgQWdlbnQg bWF5IGNob29zZSB0byBrZWVwIHNlbmRpbmcgbWVkaWEgdW50aWwgaXQgZmluZHMgYSBkaWZmZXJl bnQgY2FuZGlkYXRlIHBhaXIgdG8gdXNlIGluc3RlYWQuIMKgIA0KPiBPciBpdCBtYXkgbm90LiDC oA0KwqANClRoZSByZW1vdmVkIGNhbmRpZGF0ZSBNQVkgd29yayBmb3IgYSBzaG9ydCBwZXJpb2Qs IGJ1dCB0aGVyZSBpcyBubyBndWFyYW50ZWUsIGlzIHRoZXJlPyBTbywgaWYgdGhlIHJlY2VpdmVy IHVuZGVyc3RhbmRzIHRoZSBtZWNoYW5pc20sIHNob3VsZG4ndCBpdCBzd2l0Y2ggdG8gYW5vdGhl ciBjYW5kaWRhdGUgYXMgc29vbiBhcyBpdCByZWNlaXZlcyB0aGUgaW5kaWNhdGlvbiB0aGF0IHRo ZSBjYW5kaWRhdGUgaGFzIGJlZW4gcmVtb3ZlZCAoaWYgdGhlIHJlbW92ZWQgY2FuZGlkYXRlIGlz IHRoZSBvbmUgY3VycmVudGx5IGJlaW5nIHVzZWQsIHRoYXQgaXMpLg0KwqANCg0KPj4gSSB0aGlu ayBpdCB3b3VsZCBiZSBnb29kIHRvIHN0YXRlIHdoZXRoZXIgdGhlIHVzYWdlL3N1cHBvcnQgb2Yg dGhlIG1lY2hhbmlzbSBtdXN0IGJlIG5lZ290aWF0ZWQgYmVmb3JlIGl0IGlzIHVzZWQuDQrigIs+ DQrigIs+IFNpZ25hbGluZyB0aGUgcmVtb3ZhbCBvZiBjYW5kaWRhdGUgbmV2ZXIgZG9lcyBhbnkg aGFybSwgc28gSSBkb24ndCBzZWUgYSBuZWVkIGluIG5lZ290aWF0aW5nIHRoYXQgeW91ciBnb2lu ZyB0byBzaWduYWwgcmVtb3ZhbCAobW9kdWxvIGEgc3BlY2lmaWMgc2lnbmFsaW5nIHByb3RvY29s IG5lZWRpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gc2VuZCANCj4gbmV3IG1lc3NhZ2VzIGlmIGl0 IGNob29zZXMgdG8gZG8gc28pLsKgIFRoZSByZWFsIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIHJl bW92aW5nIGFnZW50IG5lZWRzIHRvIGtub3cgd2hldGhlciB0aGUgcmVjZWl2aW5nIGFnZW50IGlz IGdvaW5nIHRvIGRvIGFueXRoaW5nIHdpdGggdGhlIHNpZ25hbC7CoCBBbmQgc2luY2UgZXZlcnl0 aGluZyB3aWxsIA0KPiBjb250aW51ZSB0byB3b3JrIGV2ZW4gaWYgdGhlIHJlY2VpdmluZyDigIth Z2VudCBpZ25vcmVzIHRoZSBzaWduYWwgKHNpbXBseSB3aXRoIHNvbWUgcGVyaGFwcyB3YXN0ZWQg cmVzb3VyY2VzKSwgdGhlbiBpdCdzIG5vdCBuZWNlc3NhcnkgZm9yIG5lZ290aWF0aW9uIGF0IGFs bC4NCg0KSWYgdGhlIHJlbW92ZWQgY2FuZGlkYXRlIGNhbm5vdCBiZSB1c2VkIG9uY2UgaXQgaGFz IGJlZW4gcmVtb3ZlZCwgYW5kIHRoZSByZW1vdGUgZW5kcG9pbnQga2VlcCBzZW5kaW5nIG1lZGlh IHRvd2FyZHMgaXQgKGUuZy4gYmVjYXVzZSB0aGUgcmVtb3RlIGVuZHBvaW50IGRvZXMgbm90IHVu ZGVyc3RhbmQgdGhlIHJlbW92YWwgaW5kaWNhdGlvbiksIHRoZXJlIHdpbGwgYmUgbWVkaWEgY2xp cHBpbmcgdW50aWwgdGhlIHJlbW90ZSBlbmRwb2ludCByZWFsaXplcyB0aGF0IHRoZSBjYW5kaWRh dGUgbm8gbG9uZ2VyIHdvcmtzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQrCoA0KwqANCsKg DQpGcm9tOiBJY2UgW21haWx0bzppY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBl dGVyIFRoYXRjaGVyDQpTZW50OiAxMiBKdWx5IDIwMTYgMTc6MzUNClRvOiBpY2VAaWV0Zi5vcmcN ClN1YmplY3Q6IFtJY2VdIEkgc3VibWl0dGVkIGFuZCBwbGFuIHRvIHByZXNlbnQgZHJhZnQtdGhh dGNoZXItaWNlLXJlbW92ZS1jYW5kaWRhdGUgaW4gQmVybGluDQrCoA0KSSBzdWJtaXR0ZWQgZHJh ZnQtdGhhdGNoZXItaWNlLXJlbW92ZS1jYW5kaWRhdGUgYW5kIHdvdWxkIGxpa2UgdG8gc3BlYWsg YWJvdXQgaW4gbXkgYWxsb3R0ZWQgdGltZSBvbiB0aGUgYWdlbmRhIHdoZW4gSSB3aWxsIGFsc28g YmUgc3BlYWtpbmcgYWJvdXTCoGRyYWZ0LXRoYXRjaGVyLWljZS1uZXR3b3JrLWNvc3QgYW5kIGRy YWZ0LXRoYXRjaGVyLWljZS1yZW5vbWluYXRpb24uDQrCoA0KSXQncyBhIHZlcnkgc2ltcGxlIGRy YWZ0LiBCYXNpY2FsbHkgaXQgc2F5cyB5b3UgY2FuICJyZW1vdmUiIGNhbmRpZGF0ZXMganVzdCBs aWtlIHRyaWNrbGUtaWNlIGFsbG93cyB5b3UgdG8gYWRkIGNhbmRpZGF0ZXMuIFlvdSBjb3VsZCBw cm9iYWJseSByZWFkIGl0IGluIDMgbWludXRlcy4gUGxlYXNlIGRvIHNvOg0KwqANCmh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LXRoYXRjaGVyLWljZS1yZW1vdmUtY2FuZGlkYXRlLTAwLnR4 dCANCsKgDQpUaGFua3MsDQpQZXRlciAoQ2hhaXIgaGF0IG9mZikNCg0K From nobody Wed Jul 13 15:07:31 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 7517F12D90A for ; Wed, 13 Jul 2016 15:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 NdQQiWnJg1Xx for ; Wed, 13 Jul 2016 15:07:27 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 18FC612D1B3 for ; Wed, 13 Jul 2016 15:07:27 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 82so57393235qko.3 for ; Wed, 13 Jul 2016 15:07:27 -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=7x8s2PECQQ3KgIuLvH9JydtqpaKVdsCFU/e20dagNlQ=; b=PfU4aaSXhLhOyrTY9TfEXpSrtXJ8H7axOZX4iQ+4MMTCboAbw3K0SntSniDpxvpz3+ +UZFa78Nx/KEUWEjON+EeH1s+g9cY+30kYNTv9L9MD8Web1gdz19dsUNOH1g6R32Qpf4 XHjKLikU5E6ZTuu5JorbSDZPCwBhfgGRkmBCR5CNMoPjSDl2W+ZUvN4K3oDZZkW2DbOx BO4+hvKETPt99US1lYtQbTGR6A3Wblv7IIacLCIF+Eoh9gwgpPH9Hk2OZPslELxYJ5xn V4Ckk4ki5/1tUtICSoaBnKuzAeJDhMI+khnspFnBs0pITtAT5Eu4UeIcnXo0BnZydtQe EyOA== 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=7x8s2PECQQ3KgIuLvH9JydtqpaKVdsCFU/e20dagNlQ=; b=ZNNSSFM1meUyhV8Xtn5c+N1Q23Wil/5JiC9XaQ+GS8WsC168nrLAlTptNu8olnrQnh 2gzsYyB5GHJMdf+sIzMRJc03XJtB+6mbxWI/boAlCclEnyRxs0JV19pPj1u4URO4IFaQ bh5VYgKrhisn9SPT2hgxzyL0K8zs5pxLdr/c9D6IxwqoVbgJzSoj+Qd+SIn1JuIyrOcO p3tqIg1ufUn7IfOxGw2+w1cm5n1mS9wgg8JlxoY2e/oN5KAyy0Hn5tWZToORDv6y/vQs BCk61hGESAX6/OG2Q9ZzavBLkvw0foCcPVfosEjDkOV54k7zRRnyTTqnYzM/k9R4YMP2 /jRQ== X-Gm-Message-State: ALyK8tLelNVmokiic+BYB9S4g0FmdzgHoAdwpuwASIcFL93nv76DyCrYDM0RAZwlrgTctp+eEsEMZW6wpv1i2uw+ X-Received: by 10.55.192.88 with SMTP id o85mr12958005qki.15.1468447646127; Wed, 13 Jul 2016 15:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Wed, 13 Jul 2016 15:06:46 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 13 Jul 2016 15:06:46 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11498e4051eafc05378b9c83 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 22:07:29 -0000 --001a11498e4051eafc05378b9c83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: > On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher > wrote: > > > > > > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: > >> > >> Are there any cases where you think this would be useful other than > >> abetter connection with a server? > > > > Yes: continual gathering (aka continuous nomination) would benefit from > > this. > > Last time we discussed continuous nomination (in Prague last year) it > sounded to me that there were no arguments about what it was bringing > on top of simple ICE restarts. It is my understanding that optimizing > those (if at all necessary) was a more acceptable direction. > > So I don't think continuous nomination is a good argument here even if > we keep waving it all over the place :) . > > =E2=80=8BContinual gathering is a separate topic that we can save for anoth= er day. > >> If all that is changing is the connection with the server then it soun= ds > >> to me like we should rather come up with a way to update the local sid= e > of > >> the binding and not bother the remote agent with it. > > > > That would be TURN mobility, or some new equivalent ( > > the TURN mobility draft has expired). > > Something like that yes. > > > That is an option that we'd like to > > explore implementing, but it's much more work to standardize, implement= , > and > > deploy (both on client and server). Whereas this is a simply mechanism > that > > is quick to standardize, implement, and deply, and it's useful for othe= r > > things (as mentioned above). > > On a first glance the whole ICE idea is very simple and easy to > standardise, implement and deploy: gather and try everything. pick > what works. > > I think 13 years after the initial idea was being floated on the IETF > we know better. > > In other words: > > First I don't think it's that simple at all. I am particularly > concerned about potential race conditions with the ICE state machine > and the trickling itself. Same for interactions with aggressive > nomination. > > Second, while we may be able to solve the above, I am worried that the > increased complexity will not justify something that is a very limited > solution to a more general problem. So we are setting the stage for > redundancy and that's not something we need with ICE. > > =E2=80=8BIt sounds like you are making the argument that ICE has reached so= me kind of "peak complexity" and can no longer be changed because it's already too complex. Is that what you're claiming? > Also, have you done any measurements or estimates on exactly what we > are trying to optimize here? Some several hundred milliseconds of > streaming over TCP rather than UDP? > =E2=80=8BI don't know what this has to do with TCP vs. UDP.=E2=80=8B The real world problem here is that if you have two network interfaces (WiFi and Cell) and =E2=80=8Bipv4 and ipv6 and 2 TURN servers and try to co= nnect to each over TCP and UDP, you end up with 2 x 2 x 2 x 2 =3D 16 TURN candidates (at least; this ignores TCP w/ TLS). Then both sides do that, and you have 16 * 16 =3D 256 TURN-TURN candidate pairs. That's a lot. So how do you avoid that problem? TURN mobility is one option, and I'd like to see TURN mobility happen. But candidate removal is also an option, and it's a lot more simple. > > Emil > > > >> Emil > >> > >> > >> On Tuesday, 12 July 2016, Peter Thatcher wrote: > >>> > >>> I submitted draft-thatcher-ice-remove-candidate and would like to spe= ak > >>> about in my allotted time on the agenda when I will also be speaking > about > >>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination. > >>> > >>> It's a very simple draft. Basically it says you can "remove" candidat= es > >>> just like trickle-ice allows you to add candidates. You could probabl= y > read > >>> it in 3 minutes. Please do so: > >>> > >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > >>> > >>> Thanks, > >>> Peter (Chair hat off) > >> > >> > >> > >> -- > >> sent from my mobile > > > > > > > > -- > https://jitsi.org > --001a11498e4051eafc05378b9c83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov = <emcho@jitsi.org> wrote:
On W= ed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <pthatcher@google.com> wrote:
>
>
> On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Are there any cases where you think this would be useful other tha= n
>> abetter connection with a server?
>
> Yes: continual gathering (aka continuous nomination) would benefit fro= m
> this.

Last time we discussed continuous nomination (in Prague last year) i= t
sounded to me that there were no arguments about what it was bringing
on top of simple ICE restarts. It is my understanding that optimizing
those (if at all necessary) was a more acceptable direction.

So I don't think continuous nomination is a good argument here even if<= br> we keep waving it all over the place :) .


=E2=80=8BCo= ntinual gathering is a separate topic that we can save for another day. =C2= =A0

=C2=A0
>> If all that is changing is the connection with the server then it = sounds
>> to me like we should rather come up with a way to update the local= side of
>> the binding and not bother the remote agent with it.
>
> That would be TURN mobility, or some new equivalent (
> the TURN mobility draft has expired).

Something like that yes.

> That is an option that we'd like to
> explore implementing, but it's much more work to standardize, impl= ement, and
> deploy (both on client and server).=C2=A0 Whereas this is a simply mec= hanism that
> is quick to standardize, implement, and deply, and it's useful for= other
> things (as mentioned above).

On a first glance the whole ICE idea is very simple and easy to
standardise, implement and deploy: gather and try everything. pick
what works.

I think 13 years after the initial idea was being floated on the IETF
we know better.

In other words:

First I don't think it's that simple at all. I am particularly
concerned about potential race conditions with the ICE state machine
and the trickling itself. Same for interactions with aggressive
nomination.

Second, while we may be able to solve the above, I am worried that the
increased complexity will not justify something that is a very limited
solution to a more general problem. So we are setting the stage for
redundancy and that's not something we need with ICE.


=E2=80=8BIt sounds like you are making the argument t= hat ICE has reached some kind of "peak complexity" and can no lon= ger be changed because it's already too complex.=C2=A0 Is that what you= 're claiming?


=C2=A0
Also, have you done any measurements or estimates on exactly what we
are trying to optimize here? Some several hundred milliseconds of
streaming over TCP rather than UDP?

= =E2=80=8BI don't know what this has to do with TCP vs. UDP.=E2=80=8B
The real world problem here is that if you have two ne= twork interfaces (WiFi and Cell) and =E2=80=8Bipv4 and ipv6 and 2 TURN serv= ers and try to connect to each over TCP and UDP, you end up with 2 x 2 x 2 = x 2 =3D 16 TURN candidates (at least; this ignores TCP w/ TLS).=C2=A0 Then = both sides do that, and you have 16 * 16 =3D 256 TURN-TURN candidate pairs.= =C2=A0 That's a lot.=C2=A0 So how do you avoid that problem? =C2=A0 TUR= N mobility is one option, and I'd like to see TURN mobility happen.=C2= =A0 But candidate removal is also an option, and it's a lot more simple= .

=C2=A0

Emil


>> Emil
>>
>>
>> On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
>>>
>>> I submitted draft-thatcher-ice-remove-candidate and would like= to speak
>>> about in my allotted time on the agenda when I will also be sp= eaking about
>>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomin= ation.
>>>
>>> It's a very simple draft. Basically it says you can "= remove" candidates
>>> just like trickle-ice allows you to add candidates. You could = probably read
>>> it in 3 minutes. Please do so:
>>>
>>> https://www.ietf.org/= id/draft-thatcher-ice-remove-candidate-00.txt
>>>
>>> Thanks,
>>> Peter (Chair hat off)
>>
>>
>>
>> --
>> sent from my mobile
>
>



--
https://= jitsi.org

--001a11498e4051eafc05378b9c83-- From nobody Wed Jul 13 16:21: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 5C3D112D9CA for ; Wed, 13 Jul 2016 16:21:37 -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 bY3VCNouZkLJ for ; Wed, 13 Jul 2016 16:21:35 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 CDBA712D0CC for ; Wed, 13 Jul 2016 16:21:34 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id x130so87371342vkc.0 for ; Wed, 13 Jul 2016 16:21: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=0jia4Ukl5nXZy/mSo0snQZfTdb082gb2IlHGFuxTwyQ=; b=stOxX3nsamragNYZJgNsxNqtTylZRWHI+gIX54g212vLr9KmKhG3kTGiIMo62vsPcI PWvqyTlXH84PlpAK67hOqFMvZqsDo72SUF/l48c1eWPZyB97XUCwfs9OtgjBuUvrVvQK kyMw0qs8YS5tat/0tDrwIMauokIEUyRqSzzX6Ju+R65KWyo3hvoW1iUvz4u5u8tHFwNB XQgFKz0ZBfC2oVl9/EonESHuaZQOvBfAUPMzWZQLe400/IdiIs4A4I6MC8PX/Yf4H4Xp 2pIgDGGN0m0bjo5rHmn3LdynKN18DM6941ezzu0/sE5X+kLK2p4s/A09lzlqel0K0hN1 1hTw== 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=0jia4Ukl5nXZy/mSo0snQZfTdb082gb2IlHGFuxTwyQ=; b=OjMKJ2IcvYnMNoZ0uf3jvpC+l6FdE24lDyV1c52GMHGK2JNOzudTUZKl1lto1DSZep BCfqhRBhgkbAw/cWszE3bxZ+Guo7VIzY+2i2j9eUoShEA0aSY0Oa4Y9ipjkdMBY7qAur ANi5ceefG5pAhi6ooWUNGpk9Jz3oT7Vonxiz4p66oRfHAaA0ozx8rhJRA9cFfBG3VPi0 tK60J4ByCI/HV7FBqXIFwWIwXdWIjt54dWsFiQyPJDrcZtMKc3Um28MECApj4gxeRIwv uu87rlyCacTe7+fURBMcHC6BwsH4kfsLp7oo/k77o85qyQHQoZbUz+suNIpa4lLVR7CO mFHQ== X-Gm-Message-State: ALyK8tLBKt9PvogQVGLKlQGr1WTVn1++QaqeVGyTay4VSEtunJU6axeNWsxfQkWFmGWizClpZ3IJ/OIjZU6SrA== X-Received: by 10.31.147.197 with SMTP id v188mr5285897vkd.103.1468452093904; Wed, 13 Jul 2016 16:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.100 with HTTP; Wed, 13 Jul 2016 16:21:14 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Wed, 13 Jul 2016 16:21:14 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a1141d5d06d4df905378ca537 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 23:21:37 -0000 --001a1141d5d06d4df905378ca537 Content-Type: text/plain; charset=UTF-8 Emil said: "So I don't think continuous nomination is a good argument here even if we keep waving it all over the place :) ." [BA] It has always seemed to me that continuous nomination is not a "thing" per se, but an inextricable part of Trickle ICE in that it is an implementation decision as to when the gathering process is considered complete. So an implementation can choose to provide a local "end-of-candidates" indication once it has gathered on existing interfaces, or it could delay some arbitrary (perhaps infinite) time to allow new interfaces to come up or for interfaces to go down. If there are considerations relating to this that an implementation needs to consider (such as implications for unfreezing) they are currently not being articulated in the Trickle ICE specification. So either the specification is negligent in this regard, or "continuous nomination" is an optional capability that implementations can choose to support (or not), with no interoperability implications. On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: > On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher > wrote: > > > > > > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: > >> > >> Are there any cases where you think this would be useful other than > >> abetter connection with a server? > > > > Yes: continual gathering (aka continuous nomination) would benefit from > > this. > > Last time we discussed continuous nomination (in Prague last year) it > sounded to me that there were no arguments about what it was bringing > on top of simple ICE restarts. It is my understanding that optimizing > those (if at all necessary) was a more acceptable direction. > > So I don't think continuous nomination is a good argument here even if > we keep waving it all over the place :) . > > >> If all that is changing is the connection with the server then it sounds > >> to me like we should rather come up with a way to update the local side > of > >> the binding and not bother the remote agent with it. > > > > That would be TURN mobility, or some new equivalent ( > > the TURN mobility draft has expired). > > Something like that yes. > > > That is an option that we'd like to > > explore implementing, but it's much more work to standardize, implement, > and > > deploy (both on client and server). Whereas this is a simply mechanism > that > > is quick to standardize, implement, and deply, and it's useful for other > > things (as mentioned above). > > On a first glance the whole ICE idea is very simple and easy to > standardise, implement and deploy: gather and try everything. pick > what works. > > I think 13 years after the initial idea was being floated on the IETF > we know better. > > In other words: > > First I don't think it's that simple at all. I am particularly > concerned about potential race conditions with the ICE state machine > and the trickling itself. Same for interactions with aggressive > nomination. > > Second, while we may be able to solve the above, I am worried that the > increased complexity will not justify something that is a very limited > solution to a more general problem. So we are setting the stage for > redundancy and that's not something we need with ICE. > > Also, have you done any measurements or estimates on exactly what we > are trying to optimize here? Some several hundred milliseconds of > streaming over TCP rather than UDP? > > Emil > > > >> Emil > >> > >> > >> On Tuesday, 12 July 2016, Peter Thatcher wrote: > >>> > >>> I submitted draft-thatcher-ice-remove-candidate and would like to speak > >>> about in my allotted time on the agenda when I will also be speaking > about > >>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination. > >>> > >>> It's a very simple draft. Basically it says you can "remove" candidates > >>> just like trickle-ice allows you to add candidates. You could probably > read > >>> it in 3 minutes. Please do so: > >>> > >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > >>> > >>> Thanks, > >>> Peter (Chair hat off) > >> > >> > >> > >> -- > >> sent from my mobile > > > > > > > > -- > https://jitsi.org > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a1141d5d06d4df905378ca537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Emil said:=C2=A0

"So I don't think continuous nomination is a good argum= ent here even if
we keep = waving it all over the place :) ."

[BA= ] It has always seemed to me that continuous nomination is not a "thin= g" per se, but an inextricable part of Trickle ICE in that it is an im= plementation decision as to when the gathering process is considered comple= te.=C2=A0 So an implementation can choose to provide a local "end-of-c= andidates" indication once it has gathered on existing interfaces, or = it could delay some arbitrary (perhaps infinite) time to allow new interfac= es to come up or for interfaces to go down.=C2=A0

= If there are considerations relating to this that an implementation needs t= o consider (such as implications for unfreezing) they are currently not bei= ng articulated in the Trickle ICE specification. So either the specificatio= n is negligent in this regard, or "continuous nomination" is an o= ptional capability that implementations can choose to support (or not), wit= h no interoperability implications.=C2=A0

On Wed, Jul 13, 2016 at 12:45 PM, Emil = Ivov <emcho@jitsi.org> wrote:
On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <pthatcher@google.com> wrote: >
>
> On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Are there any cases where you think this would be useful other tha= n
>> abetter connection with a server?
>
> Yes: continual gathering (aka continuous nomination) would benefit fro= m
> this.

Last time we discussed continuous nomination (in Prague last year) i= t
sounded to me that there were no arguments about what it was bringing
on top of simple ICE restarts. It is my understanding that optimizing
those (if at all necessary) was a more acceptable direction.

So I don't think continuous nomination is a good argument here even if<= br> we keep waving it all over the place :) .

>> If all that is changing is the connection with the server then it = sounds
>> to me like we should rather come up with a way to update the local= side of
>> the binding and not bother the remote agent with it.
>
> That would be TURN mobility, or some new equivalent (
> the TURN mobility draft has expired).

Something like that yes.

> That is an option that we'd like to
> explore implementing, but it's much more work to standardize, impl= ement, and
> deploy (both on client and server).=C2=A0 Whereas this is a simply mec= hanism that
> is quick to standardize, implement, and deply, and it's useful for= other
> things (as mentioned above).

On a first glance the whole ICE idea is very simple and easy to
standardise, implement and deploy: gather and try everything. pick
what works.

I think 13 years after the initial idea was being floated on the IETF
we know better.

In other words:

First I don't think it's that simple at all. I am particularly
concerned about potential race conditions with the ICE state machine
and the trickling itself. Same for interactions with aggressive
nomination.

Second, while we may be able to solve the above, I am worried that the
increased complexity will not justify something that is a very limited
solution to a more general problem. So we are setting the stage for
redundancy and that's not something we need with ICE.

Also, have you done any measurements or estimates on exactly what we
are trying to optimize here? Some several hundred milliseconds of
streaming over TCP rather than UDP?

Emil


>> Emil
>>
>>
>> On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
>>>
>>> I submitted draft-thatcher-ice-remove-candidate and would like= to speak
>>> about in my allotted time on the agenda when I will also be sp= eaking about
>>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomin= ation.
>>>
>>> It's a very simple draft. Basically it says you can "= remove" candidates
>>> just like trickle-ice allows you to add candidates. You could = probably read
>>> it in 3 minutes. Please do so:
>>>
>>> https://www.ietf.org/= id/draft-thatcher-ice-remove-candidate-00.txt
>>>
>>> Thanks,
>>> Peter (Chair hat off)
>>
>>
>>
>> --
>> sent from my mobile
>
>



--
https://= jitsi.org

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

--001a1141d5d06d4df905378ca537-- From nobody Wed Jul 13 23:26:15 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 5D08912B077 for ; Wed, 13 Jul 2016 23:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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=-1.287, 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 9Y7GR-Nzac0I for ; Wed, 13 Jul 2016 23:26:12 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED7312D09D for ; Wed, 13 Jul 2016 23:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8807; q=dns/txt; s=iport; t=1468477571; x=1469687171; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SdxVuvbv5dnIrXymJdzz60OH9YPAw1A0ELTb/hP1ajc=; b=NSw1J5cpvf2PLQYM6iU5Utq1sU6sKv2ZX7v9vzY8LZSMCx1E1r5UZ44V iszPatx0VFzP48NPRZxfVwTQTv9IxBCpLLzrqF9j5VNNda/a2tKBxYHWk JQ+llATadJgLROeAJRao1e1loel96y8y22/oDPqSA2F4DHMv4U1iRoJGv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAgBXL4dX/4gNJK1bgz5WfLNkhQSBe?= =?us-ascii?q?yKFdwKBNDgUAQEBAQEBAWUnhF0BBQEBbAsQAgEIDjEHJwsUEQIEDgWIMA7ASwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqBeIJVhCuDQoIvBYgUhyeEJIU+AYYRi?= =?us-ascii?q?EeBa4RZgy6FPYZciTsBHjaCPIE1bgGJNgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,361,1464652800"; d="scan'208,217";a="296768604" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2016 06:26:10 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6E6QAiX015957 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jul 2016 06:26:10 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; Thu, 14 Jul 2016 02:26:09 -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; Thu, 14 Jul 2016 02:26:09 -0400 From: "Pal Martinsen (palmarti)" To: Peter Thatcher Thread-Topic: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin Thread-Index: AQHR3E8VGqxhxozpfkaQeWQoJWeayaAVUtmAgAGvTQCAAHZ0Hg== Date: Thu, 14 Jul 2016 06:26:09 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_A0F44E41F6B6478C875DE1C76842BEFAciscocom_" MIME-Version: 1.0 Archived-At: Cc: Emil Ivov , "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin 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, 14 Jul 2016 06:26:14 -0000 --_000_A0F44E41F6B6478C875DE1C76842BEFAciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -.- P?l-Erik On 13 Jul 2016, at 21:23, Peter Thatcher > wrote: On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov > wrote: Are there any cases where you think this would be useful other than abetter= connection with a server? ?Yes: continual gathering (aka continuous nomination) would benefit from th= is.? If all that is changing is the connection with the server then it sounds to= me like we should rather come up with a way to update the local side of th= e binding and not bother the remote agent with it. ?That would be TURN mobility, or some new equivalent (? ? ?the TURN mobility draft has expired). https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ Actually the TRAM WG have asked IESG to publish it. That is an option that we'd like to explore implementing, but it's much mor= e work to standardize, implement, and deploy (both on client and server). = Whereas this is a simply mechanism that is quick to standardize, implement,= and deply, and it's useful for other things (as mentioned above). Agree on that as well. Emil On Tuesday, 12 July 2016, Peter Thatcher > wrote: I submitted draft-thatcher-ice-remove-candidate and would like to speak abo= ut in my allotted time on the agenda when I will also be speaking about dra= ft-thatcher-ice-network-cost and draft-thatcher-ice-renomination. It's a very simple draft. Basically it says you can "remove" candidates jus= t like trickle-ice allows you to add candidates. You could probably read it= in 3 minutes. Please do so: https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt Thanks, Peter (Chair hat off) -- sent from my mobile _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_A0F44E41F6B6478C875DE1C76842BEFAciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
-.-
Pål-Erik

On 13 Jul 2016, at 21:23, Peter Thatcher <pthatcher@google.com> wrote:


https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/

Actually the TRAM WG have asked IESG to publish it.


That is an option that we'd like to explore implementing, but it's much mor= e work to standardize, implement, and deploy (both on client and server).&n= bsp; Whereas this is a simply mechanism that is quick to standardize, imple= ment, and deply, and it's useful for other things (as mentioned above).



Agree on that as well.


 

Emil 


On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
I submitted draft-tha= tcher-ice-remove-candidate and would like to speak about in my allotted tim= e on the agenda when I will also be speaking about draft-thatc= her-ice-network-cost and draft-thatcher-ice-renomination.

It's a very s= imple draft. Basically it says you can "remove" candidates just l= ike trickle-ice allows you to add candidates. You could probably read it in 3 minutes. Please do so:


Thanks,
Peter (Chair hat off)


--
sent from my mobile

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.iet= f.org/mailman/listinfo/ice
--_000_A0F44E41F6B6478C875DE1C76842BEFAciscocom_-- From nobody Thu Jul 14 08:51: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 422C812D0F9 for ; Thu, 14 Jul 2016 08:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 xrzZzEaBdrJI for ; Thu, 14 Jul 2016 08:51:21 -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 66F7E12D0BE for ; Thu, 14 Jul 2016 08:51:21 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 82so76244601qko.3 for ; Thu, 14 Jul 2016 08:51:21 -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=sy13gJnzKlLyZE7RJQLJ6YZjm32K5P8G0yFwf4S/l0g=; b=cJ6Iabx0EBdL8jnUfFsYG0Mtd/M7HjL6fO8MgLnlQmIjHbF0oRJ/i669Bq44qqrKlE uMYtJBmsmP7GUXhoL9lZ0D6QZ5HOtlcyr39Tx7pI+GoiaANvFKqBywOuuaTQuITVokzS BxUygm0PgUXu0z/KQjb3Auhy3bw7iLV19xp5my1X5qOy+Ctofo2EhquwHmNMpcRMMM8K 2eAh8CJ3AuilPFuxbjmiukmO9ptCgQH+O1DE+WXIOTEKlqGzGc3KW3KMRrFStDZChrOP /9Ar6rR/RiuGv+fXbc2LcQ2Rr6lHr+rU+0TsHhxOtLd9INh/GFljEpK3tol/M9AJ7R86 VR/g== 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=sy13gJnzKlLyZE7RJQLJ6YZjm32K5P8G0yFwf4S/l0g=; b=i2SW4JKsGUfEAO1pn2hWIc0O4qLinpHj7AodgZKLq6I86sRrhGqOMGrGaFFl8TmfsU DRqGD66wvDFtJqW79hJ7r0fP7AxC4eomLWXWNc2s9nHV97NHlKSKJn5Oxe1kCq4KQb8l fzKtodXDeFsPM6gZSzlw1Y4sJ6GfiEY/lbF42MAs5U7z0knlPkFbd6dL/6gCCq+5/jyJ ALR66Zej5B7aMd7TA7XeGJnip3mf8gJi8zNI2gbu+P28zPQfJ7kckN5/J+XsPz7YWk4/ juwb5GHA4AufazSy31ztAdodzP0eqtmFsutbI1UYiNpehMu1Scoh/l0Duy+l5NogRZCy pcbw== X-Gm-Message-State: ALyK8tIkrZAYIIZQ/49hmMrizGAkFfQqTe/LOAPbv+6nLAfcQHDu16pHBmkNgfH7ZMizNUyih7BK9BBPjx4Vqpn4 X-Received: by 10.55.4.133 with SMTP id 127mr18898117qke.207.1468511480357; Thu, 14 Jul 2016 08:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Thu, 14 Jul 2016 08:50:40 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 14 Jul 2016 08:50:40 -0700 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a114c950c22fbd505379a79de Archived-At: Cc: Emil Ivov , "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin 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, 14 Jul 2016 15:51:23 -0000 --001a114c950c22fbd505379a79de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2016 at 11:26 PM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > -.- > P=C3=A5l-Erik > > On 13 Jul 2016, at 21:23, Peter Thatcher wrote: > > > > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: > >> Are there any cases where you think this would be useful other than >> abetter connection with a server? >> >> > =E2=80=8BYes: continual gathering (aka continuous nomination) would benef= it from > this.=E2=80=8B > > > > >> If all that is changing is the connection with the server then it sounds >> to me like we should rather come up with a way to update the local side = of >> the binding and not bother the remote agent with it. >> > > =E2=80=8BThat would be TURN mobility, or some new equivalent (=E2=80=8B > =E2=80=8B > =E2=80=8Bthe TURN mobility draft has expired). > > > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ > > Actually the TRAM WG have asked IESG to publish it. > =E2=80=8BOh, well that's good news. I had no idea it had progressed. Than= ks for updating me. > > > That is an option that we'd like to explore implementing, but it's much > more work to standardize, implement, and deploy (both on client and > server). Whereas this is a simply mechanism that is quick to standardize= , > implement, and deply, and it's useful for other things (as mentioned abov= e). > > > > Agree on that as well. > > > > >> >> Emil >> >> >> On Tuesday, 12 July 2016, Peter Thatcher wrote: >> >>> I submitted draft-thatcher-ice-remove-candidate and would like to speak >>> about in my allotted time on the agenda when I will also be speaking ab= out draft-thatcher-ice-network-cost >>> and draft-thatcher-ice-renomination. >>> >>> It's a very simple draft. Basically it says you can "remove" candidates >>> just like trickle-ice allows you to add candidates. You could probably >>> read it in 3 minutes. Please do so: >>> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >>> >>> Thanks, >>> Peter (Chair hat off) >>> >> >> >> -- >> sent from my mobile >> > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a114c950c22fbd505379a79de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 13, 2016 at 11:26 PM, Pal Martinsen (palmarti) <= palmarti@cisco.com> wrote:
-.-
P=C3=A5l-Erik

On 13 Jul 2016, at 21:23, Peter Thatcher <pthatcher@google.com> wrote:


https://datatracker.ietf.org/doc/draft-ietf-tram-= turn-mobility/

Actually the TRAM WG have asked IESG to publish it.

=E2=80=8BOh, well that's good news.=C2=A0 = I had no idea it had progressed.=C2=A0 Thanks for updating me.

=C2=A0


That is an option that we'd like to explore implementing, but it's = much more work to standardize, implement, and deploy (both on client and se= rver).=C2=A0 Whereas this is a simply mechanism that is quick to standardiz= e, implement, and deply, and it's useful for other things (as mentioned above).



 Agree on that as well.


=C2=A0

Emil=C2=A0


On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
I submitted draft-tha= tcher-ice-remove-candidate and would like to speak about in my allotted tim= e on the agenda when I will also be speaking about=C2=A0draft-thatc= her-ice-network-cost and draft-thatcher-ice-renomination.

It's a ve= ry simple draft. Basically it says you can "remove" candidates ju= st like trickle-ice allows you to add candidates. You could probably read it in 3 minutes. Please do so:


Thanks,
Peter (Chair hat off)


--
sent from my mobile

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

--001a114c950c22fbd505379a79de-- From nobody Thu Jul 14 09:19:27 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1098912D0E9 for ; Thu, 14 Jul 2016 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-fAzUewHvdp for ; Thu, 14 Jul 2016 09:19:24 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6AB12D0AD for ; Thu, 14 Jul 2016 09:19:24 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id i12so76781496ywa.1 for ; Thu, 14 Jul 2016 09:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zCh3BNEaIu6hLn4n5uT9ldhEJlSsrwuW45cgDi+BMaU=; b=VLLDhFWJpk5dg387/VHRmPxPNBN69PLu8M+aBEafSYRB+dyx8mn1eEV7EYCtBrqUwz 4AATEqO+bCkjdI+YFNaFytCBiqzKXEnd55on6U5b7pLoVySOwg0lDDa1RsahGEBptQ9X ydXHE6ax4R/3ujspoVZ30vM7hLOsVwhI2zvmh3JxpIcAjyhQKvWezvBapc6kkbdl9OSb SSVR1VWXF8x7LxSKVR5xfhFxs9vIMw7jmcJi4Vg0CuzM1MB45fruSYOwColsvdtu7QCv PNhOyaOKSjjEx7WpSyH949F9D5CKGPTC3+xzVfE37nL+OzntCoMLT6roDcuFWc6rh3z3 Pl2w== 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=zCh3BNEaIu6hLn4n5uT9ldhEJlSsrwuW45cgDi+BMaU=; b=YX8pRCizo0Ia+qMLyLt0ugDzMplFf5Ln9GuHD7biPpUuLMrbZOwlBl0A+2CawFIPAl WKqXb0o/nVSvH1gsZo77jM03d5GiGw80LIFmvyrS82PzKcQUw+YtQjVuZBR5fnpDPmhT ARwM82T7PojYmgE+skLnXu8oVewhHlAdOm9gso1Ev3v80ttQuw88qbDDX284erlAC3OT rlktJWAUOFq4O6C7sGPnwwuPZW70JkoIf/I4lvSx969Y1dTWmmPG6ICaRXukHP/Yrn4n 6dpofnyOwzP1KLjAwUanYyNhHVsJUPq3QrwYimIyxLv8pQY5eHHc5jgtbOuz6DEG1KGc LnnA== X-Gm-Message-State: ALyK8tJ1Cil+jr+1lZAZIjsVhs9UbuAyMZ3TFWrh+MMQa0pZf7rciiKMZhhXXdrwCytftw== X-Received: by 10.37.36.16 with SMTP id k16mr43751ybk.37.1468513163187; Thu, 14 Jul 2016 09:19:23 -0700 (PDT) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com. [209.85.161.180]) by smtp.gmail.com with ESMTPSA id e197sm1228419ywa.16.2016.07.14.09.19.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 09:19:22 -0700 (PDT) Received: by mail-yw0-f180.google.com with SMTP id v186so15653940ywd.0 for ; Thu, 14 Jul 2016 09:19:22 -0700 (PDT) X-Received: by 10.129.91.7 with SMTP id p7mr11902827ywb.115.1468513162192; Thu, 14 Jul 2016 09:19:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Thu, 14 Jul 2016 09:19:02 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 14 Jul 2016 19:19:02 +0300 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin 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, 14 Jul 2016 16:19:26 -0000 On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher wrote: > > > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher >> wrote: >> > >> > >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: >> >> >> >> Are there any cases where you think this would be useful other than >> >> abetter connection with a server? >> > >> > Yes: continual gathering (aka continuous nomination) would benefit from >> > this. >> >> Last time we discussed continuous nomination (in Prague last year) it >> sounded to me that there were no arguments about what it was bringing >> on top of simple ICE restarts. It is my understanding that optimizing >> those (if at all necessary) was a more acceptable direction. >> >> So I don't think continuous nomination is a good argument here even if >> we keep waving it all over the place :) . >> > > Continual gathering is a separate topic that we can save for another day. > >> >> >> If all that is changing is the connection with the server then it >> >> sounds >> >> to me like we should rather come up with a way to update the local side >> >> of >> >> the binding and not bother the remote agent with it. >> > >> > That would be TURN mobility, or some new equivalent ( >> > the TURN mobility draft has expired). >> >> Something like that yes. >> >> > That is an option that we'd like to >> > explore implementing, but it's much more work to standardize, implement, >> > and >> > deploy (both on client and server). Whereas this is a simply mechanism >> > that >> > is quick to standardize, implement, and deply, and it's useful for other >> > things (as mentioned above). >> >> On a first glance the whole ICE idea is very simple and easy to >> standardise, implement and deploy: gather and try everything. pick >> what works. >> >> >> I think 13 years after the initial idea was being floated on the IETF >> we know better. >> >> In other words: >> >> First I don't think it's that simple at all. I am particularly >> concerned about potential race conditions with the ICE state machine >> and the trickling itself. Same for interactions with aggressive >> nomination. >> >> Second, while we may be able to solve the above, I am worried that the >> increased complexity will not justify something that is a very limited >> solution to a more general problem. So we are setting the stage for >> redundancy and that's not something we need with ICE. >> > > It sounds like you are making the argument that ICE has reached some kind of > "peak complexity" and can no longer be changed because it's already too > complex. Is that what you're claiming? And question the existence of this wonderful working group? No, of course not ;) What I am claiming is that ICE is too complex for *frivolous* updates that are likely to be superseded by newer more complete solutions like the one you mentioned in TRAM. >> Also, have you done any measurements or estimates on exactly what we >> are trying to optimize here? Some several hundred milliseconds of >> streaming over TCP rather than UDP? > > > I don't know what this has to do with TCP vs. UDP. > > The real world problem here is that if you have two network interfaces (WiFi > and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to each > over TCP and UDP, you end up with 2 x 2 x 2 x 2 = 16 TURN candidates (at > least; this ignores TCP w/ TLS). Then both sides do that, and you have 16 * > 16 = 256 TURN-TURN candidate pairs. That's a lot. Except that it's not (necessarily) 256. > So how do you avoid that problem? Well to begin with you can simply apply the same logic as the one you propose in your draft, but rather than doing it after sending candidates, you apply it before. That is, you start by sending your "better" candidates (the ones you wouldn't "deallocate" otherwise) and you only send your less desirable ones if you fail to obtain the prime candidates. This means that you would only end up with 256 if all of your prime candidates failed during gathering but then suddenly started working. Not a great likelihood for that to happen. On average you'll probably have one or two that leak out (and when that happens it might actually be an indication that your connection is better there). So, to be clear, I do agree that ending up with 256 candidates would be a problem, especially given the 100 pairs MAX constraint 5245. What bothers me with this draft is not the problem though: it's that the solution doesn't appear well thought out. For example: depending on your timing it is not at all clear that you will be able to remove candidates before you hit 100 pairs, before they start stun transactions or before you've already wasted the time you want to save. In other words, this whole thing may well turn out to be useless half the time. That's the sort of extra complexity we don't need with ICE. > TURN mobility is one option, and I'd like to see TURN mobility > happen. But candidate removal is also an option, and it's a lot more > simple. Again, I am not at all convinced of its purported simplicity and even less its efficiency. Emil >> >> Emil >> >> >> >> Emil >> >> >> >> >> >> On Tuesday, 12 July 2016, Peter Thatcher wrote: >> >>> >> >>> I submitted draft-thatcher-ice-remove-candidate and would like to >> >>> speak >> >>> about in my allotted time on the agenda when I will also be speaking >> >>> about >> >>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination. >> >>> >> >>> It's a very simple draft. Basically it says you can "remove" >> >>> candidates >> >>> just like trickle-ice allows you to add candidates. You could probably >> >>> read >> >>> it in 3 minutes. Please do so: >> >>> >> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >> >>> >> >>> Thanks, >> >>> Peter (Chair hat off) >> >> >> >> >> >> >> >> -- >> >> sent from my mobile >> > >> > >> >> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Sat Jul 16 07:21:10 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 8FAE112D5C7 for ; Sat, 16 Jul 2016 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 QAYUgmpoL-sZ for ; Sat, 16 Jul 2016 07:21:06 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 4390012D091 for ; Sat, 16 Jul 2016 07:21:06 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id w38so73017485qtb.0 for ; Sat, 16 Jul 2016 07:21:06 -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=gt/l4A9MPqDLM6TWYKD4DOuQoJ0PROkJTTrYLVO1T10=; b=GXbK6q1YiVKHVDdEKB27eo2+A2wRP7g77uzlhHtqTqhhzNH7C/0vbyrpCaOYocQNbO krshMjLchyOzQsAoQft1ng8MFXGVX3OYHLnjy09xiyW29JYOpx5kTzuAzf5I/vZC5nx0 FifXuLNH9G2pepW5r7Pg2vNzoc9pOLy0SL9cNXSn8aOme3UFGpzU1gYPP67qpH/9JAet zfcRi9rkGgTaOa/Nd1DyZiORLYHnZzccizZOdpfo5NYWB2wug6E6gZAHxxSyB4q77/zZ MyxnvTToDuBebHYXlRPXF3MsJpHz20WMW8nDP1iyvNa1+S9NAoXD9BMXw4U66LGeI+2b V6UA== 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=gt/l4A9MPqDLM6TWYKD4DOuQoJ0PROkJTTrYLVO1T10=; b=Ufk0s9ZklSz4/5iAsdoKBaTJr4pUkBLvlIb0vZSe3k6+O9xRhqw/v6mPDKaL/fWOKs YuFc4wg5lrqEO+DepJVMU3fDTsYFJrOqTdi1xZ7qW7yAHnGbFiYTBZeKORrXOxUMTX8N 3BToitmbb9QsDJKIj6BexCBhmif9GBSSbw5TJHw14Msk1Rl5oPLa2mIN0ziklyoh5iE4 eaW3hd+UceyzeYlr3ld0eAT7V8Gi6HME79jqomf2G04j/Yr/77ZHHnAdZhIX4ETi94M4 gFfWLC0MpvnyufAQORfM8xrOLjYhkP50VMBRi0Z4OFWwHLmeQ+VsOiOwZ252K/yy894f /GpA== X-Gm-Message-State: ALyK8tLm+6olyh2U/ofLTAUL/m83vMNhHulG5m4g2X5HNQr/jVRue/mZmISLD1riGdaXJ+bBZB/BBm0Iu2qQA8tj X-Received: by 10.200.36.200 with SMTP id t8mr37536366qtt.64.1468678865099; Sat, 16 Jul 2016 07:21:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Sat, 16 Jul 2016 07:20:25 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Sat, 16 Jul 2016 07:20:25 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a1140501e0b69e00537c17278 Archived-At: Cc: "ice@ietf.org" , Justin Uberti Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 14:21:09 -0000 --001a1140501e0b69e00537c17278 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I went to make a PR to remove this inconsistency, but while doing so I realized (I think) that's it's not an inconsistency after all, and is actually the desired behavior. That's because if two check lists have a different number of candidates, then the only logic in the RFC to allow a bigger check list to be completely unfrozen. As far as trickle-ice goes, if we keep the rule of "unfreeze out-of-order candidates", then that combined with "unfreeze the whole checklist" behavior does mean that trickle ICE will have more limited freezing behavior than non-trickle ICE. However, given the limited value of freezing when doing rtcp-mux and/or BUNDLE, and the fact that most trickle ICE endpoints will be doing rtcp-mux and BUNDLE, I think losing some freezing behavior value in certain edge cases is OK. That said, I think it may be good to put something like the following in the draft: "When an ICE agent receives a trickled candidate out of order, it SHOULD unfreeze that candidate after end-of-candidates is received. It MAY unfreeze the candidate earlier that if it expects that doing so will establish a connection faster than keeping it frozen (such as when end-of-candidates seems to be overly delayed)." That way, we do keep the freezing behavior, at the cost of delaying the unfreezing of the out-of-order candidate, at least to a point (until end-of-candidates is received). But we also allow the implementation the flexibility to unfreeze earlier if it chooses. On Mon, May 23, 2016 at 2:43 PM, Emil Ivov wrote: > Hey Justin, > > Many apologies for missing this one! I hadn't seen it until I explicitly > went to check my mailbox for updates on this thread. > > So, I've gone over the text again and I can see what you mean. I think > however that this is a contradiction in 5245 and that it goes against the > intention of the freezing algorithm so we should probably fix it in 5245b= is. > > Specifically, I think that section 5.7.4 and later section 7... are more > accurate in the description of the freezing algorithm. > > 5.7.4 describes the initial situation: > > > The agent examines the check list for the first media stream. > For that media stream: > * For all pairs with the same foundation, it sets the > state of the pair with the lowest component ID to Waiting. > > > (note how this only unfreezes a single pair per foundation) > > Then in 7.1.3.2.3 as we progress and update states we have the same > foundation-based reasoning. Specifically as we validate pairs we will > unfreeze certain foundations (and only foundations) of other frozen > checklists: > > > 7.1.3.2.3. > subpoint 1. The agent changes the states for all other Frozen pairs for > the same media stream *and same foundation* to Waiting. > > > Then once we validate an entire foundation of a given stream we will only > unfreeze the same foundation (and only that foundation) of other streams: > > > 7.1.3.2.3. > subpoint 2. If there is a pair in the valid list for every component of > this media stream. The agent examines the check list for each > other media stream in turn : > * the state of all pairs in the check list whose foundation > matches a pair in the valid list under consideration is set to > Waiting > > > This also complies with the non-normative text in 2.4: > > > The > other candidate pairs are marked "frozen". When the connectivity > checks for a candidate pair succeed, the other candidate pairs with > *the same foundation are unfrozen*. > > > And then: > > > This *avoids* (Emil: not delays) repeated checking of > components that are superficially more attractive but in fact are > likely to fail. > > > So, as incredibly convoluted as this all may sound I do think that it > makes more sense than the generic statement in 5.8. > > If we were to accept the statement in 5.8 it would create race conditions > that might even get candidates that should be frozen to be checked before > unfrozen ones ... it would be a mess. > > Do you see what I mean? > > Emil > > > > On 13.04.16 =D0=B3. 0:04, Justin Uberti wrote: > >> reading 5.8, the algo indicates that for an active checklist, you check >> the highest-prio pair in the waiting state, and if there is none, you >> check the highest-prio frozen pair, thereby unfreezing it. This repeats >> on each timer tick. >> >> Basically, once a checklist is active, you will soon end up checking all >> of its pairs. What am I missing? >> >> On Tue, Apr 12, 2016 at 6:25 PM, Emil Ivov > > wrote: >> >> >> >> On Tuesday, 12 April 2016, Justin Uberti > > wrote: >> >> >> >> On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov >> wrote: >> >> Hey Justin, >> >> On Monday, 11 April 2016, Justin Uberti >> wrote: >> >> In BA, I noted that unfreezing the candidate pairs >> associated with a candidate that arrives for a media >> stream other than the first one will cause all of that >> stream's candidate pairs to unfreeze, due to the rules >> in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.= 8 >> ). >> >> >> I may be missing your point but I don't think there's >> anything in 5245 (5.8 or elsewhere) that ever unfreezes all >> the pairs in a checklist in one go. >> >> >> It's not that the checklist unfreezes all at once - it's that >> once you unfreeze any pair in a checklist, the algo in 5.8 will >> necessarily unfreeze the entire checklist in short order. That >> defeats the purpose of a frozen checklist (i.e., you'll end up >> checking both streams in parallel). >> >> >> I really don't think that's the case (and if you are saying what I >> think you are saying then freezing would have been pointless even in >> vanilla ice) >> >> Could you please point to the specific text that's bothering you? >> >> The whole idea about unfreezing is that it happens along a >> foundation and across lists. There are many cases where you >> would unfreeze some candidates in a checklist (either because it was >> their turn or because their entire foundation got unfrozen) but >> other pairs in the same check list would remain frozen till ICE >> completes. >> >> Emil >> >> >> >> There's text that talks about activating a check list and >> there's text that unfreezes an entire foundation actoss all >> check lists but neither of them should be an issue with >> Peter's suggestion >> >> I do agree with the rest of the mail here ... I just don't >> think any of it is a problem. >> >> Emil >> >> >> Someone mentioned that there was only a single check >> list, which would make this a non-issue. However, I >> checked and indeed each stream is supposed to have its >> own check list (ignoring bundle), as described in S 5.7 >> (https://tools.ietf.org/html/rfc5245#section-5.7). >> >> >> >> >> >> Therefore, while this concern of prematurely unfreezing >> check lists isn't an issue for candidates that arrive >> for a different component (since they share a check >> list), I think it is an issue for candidates that arrive >> for different m=3D lines, and as such I'm not sure this >> new unfreezing behavior is the correct solution in these >> cases. >> >> >> >> -- >> sent from my mobile >> >> >> >> >> -- >> sent from my mobile >> >> >> > -- > https://jitsi.org > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a1140501e0b69e00537c17278 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I went to make a PR to remove this inconsistency, but w= hile doing so I realized (I think) that's it's not an inconsistency= after all, and is actually the desired behavior.=C2=A0 That's because = if two check lists have a different number of candidates, then the only log= ic in the RFC to allow a bigger check list to be completely unfrozen.
=

As far as trickle-ice goes, if we keep the rule of "un= freeze out-of-order candidates", then that combined with "unfreez= e the whole checklist" behavior does mean that trickle ICE will have m= ore limited freezing behavior than non-trickle ICE.=C2=A0 However, given th= e limited value of freezing when doing rtcp-mux and/or BUNDLE, and the fact= that most trickle ICE endpoints will be doing rtcp-mux and BUNDLE, I think= losing some freezing behavior value in certain edge cases is OK.
<= br>
That said, I think it may be good to put something like the fol= lowing in the draft:

"When an ICE agent receive= s a trickled candidate out of order, it SHOULD unfreeze that candidate afte= r end-of-candidates is received.=C2=A0 It MAY unfreeze the candidate earlie= r that if it expects that doing so will establish a connection faster than = keeping it frozen (such as when end-of-candidates seems to be overly delaye= d)."


That way, we do keep the freezi= ng behavior, at the cost of delaying the unfreezing of the out-of-order can= didate, at least to a point (until end-of-candidates is received).=C2=A0 Bu= t we also allow the implementation the flexibility to unfreeze earlier if i= t chooses.

On Mon, May 23, 2016 at 2:43 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey Justin,

Many apologies for missing this one! I hadn't seen it until I explicitl= y went to check my mailbox for updates on this thread.

So, I've gone over the text again and I can see what you mean. I think = however that this is a contradiction in 5245 and that it goes against the i= ntention of the freezing algorithm so we should probably fix it in 5245bis.=

Specifically, I think that section 5.7.4 and later section 7... are more ac= curate in the description of the freezing algorithm.

5.7.4 describes the initial situation:

=C2=A0<quote>
The agent examines the check list for the first media stream.
For that media stream:
=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 For all pairs with the same foundation, = it sets the
state of the pair with the lowest component ID to Waiting.
=C2=A0</quote>

(note how this only unfreezes a single pair per foundation)

Then in 7.1.3.2.3 as we progress and update states we have the same foundat= ion-based reasoning. Specifically as we validate pairs we will unfreeze cer= tain foundations (and only foundations) of other frozen checklists:

=C2=A0<quote>
7.1.3.2.3.
subpoint 1.=C2=A0 The agent changes the states for all other Frozen pairs f= or the same media stream *and same foundation* to Waiting.
=C2=A0</quote>

Then once we validate an entire foundation of a given stream we will only u= nfreeze the same foundation (and only that foundation) of other streams:
=C2=A0<quote>
7.1.3.2.3.
subpoint 2. If there is a pair in the valid list for every component of
=C2=A0 =C2=A0this media stream. The agent examines the check list for each<= br> =C2=A0 =C2=A0other media stream in turn :
=C2=A0 =C2=A0* the state of all pairs in the check list whose foundation =C2=A0 =C2=A0matches a pair in the valid list under consideration is set to=
=C2=A0 =C2=A0Waiting
=C2=A0</quote>

This also complies with the non-normative text in 2.4:

=C2=A0<quote>
=C2=A0 =C2=A0The
=C2=A0 =C2=A0other candidate pairs are marked "frozen".=C2=A0 Whe= n the connectivity
=C2=A0 =C2=A0checks for a candidate pair succeed, the other candidate pairs= with
=C2=A0 =C2=A0*the same foundation are unfrozen*.
=C2=A0</quote>

And then:

=C2=A0<quote>
=C2=A0 =C2=A0This *avoids* (Emil: not delays) repeated checking of
=C2=A0 =C2=A0components that are superficially more attractive but in fact = are
=C2=A0 =C2=A0likely to fail.
=C2=A0</quote>

So, as incredibly convoluted as this all may sound I do think that it makes= more sense than the generic statement in 5.8.

If we were to accept the statement in 5.8 it would create race conditions t= hat might even get candidates that should be frozen to be checked before un= frozen ones ... it would be a mess.

Do you see what I mean?

Emil



On 13.04.16 =D0=B3. 0:04, Justin Uberti wrote:
reading 5.8, the algo indicates that for an active checklist, you check
the highest-prio pair in the waiting state, and if there is none, you
check the highest-prio frozen pair, thereby unfreezing it. This repeats
on each timer tick.

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

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



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



=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov <= ;emcho@jitsi.org&g= t; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hey Justin,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Monday, 11 April 2016, Justin = Uberti <juberti@= google.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In BA, I noted that= unfreezing the candidate pairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with a c= andidate that arrives for a media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stream other than t= he first one will cause all of that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stream's candid= ate pairs to unfreeze, due to the rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I may be missing your point but I= don't think there's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anything in 5245 (5.8 or elsewher= e) that ever unfreezes all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the pairs in a checklist in one g= o.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 It's not that the checklist unfreezes all a= t once - it's that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 once you unfreeze any pair in a checklist, the = algo in 5.8 will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 necessarily unfreeze the entire checklist in sh= ort order. That
=C2=A0 =C2=A0 =C2=A0 =C2=A0 defeats the purpose of a frozen checklist (i.e.= , you'll end up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 checking both streams in parallel).


=C2=A0 =C2=A0 I really don't think that's the case (and if you are = saying what I
=C2=A0 =C2=A0 think you are saying then freezing would have been pointless = even in
=C2=A0 =C2=A0 vanilla ice)

=C2=A0 =C2=A0 Could you please point to the specific text that's bother= ing you?

=C2=A0 =C2=A0 The whole idea about unfreezing is that it happens along a =C2=A0 =C2=A0 foundation and across lists. There are many cases where you =C2=A0 =C2=A0 would unfreeze some candidates in a checklist (either because= it was
=C2=A0 =C2=A0 their turn or because their entire foundation got unfrozen) b= ut
=C2=A0 =C2=A0 other pairs in the same check list would remain frozen till I= CE
=C2=A0 =C2=A0 completes.

=C2=A0 =C2=A0 Emil



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

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil


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





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Therefore, while th= is concern of prematurely unfreezing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 check lists isn'= ;t an issue for candidates that arrive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for a different com= ponent (since they share a check
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list), I think it i= s an issue for candidates that arrive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for different m=3D = lines, and as such I'm not sure this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 new unfreezing beha= vior is the correct solution in these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent from my mobile




=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 sent from my mobile



--
https://= jitsi.org

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

--001a1140501e0b69e00537c17278-- From nobody Sat Jul 16 07:59: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 F099712D5D3 for ; Sat, 16 Jul 2016 07:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 Iq6ZBfMiNQkq for ; Sat, 16 Jul 2016 07:59:09 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 17EBB12D13A for ; Sat, 16 Jul 2016 07:59:09 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id j35so73271223qtj.2 for ; Sat, 16 Jul 2016 07:59:08 -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=8cS9uxLouFQEqa4a0W05hKITMS8wl8vH4xaX5bo2B60=; b=G4GFAX3hGyJWJh5v+dZH318zx9qjJ5yQRL5cVun55hUNR2ocxkxBeHbB5FWxompRv2 tCk9JhGTzViWdjnTZV4dK88j5VmvLrK6CUITG32HMXrT7IFljHdj3cJKa4xXVXk4cD4T 8A2AD3C3rcID/RgAMAAGG92Y810EH7a4gTWdmikC1/qq6x3ozXPx5Vl+lMrRmJgqC2ry mQFiDK2TG9r3Bk5BkU9GWBMyi3M2As5GFMqT0OXswhM7VPThYF9twCy+2qY4FyFjAVrd +0PlH4MvBuhS6/B8AF7zAwp9h4CoIGRotTMnpkEpbRe0hq8USHVBYTH7Yj+r9gIqpkMz Zzdw== 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=8cS9uxLouFQEqa4a0W05hKITMS8wl8vH4xaX5bo2B60=; b=QOr+hwKZR+hYbIaZ+WQnolUVnI4jfT99IKm3Qg7DhK8sdHCb5yNoJL0Cma9/34pSyM 41/DwpXhyp3NNy1NjTps2/rUx5FBrp/5j4A1mAo6gKGXd1eUAQDksLNRHhnV+HquR9Zr QTeYEHshb7Dhf1chK0+6Gxu04mBU5xKMt9Qv76I55/C3tATceOpnVZIZfliOX9DSe4KF foa/Pfm0y10icw0cz8OhM0Bz2BiTSeEwdx2BW3EDkHmoRaOd/eHrsSLfGsnGNFMsVY/W 9xsqZSf3p96T0VVfocX0lUqYspMM4w3WRyt9jpvwTyWrJu6KSDvH/gA8493bkJ8PvF6M tZ6w== X-Gm-Message-State: ALyK8tIK+N6DVV/jqgcLVuN1kX3b7J6qfCqQhVK8xm3Xx2+mi04B3lIeXtfzG2ple4mGpoLoYBdc4u9WwdhYH9dC X-Received: by 10.237.36.38 with SMTP id r35mr38821122qtc.3.1468681148030; Sat, 16 Jul 2016 07:59:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Sat, 16 Jul 2016 07:58:28 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Sat, 16 Jul 2016 07:58:28 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a113d3aac1e2e3a0537c1fac0 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin 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: Sat, 16 Jul 2016 14:59:12 -0000 --001a113d3aac1e2e3a0537c1fac0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov wrote: > On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher > wrote: > > > > > > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: > >> > >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher > >> wrote: > >> > > >> > > >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: > >> >> > >> >> Are there any cases where you think this would be useful other than > >> >> abetter connection with a server? > >> > > >> > Yes: continual gathering (aka continuous nomination) would benefit > from > >> > this. > >> > >> Last time we discussed continuous nomination (in Prague last year) it > >> sounded to me that there were no arguments about what it was bringing > >> on top of simple ICE restarts. It is my understanding that optimizing > >> those (if at all necessary) was a more acceptable direction. > >> > >> So I don't think continuous nomination is a good argument here even if > >> we keep waving it all over the place :) . > >> > > > > Continual gathering is a separate topic that we can save for another da= y. > > > >> > >> >> If all that is changing is the connection with the server then it > >> >> sounds > >> >> to me like we should rather come up with a way to update the local > side > >> >> of > >> >> the binding and not bother the remote agent with it. > >> > > >> > That would be TURN mobility, or some new equivalent ( > >> > the TURN mobility draft has expired). > >> > >> Something like that yes. > >> > >> > That is an option that we'd like to > >> > explore implementing, but it's much more work to standardize, > implement, > >> > and > >> > deploy (both on client and server). Whereas this is a simply > mechanism > >> > that > >> > is quick to standardize, implement, and deply, and it's useful for > other > >> > things (as mentioned above). > >> > >> On a first glance the whole ICE idea is very simple and easy to > >> standardise, implement and deploy: gather and try everything. pick > >> what works. > >> > >> > >> I think 13 years after the initial idea was being floated on the IETF > >> we know better. > >> > >> In other words: > >> > >> First I don't think it's that simple at all. I am particularly > >> concerned about potential race conditions with the ICE state machine > >> and the trickling itself. Same for interactions with aggressive > >> nomination. > >> > >> Second, while we may be able to solve the above, I am worried that the > >> increased complexity will not justify something that is a very limited > >> solution to a more general problem. So we are setting the stage for > >> redundancy and that's not something we need with ICE. > >> > > > > It sounds like you are making the argument that ICE has reached some > kind of > > "peak complexity" and can no longer be changed because it's already too > > complex. Is that what you're claiming? > > And question the existence of this wonderful working group? No, of course > not ;) > > What I am claiming is that ICE is too complex for *frivolous* updates > that are likely to be superseded by newer more complete solutions like > the one you mentioned in TRAM. > > While I'm happy that TURN mobility is progressing, I expect it will be some time before wide deployments TURN servers=E2=80=8B =E2=80=8B =E2=80=8B will have support for it. And clients working with TURN servers = that don't support mobility will find it useful to signal candidate removal. And I thought of another case outside of TURN candidates and continual gathering where this is useful: when a network interface goes away at the beginning of ICE setup. It's useful to tell the remote side when this happens to possibly avoid checking useless candidates. Oh, and another: if you have many TURN servers (say, 8), then you'll have 8*8 =3D 64 TURN-TURN candidates pairs, unless you are capable of removing candidates for worse TURN servers. TURN mobility doesn't help across TURN servers (does it?) > >> Also, have you done any measurements or estimates on exactly what we > >> are trying to optimize here? Some several hundred milliseconds of > >> streaming over TCP rather than UDP? > > > > > > I don't know what this has to do with TCP vs. UDP. > > > > The real world problem here is that if you have two network interfaces > (WiFi > > and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to ea= ch > > over TCP and UDP, you end up with 2 x 2 x 2 x 2 =3D 16 TURN candidates = (at > > least; this ignores TCP w/ TLS). Then both sides do that, and you have > 16 * > > 16 =3D 256 TURN-TURN candidate pairs. That's a lot. > > Except that it's not (necessarily) 256. > > > So how do you avoid that problem? > > Well to begin with you can simply apply the same logic as the one you > propose in your draft, but rather than doing it after sending > candidates, you apply it before. That is, you start by sending your > "better" candidates (the ones you wouldn't "deallocate" otherwise) and > you only send your less desirable ones if you fail to obtain the prime > candidates. =E2=80=8BAre you proposing to delay signaling the worse candidates? I neve= r like the idea of delaying candidates because you don't know that the "better" ones will succeed or not. For example, if only TCP candidates work, how long do you wait before you give up on UDP candidates? Or if only cell works, how long do you wait to give up on WiFi candidates?=E2=80=8B > This means that you would only end up with 256 if all of > your prime candidates failed during gathering but then suddenly > started working. Not a great likelihood for that to happen. On average > you'll probably have one or two that leak out (and when that happens > it might actually be an indication that your connection is better > there). > > > So, to be clear, I do agree that ending up with 256 candidates would > be a problem, especially given the 100 pairs MAX constraint 5245. > > What bothers me with this draft is not the problem though: it's that > the solution doesn't appear well thought out. For example: depending > on your timing it is not at all clear that you will be able to remove > candidates before you hit 100 pairs, before they start stun > transactions or before you've already wasted the time you want to > save. > =E2=80=8BActually, we did quite a lot of thinking through it. We determined that if both sides remove worse TURN candidates and also don't signal worse candidates, and also signal removal of worse candidates before the addition of better candidates, then in the worst case scenario, there are 2*N candidate pairs instead of N^2 candidates pairs. Which means in this example you would have 32 instead of 256. And that's the absolute worst case when all of your candidates are allocated in the worst possible order, on both sides. In more normal circumstances, it would reduce to far fewer. =E2=80=8B > In other words, this whole thing may well turn out to be useless half > the time. > =E2=80=8B T > hat's the sort of extra complexity we don't need with ICE. > TURN mobility is one option, and I'd like to see TURN mobility > > happen. But candidate removal is also an option, and it's a lot more > > simple. > > Again, I am not at all convinced of its purported simplicity and even > less its efficiency. > > The whole draft is approximately one sentence if you subtract the boiler plate. It's very easy to implement (it took us perhaps one day). And it's just an optimization, so it's not going to break anything. I don't know how much more simple it can get. =E2=80=8BIn a world where TURN mobility is widely deployed and no one wants= to do continual gathering and WiFi never turns off in the beginning of call setup, then perhaps this is useless.=E2=80=8B But we have use cases in w= hich we have already found this useful. > Emil > > >> > >> Emil > >> > >> > >> >> Emil > >> >> > >> >> > >> >> On Tuesday, 12 July 2016, Peter Thatcher > wrote: > >> >>> > >> >>> I submitted draft-thatcher-ice-remove-candidate and would like to > >> >>> speak > >> >>> about in my allotted time on the agenda when I will also be speaki= ng > >> >>> about > >> >>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renominatio= n. > >> >>> > >> >>> It's a very simple draft. Basically it says you can "remove" > >> >>> candidates > >> >>> just like trickle-ice allows you to add candidates. You could > probably > >> >>> read > >> >>> it in 3 minutes. Please do so: > >> >>> > >> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > >> >>> > >> >>> Thanks, > >> >>> Peter (Chair hat off) > >> >> > >> >> > >> >> > >> >> -- > >> >> sent from my mobile > >> > > >> > > >> > >> > >> > >> -- > >> https://jitsi.org > > > > > > > > -- > https://jitsi.org > --001a113d3aac1e2e3a0537c1fac0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov &= lt;emcho@jitsi.org= > wrote:
On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher <pthatcher@google.com> wrote:
>
>
> On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <pthatcher@google.com>
>> wrote:
>> >
>> >
>> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <emcho@jitsi.org> wrote:
>> >>
>> >> Are there any cases where you think this would be useful = other than
>> >> abetter connection with a server?
>> >
>> > Yes: continual gathering (aka continuous nomination) would be= nefit from
>> > this.
>>
>> Last time we discussed continuous nomination (in Prague last year)= it
>> sounded to me that there were no arguments about what it was bring= ing
>> on top of simple ICE restarts. It is my understanding that optimiz= ing
>> those (if at all necessary) was a more acceptable direction.
>>
>> So I don't think continuous nomination is a good argument here= even if
>> we keep waving it all over the place :) .
>>
>
> Continual gathering is a separate topic that we can save for another d= ay.
>
>>
>> >> If all that is changing is the connection with the server= then it
>> >> sounds
>> >> to me like we should rather come up with a way to update = the local side
>> >> of
>> >> the binding and not bother the remote agent with it.
>> >
>> > That would be TURN mobility, or some new equivalent (
>> > the TURN mobility draft has expired).
>>
>> Something like that yes.
>>
>> > That is an option that we'd like to
>> > explore implementing, but it's much more work to standard= ize, implement,
>> > and
>> > deploy (both on client and server).=C2=A0 Whereas this is a s= imply mechanism
>> > that
>> > is quick to standardize, implement, and deply, and it's u= seful for other
>> > things (as mentioned above).
>>
>> On a first glance the whole ICE idea is very simple and easy to >> standardise, implement and deploy: gather and try everything. pick=
>> what works.
>>
>>
>> I think 13 years after the initial idea was being floated on the I= ETF
>> we know better.
>>
>> In other words:
>>
>> First I don't think it's that simple at all. I am particul= arly
>> concerned about potential race conditions with the ICE state machi= ne
>> and the trickling itself. Same for interactions with aggressive >> nomination.
>>
>> Second, while we may be able to solve the above, I am worried that= the
>> increased complexity will not justify something that is a very lim= ited
>> solution to a more general problem. So we are setting the stage fo= r
>> redundancy and that's not something we need with ICE.
>>
>
> It sounds like you are making the argument that ICE has reached some k= ind of
> "peak complexity" and can no longer be changed because it= 9;s already too
> complex.=C2=A0 Is that what you're claiming?

And question the existence of this wonderful working group? No,= of course not ;)

What I am claiming is that ICE is too complex for *frivolous* updates
that are likely to be superseded by newer more complete solutions like
the one you mentioned in TRAM.


<= /div>
While I'm happy that TURN mobility is= progressing, I expect it will be some time before wide deployments TURN se= rvers=E2=80=8B
= =E2=80=8B
=E2=80=8B will have support for it.=C2=A0 And cl= ients working with TURN servers that don't support mobility will find i= t useful to signal candidate removal.

And I thought of another case ou= tside of TURN candidates and continual gathering where this is useful: when= a network interface goes away at the beginning of ICE setup.=C2=A0 It'= s useful to tell the remote side when this happens to possibly avoid checki= ng useless candidates.


Oh, and another: =C2=A0if you have many TURN serve= rs (say, 8), then you'll have 8*8 =3D 64 TURN-TURN candidates pairs, un= less you are capable of removing candidates for worse TURN servers.=C2=A0 T= URN mobility doesn't help across TURN servers (does it?)

=C2=A0
>> Also, have you done any measurements or estimates on exactly what = we
>> are trying to optimize here? Some several hundred milliseconds of<= br> >> streaming over TCP rather than UDP?
>
>
> I don't know what this has to do with TCP vs. UDP.
>
> The real world problem here is that if you have two network interfaces= (WiFi
> and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to e= ach
> over TCP and UDP, you end up with 2 x 2 x 2 x 2 =3D 16 TURN candidates= (at
> least; this ignores TCP w/ TLS).=C2=A0 Then both sides do that, and yo= u have 16 *
> 16 =3D 256 TURN-TURN candidate pairs. That's a lot.

Except that it's not (necessarily) 256.

> So how do you avoid that problem?

Well to begin with you can simply apply the same logic as the one yo= u
propose in your draft, but rather than doing it after sending
candidates, you apply it before. That is, you start by sending your
"better" candidates (the ones you wouldn't "deallocate&q= uot; otherwise) and
you only send your less desirable ones if you fail to obtain the prime
candidates.

=E2=80=8BAre you proposing = to delay signaling the worse candidates?=C2=A0 I never like the idea of del= aying candidates because you don't know that the "better" one= s will succeed or not.=C2=A0 For example, if only TCP candidates work, how = long do you wait before you give up on UDP candidates? =C2=A0 Or if only ce= ll works, how long do you wait to give up on WiFi candidates?=E2=80=8B
=C2=A0
This means that you would only= end up with 256 if all of
your prime candidates failed during gathering but then suddenly
started working. Not a great likelihood for that to happen. On average
you'll probably have one or two that leak out (and when that happens it might actually be an indication that your connection is better
there).

=C2=A0

So, to be clear, I do agree that ending up with 256 candidates would
be a problem, especially given the 100 pairs MAX constraint 5245.

What bothers me with this draft is not the problem though: it's that the solution doesn't appear well thought out. For example: depending on your timing it is not at all clear that you will be able to remove
candidates before you hit 100 pairs, before they start stun
transactions or before you've already wasted the time you want to
save.

=E2=80=8BActually, we did quit= e a lot of thinking through it.

We determined that if = both sides remove worse TURN candidates and also don't signal worse can= didates, and also signal removal of worse candidates before the addition of= better candidates, then in the worst case scenario, there are 2*N candidat= e pairs instead of N^2 candidates pairs.=C2=A0 Which means in this example = you would have 32 instead of 256.=C2=A0 And that's the absolute worst c= ase when all of your candidates are allocated in the worst possible order, = on both sides.=C2=A0 In more normal circumstances, it would reduce to far f= ewer.
=E2=80=8B
=C2=A0
In other words, this whole thing may well turn out to be useless h= alf
the time.
=E2=80=8B T
hat's the sort of extra co= mplexity we don't need with ICE.
> TURN mobility is one option, and I'd like to see TURN mobility
> happen.=C2=A0 But candidate removal is also an option, and it's a = lot more
> simple.

Again, I am not at all convinced of its purported simplicity and eve= n
less its efficiency.


The = whole draft is approximately one sentence if you subtract the boiler plate.= =C2=A0 It's very easy to implement (it took us perhaps one day).=C2=A0 = And it's just an optimization, so it's not going to break anything.= =C2=A0 I don't know how much more simple it can get.

=
=E2=80=8BIn a world where TURN mobility is widely deployed and no one wa= nts to do continual gathering and WiFi never turns off in the beginning of = call setup, then perhaps this is useless.=E2=80=8B =C2=A0 =C2=A0But we have= use cases in which we have already found this useful.

=C2=A0
Emil

>>
>> Emil
>>
>>
>> >> Emil
>> >>
>> >>
>> >> On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
>> >>>
>> >>> I submitted draft-thatcher-ice-remove-candidate and w= ould like to
>> >>> speak
>> >>> about in my allotted time on the agenda when I will a= lso be speaking
>> >>> about
>> >>> draft-thatcher-ice-network-cost and draft-thatcher-ic= e-renomination.
>> >>>
>> >>> It's a very simple draft. Basically it says you c= an "remove"
>> >>> candidates
>> >>> just like trickle-ice allows you to add candidates. Y= ou could probably
>> >>> read
>> >>> it in 3 minutes. Please do so:
>> >>>
>> >>> https://www.= ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt
>> >>>
>> >>> Thanks,
>> >>> Peter (Chair hat off)
>> >>
>> >>
>> >>
>> >> --
>> >> sent from my mobile
>> >
>> >
>>
>>
>>
>> --
>> https://jitsi.org
>
>



--
https://= jitsi.org

--001a113d3aac1e2e3a0537c1fac0-- From nobody Sun Jul 17 08:13: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 76A3C12B00B for ; Sun, 17 Jul 2016 08:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zNIUqIp--Tz for ; Sun, 17 Jul 2016 08:13:13 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 3BF0A12B007 for ; Sun, 17 Jul 2016 08:13:12 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id i12so10075876ywa.0 for ; Sun, 17 Jul 2016 08:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DdhKabARePwHej7P7Ddf/hrypkwBq45CH4tZlerBfTI=; b=tXp8PgFE3wN3ltnPMcV/DS94nzpo/dLe/v3IgyBxbsoxl+iNca8XIo7dDwt16CAVwh AAY93osab/mGj6zhTinXOMIk8LyWvu1K+0zwWfkTYH9URxeWRsY3j9plemwnvd+aeqZl SaaTwMfIdb9CRpiPdwADlJGjhTnbX3gtGb7B7PTCN5zclKNVl59SMJIVCmzNEZ+EP5eQ A93W3Nbwd+E6BBNEUjY5IaJZh6qlHOxwMQLP028nxxolrBc8zYXwTb3R6tVt84g8C00f EUF/lHmbb5U+/YynKfYRcJSKkdWrDKXOeS1p0hyCzoghZX65WsmFr7wokTHHHkujcNDL RXrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DdhKabARePwHej7P7Ddf/hrypkwBq45CH4tZlerBfTI=; b=iBVbgDLzs2qCU+JH3HpXvIqsuIbGyj1c9m5fFMGvMvpq0HJmlGRQuV1wDhfp/PEb2y pG12oImYdPvue6AMhvR/Lx9Zt+PuGs+J64dXL446rKS6geQOMR/PQxWsn+NRaUM7/m+y l+HU3IhnTmWEdrnn4rOGBzihAVKmJNLw0AX/TOCEDDzoV/MJaYFLxe0eoENC4yZGcr8R +IRANylfInotbbzRTBf9avv43x8dWSmGG8eBUqh2jah7Lfq+2CPBFgfWefQV3q7TDPuV rQIL137XixNeMqBj0qu7h2KYup5jwtV9I5QTD0phfjwbw37Yo0KF9HbUA2OGABtHBHZc M6GA== X-Gm-Message-State: ALyK8tIV4wXAaQCHrSE6TsXnkh5iFebTQ8apMPu7ffsT4WBvh8lWn8uKJi8egM9sGlTgqA== X-Received: by 10.129.135.1 with SMTP id x1mr19306403ywf.141.1468768391965; Sun, 17 Jul 2016 08:13:11 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com. [209.85.161.174]) by smtp.gmail.com with ESMTPSA id v68sm1750964ywg.31.2016.07.17.08.13.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jul 2016 08:13:11 -0700 (PDT) Received: by mail-yw0-f174.google.com with SMTP id y188so8407281ywf.0 for ; Sun, 17 Jul 2016 08:13:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.169.132 with SMTP id g126mr20934938ywh.179.1468768390806; Sun, 17 Jul 2016 08:13:10 -0700 (PDT) Received: by 10.83.17.204 with HTTP; Sun, 17 Jul 2016 08:13:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Jul 2016 18:13:10 +0300 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: Peter Thatcher Content-Type: multipart/alternative; boundary=94eb2c145a6a31376d0537d64a33 Archived-At: Cc: "ice@ietf.org" , Justin Uberti Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 15:13:16 -0000 --94eb2c145a6a31376d0537d64a33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Peter, On Saturday, 16 July 2016, Peter Thatcher wrote: > I went to make a PR to remove this inconsistency, but while doing so I > realized (I think) that's it's not an inconsistency after all, and is > actually the desired behavior. > > I disagree. The current text is clearly contradictory. If it turns out that one of its interpretations somehow appears to unblock certain situations that to me is a side effect not an intention > That's because if two check lists have a different number of candidates, > then the only logic in the RFC to allow a bigger check list to be > completely unfrozen. > I think we specifically need text in 5245 bis to address the situation with unequal number of foundations. The easiest way would be to just outlaw it. If you need to do funky stiff like that: just negotiate a different session. If not then just drop all candidates for the crippled foundation. Now ... if you truly really absolutely want to have support for checklists with different sizes we can add wording to the effect of: when unfreezing the first pair in a checklist C as a result of successful checks in preceding checklists P, the agent also unfreezes any pairs in C with foundations that did not have pairs in P. > As far as trickle-ice goes, if we keep the rule of "unfreeze out-of-order > candidates", then that combined with "unfreeze the whole checklist" > behavior does mean that trickle ICE will have more limited freezing > behavior than non-trickle ICE. However, given the limited value of > freezing when doing rtcp-mux and/or BUNDLE, and the fact that most trickl= e > ICE endpoints will be doing rtcp-mux and BUNDLE, I think losing some > freezing behavior value in certain edge cases is OK. > I haven't had a chance to comment on the whole "let's get rid of freezing" topic but I think it's a bad idea. To begin with: BUNDLE is not an argument for removing freezing as it simply doesn't use it. In other words: the fact that everyone drives in a car today is not a reason to slaughter all horses ;). For non-bundle cases, freezing still accelerates ICE processing and the reasons for creating it are still there. > That said, I think it may be good to put something like the following in > the draft: > > "When an ICE agent receives a trickled candidate out of order, it SHOULD > unfreeze that candidate after end-of-candidates is received. It MAY > unfreeze the candidate earlier that if it expects that doing so will > establish a connection faster than keeping it frozen (such as when > end-of-candidates seems to be overly delayed)." > I like your original suggestion better, provided that we make it clear in 5245bis that unfreezing one pair does not and should not imply unfreezing all pairs. Emil > > > That way, we do keep the freezing behavior, at the cost of delaying the > unfreezing of the out-of-order candidate, at least to a point (until > end-of-candidates is received). But we also allow the implementation the > flexibility to unfreeze earlier if it chooses. > > On Mon, May 23, 2016 at 2:43 PM, Emil Ivov > wrote: > >> Hey Justin, >> >> Many apologies for missing this one! I hadn't seen it until I explicitly >> went to check my mailbox for updates on this thread. >> >> So, I've gone over the text again and I can see what you mean. I think >> however that this is a contradiction in 5245 and that it goes against th= e >> intention of the freezing algorithm so we should probably fix it in 5245= bis. >> >> Specifically, I think that section 5.7.4 and later section 7... are more >> accurate in the description of the freezing algorithm. >> >> 5.7.4 describes the initial situation: >> >> >> The agent examines the check list for the first media stream. >> For that media stream: >> * For all pairs with the same foundation, it sets the >> state of the pair with the lowest component ID to Waiting. >> >> >> (note how this only unfreezes a single pair per foundation) >> >> Then in 7.1.3.2.3 as we progress and update states we have the same >> foundation-based reasoning. Specifically as we validate pairs we will >> unfreeze certain foundations (and only foundations) of other frozen >> checklists: >> >> >> 7.1.3.2.3. >> subpoint 1. The agent changes the states for all other Frozen pairs for >> the same media stream *and same foundation* to Waiting. >> >> >> Then once we validate an entire foundation of a given stream we will onl= y >> unfreeze the same foundation (and only that foundation) of other streams= : >> >> >> 7.1.3.2.3. >> subpoint 2. If there is a pair in the valid list for every component of >> this media stream. The agent examines the check list for each >> other media stream in turn : >> * the state of all pairs in the check list whose foundation >> matches a pair in the valid list under consideration is set to >> Waiting >> >> >> This also complies with the non-normative text in 2.4: >> >> >> The >> other candidate pairs are marked "frozen". When the connectivity >> checks for a candidate pair succeed, the other candidate pairs with >> *the same foundation are unfrozen*. >> >> >> And then: >> >> >> This *avoids* (Emil: not delays) repeated checking of >> components that are superficially more attractive but in fact are >> likely to fail. >> >> >> So, as incredibly convoluted as this all may sound I do think that it >> makes more sense than the generic statement in 5.8. >> >> If we were to accept the statement in 5.8 it would create race condition= s >> that might even get candidates that should be frozen to be checked befor= e >> unfrozen ones ... it would be a mess. >> >> Do you see what I mean? >> >> Emil >> >> >> >> On 13.04.16 =D0=B3. 0:04, Justin Uberti wrote: >> >>> reading 5.8, the algo indicates that for an active checklist, you check >>> the highest-prio pair in the waiting state, and if there is none, you >>> check the highest-prio frozen pair, thereby unfreezing it. This repeats >>> on each timer tick. >>> >>> Basically, once a checklist is active, you will soon end up checking al= l >>> of its pairs. What am I missing? >>> >>> On Tue, Apr 12, 2016 at 6:25 PM, Emil Ivov >> >>> >> >> wrote: >>> >>> >>> >>> On Tuesday, 12 April 2016, Justin Uberti >> >>> >> >> wrote: >>> >>> >>> >>> On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov >> > wrote: >>> >>> Hey Justin, >>> >>> On Monday, 11 April 2016, Justin Uberti >> > >>> wrote: >>> >>> In BA, I noted that unfreezing the candidate pairs >>> associated with a candidate that arrives for a media >>> stream other than the first one will cause all of that >>> stream's candidate pairs to unfreeze, due to the rules >>> in S 5.8 ( >>> https://tools.ietf.org/html/rfc5245#section-5.8). >>> >>> >>> I may be missing your point but I don't think there's >>> anything in 5245 (5.8 or elsewhere) that ever unfreezes all >>> the pairs in a checklist in one go. >>> >>> >>> It's not that the checklist unfreezes all at once - it's that >>> once you unfreeze any pair in a checklist, the algo in 5.8 will >>> necessarily unfreeze the entire checklist in short order. That >>> defeats the purpose of a frozen checklist (i.e., you'll end up >>> checking both streams in parallel). >>> >>> >>> I really don't think that's the case (and if you are saying what I >>> think you are saying then freezing would have been pointless even i= n >>> vanilla ice) >>> >>> Could you please point to the specific text that's bothering you? >>> >>> The whole idea about unfreezing is that it happens along a >>> foundation and across lists. There are many cases where you >>> would unfreeze some candidates in a checklist (either because it wa= s >>> their turn or because their entire foundation got unfrozen) but >>> other pairs in the same check list would remain frozen till ICE >>> completes. >>> >>> Emil >>> >>> >>> >>> There's text that talks about activating a check list and >>> there's text that unfreezes an entire foundation actoss all >>> check lists but neither of them should be an issue with >>> Peter's suggestion >>> >>> I do agree with the rest of the mail here ... I just don't >>> think any of it is a problem. >>> >>> Emil >>> >>> >>> Someone mentioned that there was only a single check >>> list, which would make this a non-issue. However, I >>> checked and indeed each stream is supposed to have its >>> own check list (ignoring bundle), as described in S 5.7 >>> (https://tools.ietf.org/html/rfc5245#section-5.7). >>> >>> >>> >>> >>> >>> Therefore, while this concern of prematurely unfreezing >>> check lists isn't an issue for candidates that arrive >>> for a different component (since they share a check >>> list), I think it is an issue for candidates that arriv= e >>> for different m=3D lines, and as such I'm not sure this >>> new unfreezing behavior is the correct solution in thes= e >>> cases. >>> >>> >>> >>> -- >>> sent from my mobile >>> >>> >>> >>> >>> -- >>> sent from my mobile >>> >>> >>> >> -- >> https://jitsi.org >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > > --=20 sent from my mobile --94eb2c145a6a31376d0537d64a33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Peter,

On Saturday, 16 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
I went to make a PR to remove t= his inconsistency, but while doing so I realized (I think) that's it= 9;s not an inconsistency after all, and is actually the desired behavior.= =C2=A0

I disagree. The current te= xt is clearly contradictory. If it turns out that one of its interpretation= s=C2=A0somehow appears to unblock certain situations that to me is a side e= ffect not an intention
=C2=A0
=C2=A0That's because if two check lists have a dif= ferent number of candidates, then the only logic in the RFC to allow a bigg= er check list to be completely unfrozen.

<= /div>
I think we specifically need text in 5245 bis to address the situ= ation with unequal number of foundations. The easiest way would be to just = outlaw it. If you need to do funky stiff like that: just negotiate a differ= ent session. If not then just drop all candidates for the crippled foundati= on.
=C2=A0
Now ... if you truly really absolutely want = to have support for checklists with different sizes we can add wording to t= he effect of: when unfreezing the first pair in a checklist C=C2=A0as a res= ult of successful checks in preceding checklists P, the agent also unfreeze= s any pairs in C with foundations that did not have pairs in P.
<= br>

As= far as trickle-ice goes, if we keep the rule of "unfreeze out-of-orde= r candidates", then that combined with "unfreeze the whole checkl= ist" behavior does mean that trickle ICE will have more limited freezi= ng behavior than non-trickle ICE.=C2=A0 However, given the limited value of= freezing when doing rtcp-mux and/or BUNDLE, and the fact that most trickle= ICE endpoints will be doing rtcp-mux and BUNDLE, I think losing some freez= ing behavior value in certain edge cases is OK.

I haven't had a chance to comment on the whole "l= et's get rid of freezing" topic but I think it's a bad idea. T= o begin with: BUNDLE is not an argument for removing freezing as it simply= =C2=A0doesn't use it.=C2=A0In other words: the fact that everyone drive= s in a car today is not a reason to slaughter all horses ;).=C2=A0

For non-bundle cases, freezing still accelerates ICE proce= ssing and the reasons for creating it are still there.

=

That said, = I think it may be good to put something like the following in the draft:

"When an ICE agent receives a trickled candidate ou= t of order, it SHOULD unfreeze that candidate after end-of-candidates is re= ceived.=C2=A0 It MAY unfreeze the candidate earlier that if it expects that= doing so will establish a connection faster than keeping it frozen (such a= s when end-of-candidates seems to be overly delayed)."

I like your original suggestion better, provid= ed that we make it clear in 5245bis that=C2=A0unfreezing one p= air does not and should not imply unfreezing all pairs.

Emil=C2=A0

That way, we do keep the freezing behavior, at the = cost of delaying the unfreezing of the out-of-order candidate, at least to = a point (until end-of-candidates is received).=C2=A0 But we also allow the = implementation the flexibility to unfreeze earlier if it chooses.

On Mon, May 23,= 2016 at 2:43 PM, Emil Ivov <emcho@= jitsi.org> wrote:
Hey Just= in,

Many apologies for missing this one! I hadn't seen it until I explicitl= y went to check my mailbox for updates on this thread.

So, I've gone over the text again and I can see what you mean. I think = however that this is a contradiction in 5245 and that it goes against the i= ntention of the freezing algorithm so we should probably fix it in 5245bis.=

Specifically, I think that section 5.7.4 and later section 7... are more ac= curate in the description of the freezing algorithm.

5.7.4 describes the initial situation:

=C2=A0<quote>
The agent examines the check list for the first media stream.
For that media stream:
=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 For all pairs with the same foundation, = it sets the
state of the pair with the lowest component ID to Waiting.
=C2=A0</quote>

(note how this only unfreezes a single pair per foundation)

Then in 7.1.3.2.3 as we progress and update states we have the same foundat= ion-based reasoning. Specifically as we validate pairs we will unfreeze cer= tain foundations (and only foundations) of other frozen checklists:

=C2=A0<quote>
7.1.3.2.3.
subpoint 1.=C2=A0 The agent changes the states for all other Frozen pairs f= or the same media stream *and same foundation* to Waiting.
=C2=A0</quote>

Then once we validate an entire foundation of a given stream we will only u= nfreeze the same foundation (and only that foundation) of other streams:
=C2=A0<quote>
7.1.3.2.3.
subpoint 2. If there is a pair in the valid list for every component of
=C2=A0 =C2=A0this media stream. The agent examines the check list for each<= br> =C2=A0 =C2=A0other media stream in turn :
=C2=A0 =C2=A0* the state of all pairs in the check list whose foundation =C2=A0 =C2=A0matches a pair in the valid list under consideration is set to=
=C2=A0 =C2=A0Waiting
=C2=A0</quote>

This also complies with the non-normative text in 2.4:

=C2=A0<quote>
=C2=A0 =C2=A0The
=C2=A0 =C2=A0other candidate pairs are marked "frozen".=C2=A0 Whe= n the connectivity
=C2=A0 =C2=A0checks for a candidate pair succeed, the other candidate pairs= with
=C2=A0 =C2=A0*the same foundation are unfrozen*.
=C2=A0</quote>

And then:

=C2=A0<quote>
=C2=A0 =C2=A0This *avoids* (Emil: not delays) repeated checking of
=C2=A0 =C2=A0components that are superficially more attractive but in fact = are
=C2=A0 =C2=A0likely to fail.
=C2=A0</quote>

So, as incredibly convoluted as this all may sound I do think that it makes= more sense than the generic statement in 5.8.

If we were to accept the statement in 5.8 it would create race conditions t= hat might even get candidates that should be frozen to be checked before un= frozen ones ... it would be a mess.

Do you see what I mean?

Emil



On 13.04.16 =D0=B3. 0:04, Justin Uberti wrote:
reading 5.8, the algo indicates that for an active checklist, you check
the highest-prio pair in the waiting state, and if there is none, you
check the highest-prio frozen pair, thereby unfreezing it. This repeats
on each timer tick.

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

On Tue, Apr 12, 2016 at 6:25 PM, Emil Ivov <emcho@jit= si.org
 <mailto:emcho@jitsi.org>> wrote:



=C2=A0 =C2=A0 On Tuesday, 12 April 2016, Justin Uberti <juberti@google.com
=C2=A0 =C2=A0 <mailto:juberti@google.com>&g= t; wrote:



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hey Justin,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Monday, 11 April 2016, Justin = Uberti <juberti@google.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In BA, I noted that= unfreezing the candidate pairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with a c= andidate that arrives for a media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stream other than t= he first one will cause all of that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stream's candid= ate pairs to unfreeze, due to the rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I may be missing your point but I= don't think there's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anything in 5245 (5.8 or elsewher= e) that ever unfreezes all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the pairs in a checklist in one g= o.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 It's not that the checklist unfreezes all a= t once - it's that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 once you unfreeze any pair in a checklist, the = algo in 5.8 will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 necessarily unfreeze the entire checklist in sh= ort order. That
=C2=A0 =C2=A0 =C2=A0 =C2=A0 defeats the purpose of a frozen checklist (i.e.= , you'll end up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 checking both streams in parallel).


=C2=A0 =C2=A0 I really don't think that's the case (and if you are = saying what I
=C2=A0 =C2=A0 think you are saying then freezing would have been pointless = even in
=C2=A0 =C2=A0 vanilla ice)

=C2=A0 =C2=A0 Could you please point to the specific text that's bother= ing you?

=C2=A0 =C2=A0 The whole idea about unfreezing is that it happens along a =C2=A0 =C2=A0 foundation and across lists. There are many cases where you =C2=A0 =C2=A0 would unfreeze some candidates in a checklist (either because= it was
=C2=A0 =C2=A0 their turn or because their entire foundation got unfrozen) b= ut
=C2=A0 =C2=A0 other pairs in the same check list would remain frozen till I= CE
=C2=A0 =C2=A0 completes.

=C2=A0 =C2=A0 Emil



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

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil


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





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Therefore, while th= is concern of prematurely unfreezing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 check lists isn'= ;t an issue for candidates that arrive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for a different com= ponent (since they share a check
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list), I think it i= s an issue for candidates that arrive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for different m=3D = lines, and as such I'm not sure this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 new unfreezing beha= vior is the correct solution in these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent from my mobile




=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 sent from my mobile



--
https://= jitsi.org

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



--
sent from my mobile
--94eb2c145a6a31376d0537d64a33-- From nobody Mon Jul 18 04:38:44 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CF712D923 for ; Mon, 18 Jul 2016 04:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBoJn2ckNpKh for ; Mon, 18 Jul 2016 04:38:39 -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 22E0912D92D for ; Mon, 18 Jul 2016 04:38:34 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l125so156659455ywb.2 for ; Mon, 18 Jul 2016 04:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MPrx7MwREalBRXn6bCsWMlg6qQWUiZHlhPVA3aJBSbc=; b=jTyQk0cssfdvq0xLR88IrwLkiLWXR+TSxdScYIP67HYt5e6zhR91w+Zqv4Zqgf1Xr/ aLOdhf+ADKLNNfNVdYvRWjmXJyHUSbLh+ReRP18AnoAL/qjwuMFKGHUXBrdO/hB1aSBQ h3lxtHFhQxvo88ru3ApMFlRFVgMm3SvCna4VH4FbLEGDqOFKdsBqf/JHYU6Td2RJrEJa ul7kMexb322Y4XwMOvyHRBHc6ve9YnXOkOEsxriup+u0thbvLNeD2DdFJ8QkFAOIdIkW 70SriRxNOOyN/uB+sTkIHDnF3NkShdi073+G3wzqDRDclvYLL+0zNaR/HF/3/k2UJc5l amdQ== 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=MPrx7MwREalBRXn6bCsWMlg6qQWUiZHlhPVA3aJBSbc=; b=F3t3MHY1e8LmSy/2tswY/Sa//1oHwkTRMEeTBfmJ1Z9rDN/u5Cr/cFIeSXYGj2XWii ZUar6K/rIF+GNQJ2vExK8v0cotyv8r4bZeE7pFfE/5pmewf6NGZSjWmpVnR50Q/uPsA1 lvFOq4tl5X0rro7TI4prOwPFpmvf2kR8vNHTdNecsVOrEUnsBGrEIqO0rViBpTMxE2hB 3BFz1hGwDOw8UHQ9xrxsJqQGs5CEObMy5aJyxFpm1+pKg72gYWGlt6z55ZsFTcGbFe1J ukNiT5yAWLt4VhK5BZd1Ar6gdKh4XfxBorjLZ7KtjA5heeNWGH+MyWJ3IB4K3r/WHNM9 epHw== X-Gm-Message-State: ALyK8tJbT3OdtUI/WYgLvTLgRjX3s2Vc/4QyqxsfhLYn5bc0vJYzLk1EwoJ2dLgye7xYUw== X-Received: by 10.129.129.131 with SMTP id r125mr21673137ywf.20.1468841913139; Mon, 18 Jul 2016 04:38:33 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com. [209.85.161.173]) by smtp.gmail.com with ESMTPSA id t22sm6321580ywg.21.2016.07.18.04.38.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 04:38:32 -0700 (PDT) Received: by mail-yw0-f173.google.com with SMTP id c124so29607527ywd.3 for ; Mon, 18 Jul 2016 04:38:32 -0700 (PDT) X-Received: by 10.129.161.129 with SMTP id y123mr25139420ywg.214.1468841912259; Mon, 18 Jul 2016 04:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Mon, 18 Jul 2016 04:38:12 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Mon, 18 Jul 2016 14:38:12 +0300 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 11:38:42 -0000 Hey Peter, On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher wrote: > > > On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov wrote: >> >> On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher >> wrote: >> > >> > >> > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: >> >> >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher >> >> wrote: >> >> > >> >> > >> >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov wrote: >> >> >> >> >> >> Are there any cases where you think this would be useful other than >> >> >> abetter connection with a server? >> >> > >> >> > Yes: continual gathering (aka continuous nomination) would benefit >> >> > from >> >> > this. >> >> >> >> Last time we discussed continuous nomination (in Prague last year) it >> >> sounded to me that there were no arguments about what it was bringing >> >> on top of simple ICE restarts. It is my understanding that optimizing >> >> those (if at all necessary) was a more acceptable direction. >> >> >> >> So I don't think continuous nomination is a good argument here even if >> >> we keep waving it all over the place :) . >> >> >> > >> > Continual gathering is a separate topic that we can save for another >> > day. >> > >> >> >> >> >> If all that is changing is the connection with the server then it >> >> >> sounds >> >> >> to me like we should rather come up with a way to update the local >> >> >> side >> >> >> of >> >> >> the binding and not bother the remote agent with it. >> >> > >> >> > That would be TURN mobility, or some new equivalent ( >> >> > the TURN mobility draft has expired). >> >> >> >> Something like that yes. >> >> >> >> > That is an option that we'd like to >> >> > explore implementing, but it's much more work to standardize, >> >> > implement, >> >> > and >> >> > deploy (both on client and server). Whereas this is a simply >> >> > mechanism >> >> > that >> >> > is quick to standardize, implement, and deply, and it's useful for >> >> > other >> >> > things (as mentioned above). >> >> >> >> On a first glance the whole ICE idea is very simple and easy to >> >> standardise, implement and deploy: gather and try everything. pick >> >> what works. >> >> >> >> >> >> I think 13 years after the initial idea was being floated on the IETF >> >> we know better. >> >> >> >> In other words: >> >> >> >> First I don't think it's that simple at all. I am particularly >> >> concerned about potential race conditions with the ICE state machine >> >> and the trickling itself. Same for interactions with aggressive >> >> nomination. >> >> >> >> Second, while we may be able to solve the above, I am worried that the >> >> increased complexity will not justify something that is a very limited >> >> solution to a more general problem. So we are setting the stage for >> >> redundancy and that's not something we need with ICE. >> >> >> > >> > It sounds like you are making the argument that ICE has reached some >> > kind of >> > "peak complexity" and can no longer be changed because it's already too >> > complex. Is that what you're claiming? >> >> And question the existence of this wonderful working group? No, of course >> not ;) >> >> What I am claiming is that ICE is too complex for *frivolous* updates >> that are likely to be superseded by newer more complete solutions like >> the one you mentioned in TRAM. >> > > While I'm happy that TURN mobility is progressing, I expect it will be some > time before wide deployments TURN servers > will have support for it. And clients working with TURN servers that don't > support mobility will find it useful to signal candidate removal. Sure. > And I thought of another case outside of TURN candidates and continual > gathering where this is useful: when a network interface goes away at the > beginning of ICE setup. It's useful to tell the remote side when this > happens to possibly avoid checking useless candidates. This would be a bad way to handle if down events as it would only work in a very limited window of time (at least the way it's currently defined). > Oh, and another: if you have many TURN servers (say, 8), then you'll have > 8*8 = 64 TURN-TURN candidates pairs, unless you are capable of removing > candidates for worse TURN servers. TURN mobility doesn't help across TURN > servers (does it?) This makes no sense to me. If you are going to remove TURN candidates as soon as you send them, then why the heck do you have 8 TURN servers to begin with? >> >> Also, have you done any measurements or estimates on exactly what we >> >> are trying to optimize here? Some several hundred milliseconds of >> >> streaming over TCP rather than UDP? >> > >> > >> > I don't know what this has to do with TCP vs. UDP. >> > >> > The real world problem here is that if you have two network interfaces >> > (WiFi >> > and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to >> > each >> > over TCP and UDP, you end up with 2 x 2 x 2 x 2 = 16 TURN candidates (at >> > least; this ignores TCP w/ TLS). Then both sides do that, and you have >> > 16 * >> > 16 = 256 TURN-TURN candidate pairs. That's a lot. >> >> Except that it's not (necessarily) 256. >> >> > So how do you avoid that problem? >> >> Well to begin with you can simply apply the same logic as the one you >> propose in your draft, but rather than doing it after sending >> candidates, you apply it before. That is, you start by sending your >> "better" candidates (the ones you wouldn't "deallocate" otherwise) and >> you only send your less desirable ones if you fail to obtain the prime >> candidates. > > > Are you proposing to delay signaling the worse candidates? No. > I never like the > idea of delaying candidates because you don't know that the "better" ones > will succeed or not. For example, if only TCP candidates work, how long do > you wait before you give up on UDP candidates? Or if only cell works, how > long do you wait to give up on WiFi candidates? You don't need to implement explicit delays. You only need to order your gathering and trickling according to the priority you desire. Pacing will take care of the actual delays. >> This means that you would only end up with 256 if all of >> your prime candidates failed during gathering but then suddenly >> started working. Not a great likelihood for that to happen. On average >> you'll probably have one or two that leak out (and when that happens >> it might actually be an indication that your connection is better >> there). > > > >> >> >> So, to be clear, I do agree that ending up with 256 candidates would >> be a problem, especially given the 100 pairs MAX constraint 5245. >> >> What bothers me with this draft is not the problem though: it's that >> the solution doesn't appear well thought out. For example: depending >> on your timing it is not at all clear that you will be able to remove >> candidates before you hit 100 pairs, before they start stun >> transactions or before you've already wasted the time you want to >> save. > > > Actually, we did quite a lot of thinking through it. I am sure you have but this is not obvious from reading the document. > We determined that if both sides remove worse TURN candidates and also don't > signal worse candidates, and also signal removal of worse candidates before > the addition of better candidates, I am having trouble parsing this sentence but "don't signal worse candidates" sounds to me as the opposite of "signal removal". My guess at this stage is that once you implement "non-signalling of worse candidates" removal of worse candidates is going to have a very marginal benefit. > then in the worst case scenario, there > are 2*N candidate pairs instead of N^2 candidates pairs. Which means in > this example you would have 32 instead of 256. And that's the absolute > worst case when all of your candidates are allocated in the worst possible > order, on both sides. In more normal circumstances, it would reduce to far > fewer. > >> >> In other words, this whole thing may well turn out to be useless half >> the time. >> T >> hat's the sort of extra complexity we don't need with ICE. >> >> > TURN mobility is one option, and I'd like to see TURN mobility >> > happen. But candidate removal is also an option, and it's a lot more >> > simple. >> >> Again, I am not at all convinced of its purported simplicity and even >> less its efficiency. >> > > The whole draft is approximately one sentence if you subtract the boiler > plate. Yup. And that's pretty much my main problem. I am very much missing a description of all possible states where a removal signal can arrive and how the agent should behave under those circumstances. I am also missing guidelines for when exactly removal signals should be sent. > It's very easy to implement (it took us perhaps one day). And it's > just an optimization, so it's not going to break anything. I don't know how > much more simple it can get. > > In a world where TURN mobility is widely deployed and no one wants to do > continual gathering and WiFi never turns off in the beginning of call setup, > then perhaps this is useless. But we have use cases in which we have > already found this useful. If twelve months from now you decide this wasn't worth doing, you'll simply go and take it out of your code. If by that time the document is out of editor's queue it will stay there. Emil >> Emil >> >> >> >> >> Emil >> >> >> >> >> >> >> Emil >> >> >> >> >> >> >> >> >> On Tuesday, 12 July 2016, Peter Thatcher >> >> >> wrote: >> >> >>> >> >> >>> I submitted draft-thatcher-ice-remove-candidate and would like to >> >> >>> speak >> >> >>> about in my allotted time on the agenda when I will also be >> >> >>> speaking >> >> >>> about >> >> >>> draft-thatcher-ice-network-cost and >> >> >>> draft-thatcher-ice-renomination. >> >> >>> >> >> >>> It's a very simple draft. Basically it says you can "remove" >> >> >>> candidates >> >> >>> just like trickle-ice allows you to add candidates. You could >> >> >>> probably >> >> >>> read >> >> >>> it in 3 minutes. Please do so: >> >> >>> >> >> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >> >> >>> >> >> >>> Thanks, >> >> >>> Peter (Chair hat off) >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> sent from my mobile >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> https://jitsi.org >> > >> > >> >> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Mon Jul 18 08:57: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 B38B012DA2A for ; Mon, 18 Jul 2016 08:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 pt95hMipedZi for ; Mon, 18 Jul 2016 08:57:00 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 DBD0212DA15 for ; Mon, 18 Jul 2016 08:56:59 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p74so161009279qka.0 for ; Mon, 18 Jul 2016 08:56:59 -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=UQak3pwCksnjJ6dzxnu8rmz8wybs4AQR1SQxPAIt/Ug=; b=LWa9r2MTOovGLmMR+zK3XBuFM8hdCkRIqJB254SzPWkHcFVBBEn20ia/INu1YzxI4F NO8dfHQhUeJcHAFdPb6CovaV3yvyL3IxWTvQowYnQEjukx1tDrazu1tq96Iup0ZpN6+k JoWtwHs1+MJ/7TAwnyOzM55YsjpWlfO4xGFTA80n94LoYB2Vkp8qSnzoY3bqKvSsQDYh 8I4HAIV9bCorJtc8/negchcct8LpCrPJj+irM7R0SzcTWqv3AAnriwe0f5OaZz8Y8EdW IvcVAVHe5B38HkSC/Bb3Qa7gGNr3QYo7K88WqVG7ZoLKDJo4L9NSjEehcidda1MIHLrt hlIg== 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=UQak3pwCksnjJ6dzxnu8rmz8wybs4AQR1SQxPAIt/Ug=; b=LeSFjYkRIJnOt5hMM0ydS9HrmDFuq6Lthi9FiAHwojLjftbfzbJwy40SIh4VxYN92F 1YRRFEnezmIZpi2EeTaBar23G25jxeI5sJkumvxKJKAwrlILTjjk3mDwOyAMLwtf5QMB 8ZguEPeElF9hjbLKH9aJ/KmBfqsigxCwEs0Eu6ALfgvBVKvl4nseZrzwzbGICUv8BzDB VwJwUGIxZVfTvQixsk7Rk5j92hx0GT10WIDdaVBffsX5346GutEjAmsPiUutP2JlIQ/X h3WDekG+vmNSpYy+mDPNOfCBokj3VExVncRLthewEeSQVw61nQ9HR+f7TVPFabTS9Xv3 JI5A== X-Gm-Message-State: ALyK8tKbYvJ1qMM0eq6frltFua1gIOIuhc8lUhKjv+VudfDTJbbqubbS93J3/aMSBb9nmhorWxqgPf2V2cOa2lEx X-Received: by 10.55.19.74 with SMTP id d71mr17138629qkh.118.1468857418796; Mon, 18 Jul 2016 08:56:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Mon, 18 Jul 2016 08:56:19 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 18 Jul 2016 08:56:19 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11401adcacb3ff0537eb0480 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 15:57:04 -0000 --001a11401adcacb3ff0537eb0480 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 4:38 AM, Emil Ivov wrote: > Hey Peter, > > On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher > wrote: > > > > > > On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov wrote: > >> > >> On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher > >> wrote: > >> > > >> > > >> > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: > >> >> > >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher < > pthatcher@google.com> > >> >> wrote: > >> >> > > >> >> > > >> >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov > wrote: > >> >> >> > >> >> >> Are there any cases where you think this would be useful other > than > >> >> >> abetter connection with a server? > >> >> > > >> >> > Yes: continual gathering (aka continuous nomination) would benefi= t > >> >> > from > >> >> > this. > >> >> > >> >> Last time we discussed continuous nomination (in Prague last year) = it > >> >> sounded to me that there were no arguments about what it was bringi= ng > >> >> on top of simple ICE restarts. It is my understanding that optimizi= ng > >> >> those (if at all necessary) was a more acceptable direction. > >> >> > >> >> So I don't think continuous nomination is a good argument here even > if > >> >> we keep waving it all over the place :) . > >> >> > >> > > >> > Continual gathering is a separate topic that we can save for another > >> > day. > >> > > >> >> > >> >> >> If all that is changing is the connection with the server then i= t > >> >> >> sounds > >> >> >> to me like we should rather come up with a way to update the loc= al > >> >> >> side > >> >> >> of > >> >> >> the binding and not bother the remote agent with it. > >> >> > > >> >> > That would be TURN mobility, or some new equivalent ( > >> >> > the TURN mobility draft has expired). > >> >> > >> >> Something like that yes. > >> >> > >> >> > That is an option that we'd like to > >> >> > explore implementing, but it's much more work to standardize, > >> >> > implement, > >> >> > and > >> >> > deploy (both on client and server). Whereas this is a simply > >> >> > mechanism > >> >> > that > >> >> > is quick to standardize, implement, and deply, and it's useful fo= r > >> >> > other > >> >> > things (as mentioned above). > >> >> > >> >> On a first glance the whole ICE idea is very simple and easy to > >> >> standardise, implement and deploy: gather and try everything. pick > >> >> what works. > >> >> > >> >> > >> >> I think 13 years after the initial idea was being floated on the IE= TF > >> >> we know better. > >> >> > >> >> In other words: > >> >> > >> >> First I don't think it's that simple at all. I am particularly > >> >> concerned about potential race conditions with the ICE state machin= e > >> >> and the trickling itself. Same for interactions with aggressive > >> >> nomination. > >> >> > >> >> Second, while we may be able to solve the above, I am worried that > the > >> >> increased complexity will not justify something that is a very > limited > >> >> solution to a more general problem. So we are setting the stage for > >> >> redundancy and that's not something we need with ICE. > >> >> > >> > > >> > It sounds like you are making the argument that ICE has reached some > >> > kind of > >> > "peak complexity" and can no longer be changed because it's already > too > >> > complex. Is that what you're claiming? > >> > >> And question the existence of this wonderful working group? No, of > course > >> not ;) > >> > >> What I am claiming is that ICE is too complex for *frivolous* updates > >> that are likely to be superseded by newer more complete solutions like > >> the one you mentioned in TRAM. > >> > > > > While I'm happy that TURN mobility is progressing, I expect it will be > some > > time before wide deployments TURN servers > > will have support for it. And clients working with TURN servers that > don't > > support mobility will find it useful to signal candidate removal. > > Sure. > > > And I thought of another case outside of TURN candidates and continual > > gathering where this is useful: when a network interface goes away at t= he > > beginning of ICE setup. It's useful to tell the remote side when this > > happens to possibly avoid checking useless candidates. > > This would be a bad way to handle if down events as it would only work > in a very limited window of time (at least the way it's currently > defined). > > > Oh, and another: if you have many TURN servers (say, 8), then you'll > have > > 8*8 =3D 64 TURN-TURN candidates pairs, unless you are capable of removi= ng > > candidates for worse TURN servers. TURN mobility doesn't help across > TURN > > servers (does it?) > > This makes no sense to me. If you are going to remove TURN candidates > as soon as you send them, then why the heck do you have 8 TURN servers > to begin with? > >> >> Also, have you done any measurements or estimates on exactly what w= e > >> >> are trying to optimize here? Some several hundred milliseconds of > >> >> streaming over TCP rather than UDP? > >> > > >> > > >> > I don't know what this has to do with TCP vs. UDP. > >> > > >> > The real world problem here is that if you have two network interfac= es > >> > (WiFi > >> > and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to > >> > each > >> > over TCP and UDP, you end up with 2 x 2 x 2 x 2 =3D 16 TURN candidat= es > (at > >> > least; this ignores TCP w/ TLS). Then both sides do that, and you > have > >> > 16 * > >> > 16 =3D 256 TURN-TURN candidate pairs. That's a lot. > >> > >> Except that it's not (necessarily) 256. > >> > >> > So how do you avoid that problem? > >> > >> Well to begin with you can simply apply the same logic as the one you > >> propose in your draft, but rather than doing it after sending > >> candidates, you apply it before. That is, you start by sending your > >> "better" candidates (the ones you wouldn't "deallocate" otherwise) and > >> you only send your less desirable ones if you fail to obtain the prime > >> candidates. > > > > > > Are you proposing to delay signaling the worse candidates? > > No. > > > I never like the > > idea of delaying candidates because you don't know that the "better" on= es > > will succeed or not. For example, if only TCP candidates work, how lon= g > do > > you wait before you give up on UDP candidates? Or if only cell works, > how > > long do you wait to give up on WiFi candidates? > > You don't need to implement explicit delays. You only need to order > your gathering and trickling according to the priority you desire. > Pacing will take care of the actual delays. > =E2=80=8BWhat does "order the gathering" mean? If I gather all the TURN ca= ndidates in parallel, I can't control which comes back first. And if I don't gather them all in parallel, then I'm delaying the gathering of some, which I don't want to do.=E2=80=8B =E2=80=8B > > >> This means that you would only end up with 256 if all of > >> your prime candidates failed during gathering but then suddenly > >> started working. Not a great likelihood for that to happen. On average > >> you'll probably have one or two that leak out (and when that happens > >> it might actually be an indication that your connection is better > >> there). > > > > > > > >> > >> > >> So, to be clear, I do agree that ending up with 256 candidates would > >> be a problem, especially given the 100 pairs MAX constraint 5245. > >> > >> What bothers me with this draft is not the problem though: it's that > >> the solution doesn't appear well thought out. For example: depending > >> on your timing it is not at all clear that you will be able to remove > >> candidates before you hit 100 pairs, before they start stun > >> transactions or before you've already wasted the time you want to > >> save. > > > > > > Actually, we did quite a lot of thinking through it. > > I am sure you have but this is not obvious from reading the document. > =E2=80=8B I take that as a sign that the document is simple.=E2=80=8B :) > > > We determined that if both sides remove worse TURN candidates and also > don't > > signal worse candidates, and also signal removal of worse candidates > before > > the addition of better candidates, > > I am having trouble parsing this sentence but "don't signal worse > candidates" sounds to me as the opposite of "signal removal". It depends on the order a candidate gets gathered in (which candidate returns from the server first). Assume A is better than B. If A comes before B, then signal A but not B. If B comes before A, signal B, then signal removal of B, then signal A. =E2=80=8B > My guess at this stage is that once you implement "non-signalling of > worse candidates" removal of worse candidates is going to have a very > marginal benefit. > =E2=80=8B =E2=80=8BAs long as the best candidates always finish first, you're then re= moval is useless. But if they don't, then removal is beneficial. That's all there is to it. If you think your best TURN candidates will always return first (or close), then don't bother with candidate removal. =E2=80=8B It's one of those "you don't need it until you do" type of things. Also, this is just one use case. We find the continual gathering use case even more compelling. > > > then in the worst case scenario, there > > are 2*N candidate pairs instead of N^2 candidates pairs. Which means i= n > > this example you would have 32 instead of 256. And that's the absolute > > worst case when all of your candidates are allocated in the worst > possible > > order, on both sides. In more normal circumstances, it would reduce to > far > > fewer. > > > >> > >> In other words, this whole thing may well turn out to be useless half > >> the time. > >> T > >> hat's the sort of extra complexity we don't need with ICE. > >> > >> > TURN mobility is one option, and I'd like to see TURN mobility > >> > happen. But candidate removal is also an option, and it's a lot mor= e > >> > simple. > >> > >> Again, I am not at all convinced of its purported simplicity and even > >> less its efficiency. > >> > > > > The whole draft is approximately one sentence if you subtract the boile= r > > plate. > > Yup. And that's pretty much my main problem. > > =E2=80=8BFirst you said it's too complex. Now you say it's too simple?=E2= =80=8B > I am very much missing a description of all possible states where a > removal signal can arrive and how the agent should behave under those > circumstances. > =E2=80=8BThis mechanism can be used for many different situations. It's no= t specific to gathering TURN candidates, so I don't think adding a bunch of TURN-gathering-specific text makes sense, if that's what you mean. =E2=80= =8B =E2=80=8B I also think we don't need to specify exactly what the receiving agent's behavior is, other than it SHOULD not pair with that candidate any more. The rest is up to the receiving agent. > I am also missing guidelines for when exactly removal signals should be > sent. > > =E2=80=8BWe don't need to specify that, because there are many different si= tuations where this could be used. It should send it when it wants the receiving agent to stop making new pairs with that candidate :). > > It's very easy to implement (it took us perhaps one day). And it's > > just an optimization, so it's not going to break anything. I don't kno= w > how > > much more simple it can get. > > > > In a world where TURN mobility is widely deployed and no one wants to d= o > > continual gathering and WiFi never turns off in the beginning of call > setup, > > then perhaps this is useless. But we have use cases in which we have > > already found this useful. > > If twelve months from now you decide this wasn't worth doing, you'll > simply go and take it out of your code. If by that time the document > is out of editor's queue it will stay there. > =E2=80=8BI don't quite follow you point here. You don't thing we should wo= rk on this because we might change our mind about this being useful? Isn't that true of *every* RFC (that we might change our minds)? But, to be clear: if no one else in the WG finds this useful, then it won't become a WG work item. But if other people *do* find it useful, then even if we change our minds, then someone else will still find it useful. Unless we all change our minds. Which is true of any draft/RFC. And even though it doesn't matter, I think we'll be keeping the code around because we find it an important part of continual gathering, and we find continual gathering important. > > Emil > > >> Emil > >> > >> >> > >> >> Emil > >> >> > >> >> > >> >> >> Emil > >> >> >> > >> >> >> > >> >> >> On Tuesday, 12 July 2016, Peter Thatcher > >> >> >> wrote: > >> >> >>> > >> >> >>> I submitted draft-thatcher-ice-remove-candidate and would like = to > >> >> >>> speak > >> >> >>> about in my allotted time on the agenda when I will also be > >> >> >>> speaking > >> >> >>> about > >> >> >>> draft-thatcher-ice-network-cost and > >> >> >>> draft-thatcher-ice-renomination. > >> >> >>> > >> >> >>> It's a very simple draft. Basically it says you can "remove" > >> >> >>> candidates > >> >> >>> just like trickle-ice allows you to add candidates. You could > >> >> >>> probably > >> >> >>> read > >> >> >>> it in 3 minutes. Please do so: > >> >> >>> > >> >> >>> > https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt > >> >> >>> > >> >> >>> Thanks, > >> >> >>> Peter (Chair hat off) > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> sent from my mobile > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> https://jitsi.org > >> > > >> > > >> > >> > >> > >> -- > >> https://jitsi.org > > > > > > > > -- > https://jitsi.org > --001a11401adcacb3ff0537eb0480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 18, 2016 at 4:38 AM, Emil Ivov &= lt;emcho@jitsi.org= > wrote:
Hey Peter,

On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher <pthatcher@google.com> wrote:
>
>
> On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher <pthatcher@google.com>
>> wrote:
>> >
>> >
>> > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov <emcho@jitsi.org> wrote:
>> >>
>> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <pthatcher@google.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <emcho@jitsi.org> wrote:
>> >> >>
>> >> >> Are there any cases where you think this would b= e useful other than
>> >> >> abetter connection with a server?
>> >> >
>> >> > Yes: continual gathering (aka continuous nomination)= would benefit
>> >> > from
>> >> > this.
>> >>
>> >> Last time we discussed continuous nomination (in Prague l= ast year) it
>> >> sounded to me that there were no arguments about what it = was bringing
>> >> on top of simple ICE restarts. It is my understanding tha= t optimizing
>> >> those (if at all necessary) was a more acceptable directi= on.
>> >>
>> >> So I don't think continuous nomination is a good argu= ment here even if
>> >> we keep waving it all over the place :) .
>> >>
>> >
>> > Continual gathering is a separate topic that we can save for = another
>> > day.
>> >
>> >>
>> >> >> If all that is changing is the connection with t= he server then it
>> >> >> sounds
>> >> >> to me like we should rather come up with a way t= o update the local
>> >> >> side
>> >> >> of
>> >> >> the binding and not bother the remote agent with= it.
>> >> >
>> >> > That would be TURN mobility, or some new equivalent = (
>> >> > the TURN mobility draft has expired).
>> >>
>> >> Something like that yes.
>> >>
>> >> > That is an option that we'd like to
>> >> > explore implementing, but it's much more work to= standardize,
>> >> > implement,
>> >> > and
>> >> > deploy (both on client and server).=C2=A0 Whereas th= is is a simply
>> >> > mechanism
>> >> > that
>> >> > is quick to standardize, implement, and deply, and i= t's useful for
>> >> > other
>> >> > things (as mentioned above).
>> >>
>> >> On a first glance the whole ICE idea is very simple and e= asy to
>> >> standardise, implement and deploy: gather and try everyth= ing. pick
>> >> what works.
>> >>
>> >>
>> >> I think 13 years after the initial idea was being floated= on the IETF
>> >> we know better.
>> >>
>> >> In other words:
>> >>
>> >> First I don't think it's that simple at all. I am= particularly
>> >> concerned about potential race conditions with the ICE st= ate machine
>> >> and the trickling itself. Same for interactions with aggr= essive
>> >> nomination.
>> >>
>> >> Second, while we may be able to solve the above, I am wor= ried that the
>> >> increased complexity will not justify something that is a= very limited
>> >> solution to a more general problem. So we are setting the= stage for
>> >> redundancy and that's not something we need with ICE.=
>> >>
>> >
>> > It sounds like you are making the argument that ICE has reach= ed some
>> > kind of
>> > "peak complexity" and can no longer be changed beca= use it's already too
>> > complex.=C2=A0 Is that what you're claiming?
>>
>> And question the existence of this wonderful working group? No, of= course
>> not ;)
>>
>> What I am claiming is that ICE is too complex for *frivolous* upda= tes
>> that are likely to be superseded by newer more complete solutions = like
>> the one you mentioned in TRAM.
>>
>
> While I'm happy that TURN mobility is progressing, I expect it wil= l be some
> time before wide deployments TURN servers
> will have support for it.=C2=A0 And clients working with TURN servers = that don't
> support mobility will find it useful to signal candidate removal.

Sure.

> And I thought of another case outside of TURN candidates and continual=
> gathering where this is useful: when a network interface goes away at = the
> beginning of ICE setup.=C2=A0 It's useful to tell the remote side = when this
> happens to possibly avoid checking useless candidates.

This would be a bad way to handle if down events as it would only wo= rk
in a very limited window of time (at least the way it's currently
defined).

> Oh, and another:=C2=A0 if you have many TURN servers (say, 8), then yo= u'll have
> 8*8 =3D 64 TURN-TURN candidates pairs, unless you are capable of remov= ing
> candidates for worse TURN servers.=C2=A0 TURN mobility doesn't hel= p across TURN
> servers (does it?)

This makes no sense to me. If you are going to remove TURN candidate= s
as soon as you send them, then why the heck do you have 8 TURN servers
to begin with?


>> >> Also, have you done any measurements or estimates on exac= tly what we
>> >> are trying to optimize here? Some several hundred millise= conds of
>> >> streaming over TCP rather than UDP?
>> >
>> >
>> > I don't know what this has to do with TCP vs. UDP.
>> >
>> > The real world problem here is that if you have two network i= nterfaces
>> > (WiFi
>> > and Cell) and ipv4 and ipv6 and 2 TURN servers and try to con= nect to
>> > each
>> > over TCP and UDP, you end up with 2 x 2 x 2 x 2 =3D 16 TURN c= andidates (at
>> > least; this ignores TCP w/ TLS).=C2=A0 Then both sides do tha= t, and you have
>> > 16 *
>> > 16 =3D 256 TURN-TURN candidate pairs. That's a lot.
>>
>> Except that it's not (necessarily) 256.
>>
>> > So how do you avoid that problem?
>>
>> Well to begin with you can simply apply the same logic as the one = you
>> propose in your draft, but rather than doing it after sending
>> candidates, you apply it before. That is, you start by sending you= r
>> "better" candidates (the ones you wouldn't "dea= llocate" otherwise) and
>> you only send your less desirable ones if you fail to obtain the p= rime
>> candidates.
>
>
> Are you proposing to delay signaling the worse candidates?

No.

> I never like the
> idea of delaying candidates because you don't know that the "= better" ones
> will succeed or not.=C2=A0 For example, if only TCP candidates work, h= ow long do
> you wait before you give up on UDP candidates?=C2=A0 =C2=A0Or if only = cell works, how
> long do you wait to give up on WiFi candidates?

You don't need to implement explicit delays. You only need to or= der
your gathering and trickling according to the priority you desire.
Pacing will take care of the actual delays.

=E2=80=8BW= hat does "order the gathering" mean?=C2=A0 If I gather all the TU= RN candidates in parallel, I can't control which comes back first.=C2= =A0 And if I don't gather them all in parallel, then I'm delaying t= he gathering of some, which I don't want to do.=E2=80=8B
=E2=80=8B=

=C2=A0

>> This means that you would only end up with 256 if all of
>> your prime candidates failed during gathering but then suddenly >> started working. Not a great likelihood for that to happen. On ave= rage
>> you'll probably have one or two that leak out (and when that h= appens
>> it might actually be an indication that your connection is better<= br> >> there).
>
>
>
>>
>>
>> So, to be clear, I do agree that ending up with 256 candidates wou= ld
>> be a problem, especially given the 100 pairs MAX constraint 5245.<= br> >>
>> What bothers me with this draft is not the problem though: it'= s that
>> the solution doesn't appear well thought out. For example: dep= ending
>> on your timing it is not at all clear that you will be able to rem= ove
>> candidates before you hit 100 pairs, before they start stun
>> transactions or before you've already wasted the time you want= to
>> save.
>
>
> Actually, we did quite a lot of thinking through it.

I am sure you have but this is not obvious from reading the document= .
=E2=80=8B
I take that as a sign t= hat the document is simple.=E2=80=8B :)
=C2=A0
=

> We determined that if both sides remove worse TURN candidates and also= don't
> signal worse candidates, and also signal removal of worse candidates b= efore
> the addition of better candidates,

I am having trouble parsing this sentence but "don't signal= worse
candidates" sounds to me as the opposite of "signal removal"= .=C2=A0

It depends on the order a candi= date gets gathered in (which candidate returns from the server first).=C2= =A0 Assume A is better than B.=C2=A0 If A comes before B, then signal A but= not B.=C2=A0 If B comes before A, signal B, then signal removal of B, then= signal A. =C2=A0=E2=80=8B

=C2=A0
My guess at this stage is that once you implement "non-signalling of worse candidates" removal of worse candidates is going to have a very<= br> marginal benefit.
=E2=80=8B
=E2=80=8BAs long as th= e best candidates always finish first, you're then removal is useless.= =C2=A0 But if they don't, then removal is beneficial. =C2=A0 That's= all there is to it.=C2=A0 If you think your best TURN candidates will alwa= ys return first (or close), then don't bother with candidate removal. = =C2=A0
=E2=80=8B=C2=A0
It's one of those "yo= u don't need it until you do" type of things.


Also, this is just one use case.=C2=A0 We find the continual = gathering use case even more compelling.
=C2=A0

> then in the worst case scenario, there
> are 2*N candidate pairs instead of N^2 candidates pairs.=C2=A0 Which m= eans in
> this example you would have 32 instead of 256.=C2=A0 And that's th= e absolute
> worst case when all of your candidates are allocated in the worst poss= ible
> order, on both sides.=C2=A0 In more normal circumstances, it would red= uce to far
> fewer.
>
>>
>> In other words, this whole thing may well turn out to be useless h= alf
>> the time.
>> T
>> hat's the sort of extra complexity we don't need with ICE.=
>>
>> > TURN mobility is one option, and I'd like to see TURN mob= ility
>> > happen.=C2=A0 But candidate removal is also an option, and it= 's a lot more
>> > simple.
>>
>> Again, I am not at all convinced of its purported simplicity and e= ven
>> less its efficiency.
>>
>
> The whole draft is approximately one sentence if you subtract the boil= er
> plate.

Yup. And that's pretty much my main problem.


=E2=80=8BFirst you said it's to= o complex.=C2=A0 Now you say it's too simple?=E2=80=8B

<= div>=C2=A0
I am very much missing a description of all possible states where a
removal signal can arrive and how the agent should behave under those
circumstances.

=E2=80=8BThis mechanism can be used for= many different situations.=C2=A0 It's not specific to gathering TURN c= andidates, so I don't think adding a bunch of TURN-gathering-specific t= ext makes sense, if that's what you mean. =C2=A0=E2=80=8B
=E2=80= =8B

I also think we don't need to sp= ecify exactly what the receiving agent's behavior is, other than it SHO= ULD not pair with that candidate any more.=C2=A0 The rest is up to the rece= iving agent. =C2=A0



=E2=80=8BWe= don't need to specify that, because there are many different situation= s where this could be used. =C2=A0 It should send it when it wants the rece= iving agent to stop making new pairs with that candidate :).
=C2=A0
>=C2=A0 It's very easy to implement (it took us perhaps one day).=C2= =A0 And it's
> just an optimization, so it's not going to break anything.=C2=A0 I= don't know how
> much more simple it can get.
>
> In a world where TURN mobility is widely deployed and no one wants to = do
> continual gathering and WiFi never turns off in the beginning of call = setup,
> then perhaps this is useless.=C2=A0 =C2=A0 But we have use cases in wh= ich we have
> already found this useful.

If twelve months from now you decide this wasn't worth doing, yo= u'll
simply go and take it out of your code. If by that time the document
is out of editor's queue it will stay there.

<= /div>
=E2=80=8BI don't quite follow you point here.=C2=A0 You do= n't thing we should work on this because we might change our mind about= this being useful?=C2=A0 Isn't that true of *every* RFC (that we might= change our minds)?

But, to be clear: if no one else i= n the WG finds this useful, then it won't become a WG work item. =C2=A0= But if other people *do* find it useful, then even if we change our minds,= then someone else will still find it useful.=C2=A0 Unless we all change ou= r minds.=C2=A0 Which is true of any draft/RFC.

And eve= n though it doesn't matter, I think we'll be keeping the code aroun= d because we find it an important part of continual gathering, and we find = continual gathering important.

=C2=A0

Emil

>> Emil
>>
>> >>
>> >> Emil
>> >>
>> >>
>> >> >> Emil
>> >> >>
>> >> >>
>> >> >> On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> I submitted draft-thatcher-ice-remove-candid= ate and would like to
>> >> >>> speak
>> >> >>> about in my allotted time on the agenda when= I will also be
>> >> >>> speaking
>> >> >>> about
>> >> >>> draft-thatcher-ice-network-cost and
>> >> >>> draft-thatcher-ice-renomination.
>> >> >>>
>> >> >>> It's a very simple draft. Basically it s= ays you can "remove"
>> >> >>> candidates
>> >> >>> just like trickle-ice allows you to add cand= idates. You could
>> >> >>> probably
>> >> >>> read
>> >> >>> it in 3 minutes. Please do so:
>> >> >>>
>> >> >>> htt= ps://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Peter (Chair hat off)
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> sent from my mobile
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> https://jitsi.org
>> >
>> >
>>
>>
>>
>> --
>> https://jitsi.org
>
>



--
https://= jitsi.org

--001a11401adcacb3ff0537eb0480-- From nobody Mon Jul 18 09:24: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 3D32712DAEA for ; Mon, 18 Jul 2016 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj8DCiITSg8P for ; Mon, 18 Jul 2016 09:24:12 -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 710E812DAE7 for ; Mon, 18 Jul 2016 09:24:07 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id r9so14645661ywg.0 for ; Mon, 18 Jul 2016 09:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SqGbcNJA1x4XsK7M6yeaUWUAaR/ioQr9vFEMivV/AT0=; b=O3MK4RyuL2FWvGvN9wIuLGVyJU9ZHcez9mP3D/2yrTD0D2dibNVMsFyX4zavT/Cimz nG8zRd7EgtCWX5/SrtV8Y2mY2blKZLuq+GU26WtPU42gmz057FTu8mNEeck+jGXp+BUc UTAW7WmEsJ3IAkAwCsQt7/KWyXwDT4oNESMW1iO8Rmk62VRsFEpGoQGsdHAWz+1kf0zo jkDz2vHU2xjSHfVkVpWVtUc5mnWHcbAa2ltdMVgSulVUNZWB3iLedcqlYvTlCMRX0kG5 VTafdusHswMetsMUjbIL/FTDRIYlUXTFBpM6pe9I+l49X9kocYG4PemphEX30jgXJ70I eVbw== 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=SqGbcNJA1x4XsK7M6yeaUWUAaR/ioQr9vFEMivV/AT0=; b=fyfgVIDXGwHR22e257x950lqZEnB7QU3yuks7i0e5aFjly7qh83kmxZpW07EDMDEVE SEd0WDStHIAHM2EBLe+4245PWgbp6x+GgEXerT3pDq6lAtUiGHslNcdRB53VSPpgImyv oqLyc4tdt20dhzMFr26G+mwhX2xGuVrknL7e970HKDOcqC4gQxBk3Onc32mxaG+vsqec yUsr64s9lmeVQlKRc9cMNSacSSCo4FB5JGWVZy1S9F+AOVhv5m9UnzSI7KSOArCyHTSp DTrk65WLTT01JYO0aXMVMa8LX8+faJ0TdFA3U/WDgjpZXbymPhD4rxbO1diJHpqkl7aS 2qow== X-Gm-Message-State: ALyK8tI0Eh1UlVwzaaTtowDRa48QjBWiAXCOwtBsigCrkUYvogcEBvxff2HOB2sVOtM78Q== X-Received: by 10.37.112.139 with SMTP id l133mr23290151ybc.144.1468859046297; Mon, 18 Jul 2016 09:24:06 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com. [209.85.161.179]) by smtp.gmail.com with ESMTPSA id h62sm11113802ywd.46.2016.07.18.09.24.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 09:24:06 -0700 (PDT) Received: by mail-yw0-f179.google.com with SMTP id c124so37276062ywd.3 for ; Mon, 18 Jul 2016 09:24:05 -0700 (PDT) X-Received: by 10.129.89.66 with SMTP id n63mr24738546ywb.239.1468859045398; Mon, 18 Jul 2016 09:24:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Mon, 18 Jul 2016 09:23:45 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Mon, 18 Jul 2016 18:23:45 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 16:24:15 -0000 On Mon, Jul 18, 2016 at 5:56 PM, Peter Thatcher wrote: > > > On Mon, Jul 18, 2016 at 4:38 AM, Emil Ivov wrote: >> >> Hey Peter, >> >> On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher >> wrote: >> > >> > >> > On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov wrote: >> >> >> >> On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher >> >> wrote: >> >> > >> >> > >> >> > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov wrote: >> >> >> >> >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher >> >> >> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov >> >> >> > wrote: >> >> >> >> >> >> >> >> Are there any cases where you think this would be useful other >> >> >> >> than >> >> >> >> abetter connection with a server? >> >> >> > >> >> >> > Yes: continual gathering (aka continuous nomination) would benefit >> >> >> > from >> >> >> > this. >> >> >> >> >> >> Last time we discussed continuous nomination (in Prague last year) >> >> >> it >> >> >> sounded to me that there were no arguments about what it was >> >> >> bringing >> >> >> on top of simple ICE restarts. It is my understanding that >> >> >> optimizing >> >> >> those (if at all necessary) was a more acceptable direction. >> >> >> >> >> >> So I don't think continuous nomination is a good argument here even >> >> >> if >> >> >> we keep waving it all over the place :) . >> >> >> >> >> > >> >> > Continual gathering is a separate topic that we can save for another >> >> > day. >> >> > >> >> >> >> >> >> >> If all that is changing is the connection with the server then it >> >> >> >> sounds >> >> >> >> to me like we should rather come up with a way to update the >> >> >> >> local >> >> >> >> side >> >> >> >> of >> >> >> >> the binding and not bother the remote agent with it. >> >> >> > >> >> >> > That would be TURN mobility, or some new equivalent ( >> >> >> > the TURN mobility draft has expired). >> >> >> >> >> >> Something like that yes. >> >> >> >> >> >> > That is an option that we'd like to >> >> >> > explore implementing, but it's much more work to standardize, >> >> >> > implement, >> >> >> > and >> >> >> > deploy (both on client and server). Whereas this is a simply >> >> >> > mechanism >> >> >> > that >> >> >> > is quick to standardize, implement, and deply, and it's useful for >> >> >> > other >> >> >> > things (as mentioned above). >> >> >> >> >> >> On a first glance the whole ICE idea is very simple and easy to >> >> >> standardise, implement and deploy: gather and try everything. pick >> >> >> what works. >> >> >> >> >> >> >> >> >> I think 13 years after the initial idea was being floated on the >> >> >> IETF >> >> >> we know better. >> >> >> >> >> >> In other words: >> >> >> >> >> >> First I don't think it's that simple at all. I am particularly >> >> >> concerned about potential race conditions with the ICE state machine >> >> >> and the trickling itself. Same for interactions with aggressive >> >> >> nomination. >> >> >> >> >> >> Second, while we may be able to solve the above, I am worried that >> >> >> the >> >> >> increased complexity will not justify something that is a very >> >> >> limited >> >> >> solution to a more general problem. So we are setting the stage for >> >> >> redundancy and that's not something we need with ICE. >> >> >> >> >> > >> >> > It sounds like you are making the argument that ICE has reached some >> >> > kind of >> >> > "peak complexity" and can no longer be changed because it's already >> >> > too >> >> > complex. Is that what you're claiming? >> >> >> >> And question the existence of this wonderful working group? No, of >> >> course >> >> not ;) >> >> >> >> What I am claiming is that ICE is too complex for *frivolous* updates >> >> that are likely to be superseded by newer more complete solutions like >> >> the one you mentioned in TRAM. >> >> >> > >> > While I'm happy that TURN mobility is progressing, I expect it will be >> > some >> > time before wide deployments TURN servers >> > will have support for it. And clients working with TURN servers that >> > don't >> > support mobility will find it useful to signal candidate removal. >> >> Sure. >> >> > And I thought of another case outside of TURN candidates and continual >> > gathering where this is useful: when a network interface goes away at >> > the >> > beginning of ICE setup. It's useful to tell the remote side when this >> > happens to possibly avoid checking useless candidates. >> >> This would be a bad way to handle if down events as it would only work >> in a very limited window of time (at least the way it's currently >> defined). >> >> > Oh, and another: if you have many TURN servers (say, 8), then you'll >> > have >> > 8*8 = 64 TURN-TURN candidates pairs, unless you are capable of removing >> > candidates for worse TURN servers. TURN mobility doesn't help across >> > TURN >> > servers (does it?) >> >> This makes no sense to me. If you are going to remove TURN candidates >> as soon as you send them, then why the heck do you have 8 TURN servers >> to begin with? > > >> >> >> >> Also, have you done any measurements or estimates on exactly what we >> >> >> are trying to optimize here? Some several hundred milliseconds of >> >> >> streaming over TCP rather than UDP? >> >> > >> >> > >> >> > I don't know what this has to do with TCP vs. UDP. >> >> > >> >> > The real world problem here is that if you have two network >> >> > interfaces >> >> > (WiFi >> >> > and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to >> >> > each >> >> > over TCP and UDP, you end up with 2 x 2 x 2 x 2 = 16 TURN candidates >> >> > (at >> >> > least; this ignores TCP w/ TLS). Then both sides do that, and you >> >> > have >> >> > 16 * >> >> > 16 = 256 TURN-TURN candidate pairs. That's a lot. >> >> >> >> Except that it's not (necessarily) 256. >> >> >> >> > So how do you avoid that problem? >> >> >> >> Well to begin with you can simply apply the same logic as the one you >> >> propose in your draft, but rather than doing it after sending >> >> candidates, you apply it before. That is, you start by sending your >> >> "better" candidates (the ones you wouldn't "deallocate" otherwise) and >> >> you only send your less desirable ones if you fail to obtain the prime >> >> candidates. >> > >> > >> > Are you proposing to delay signaling the worse candidates? >> >> No. >> >> > I never like the >> > idea of delaying candidates because you don't know that the "better" >> > ones >> > will succeed or not. For example, if only TCP candidates work, how long >> > do >> > you wait before you give up on UDP candidates? Or if only cell works, >> > how >> > long do you wait to give up on WiFi candidates? >> >> You don't need to implement explicit delays. You only need to order >> your gathering and trickling according to the priority you desire. >> Pacing will take care of the actual delays. > > > What does "order the gathering" mean? If I gather all the TURN candidates > in parallel, I can't control which comes back first. And if I don't gather > them all in parallel, then I'm delaying the gathering of some, which I don't > want to do. You might want to check this as a memory refresher: https://tools.ietf.org/html/rfc5245#appendix-B.1 Once you start pacing the gathering, ordering is pretty much implied. Once you have ordering and pacing in place, then better candidates will come first. If they don't, then why are you assuming they are better? >> >> This means that you would only end up with 256 if all of >> >> your prime candidates failed during gathering but then suddenly >> >> started working. Not a great likelihood for that to happen. On average >> >> you'll probably have one or two that leak out (and when that happens >> >> it might actually be an indication that your connection is better >> >> there). >> > >> > >> > >> >> >> >> >> >> So, to be clear, I do agree that ending up with 256 candidates would >> >> be a problem, especially given the 100 pairs MAX constraint 5245. >> >> >> >> What bothers me with this draft is not the problem though: it's that >> >> the solution doesn't appear well thought out. For example: depending >> >> on your timing it is not at all clear that you will be able to remove >> >> candidates before you hit 100 pairs, before they start stun >> >> transactions or before you've already wasted the time you want to >> >> save. >> > >> > >> > Actually, we did quite a lot of thinking through it. >> >> I am sure you have but this is not obvious from reading the document. > > I take that as a sign that the document is simple. :) This discussion is becoming more and more productive with every mail. >> > We determined that if both sides remove worse TURN candidates and also >> > don't >> > signal worse candidates, and also signal removal of worse candidates >> > before >> > the addition of better candidates, >> >> I am having trouble parsing this sentence but "don't signal worse >> candidates" sounds to me as the opposite of "signal removal". > > It depends on the order a candidate gets gathered in (which candidate > returns from the server first). Assume A is better than B. If A comes > before B, then signal A but not B. If B comes before A, signal B, then > signal removal of B, then signal A. So you sent an AR to A first (because that's the one you prefered), then applied your pacing timeout, then sent an AR to B. 1. It is most likely that A *will* come back before B which means that the likelyhood of you needing to remove B is low and hence the gain from that removal is low. 2. If B did come back before A, then is it really a good idea to remove A given that it obviously didn't perform great? >> My guess at this stage is that once you implement "non-signalling of >> worse candidates" removal of worse candidates is going to have a very >> marginal benefit. > > > As long as the best candidates always finish first, you're then removal is > useless. But if they don't, then removal is beneficial. That's all there > is to it. If you think your best TURN candidates will always return first > (or close), then don't bother with candidate removal. I expect that most of the time they will come first and I expect that when they don't then my assumption that they were best is potentially flawed. > It's one of those "you don't need it until you do" type of things. > Also, this is just one use case. We find the continual gathering use case > even more compelling. Continual gathering? Do you mean continuous nomination? If you do then I thought we agreed not to go down that rabbit hole ... mostly because there is currently no such thing as continuous nomination. >> > then in the worst case scenario, there >> > are 2*N candidate pairs instead of N^2 candidates pairs. Which means in >> > this example you would have 32 instead of 256. And that's the absolute >> > worst case when all of your candidates are allocated in the worst >> > possible >> > order, on both sides. In more normal circumstances, it would reduce to >> > far >> > fewer. >> > >> >> >> >> In other words, this whole thing may well turn out to be useless half >> >> the time. >> >> T >> >> hat's the sort of extra complexity we don't need with ICE. >> >> >> >> > TURN mobility is one option, and I'd like to see TURN mobility >> >> > happen. But candidate removal is also an option, and it's a lot more >> >> > simple. >> >> >> >> Again, I am not at all convinced of its purported simplicity and even >> >> less its efficiency. >> >> >> > >> > The whole draft is approximately one sentence if you subtract the boiler >> > plate. >> >> Yup. And that's pretty much my main problem. >> > > First you said it's too complex. Now you say it's too simple? Yes. The document is way too simple for a problem and a solution that are significantly more complex. >> I am very much missing a description of all possible states where a >> removal signal can arrive and how the agent should behave under those >> circumstances. > > > This mechanism can be used for many different situations. It's not specific > to gathering TURN candidates, so I don't think adding a bunch of > TURN-gathering-specific text makes sense, if that's what you mean. Well, let's show at least some clearly defined cases where this indisputably makes sense then explain why it does and exactly how it should be done. > I also think we don't need to specify exactly what the receiving agent's > behavior is, other than it SHOULD not pair with that candidate any more. > The rest is up to the receiving agent. Well, if we only care about syntax and are not going to hold ourselves to a standard where demonstrating gain is a requirement then ... In that case I suggest we also specify a document that let's you add an ICE signal for advertising your favorite spaghetti brand. >> I am also missing guidelines for when exactly removal signals should be >> sent. >> > > We don't need to specify that, because there are many different situations > where this could be used. It should send it when it wants the receiving > agent to stop making new pairs with that candidate :). > >> >> > It's very easy to implement (it took us perhaps one day). And it's >> > just an optimization, so it's not going to break anything. I don't know >> > how >> > much more simple it can get. >> > >> > In a world where TURN mobility is widely deployed and no one wants to do >> > continual gathering and WiFi never turns off in the beginning of call >> > setup, >> > then perhaps this is useless. But we have use cases in which we have >> > already found this useful. >> >> If twelve months from now you decide this wasn't worth doing, you'll >> simply go and take it out of your code. If by that time the document >> is out of editor's queue it will stay there. > > > I don't quite follow you point here. You don't thing we should work on this > because we might change our mind about this being useful? Isn't that true > of *every* RFC (that we might change our minds)? > But, to be clear: if no one else in the WG finds this useful, then it won't > become a WG work item. > But if other people *do* find it useful, then even > if we change our minds, then someone else will still find it useful. Unless > we all change our minds. Which is true of any draft/RFC. This argument makes no sense to me. The fact that some rockets may explode during a launch is not a reason to stop making every possible effort that they don't. The IETF certainly does try to minimize the number of unused RFCs even if that goal would never be 100% achieved. Emil > And even though it doesn't matter, I think we'll be keeping the code around > because we find it an important part of continual gathering, and we find > continual gathering important. > > >> >> >> Emil >> >> >> Emil >> >> >> >> >> >> >> >> Emil >> >> >> >> >> >> >> >> >> >> Emil >> >> >> >> >> >> >> >> >> >> >> >> On Tuesday, 12 July 2016, Peter Thatcher >> >> >> >> wrote: >> >> >> >>> >> >> >> >>> I submitted draft-thatcher-ice-remove-candidate and would like >> >> >> >>> to >> >> >> >>> speak >> >> >> >>> about in my allotted time on the agenda when I will also be >> >> >> >>> speaking >> >> >> >>> about >> >> >> >>> draft-thatcher-ice-network-cost and >> >> >> >>> draft-thatcher-ice-renomination. >> >> >> >>> >> >> >> >>> It's a very simple draft. Basically it says you can "remove" >> >> >> >>> candidates >> >> >> >>> just like trickle-ice allows you to add candidates. You could >> >> >> >>> probably >> >> >> >>> read >> >> >> >>> it in 3 minutes. Please do so: >> >> >> >>> >> >> >> >>> >> >> >> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt >> >> >> >>> >> >> >> >>> Thanks, >> >> >> >>> Peter (Chair hat off) -- https://jitsi.org From nobody Wed Jul 20 14:51:45 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 9262112D8B0; Wed, 20 Jul 2016 14:51:43 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160720215143.26470.87950.idtracker@ietfa.amsl.com> Date: Wed, 20 Jul 2016 14:51:43 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-trickle-03.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: Wed, 20 Jul 2016 21:51:43 -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-03.txt Pages : 26 Date : 2016-07-20 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-03 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 Wed Jul 20 16:47: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 8F4CD12D850 for ; Wed, 20 Jul 2016 16:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 Slb6eDJN9zOv for ; Wed, 20 Jul 2016 16:47:50 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 C994812D7C1 for ; Wed, 20 Jul 2016 16:47:49 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 52so35176701qtq.3 for ; Wed, 20 Jul 2016 16:47:49 -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=oS9lNFPdscl+rmODJ9AfK/G8WkMLvK+yEDUmbyx2o6M=; b=HfkZ+vW61P1qDoxYvOvbOU+qGzw7d2ZKKzNGsPQzS2f9nUZCkj4xSSd020GurMFtgj SJpjmPkYBzUdrCcZe2CJC7FyjVNaEuhC6GS1+W3cSw/eTZFHP8cFjR6O5YYzK0ygaLvN xg+vWA4sODG0qPxPD40IK1xJB7paU0TlFdMWgKntXqJqhMGmPjxWRUAO+tZ2N8tnGXR2 1F5ZnMdsPFbgOniRaHBocejj00bpoT3SY8UcBmJjfyJRrAY2cnbpczd0UT2cQIyvMaOb tR3TlwzhLFfJ7Q//qEaD8QSCgpBS+KN9HdQRWahrOVcO1ISZX9iWUKQGSrcx1K5R31NK VRQw== 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=oS9lNFPdscl+rmODJ9AfK/G8WkMLvK+yEDUmbyx2o6M=; b=fCAy0nr0ywB9JymrWaLoLA75macbk56q59ZDviyljEwLySfhce1Uepv0fgfuiW+bHR 6KDxQ7er0EGyvUxMIcvpUNDlWeReFj9Dw5Jk3yiPdV/Vr1tMPBs1cQxET9TzEkV+GtqH NXJGp+6MrUXIjeRcg/Lbu7mkZmTBwFMfMOFAueRIn0dzXifCb9CoJxjjtARHVk6RpSVR KAxfK9KxJXq2NPDV0mB++9wGutzK9H9RdB8vH502Mn9FQU5M09dZHbO4E00113f/UpJR U6DMj6JJLlhQ7RsmGeOJkUjgbdFG+mpGjIwIcFMrtr9pvZHBuklCfUia3dgRu+WcE6sf EKmw== X-Gm-Message-State: AEkooutG1Xk8Q9qLbxRUjSZI5NTgY0pQZrJcCJlN4zWOrtiy4/AwXYTz7rbvcVssOg/G190tHzTfaGudvCY50+gd X-Received: by 10.200.44.213 with SMTP id 21mr5117604qtx.91.1469058468724; Wed, 20 Jul 2016 16:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Wed, 20 Jul 2016 16:47:09 -0700 (PDT) From: Peter Thatcher Date: Wed, 20 Jul 2016 16:47:09 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a1145711c2f2474053819d48f Archived-At: Subject: [Ice] Plan for handling trickle unfreezing 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, 20 Jul 2016 23:47:56 -0000 --001a1145711c2f2474053819d48f Content-Type: text/plain; charset=UTF-8 Justin brought up an issue with trickle unfreezing mixed with the 5245 "unfreeze the whole checklist" loop. We've had some off-list discussions about what we can do and we've come up with the following plan: 1. Keep the "for every foundation, unfreeze the 'top' candidate you have received so far" that we came up with in Buenos Aires. It's already in the trickle draft. 2. Remove the "unfreeze the whole checklist" loop in 5245bis and replace it with a new unfreezing rule to 5245bis: unfreeze the 'top' candidate for every foundation. This fixes the problem Justin brought up while maintaining the reason that loop exists in the first place (as far as we can tell). It also makes the behavior consistent between non-trickle and trickle when candidates are trickled in order. It also makes 5245bis less complex. #1 is already. #2 will be discussed at the WG meeting during the time slot for 5245bis. --001a1145711c2f2474053819d48f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin brought up an issue with trickle unfreezing mixe= d with the 5245 "unfreeze the whole checklist" loop. =C2=A0 We= 9;ve had some off-list discussions about what we can do and we've come = up with the following plan:

1.=C2=A0 Keep the "for every foundation,= unfreeze the 'top' candidate you have received so far" that w= e came up with in Buenos Aires.=C2=A0 It's already in the trickle draft= .

2.=C2=A0 Remove the &= quot;unfreeze the whole checklist" loop in 5245bis and replace it with= a=C2=A0new unfreezing rule to 5245bis: un= freeze the 'top' candidate for every foundation.=C2=A0=C2=A0=

This fixes the probl= em Justin brought up while maintaining the reason that loop exists in the f= irst place (as far as we can tell).=C2=A0 It also=C2=A0makes the behavior consistent between non-trickle and t= rickle when candidates are trickled in order.=C2=A0 It also makes 5245bis l= ess complex. =C2=A0

#1 is already.

#2 will be discussed at the WG meeting during the time slot for 5245bis.=

--001a1145711c2f2474053819d48f-- From nobody Wed Jul 20 22:37:36 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A2012DA19 for ; Wed, 20 Jul 2016 22:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 1k9vF7yH_QBB for ; Wed, 20 Jul 2016 22:37:32 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 C147B12D9F1 for ; Wed, 20 Jul 2016 22:37:31 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o80so9810044wme.1 for ; Wed, 20 Jul 2016 22:37:31 -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=Q/s29CggXlwTa35cXb8HkPEpFBu2CnIpmOaaqZTNLYg=; b=OmKG98gXVJCyimU6Y+PfvlGwB4M9++j+UwFi12D4VAu4GrNTuGLFdsXZ1pJlfRo8IE 3N0K8gK2zFuFrtFdreyyxY1dzXjJvm/Lr7JIUg3qSqs/2P/koiswLddew7McQozD0v/p jY8J1FC7WIBOCnE6l6jb+Eqxla7zOol1zzcI0jx1d9Jm4/KeawX59YCphLWiSMt9RFj+ D6iHqkk83i5Wu35OYV6cK5Rm6JVqDvhTbmkjU0RFD7qO2HRpvfLjr7eFsLB4CQ7P62RU JaJxa1urifrGKNLEhL5UJ4OtuqbNREsyvQHvo+5akHcdgolt9qAvwAfb+/mRA5PgLiAi Vtwg== 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=Q/s29CggXlwTa35cXb8HkPEpFBu2CnIpmOaaqZTNLYg=; b=CvmBa1cXavvpDXKUID13WYuEzcqTwd5xj5ulWkGuUyi/8Q6kWIpvaWaiFSVV7otXsl DOS7FT2tj4rMQefYL3LksvR+lG6zACkChNmqzJTX1R57LJCkPFiZZWrGm0Al/NfAaC06 s6JyL5OwSuungu0ps7Stmru6K89N0nbkHxNv72OabLs+ONXimzHerwoTLOzSLb2Adwaq yxOexHnL59PM03oNMhzU7mQI7khIfYn0Wt3oUE6CU1BYRIgzmnCbgmAUF97eaSyEEyIw Iap1thkGLHhB4r/xObG59A6afDLCCr1HFPnlptvkMxQ9hrSI33nJOgb8z8Z0s+EYJkm3 6p5Q== X-Gm-Message-State: ALyK8tLWGQsuRaLlaZ05Z0o61YiL1Ef05xFxOvUjOKVCLJBvcyeudAo+ZYf/G8ucHVW4q2mu5GLo8u6bNHmUxAYH X-Received: by 10.194.99.11 with SMTP id em11mr4725651wjb.8.1469079450182; Wed, 20 Jul 2016 22:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.207.199 with HTTP; Wed, 20 Jul 2016 22:37:10 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 20 Jul 2016 22:37:10 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=089e0103e084c6c8d805381eb616 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Plan for handling trickle unfreezing 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, 21 Jul 2016 05:37:34 -0000 --089e0103e084c6c8d805381eb616 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2016 at 4:47 PM, Peter Thatcher wrote: > Justin brought up an issue with trickle unfreezing mixed with the 5245 > "unfreeze the whole checklist" loop. We've had some off-list discussions > about what we can do and we've come up with the following plan: > > 1. Keep the "for every foundation, unfreeze the 'top' candidate you have > received so far" that we came up with in Buenos Aires. It's already in the > trickle draft. > In this context, I assume 'top' == 'highest priority candidate for the lowest-index m= line'? > > 2. Remove the "unfreeze the whole checklist" loop in 5245bis and replace > it with a new unfreezing rule to 5245bis: unfreeze the 'top' candidate > for every foundation. > Is 'top' the same definition here? And do 'non-top' candidates only get unfrozen when the 'top' one succeeds (or times out)? If so, this seems sensible to me, as it preserves the general goal of freezing (don't check things that are redundant) without adding extra delay. > This fixes the problem Justin brought up while maintaining the reason that > loop exists in the first place (as far as we can tell). It also makes > the behavior consistent between non-trickle and trickle when candidates are > trickled in order. It also makes 5245bis less complex. > > #1 is already. > > #2 will be discussed at the WG meeting during the time slot for 5245bis. > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --089e0103e084c6c8d805381eb616 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 20, 2016 at 4:47 PM, Peter Thatcher <<= a href=3D"mailto:pthatcher@google.com" target=3D"_blank">pthatcher@google.c= om> wrote:
Justin brought up an= issue with trickle unfreezing mixed with the 5245 "unfreeze the whole= checklist" loop. =C2=A0 We've had some off-list discussions about= what we can do and we've come up with the following plan:

1.=C2= =A0 Keep the "for every foundation, unfreeze the 'top' candida= te you have received so far" that we came up with in Buenos Aires.=C2= =A0 It's already in the trickle draft.

In this context, I assume 'top' =3D=3D 'highe= st priority candidate for the lowest-index m=3D line'?

2.=C2=A0 Remove the "unfreeze the whole checklist"= loop in 5245bis and replace it with a=C2=A0new unfreezing rule to 5245bis: unfreeze the 'top' candidate for = every foundation.=C2=A0=C2=A0
Is 'top' the same definition here? And do 'non-top&= #39; candidates only get unfrozen when the 'top' one succeeds (or t= imes out)?

If so, this seems sensible to me, as it= preserves the general goal of freezing (don't check things that are re= dundant) without adding extra delay.



This fixes the problem Justin brought up while mainta= ining the reason that loop exists in the first place (as far as we can tell= ).=C2=A0 It also=C2=A0makes the beh= avior consistent between non-trickle and trickle when candidates are trickl= ed in order.=C2=A0 It also makes 5245bis less complex. =C2=A0
<= div style=3D"font-size:12.8px">
=
#1 i= s already.

#2 will be discussed at the WG meeting during the tim= e slot for 5245bis.


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


--089e0103e084c6c8d805381eb616-- From nobody Wed Jul 20 22:53:54 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 CAB4612D799 for ; Wed, 20 Jul 2016 22:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-bdx1aUG42G for ; Wed, 20 Jul 2016 22:53:50 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6E412D18D for ; Wed, 20 Jul 2016 22:53:49 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id r9so65709602ywg.0 for ; Wed, 20 Jul 2016 22:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fnkf0gvWPGmhXE6/0+GgWj+bv8w4jYntecxa7ehfW0w=; b=uxVCILucPlx7Bzd4xQxecyqvNSt/a4pftpiDRdhXxyM32E9HwOT/G5cCPhaWx4r4vm XAkxH/f19DrwUPm4M+Iu7VY6nczuS5jIFP//btrxC+8mUg5WzQ/KGX9+ncciGst6cAvK yt4XHmBEierglMEossxa2Ot18YmJEwrSmudKHUeQ+sPVjF9qcmHcEuhi4mXMke+NEpRy 5wTHLkrpGrLOq+RUNftFvX1F5Vy9ZLdDjyygNlah/Wmo1ZUj/q4Zt4Wi1FZYN7iHXxJs RXFR7ImUyP5I+4+hXAbSHx0P8Xj9NMvN6WXkWDVi3Sbm6Nz/hzNo7sIxRMnG2vvL/DA/ 1Rag== 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=fnkf0gvWPGmhXE6/0+GgWj+bv8w4jYntecxa7ehfW0w=; b=iHqnVYctAYiBELfN9jCC97ozkHhLR+IckvNqSI7I4CFZII7UOuC5IB67nAqdYNiOxz ipshdXlpUSf5ReaEtad138q/a9xx93JdhJT/Gq7NmDh/0jjarjDGx8zpTfP4UQTKWMo3 TC1rV521agfqv7HhVuhN85/MUHKhU2hOK0IJUhf5UvW90UKUy4ekLufyZyy3VoGLmjOa qpfZoJb2zDJD9s+4fwzVsbqiMnsG+LR6yXKmG6J38GEN+wk5zRbbmfqMeVRhpVcMPVHT JRgu/PoQASI9FAR9vH7gaVevKNkVLWrP4i+BOVXlcWfQJZCn+31ESb2aU/tpvdDXcbTg lpJA== X-Gm-Message-State: ALyK8tJavgxwhAUDJnqRY7DwT4laHok0jhDGsIHRR6N/G30X9Ks/vhw3MPFZ9fkpL/EZlA== X-Received: by 10.13.206.65 with SMTP id q62mr8832891ywd.317.1469080429028; Wed, 20 Jul 2016 22:53:49 -0700 (PDT) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com. [209.85.161.181]) by smtp.gmail.com with ESMTPSA id b9sm2623990ywh.45.2016.07.20.22.53.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 22:53:48 -0700 (PDT) Received: by mail-yw0-f181.google.com with SMTP id z8so43643411ywa.1 for ; Wed, 20 Jul 2016 22:53:48 -0700 (PDT) X-Received: by 10.129.159.131 with SMTP id w125mr30548551ywg.168.1469080428302; Wed, 20 Jul 2016 22:53:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Wed, 20 Jul 2016 22:53:28 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 21 Jul 2016 07:53:28 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Content-Type: multipart/mixed; boundary=94eb2c0c021013cdd005381ef1d6 Archived-At: Cc: Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Plan for handling trickle unfreezing 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, 21 Jul 2016 05:53:53 -0000 --94eb2c0c021013cdd005381ef1d6 Content-Type: multipart/alternative; boundary=94eb2c0c021013cdc805381ef1d4 --94eb2c0c021013cdc805381ef1d4 Content-Type: text/plain; charset=UTF-8 Hey Justin, Have a look at the attachment. The table there is probably the simplest (or at least what I believe to be the simplest) way to represent the current unfreezing algorithm of 5245. It's what Peter, Jonathan and I used to support our discussion the other day and I am trying to make the case that we should also use this representation to actually explain the algorithm in 5245bis. So anyways, topmost therefore refers to the first candidate in a given column. This is not necessarily the highest priority (priority mostly plays in the ordering of foundations here) but the first pairs in any component/stream to actually have a candidate pair for a given foundation. Emil On Thursday, 21 July 2016, Justin Uberti wrote: > > > On Wed, Jul 20, 2016 at 4:47 PM, Peter Thatcher > wrote: > >> Justin brought up an issue with trickle unfreezing mixed with the 5245 >> "unfreeze the whole checklist" loop. We've had some off-list discussions >> about what we can do and we've come up with the following plan: >> >> 1. Keep the "for every foundation, unfreeze the 'top' candidate you have >> received so far" that we came up with in Buenos Aires. It's already in the >> trickle draft. >> > > In this context, I assume 'top' == 'highest priority candidate for the > lowest-index m= line'? > >> >> 2. Remove the "unfreeze the whole checklist" loop in 5245bis and replace >> it with a new unfreezing rule to 5245bis: unfreeze the 'top' candidate >> for every foundation. >> > > Is 'top' the same definition here? And do 'non-top' candidates only get > unfrozen when the 'top' one succeeds (or times out)? > > If so, this seems sensible to me, as it preserves the general goal of > freezing (don't check things that are redundant) without adding extra delay. > > > >> This fixes the problem Justin brought up while maintaining the reason >> that loop exists in the first place (as far as we can tell). It also makes >> the behavior consistent between non-trickle and trickle when candidates are >> trickled in order. It also makes 5245bis less complex. >> >> #1 is already. >> >> #2 will be discussed at the WG meeting during the time slot for 5245bis. >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --94eb2c0c021013cdc805381ef1d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Justin,

Have a look at the attachme= nt. The table there is probably the simplest (or at least what I believe to= be the simplest) way to represent the current unfreezing algorithm of 5245= . It's what Peter, Jonathan and I used to support our discussion the ot= her day and I am trying to make the case that we should also use this repre= sentation to actually explain the algorithm in 5245bis.

So anyways, topmost therefore refers to the first candidate in a give= n column. This is not necessarily the highest priority (priority mostly pla= ys in the ordering of foundations here) but the first pairs in any componen= t/stream to actually have a candidate pair for a given foundation.

Emil

On Thursday, 21 July 2016, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:


On Wed, Jul 20, 2016 at= 4:47 PM, Peter Thatcher <pthatcher@google.com&= gt; wrote:
Justin brought up an issue = with trickle unfreezing mixed with the 5245 "unfreeze the whole checkl= ist" loop. =C2=A0 We've had some off-list discussions about what w= e can do and we've come up with the following plan:

1.=C2=A0 Keep = the "for every foundation, unfreeze the 'top' candidate you ha= ve received so far" that we came up with in Buenos Aires.=C2=A0 It'= ;s already in the trickle draft.

In this context, I assume 'top' =3D=3D 'highest priorit= y candidate for the lowest-index m=3D line'?

2.=C2=A0 Remove the "unfreeze the whole checklist" loop in 5= 245bis and replace it with a=C2=A0new unfr= eezing rule to 5245bis: unfreeze the 'top' candidate for every foun= dation.=C2=A0=C2=A0

Is 'top' the same definition here? And do 'non-top' candi= dates only get unfrozen when the 'top' one succeeds (or times out)?=

If so, this seems sensible to me, as it preserves= the general goal of freezing (don't check things that are redundant) w= ithout adding extra delay.



This fixes the problem Justin brought up while maintaining the r= eason that loop exists in the first place (as far as we can tell).=C2=A0 It= also=C2=A0makes the behavior consi= stent between non-trickle and trickle when candidates are trickled in order= .=C2=A0 It also makes 5245bis less complex. =C2=A0

#1 is already= .

#2 will be discussed at the WG meeting during the time slot fo= r 5245bis.


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


--94eb2c0c021013cdc805381ef1d4-- --94eb2c0c021013cdd005381ef1d6 Content-Type: application/pdf; name="unfreezing.pdf" Content-Disposition: attachment; filename="unfreezing.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqvwd51p0 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHdW9tyHLcRfcdXILJFLyVxOcDcoyS60LZix44lcxMnFeVJ FcflElOl6CG/73Ma6AEwM7tcLvPkUpWwwKAPGn1Do2f4wb6xH2xX2WrbV+M4uhadyjZtZf/7L/uD /Y+9vPro7LuP1sm/j+84GY+3vbM3tps65r10IkztLPoTqnR/sj9ajOAfQD4AjT+BWo3bqnGdbapq 67HUjXm5sxfVtnKj3b2zvpWJsdnd2MvdzoNu96P9h9385sG5vWjs5hM0vrKbT9HWaOPww3Mj3TMM O0z7jNMGu3m74bwaP87xo7ObR3HCY7Z284SPMXyBFmRbNH4wiUyXU9xLkmHihFtxoLcbneDQrzEh 8Gc2cZ3YeOLj6UPOAvdKlbPbAK0+tw7c6+phupk2HdgMXGD2HG1irjm3FILC6GoqrDZyoa3OIz25 6PAcjYquP7f/tLuv7Rc72FK1bcahqkdvpl9pbKZ454Li674PirdR8b711Dy2KiYijZlrfsC6FzX4 GNFG2VE45Jrtb89ti0ZkQkVT444qf/opjMJByr+DGNANjc6jRjxQL4XAN0A+07Hf41kNEnnUY9In QGpgJk+BCfQJkxLjOM2IEnuUVqdhUtVh1QnpMZC47B/wmJt6qttQKCqT2zqbfsA4YKkJ+dkZjAzc 6faUa21pZHApMQtBygBknxPyxNVzSgqLvoiLv4zt89heKYlK7/PSFtq6920zwgLiL1iFjhVBwPd1 sAXfbLumh+ze3SRrEGMIoQMy5r/djSnCwCXkT6mqtOhuDAeQdrLNFHP86MvlTFguok+LZLFm88W5 3f0cjDwHagnUY/GJbw1fXsLXAUiEr4dfglFaEszhArpDN+PXaIysnfBbLEPxHABf57d2M37jxhFt K4RU+NxMzJkEwO44PoOcYdjUN+wC6me4gpmTayMRIAmnbrqFcI7l2vBYmrbfyBGx2D4Pibq9jW2z eQDrYHSmtUavdBA2g/sA9ulqGIafZLJPiwfTTIufait1vxTHnWyF0STweYEDNXi+rxDRGAkbZzav 0NKYxH8x/sewbQYAElBpNbQWcaLJ0XMoBLoOTv3NV+gDSzAE/Ws8gFkU6KuCqqEO+gKMNfNhQy01 IaAfNK7qiguBffLLuAvO0GPARCORpjZkD1sIO0TSIHtvMZl7H8GlPOEDnlIcoIex5XaR3aiLBWO9 fPXR2X9/RICqKzm3GKqqdhgQTJDKNM71XctjCwg0Z0l6HIZi571Fx9Teb6HdDjkP56UeUp5HnKHT b6yHrCda6aTZMyghzubfAHlCeh86iXiG9ZPBytn8G9s0GbF0ErFMTF1ZOc03N7aFZUxsSyfNnmEJ cTYfSSJiRCBmkshOIp5hCXG1HVzbDV0NFQxNT3Xg1xgVFJURIcCbyDchsuvHATaHw14UkvUEvyCI KlG496KhjGIGJwCFrKNaEgMUpgJgw5ysXfAjAIW8o2oSAAWaUczwBKCQeVRPAqBQM4AZngBgSjLb qKIEQCVlADM8AYBCHE93ZOfb0Y/wlAGH+0i9IY8JSpoggpKmrngNjsyRXtNHJaUe8U0h96CkjF6E isAMf4xg2hHmcpnDQnIJYr50dX6BJMTF7KAcXRnqFGEqcYEkxIWsg2KUGCuLIIV4jiTEhZyDUjJi UYquXCAJ8a1eIxIN9FGeCiYyiPIHYzKxVEewYiUuti2dNHuGlSSqxIUApZOIZ1hJokIc4xBzRdG7 yCARz7CSRHXlJEBsUjqJeIYVJbowcRp7aeIRIsahzKZFirjSCqs4Frz+FuxCxlEdChVjhmeqJjFM JqeuAORyxkV8JjnpRgpsVibPAAqKaOZJHiLMRDHDEw4KeUdTTwAi0AQwwxMATDGTwKK5JwBRUAKY 4QnAiskzBqWDohBclHKCFKmoVgp1Ed0UQosSTsQiESUukIS1QmBRuolYpKHEBZIQF8KKko3EUKZI QokLJCEuBBWlmlYWqQrxHEmIne9R/fkfkt+fLXIjz9xICkBX1xjjv+srJOa8LlRV13auQwLNf0zy sqEpXWKy7FxT4xmS1xrq7ZCEpTHva1dj9nt7LZWoEuZW5HFw8KsSOY7dD7luB4eCVIGsY/dDbhtX zXnWsfsh95Wr5jzrWIlcD07UfFdNBg2OnbN1Xw0NSjxQ5eDrdmR+qENBl2pKp6+B9BvmtWWdUdeY hk60F1d3HVh1zqHGVGXAOnIabpKLa4a6RuEzsawjpyE75XhoG1pNhhtHTsMtLRun0738cPB+ZNk4 93Adux9ykiyKw3XlPUpDSQZp7DQpJHTvfQvnybB1JCCH4FfWrFAEl8J1jYtvi5M6FgakdN1LVcJL bEStgYEsFDAbxNBUuuaFVGpW4bor92zcdBtvWAPmvRxFOhTF44UXs1l1Xb19d1JB661yk1XQXG9Y 2rkTN1IQx/rCjVSkAzfmKG6agbUOFBtm3EBirscRA1vZvTOHOXrLQkCNguUTFGpYvkH9Ym3nbS91 5LTzTA8e9YRbt/5YqvdYiAUhVrdYvGeB3LG8i1afo4KaGAjnXmERDplmsIiqSxVtsZJ92y3fZDQo 2kitCoJHQYNd6rvH5lHlRhXkaeBgXmnzDeuDqBvXawuval4XNps/oTLSYZco7aGEQbtjgz2zgXFS 7yjCkBkYA3uRIM78ZpJKWbRrm2gCd+bJkidzH55QsE6a+jDVUZuuvxdPkJM5WU7fFjwhDNCCHNI5 FjfpKiKnaLxqNAd1J3I6pDtzm+5Q0E9yYsmVFxXUsnFp6Vs7DvlLQIOXgCtGP3aoCI+kSCV73Fr2 eF0wO4Na8ttzhhjYnZQnEdlYluQrEHghen9Gj7Vl1v1Y32PxsoWPFhV9cGzSW8b97y5X2HaNW/Jd +X2BMrrL5hWsXV8DSIma1aa62w4s/6EYcpTIHITlBxeI4puHleCsa37HJYPLc8lTN9wP06J5hAz1 8/3LQ1XPLqkFvtCC56NwzlqrRzig5xt980fW5B6k0nDVXBx8jbyiCo+Yq+LIOKv2hm6NXeDg9Qsy A3v55s338de1juzOjcPR+fz6+npu5nLnmhiFl5R628NojSr6jFH4qUeh8qC18z31XxCR+PIRnGQN BIi0YbNDdIWJvwnPYhNnxmexEQK7+Wvs4j1chnZ9bmKv9GncEXk5A+/Tjo9VTdMudiw3vWNU8+2k iBev76Aa3F9n3OKKeUg9U3Rv22RHWTA6xo6C7ZjNCqO4LKzbkFQM8K6DqV9wfbkC1xIzTfpwYsXi JQC0fSANAYCbxhG7Ykjlm87v+AYOcRDnMxs6Jt+ZwDH5igdyhpcWp9/kl8pq8MvAq5l95LHCq3hn yeseE1i8or/FO1WyDCPTBwRkV7xzYle882h2xUdLdvf46ILdAz5qb/FRQ/89zkfFYxdbTj467Vt8 9Oh9i6eW+z5aTYc9da+akqcqz+KpR7Ms/noayxrrD/jrQsRIbfA2j7lWHZIbYdQf4QJMcTwvGaA8 mOQsTOrkJAefLQV3lnbh0Iw9bhh4yVgkHXsOL4k5dQ2SlGI6lAPDXeyWPLORNEyiDvImpmy8kCFJ 560AQYcfiSwEzmwgMnm3XCDnco8Rx9v0nTOBhSQZa5TJO+UBOZN7IsyCyQMR5v+dBSw2OkUY3e2d coB8t0er5HBc0eRswekUVyKnt5z/2U0KfnoKoweiyV4mxQNRc0mJfwgn+Y2p9MQpTxFPrIY8/YcB 3cUXDTNeZACFL8oNPfriQqbii8pulgEcE/4kAyj53WMCi/h3ZAZQXI01A4BAgohQ4kcCeHS0lgyg ZHePfy7YPeCf0/G+J0u/awaw2HLyz2nfKQM4Rk2SAZT7PlpNhz1VM4AFz8lTleeUARzDsmQAp7F8 wGf3srt2cz7i+He4Ojm8ufIjChApW8eXVszWw+fJoVkYFGtrOC/5jRUOSn6blDLdD1PgcvjaaGWB UYoROf7iQNniXOYnXagO4n9UB7EYPmfjUHzyBD1c2fFtLwdRPeF15oc9fPTjCh+u04LtLZv9Sr69 GoGPtVktAFf8Eos1RFxVPkOTnqF4CH6QSLDACkKzJhiPivxMMGLSsaq7LhoTyusPtIKN5bnnonCU ZO+ZSZXKPaBS5vha/kkYYiAOqVUykAJD1YYTALxt/raKgWI4XvbkGNwqzGZuZCUaagtP+AaBW4RM JV3EySAt1ADxa09nQRAXVARkD9HLR4F43RC+m2PFjV8582AJ1Dqb0mRKynkwZQXTJYW8Q07YoWZO S8On6hcs3n/JFv2XREWfE3uswi90UVzgxfWC1oFrreArYODaTAspH4ErpdLZM67gb/xmMOwwspag 4CAQS/h/4hu+I+vrxsI6BZAKEjT4LJqiUqaUncgGMmHZKw5j2fvhvmHmPMlmzQ1oX2MrpqEXkJPs a4bxq7IvHMuTDH/t9oXsTvaKEmHRqh0hSF14BP3X8hxVrThPW32urdLRfPfZH/9GA+FNX3Ku2h9O n4PxTTHCIYpPdapq2B/fAhri2xXcC7uBs/Ez5PC3FDzTGLokThn+xcQlzxI8j6Pi2Jz1LA7Ex+Ki iFOKlg3jbzuMkiMMMEaGt27lHJyzgSGe6glpWvDsGanM5iqSxWkZX/xDoKfl04n6CcJrCIvgPSyP 5Qw6/DMUbvAssh4BGWQQzgiQdJf+zGLllyleWnZVrA67If9s+9BfAjBgySlYvPDrHBXKXKkEwiiK BTzFQnUxNuXf85jN3wFKkX+f7+PNL8zHx40KZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjM1MzkK ZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYg MCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA3MjAgNDUwLjcxXQo+PgplbmRvYmoK NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMQoxMiAwIFIgL0dzMiAxMyAwIFIgPj4gL0ZvbnQgPDwg L1RUNCAxMSAwIFIgL1RUMiA5IDAgUiA+PiA+PgplbmRvYmoKMTIgMCBvYmoKPDwgL1R5cGUgL0V4 dEdTdGF0ZSAvQUFQTDpBQSBmYWxzZSA+PgplbmRvYmoKMTMgMCBvYmoKPDwgL1R5cGUgL0V4dEdT dGF0ZSAvQUFQTDpBQSB0cnVlID4+CmVuZG9iagoxNCAwIG9iago8PCAvTGVuZ3RoIDE1IDAgUiAv TiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQL g4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwS E8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8 fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGj jAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWie AHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt 7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADy BQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqem S0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6d axRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2 DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx 2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5 Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7 HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKp RZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCes P3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTv gg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIp sY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRP ShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eX Xy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDp sNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZ pYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq +9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0 aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dC T0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7Zx ivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2L WIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDd FrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsM F/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT 5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegK pARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcE LWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS 3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufG K+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000Il YYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR 5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41l G99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9 V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0Mqiy vUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui 6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx 4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdL z5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX29 7Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel9 3v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nP K0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3n ZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFt CmVuZG9iagoxNSAwIG9iagoyNjEyCmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDE0IDAgUiBd CmVuZG9iagoxNyAwIG9iago8PCAvTGVuZ3RoIDE4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHFWttyGzcSfZ+vwCaxQ9kmNcDc4yS+JfEmcTZxxI1ra50HlULb8opSbHHL+/l7 TgMYAEMORdIPKVUJBAbdOOgbgAbeqefqnapzlc+avOs6XaGSq7LK1fuFeqEu1fGTa63OrpWWv+sz dsbnWaPVUtV9JbuQimNTaIV6z1Wqb9QrjFIVjanKbuMvMH+HUUCG/6YpZnmpa2XKWV02ZZ2dLdXj uZrms9xUan6mNDuiqy3mS3U8nxtQzl+pf6vJ8WdHIFWTT4/UtKzVRKM0uZp8cqR+z+Y/qG/nMvV+ uM6kwyk73JZBJt8eqfnbbI1RRUZNj9sxEtzddtwZcN/6DkCbRk2+JGA1QfV3tY630IJ3bZgEb5YI xeIdTrzQm/FCzDlkORBzyhFwu+4B5Az5zgC3BfwjVUDK90ZQl3UqHKfUBLXaBXXZpYwg5cxZR7GD dXwC69CwDsCdAjzgTjWEPeUkAL86yth8d2QW1jS3yz7MIoNBjsi+GYjjRlvJEhu/RdwW5xQ+Nnk5 Qd3khZo0+FGi5SlKGpN8Qfvf7bQxMRBkorQCWnN8nMnRcygEug4CweR71BPuP+ADVBZzzzYaaQEr oi/AWMWHo/mVZs24vMgy78P5Ew4E+MRbQl1AhhpceIqCutOYE+BhCnaGiBcy9wqdOfcuz+wXfqil QVwKH6yHIeClLnb8FPHu9TUCVJF3bV5IqMqrtjVlhuhWat3UlUKoAocC5ixxUKPJVS6UVIyZFU1d IwyyX6ghCt5hj6ynNZB1TyuV0HvASoij/ktw7jldsBIPNeAlxNLFoy7LCDUqWYRzwEuIo/5LVcEy ethSCbAHvIQ46o91AzGiJ5ZKIB7wepNBYPms1VXd1gV/lQ3VgV+dU5BThmexHGqAUjRdC1MsCqxT UIivQT0CLpHzUg0kx2pEMWAnDBIKUUusCQozYjDgJwzQJYh/qUTUfkIXUo0YDPgJg5gic+oJDCjU iAE7R1VhkMjdqcgx4OIOjUUUA37CAArRXN0rqsZ08BRREvVmGucxngUQxmKEHqSKqA6vaazXmFAT /gmBVVLP7kJ0xj0D/NEx8xUhTmRuFeSJ0V8EKv0xVemaECfytsqJiEWYvn/CSUZOZG0VExGLID1x wkmIYzlDZgMtSNUTJ5yEeKvXZPAakaild/L0zEQGQf4D5QSJSn8AC9P20gzEA15CHPV38rScnKkH YukYqkIcicnJ08MWGbje0KR0HBBHYnLy9MQizdB7wMtJdAcT9yycifuqs8qcW2cXheQ3BCa8Exk7 dQRaEaLhVq0ovIG7KpgJg0TOTiWBgQgyMBjwEwbokvVO59QSGIgwA4MBP2EQy9vFoJ7fhawYJjAY 8BMGscx5vGDQcQgwS6kGBtI5VIXBVpNnDIKUsx6Ek3LgIVLxWhGF+IpwT4QmEg68XBDx/RNOQpwI zEk3jAxpZMYTS1dfEeJEWM7oA7FIwvdPOAlxIign1UAsUvXECScSZ9o0OBB+wLnqrcLeyHBvJGfC Jydo49/JExzbeFzI87qqdY0NNP944Ima+u0St/xalwW+YfNaQL01NmGhzZhCF+h9oU7khJayuZFz 12rIMeXs2j6Oc1G1uhxw9m0fx7kqdT7E7Ns+jnOT63yI2belnItWi5r31aTVYFdrVTR5W+azEqps TVF13B/6JqtLb0qHj4HtN8xrxtSDH6NvOtBedFHXgKq1NhX2eYGxbzmMb5CLLtuiQC4k4uxaDuOs PeK2Kmk1EV/Xchjf1GcQeD/KD1tjOmaSYg/3bR/HOUg2n5kiNwbZnSCD0HaYFAJ3g2UCzhPx9i2W c58Qi3JWyItJzqrAwbfiaSPkrHCMZTLF2JyVLWyio0QMtTmrv+FkywOp5KzscVfO2Tjpliab3Lbn 8s+j4zhyHZOXRyNpiloyaI3yaKLTt26yvdHc4Xkbx2ZBowKarE8ObENTtsx1INkwQAOJ6QZLDGxl fobVZpt8XjIRgBP55B4SNUzfIOm0Ke9QNZp6CDOP9GB2UcTdY84VAzEhxOxWzhJZBo3EUInSfzcx AKZSZdNQ6xlkgoNQ1w7TqHZtxEYkWI3GkaXIa5A4mGJEY9YSMpy0lhL5D0ll2WwMqzSHpswmneRK 7g8BhqzseK53A0hTMt9YQKQHIP0RiaUaUkOqECkRWg4LyJDFp0fY+EhSh+hhXKw5AtfzWTyJILii Kp1JCSaXAtxReh+L6dFmTGXd/HWYftqMqaqYLKXr/QVyehxjoocw/YKcPoy+GTpIhnuGDbbX4RKg 7kgRwilOQSMBzDoIU+kvjxiyYHeS7kSkZJoTqQh6NWr/QI25auYRmS9kBruCz8OtQlAB4uxAl9FI wK7hzs1Y4HWOPXkKa5+/tWn6PqIU9axlOnEtpoyIjDHFtNoSuZuMDaHVj/lzuMngkIdOuGn7QeOI a/Px48NDVQ+OqQXe08DzkYhn7tYgHNDz+9saQpNzlZeGzocWxJuqDRZkEMO9OCJk+Q5rclFWyBtz 3SvuNO5X61u6o4yrxBdt2w6MxmZEeqCIaTutBQXS+AOgiGd5O2rtYfNwv7KbByDhHsIVBWuyGBQw cfgDv7nCdcFCwW+uEAKowVW/SLi1mK/lnXgIEy087AF7P+NdVVNWazOWk+MuqvmqV0RV7qEaHHIH aHFk3aYeXEjQqLikBzuKgtEudmRtJ5tsAKrGbEg2E7g74VbSur4cqQvZVGThbnaDxUsAqBpLagMA J40ldkPYTG+VfuaNHqwa6zMLOibvYOCYvGOCZ8JLk9Wv90sP1fqlxZoN7pE3YBXvTLGOmMDa9eOz Xx4xVMAmnz3/1f068S1z2C4QPzw5STYQhCsZlh6ueOfOcMVHU7gQrcHlxFC0a3D/CblBlZOTpAA6 NgIu77ie25orXM/5UcZvrosj+M1VHybcHMXalIOP9vMWH9153uKp6bx3VtNPvVIe/bKHmoKneszi qTtDFn89DLK3pn3gYmuD20HutQq7uRGgZgcX4BbH8NACyq2bnDWTOniTk8mVMZVBt15zaMYe3bb7 HmRMUSQHGY30oj3bbTz7htNMKdswiTq8uMaWjQe8L2H3cA2gxGWS7Ab6txA+6jiQ++0FYpQjRuxv o/vT+Q2xJnOxZk2SjDUe5F77gBjkSIRZA7klwmQ+fIxEGIk+u0WYjPFqbaJ9hPGz3WsPEM92Z5Vs jyujKunjikN6w/oPE4jW/0OAbokmoyDFA5HDCRt/G07GUwr9PkVW/7yNt/8woH18MeOaih1A4ouS bnC+uKZ97swxgh0z2gHsEv5kB5DiHTGBtfh3g1f6HUByNPY7gAA37AB2gSs7gBTuiH+uwd3in/3y PuKf++4A1qYc/PNANckOIJ33zmra7qmjagqe6jGHHcAuqpIdwGGQt/jsKNxNJ+cdln+No5NuqpDi gDnl7lSBNy88e0ixbk540AVH/ZHHZZv6o99iQ+gXdSmRg5HSt/+Gx1LIY0rKAzt7pJu5ur5ALxRI g6BNnlOhB5IhzHtK7hcx33V1rdKpxTsyeaeFz46FJ0b8kBdazNqCp0YVKB0PnDLkI46tUyz4wtI9 1mrtBoA0eP44xSHEcUCqc8oksxtnAE5OKpJeBONs8jmmhWO7gNEVJuG+RxPkQE52njWOOVOu5Mjs spCBJfUuYP3M3ByQn5RmP1H/eQDMobe9ZRkOx+eQzhQjKOUFS39g00hM8VQRG4Fb87Gp4MtCJE/m bxbq9PXicqUW/ztdnl8urtUKTWdvFmf/UUDIB4AX59cr9erqvXx5df4eteXij/NTdb16vzhdzpQ6 2viET0CZJrHM7aBwl5FNvpORTtNBkEvwia1o1lWjOlg+Xh/XbuvLpWrDvJ3xY97uuuSOUhzn9OJC /XmKKakP56s3fsKUwPXpcoFJ//fyj9PV+dXlPXW+UteLlRXP+Hwb5BpvhhPUwBlDDder09VCXb0S EROQxUMgXglXHxYQ/NnV8s+rS+rr+2/U6kq9OD1fnV++nqEb7cK+KN7jqXSdu+yLbpNnlrB+CR1S pKGDm7d1XdRa4g5iUcqICrF2OM4RAvgXzpy8C/o1zoVZivTCI5fHu7XC1TTPF+HpLhIhsHbsl0nl iuQ1MEbhtQdjF1xQHnSL48LPXfMtRDZmdcXZ0A1RQG5uxDW5beX9CB/NSkhDBzgn4889FAWakRt2 kRFkLh6RzA/n+YrLg7znyysi5kl8B0Y75tUsvsyP44ZDeJnyeTpj0hjcEtyYjkPo8qPb7pljanPW jM9Egd5Dbj240oZxz8Zj9MJiDCYKX/p+pCcKJNf44taLDq+LQwDDlb+8kzV4Hut+4TWI/5UqXsu9 XI3VoLGKDy/67XNgvBjEHx8Oqjy1WGi+xbhTLgrITVJHEs8xeVlBUCK+MMwzj8/csUxeU3f3P4NR cC2wyeX7tvD9qBHeChwLgWGe5bZv+4ojcmWFICSO4rZK0tT3wRP67nlSYkxf04wosTthdBomVW1H 7TndBScO+zU+c1LM3069rsnKT+92/4MrWjyvB7dhZEDnp+dR+5JGxtziJgYyz/5Dj+ohJQUhIj5I +diVD135xJN46X0T28Lz/wOWhx/+CmVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKMzQzMgplbmRv YmoKMTYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE5IDAg UiAvQ29udGVudHMgMTcgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA0NTAuNzFdID4+CmVuZG9iagox OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMQoxMiAwIFIgL0dzMiAxMyAwIFIgPj4gL0ZvbnQgPDwg L1RUNCAxMSAwIFIgL1RUMiA5IDAgUiAvVFQ1IDIwIDAgUiA+PiA+PgplbmRvYmoKMjIgMCBvYmoK PDwgL0xlbmd0aCAyMyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBpVvbchy3 EX2fr0DsWNqVxeVgMFdLtiQrthJHji1zE1cq8gOLoiS6eIlIplKVr885DWAAzGU1XBWrNAsMunHQ N6Abow/qlfqg6lzlmybvuk5XaOSqrHJ1fap+VZfq8PmNVic3SsvfzQkH4/Wm0epC1X0jO5eGY2O0 QrvnKs336i1mqUxTVGU3+QvMP2AWkOHfojGbvNS1KspNXTZlnZ1cqG+36iDf5EWltidKcyCG2sf2 Qh1utwUot2/Vv9Tq8I9rkKrV52t1UNZqpfEscrX6bK1+y7Y/qO+2svR+uq5Ip1N2uh2TrL5bq+3v 2YhRRUZNj9sxEtzdbtwZcH/xPYA2jVo9JmC1QvM3NcZrtOAdTZPgzRKhWLzDhRs9jRdiziHLgZhT joDbdU8gZ8h3A7gt4K+VgZQfzqAu61Q4TqkJarUEddmljCDlzFmHWWAdn8E6NKwDcA8AHnAPNIR9 wEUAfrXO2P3lzCqsae6WfVhFBoOckX0zEMdHbSVLbPwL4rY4D+Bjq9crtIvcqFWDHyV6XuBJY5I3 6P+zXTYWBoJMlGagNcfHmRw9h0Kg6yAQrP6CdsL9B7yAymLu2aSRGlgRfQHGKj4cra8sRsblRZZ5 H86fcyLAJ94S6gIytODCB3hQdxprAjwswa4Q8ULWXmEw197lmX3DF7V0iEvhhfUwBLzUxQ5fIN69 u0GAMnnX5kZCVV61bVFmiG6l1k1dKYQqcDAwZ4mDGl2uca6kURQb09Q1wiDHhRai4AOOyHraArLu aaURRg9YCXE0/gKce07nbMRTDXgJsQzxqMsyQo1GFuEc8BLiaPyFqmAZPWxpBNgDXkIcjce+gRjR E0sjEA94vc8gsHzT6qpua8NfZUN14FfnFOSU4VlcDDVAKRZdC1M0BvsUFOJbUI+AS+R8oQaSYzOi GLATBgmFqCXWBIUZMRjwEwYYEsR/oUTUfkHn0owYDPgJg5gic+oJDCjUiAEHR01hkMjdqcgx4OYO jUUUA37CAArR3N0rqqbo4CmiJOqtaJzHeBZAGIsRepAmojq8prFeU4SW8E8IrJJ6dueiM54Z4I+O mW8IcSJzqyBPjPEiUBmPpcrQhDiRt1VORCzC9OMTTjJzImurmIhYBOmJE05CHMsZMhtoQZqeOOEk xDu9JoPXiEQtvZOnZyYyCPIfKCdIVMYDWFi2l2YgHvAS4mi8k6fl5Ew9EMvA0BTiSExOnh62yMCN hiZl4IA4EpOTpycWaYbRA15OogtM3LNwJu6bzipzHp1dFJLfEJjwTmTs1BFoRYgFj2rGeAN3TTAT BomcnUoCAxFkYDDgJwwwJOudzqklMBBhBgYDfsIglreLQT2/c9kxisBgwE8YxDJnesGg4xBgldIM DGRwaAqDnSbPGAQpZz0IJ+XAQ6TitSIK8Q3hnghNJBx4uSDixyechDgRmJNumBnSyApPLEN9Q4gT YTmjD8QiCT8+4STEiaCcVAOxSNUTJ5xInOmiQUL4X+RVvyucjQqejSQnfH6EPv4dPUfaxnQhz+uq 1jUO0PxjwhN19cclHvm1Lg3e4fBqoN4ah7DQVxRGG4w+V0eSoaVsPsq5azXkmHJ2fZ/G2VStLgec fd+nca5KnQ8x+75P49zkOh9i9n0pZ9NqUfNdNWk12NVamSZvy3xTQpVtYaqO50PfZXXpTWn/OXD8 hnltWHrwc/Rde9qLNnUNqFrrosI5LzD2PfvxDXLRZWsMaiERZ9ezH2ftEbdVSauJ+Lqe/fimPoPA +0l+2BZFx0pS7OG+79M4B8nmm8LkRYHqTpBB6NtPCoF7gW0CzhPx9j2Wc18Qi2pWqItJzcog8a2Y bYSaFdJYFlMKW7OyD1voKBFDbc3qD8hsmZBKzcqmu5JnI9Mti2x1z+bl96N0HLWO1ev1TJmilgpa ozyaKPvWTXZnNA+YbyNtFjQqoMn64sAuNGXLWgeKDQM0kJhusMXAVrYn2G12yec1CwHIyFcPUahh +QZFp6m6Q9Vo6iGsPNJDsUQRXx5yrZiIBSFWt3I+UWXQKAyVePr3RQyApVQ5NNR6A5kgEeraYRnV 7o04iASr0UhZTF6DxMEUI5qzllDhpLWUqH9IKctWY9ikOTRltuqkVvJoCDBUZedrvRMgi1LKhPVe SP+KwlINqaFUiJIILYcPyJCPz9c4+EhRh+hhXGw5Aoyc0q+pSmdLIjZn1yK2ObMOYvsIGJleJJuN wRDvs2lMZd3MYZoz7D0wUUAiriAgYvpxGlNVsUpKnxvJaWReo8ruYjmNlZYR07cxJroG6y4o5sPa m4We0aH6X3fMl0IcRfozE7mCOF+vGatgcFLnRIhkfRM1CLhzhtbf0GKRmgVEFgpZuq7g7NB6sLYl 9yIZ7kUmfEWj8mpxRxE3t/XOifhmcWerFy95n2Dr830oMfWmZR3xLsGkaLUQOalNxVQnq9VP6ZSz wSELF0FTC25a5SeNluyuaQZLTkvYTw6pBV7QwKJRgWfRtkAcgCxSXUhC5aWhc1pQNriiArJNlWuc O1B4YrIXYmyBID6BMB9vys4PwqZsygqFY2585kHjfrW+B0GW28RXbdsOAUsS1wNGUJsEPARqUMcf AEVcy9ux1Y+APqrs6QFIeIhwD2NbAGpg6vALvnMPN6RboxqNqxw7xBE8ds2vEm6Bd6odJJ3M9oC9 X/GcioYrLqvRiiV1XKKar3tFVOUdVIMsd4AWOesi9VTV3nbkbecuQOU0gcsTniVtCJCc2kxY/lCs PFUUVWNJbfjkorHHDsPnKPL/xCs9WDU2aD7ooLyEgYPykgkeOtwFGa3EPz1U65+LsYp3plgXm8Ay 74RRpwYr3tnDFe9cDFd8NIUL0Ra4nfioaP+O0wNUuTpKHgh27NziPAc/fGVb7uFGbtcZ37khjuAf rvk04eYoRhE0+Gi/bvHRxesWT03XvVtNYUd++eMRIztCz8tnP7tffQ9WoWFYT4+ORpiDp3rM4qmL IYu/7gf5FwfzLnBxxMH1IM9cxh5yBGixwF151CmYtYBy52Fn5K07Djtq52EnkztjrpJunRxr/fFD t+1dM5nCmCST0agv2uRuMvkNJlLKcUyiDm+ucXRjhvcYdg/XAErcJk2fChxIG3MW5FsSbWKUM0bs r6P79Pzlz8+cTbx85a0jMuLMGfFIkow1HqREmgUgJcbEIGcizAjkjgiT+fAxE2Ek+iyLMBnj1Wih fYTxq5X4smC1Elni1S5Wye64MquSPq44pBJVFgCVeLIPUG8vE9FkFiR3f7hPlADYcDKPE19O8Hiu EYWw++etJe13/7v4YsZgjRNA4otSb3C+ONI+TwA93OgEsCT8iU+meGdMYBT/PuKVfmtJUmTGN/FK L13cGeAAuDhai3emcGf8cwR3h3/22/uMf971BDBacvDPft3hBLBETeKn6boXq2m3p86qKXiqxxxO AEsgi8fuB3mHz87CncqgF2z/GqmTrlA27FCICP6K6gSPlPjshV4tD2dQiAwsGq80ihe+aBDSXY0v H/dhhw/6tu9P1fG708tbdfL++PLd6Y26Rc/N7fEtfuKswK/J3l5dq+PzczTDofpDH3tK1D6XTe42 L7+WK8x0PfVNZVl3+3H8/vrqf6eX62wsoYp78iKBJyCz1b+Pz65vFCUwK3hT3V2PFPIkQySceh+G N8cXp5MMcdLci+HF6Zuz40mMBTKTvVje3F6fHl9MocSZcT+Wx5dvJjEaHFj2wzgjR9PsyfDt1X8u 3xzfnl1dTi28xE3qXjhvrybXXbaw833s59fjs9uzy3dTGHE3PeS5K0RFEeoO33/Xuaso6Tb5/nvX p8LY8MaeXmvWPRhfHSPEV34qjF4kGAyvtqLpHsnHx4iH/0ROyguuX+JgZylYYeyjns7li+Ra4b6d OVNI4lAgxCyIN6Ryj+EsuMvBxZK9+cNRhHc6UqJGSZrdTI1YscZ9yAGzovt48jrKfvSKozgvffgl sNzR4fKHhW+AfoiHQfcBniBjoTsh40Ujp/N8cd4T/j3fHLBY+/EDNAawVujxuXncA7dhB/zmfhqu /RK3BDdUY5jN+dn9cM80honR/rXHAHBIXbHoEpqJ2Pj3fjzKoSI0//TTcXFEgYLhQQNQTnT4ZDrs ZviOQT7+Re164ldSWsZ3Akjb8X2xaZqQ+fJYhA8KxL5YjUY4s4+h5lt+qm0AB/VWr2oKh5+g84n6 a4WHyISK5ifemqt/RHGxLG0L54/sw4+jRnjjcSgEiNC4PvZ9X+OdQa1dXnE/l/tmmMmjAU/fTzOi xB742TP5BpuqtrP2nPwU33AKULAmLcvwrKgcLute/+P+Gj4UrevJPRgZ0PnleZb+SSNjzT1igLOQ ZSDr7F/0qJ66SZGyyOS4mpKn73/uSbz0/mRtwf7fjlf/B5tnUSgKZW5kc3RyZWFtCmVuZG9iagoy MyAwIG9iagozMjk1CmVuZG9iagoyMSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBS IC9SZXNvdXJjZXMgMjQgMCBSIC9Db250ZW50cyAyMiAwIFIgL01lZGlhQm94ClswIDAgNzIwIDQ1 MC43MV0gPj4KZW5kb2JqCjI0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxCjEyIDAgUiAvR3MyIDEz IDAgUiA+PiAvRm9udCA8PCAvVFQ0IDExIDAgUiAvVFQyIDkgMCBSIC9UVDUgMjAgMCBSID4+ID4+ CmVuZG9iagoyNiAwIG9iago8PCAvTGVuZ3RoIDI3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGlW2uT27YV/Y5fgSaNI9leLQHwGTtPN3WTOk2dVZvp1PmgWcvZTVe7yUpJ2n/f cy8AAuBDpujxjLmggMOD+8LFBfmLfCl/kWUms1WVNU2jCjQymReZvN/K7+WtPH+2V/JyLxX/219S Z/y8qpTcybJtiBtuOBijJNotKjev5Bs8pTCVLvJm8C+A/4KnYBj+15VZZbkqpc5XZV7lpbjcyS/W 8ixbZbqQ60upqCO62st6J8/Xa42R6zfy33Jx/sclhsrF+0t5lpdyoXDVmVy8t5Q/iPXX8ss1T719 XKPTx0n7uCMPWXy5lOufRA+oIKCq5e2AmHdznLcA7w/+DKJVJRdPibBcoPmD7PM1ivn2HpPwFYlQ LN/uxI0a5gsxZ5BlR8wpIug2zaeQM+S7At0a9JfSQMqPR1jnZSocp9SEtZzCOm9SIEhZOOswE6zj PViHgnWA7hnIg+6ZgrDPaBKgXywF3X40MgtrmsdlH2YhYJAjsq864nirrYjExj8g3pbnGXxs8WqB ts6MXFT4I8ed57iSMfEvuP8XO21MDAMEK81Aaw7HmRx5DgmBXAeBYPEV2gn61/gBKovRxaCRGlgR +QKMlX04ml+ue8blRSa8D2fP6EGgT3xzqAvM0IILn+FCulOYE+hhCnaGiBc89wKdae5NJuwv9EPJ N9il8IP1MAS81MXOnyPe/bhHgDJZU2eGQ1VW1LXOBaJbrlRVFhKhCggG5sxxUOGWa9xIbmi9MlVZ IgxSv9BCFHxIPUQ7VkPW7VhuhN4dKB4c9d8BuUW6oUb8qA4WD+YunnWeR6zREBHPDhYPjvrvZAHL aGlzI9DuYPHgqD/WDcSIdjA3wuAO1pWAwLJVrYqyLg39lVekDvzVOAU5ZXiIXVcDJEXd1DBFY7BO QSG+BfUwuUTOO9mRHDWjER04BkhGsFpiTZAwI4AOHgOgSxD/TrKo/YRuuBkBdPAYIB4hnHoCAAk1 AqDOUZMBErk7FTkAWtyhsWhEB48BoBBFq3tBqtENPIWVRHrTlfMYDwGGsRihB24iqsNrKus1OrQY PxlgldTC3bDOKGeAPzow3+DBicytgvxg9GeBcn9MlbsmgxN5W+VEg1mYvn+CxE9OZG0VEw1mQfrB CRIPjuUMmXW0wE0/OEHiwUe9RsBrWKJ2vJOnB2MZBPl3lBMkyv1BLEzbSzMM7mDx4Ki/k6dFcqYe BnPH0OTBkZicPD1tloHrDU1yx87gSExOnn4wSzP07mA5iU4wcQ/hTNw3nVVmlDq7KMR/Q2CMncjY qSOMZSFqStWM8QbumgBjgETOTiUBgAUZADp4DIAuonU6p5YAwMIMAB08Bojl7WJQi3fDK4YOAB08 BohlTtsLCjqOAWbJzQDAnUOTAY6aPMUgSFm0JJyUAwZLxWuFFeIbjJ4IjSUcsFwQ8f0TJB6cCMxJ NzwZ0hDaD+auvsGDE2E5ow+DWRK+f4LEgxNBOamGwSxVPzhBosFC6Qobwt+xr/pJIjfSlBvxnvDZ Be7Rv4tn2LbRdiHLyqJUJRJo+kcbnuhWmy5Ryq9UbvAbklcD9ZZIwsI9rY0y6H0jL3iHlsK8Fbmp FeSYIrt774ZsilrlHWR/792Qi1xlXc7+3rshV5nKupz9vRTZ1IrVfKomrQabUklTZXWerXKostam aCg/9LesLr0pzX8G0m+Y14pKD/4Z7a2Z9qJMWYKqUkoXyPMCsL8zDzfIReW1MaiFRMjuzjxk5RnX RU5WE+G6O/NwU59B4H0nP6y1bqiSFHu4v/duyEGy2UqbTGtUd4IMwr15UgjoGssEnCfC9ncsclsQ i2pWqItxzcpg41vQbiPUrLCNpWKKtjUre7GFjhwx1Nas/oCdLW1IuWZlt7u8z8ZON9di8cDuyz+M tuOodSxeLUfKFCVX0Crp2US7b1WJk9k8pP02ts3MRgY2oi0OHGOT11TrQLGhwwYSUxWWGNjK+hKr zTH5vKJCAHbki8co1FD5BkWnobpDUSnSQ5h5pAc9RRGPzmmueBAVhKi6ldEVVQaFwlCOq/9dxwSo lMpJQ6lWkAk2Qk3dLaPatRGJSLAahS2LyUoMcTTZiMasJVQ4yVpy1D+4lGWrMdQkc6hysWi4VvKk SzBUZcdrvQMkdc5lwnIW07+isFRCaigVoiRClkMXyJAu7y+R+HBRh9jDuKjlBqDnkH5NkTtbYrE5 u2axjZl1ENtbyPDjWbKiT4b4fj7MKS+rMU5jhj2DEwmIxRUERJy+GeZUFFQlJZ/ryalnXr3K7mQ5 9ZUmiNMXMSdyDaq7oJgPa68mekaD6n/Z0H4pxFFsf0YiVxDnqyXFKhgc1zkRIqm+iRoE3Fmg9Te0 qEhNBUQqFFLpuoCzQ+vB2qaciwiciwz4ikLl1fKOIm5m650D8c3yFovnL+g8wdbn21BiylVNdcRT gomuFQ9yUhuKqU5Wi2/TR44GBxEOgoYmXNXSPzSasjum6Uw5LWF/ek5aoAMaWDQq8FS01YgDkEWq C95QeWmojCxIdI6owGxVZAp5BwpPtNkLMVYjiA8wzPqLsvODsCibvEDhmBY+87Byf9X+DoIsLRMf 1XXdJcybuJYwgtog4S5Rgzp+hyjiWlb3rb5H9ElhswcwoSTCXYxtgaiBqcMv6Dd3cV2aJarROMqx XdyAp675UYIWsFPtYNNJuz1wb2c8pqLujPOiN2PeOk5RzcetIor8BNVgl9thiz3rJPUUxWw78rZz ClHOJnB4QrmkDQG8pzYDlt8VK2UVuqjsUBs+adJYY7vhsxf5v6UjPVg1Fmi6kIPSIQwclA6Z4KHd VZCiFfunp2r9c5TrUS9NOU82hWleCuNODZe9tKXNXjpKuyti9tWULkSscUrxVhH/A1kEVLq4SC4I enRzjbwO/vjSttzF9VwvBf3murgB/3TNzxI0N6IXSYOvtvNmX508b/bYdN7H1RRW5hffXFCERwh6 8fnf3V/tHcxCwcA+u7jocQ4e6zmzx06mzH47j/J3juYpdJHq4JiQci9jkx0mqie4LaU8mnYvGHk0 6el57ZGkRx5NegSfHdMsyb2T9NanIaquT93RaGOSHY1CndFu8gY3wcFEck7LOPrQCTZSONrpPYXd wzXAEqdKw9mBI2ljz4R9F+cEMcsRI3bH0pMzAuEyAizH/VjjSXKkmUCSY0xMciTC+LPztpZwJMII Hz5GIgxHn2kRRlC86plMG2H8bDm+TJgtR5Z4tsdVEozmLXFFuLjSY9rGFceUo8oEohxP5hA9Ek1G SVIWAPeJNgI2nIzzxBsUlKYrRCFkAVlth7ZZwCm+KChYIxNIfJHrDs4XezKlTKClG2UCU8If+2TK d8QEeunvxDz940Gv9NLF2QESwcnRmr0zpTvin71wfcQ/2+V9xD9PzQCS6gCF9OCf7bxDBjBFTeyn 6byPq2myp/oMoMc5eKrnHDKAKZTZY+dRPuKzo3SHdtITln+FLZQqUD5sUJAI/ooqBaWUeP2FvJov zqAQGah4vNAr+dUbGXbzYeur8LblLMjD1fZ+O4jY4I2uOSSv90NwyHdmweHtw438eXN9L69vMXN+ zw2c8WdYdoMYDLa4EWl6WRCuqgYk65ZSL9nfNjfXr4d4mxpW7cQQKrcTEG+u94chwFzPBHxzdz+o +hyzm8Vw+9v2/n9DFAuUsWYhXt7tfr673d4e5N2ImeJlXWUKtvyTpHm4GjYrVc4E3G1fX28G5alR SpvFcX+43252QwLVCBRzIGH8K7mGtW9+JKE689/+d7O7vt3uJfnB5dX28j9yOfhmZpEhKDhpH48z iTeIxZjt0jvdpwHatzwXY7aL03ZahhEaJtHshMPt5vJqSNyKrEw1p8fXO4qGg4gVbGIO4hEzowRq DuQRM6vKeZAcWn1VOoqmOK6bRfHw6/3tkBgN8ssOYLLcwQypcOyDMqqSfVKk3Lpi3frN80iIT60F vvSQPWZ/2By2FKA2Nze8suy9Y0EMkUvFC0ybaueolU17euJSsnWp7pcEeTkT8Peru/12KfoCKlDG m0FRwEl/vX29OVzfDeqO5I4TV8pZTpL7Yrc5IEjtZVjGSchDqkXtoPMIvIz9bqs3ApYnfdJ6MxYB TT0TEKIdDi25qeZRvLy73V8DdFRjFK1nTX54qS3wCiXH6lmY++1BHu4G1U6WVdicwL9LMU3t32+u D9e3PwZTGvjyCBbkv0ZKzorKzJ1lqDr5amH8IxVBh519dysVyPISlgLRFGxCb8/SHLD77KX9+uFf qILSqxXfxQmtHZHwVRl/C1NKvOlFVbpQNlQNHYfjGI5GuUvycQ0iH71FcIYCG71zgnWH3ibgw1F3 m4pxdFb6AC8+UB3uQ+qGCpz93ALFH3rdgL5B4bdD0IGOXEH6MY3D7TNccZeOWKNhon0cTvgZFxUG vra49MYFnTr4DgptOqXy/NxzHhEvbH/wK2yFzyosXQsX082BZmz90E/Wz86C2u9hPE309j97Di25 HJqBEDyM/933p8+HiAUqgHz1/Wg8scBRFX3A4kWHj3XCjgVv0PFnJzg19X/BUP29VPGKX3PBOxkV Vr1Y8XiVjTeMdA6KhdpeuvZV00dCCDF08Ec6IvZUXCXWdMUaW+DCqiNF08dFiup9T0hcdCCKoiyO bJ/Yk1vfjxRDZ+3nPEDTacUDfw/FlzODIfwTfZdEkqHD3yfAhCIZk46B/X0yI5LYw/B0MkxStX1q i+Qf8Qk9ohILOg3laXgoP70H7R8wDphOQP70AYwMD/fTs5CCTZpmREZGtd0hAJ5n+0PL6jNHAkUy kOE4waT8/Wd+iJfen2JbePl/ecO/hQplbmRzdHJlYW0KZW5kb2JqCjI3IDAgb2JqCjM2MDQKZW5k b2JqCjI1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyOCAw IFIgL0NvbnRlbnRzIDI2IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNDUwLjcxXSA+PgplbmRvYmoK MjggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3 IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEKMTIgMCBSIC9HczIgMTMgMCBSID4+IC9Gb250IDw8 IC9UVDQgMTEgMCBSIC9UVDIgOSAwIFIgL1RUNSAyMCAwIFIgPj4gPj4KZW5kb2JqCjMwIDAgb2Jq Cjw8IC9MZW5ndGggMzEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1aTZPc thG941fAsh1zJHGWAEiQtJXYsipRVbKOLe8kriTKSRUn5dpNlaJD/n5eNxoEwI8RZ/YS6cAFB914 eP2BRs+812/0e+0b3Rz7ZhxH02HQ6LZr9H/+oX/S/9Y3rz4Y/e6DNvz/wzuajI+PvdEP2k8Ddc8D UeOMxnjSysN/6Z/1zWso++cHrOaacWjciL+6phsG2xKC1pjedwqLjI12rQ+LGN/Fwb3mgbVH13uP NWheGmGJp2GGyCprJ0X3mgdp9kwVC2fzH6A5Lax4kIRnulg4m/+g2zYJh4EIg6mZLhbO5j/oDvzL /u/DIK3ME5MuFs7mwyguE+ZBEuaJacjCzXEwnR+8U/ir7ckcMMYoBhJjRJmHuQWIRTsOx6Z1Lhgk jrBR1l/w/DC3AhEZJSA/U8cKMAX0i83FLHEYyMwUzPSxgpxvJaZJCojQTAFNzoasIOccbp+ziF3S MJOY6WMFuQTFDZkoIaBhVLDUxwpgEON623VkGjsiUthIZDfb62CkqAIL5DRCIw/bkaKmFyOlEevP BSA/Y5GHvUM8RmU8gCoWLmYHA01YxEBxfqGJhQu+g3EyYSYzCvPUOGDhnGtYdmYJHsb5hSYWLmYH o8SVsU02ShQuNLHwFDUwyGrUMKMsD2Bp2+CMB4n/mXFYezZf+AyahM0kPNPFwhlNwmfcBnMgwtgi T0y6WDijSfiMwsxBmj3TxcIZTcJnFGY2k/BMFwtPLo48tOniUYW4eByKizd8LvGxYPlvbJJ1FxyL OZIsk2i7mMN4chqyAkxRNkqISeJQiEwSM32sIOdactCk754PCJsU8OQ0ZAU535KDogLskglNEjw5 DVlBwbmYJ22BDSQSS32sYJ/Lx1WZZRzAE63MSrQQcxwHrL0gTRhOwmBEBZPGACqEC8LE6ZMwsxHn F5oSs3G2OH0cCrNRuNBEwqogXlhNwsxqFOapccArG9uj2vovSqtfqDayCrURF1yv7qTgunuF+qw5 NvjnO2/8gKIK/+vyVSqX3iEwTOswXdXewbweJd30DqnHGYfZ9/qOK79SzTnNijSPg4ERdKFZ3j1O s+sG0840x3eP09y1ppljju8ep7lvTDPHHN+Vmt1g2MyXWJL4DjyP3mjXN0PbHFuYcrCuG6k+jK+C LaMrXb8Gym+415Hq+rjG9OpKfzHOe0A1xtgOdV5SHN9cpzfxYtrBOVw0Ms3y5jrNJiIeupa8JtMr b67TW8YMqr1HxeFg7UjXtDwO47vHaU7MNkfrGmtbn3GQ3l3HQtJucS4geDLd8U3QPN023yMPUloy GgI4oI3XzuHSiNsGRci3J06Fptend9rYMDU8Tg/65nRqIXn6Wf9NV588OWjkwurTg67bVlef4Wka XX1+0K1V1a8OGh5afYGH0dXbCp86zH57OOi/69Pv9W9PnDAjGucdoeknNDpHoy5G8zRHoxMatQtN O3gqXoY5GjBmehwx8JXTO3Wen7fVs4PGjbx6XoMoEHRc33nXm3LnmR3sHkM8u6G9YiGsU1uvq4ae g67MQdUtnvFzmwOgPgUXDd4cwQkuQuMw71GEsxGXoeQ1Bn0K13iICEx2oi1vsYW3tI69BAeTrl7D SzAkd+hbVY146OqrOcDU8thupKyAtC0VSeTaVyD9w4uD9mDtazxAJvyYHuCQHp8eUDXpCq5P6OHq NBIBzFz17K4VX2Iw4tdM25ZbJ9o+AoaXZzBqCYbwvlzH1Pp+C9OWY1+BiQhiuhJBhOm7dUxdN57B VCYjFZLRlZhKoynC9G2OiUIDNR2SNTXM+p2RMXpt/UhX+pS50MLZyFwJ+tsD5So4HNIFp8jnFL6I hvqgkDD/SG/hZPC1ugtZpO4Q7LB68rY9TUeFpuNKrJgWRwHjzjJuY8/jVtXr24M+/RKy+JRKnD8O 1Ee8JJnYwbCQsLaWU4Wr6vtyyc3koFKXdW3D/aDjotmW0aVaMZXCkZdM9fUNWQFHOIW85SRWW+QB cFHagu9ekQ3TkAepWf8XyNCqNag70HiihlPKsRZJfAVhszyUJQ7SoezazuO0gb+4p738NcQ3SLJ0 THw5DMMcMN/3JsBIaquA50AdGtEzoMhrzbD0+gXQr7pQPQAJFRHycGEEoA6ujrigz+QhU8aDos9k igi8kOGXhbaku7QOLp10AQT2acdbJprvuO0WO+ar4x7T/HoyRNdeYBrccmdocWfdZZ6uu9qPou9c ApSrCWO5lgwpgK/ZbsXz57RSVWG7PoiG9Embxhk7j8lF5v8e57SFV+OApgcFKIomClA4J5UZ81OQ shXHZ4Qa4nMT69koLTHvdoV9UQrnLh2Xo3SCzVG6CXtOMcdqCRcUW7+D4j+hisBJVt0VDyQ9enlC KYR4fBNG8pCZp4Oiz2SKCPxZht8U2kRikUlTrE775ljdvW+O2HLf582U0v3td3fwnxop6PblD/LX 9Aa7MHCwb+7uFphTxEbMHLG7IXPcXgf5R4F5CVyUOviakGovF4odBmp3hC2VPJZuL5A8W/QsovZM 0aPPFj2qlrDmZ1HexjLEDMOlNxrrXHGjMegzhkteWXfqed3ZclnG2Qd1FJVwdNN7Ab9HaMAW+FZp vToQkCH37Lh3cU2Qo9xwYkG4uyJQUhHgOF7mmgiSM80OkJxjcpAb1cAC5JlqgO+GZ6oBrhT2VQOK qonFRqcME3fL+WXHbjmz5LvdbZLzlcCmSaa8Ikg5q+wAyvnkGqBnqoBNkFQFIHyyi0BIJ9s4VewB cRXQDEF0qgIuiUVFyRqVQBGLfFWXWFwkDKoEJrhZJbAn/XFMlng3XGCR/25/eCmZ+vZNzNkrR0tx Vab8RhVAgpsqgD1wOTpLuP+HFcBiyyk+o1ddaCaO03Lfu820rwJYYE6RGjGnCmCPqThir4McvelM BbCAu3aTXhz/x45+L9HyT4wWfxX3V9/I/coMR9/2rY93+3Abx+2U/hdHaYVqMLYT0kXYGzpAcFGL ilBlKLSo8RbHLF0NtjWiQ/0XVGbU7v0xP9uCBOFNeafhzhN6z4M7mmHE77OmTniD0wALuZ4xy6OA joX++vSgqBik4x8PbnbTyU+NWNxF0Bik14Z7nNQmR20gU+WBzmxNU1BNmNA7p9EXSR1uNtQqpTYR XYfxoUg+J0lc92s8w+mGDkrQQx1n6lFTq4imTLBwrwACAMGvxOiiVFPN8iqopWs5REQ7ztWpKlDJ Lqj7DLp14DYQhR4I0SqPwE4fWr/VJ2uGNehwBA1Zs6wZ+Ba9pizV5KCaNwqmsIe8pZ7hM34sAVK8 m3GH+mewVW28Is5qut5QfQfS+csNGOEZ+KHxTxkxeeemxbZzZmhhS9+X4vtjuNH5vdW0GBahNdIj 32O+FH5VtqQw9IjOL2OwGXEg2hEGeMADebfsxyABA7jfZPxsYedhjXyPG6spfE1EJfAyrMl9HH/r sNN91OzLInafXAPn853uwzWC+DeZFdaUEQKURhQR2H76bI0F+mYmbEI8eIMF+rKMLsBLFvB1YEkD bwLh/1E/+UxshuikihZ4Eb+/wwCtDnw0wc0iwqHLWHBOAYHviD661hNKN4iHXG/uDPit32V6yS2Q Mp9AIcXXb6Aezlh0s1OicbBpoZ4DGfuc4y4LrOpzePCScfxyodS2ajMcC2Sz1QOptfD93PFWNUjm e31QKxhA+m4NOLhEg3rzP6C46y8KZW5kc3RyZWFtCmVuZG9iagozMSAwIG9iagoyNzYzCmVuZG9i agoyOSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzIgMCBS IC9Db250ZW50cyAzMCAwIFIgL01lZGlhQm94ClswIDAgNzIwIDQ1MC43MV0gPj4KZW5kb2JqCjMy IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxCjEyIDAgUiAvR3MyIDEzIDAgUiA+PiAvRm9udCA8PCAv VFQ0IDExIDAgUiAvVFQyIDkgMCBSIC9UVDcgMzQgMCBSID4+ID4+CmVuZG9iagozNiAwIG9iago8 PCAvTGVuZ3RoIDM3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNW9uS3LYR fcdXwJK85kjiLHHhzbIiy5tElUSOLe8krlSUp63YKdVuqhQ95PdzugEQF5IznF2nytYDFxh0o3H6 iib9Ub6TH2XXyGbfN+M4qhaDRtq2kf/5p/xR/lteXn1S8uaTVPzv0w0txs/7Xsk72U0DccsDz8Yo ifHElYf/kj/Jyzdg9vMn7GaacWjMiL/aph0GbUkCq1TftQKbjI00tnObqK4Ng1vJA633pu867EHr 4ghbPHUrPK3QemJ0K3kQVxesmDhZfwfOcWPBg0hc8GLiZP2dtDYSu4EnBlIFLyZO1t/JFvj789+6 QdyZF0ZeTJysh1JMQsyDSMwL45CJm/2g2m7ojMBftid1QBmjV5BXRqC5KzVAKOpx2DfWGKeQMMJB mX+G812pBQIyUIC+YMcMsATwe517tYShAzNhUPBjBinewqsmMiBAEwa0OBkygxRzmH2KIk5Jw4Si 4McMUgryG1JRlICGgcGcHzOAQpTpdduSavQIT2Elkd50L52SAgtskMIIjjy0I3lN75UUR8w/JQB9 gSIPewN/DMx4AFZMnK12Cppk8QoK6zNOTJzh7ZSTEDOYgZiXhgETp1hDs4UmeBjWZ5yYOFvtlBJ2 xjFZKYE448TEk9dAIYtew4gyPQSLxwZmPIj4F8ph7sl6j6fj5NGMxAUvJk5g8niGYzAGnhhH5IWR FxMnMHk8AzFjEFcXvJg4gcnjGYgZzUhc8GLiycQRh1ZNPLDwJh6G3sQbzkucFjT/jUMy7wxjr45I yyDqNsQwXhyHzABLhA4UXiVh6IGMFAU/ZpBi7WPQxO+WE4SODHhxHDKDFG8fgwIDnJIBjRS8OA6Z QYa5V088AivIU8z5MYNtJh92ZZSRgCdYGZWgIcY4DJh7BppHOBIDEeFUGhwoI84A80YfiRmNsD7j FJENq73Rh6FHNhBnnIhYZMB7VCMxoxqIeWkY8M5K96i2/ovS6gPVRlqgNuKC6+raF1zXV6jPmn2D /7q2U92Aogr/6nwqlks3cAxlDZaLujNQb4eSbppD6DHKYPWtvObKL2dzjLMgzuOgoASZcfZzD+Ns 2kHZgnOYexjn1qqmlDnMPYxz36imlDnM5ZzNoFjN52iS8HY4j52Spm8G2+wtVDlo045UH4Ypp8tg SvffA+U3zGtPdX3YY5q6p70o03UQVSmlW9R5kXGYuR/fiIuygzG4aCSc/cz9OKsg8dBaspqEr5+5 H9/cZ1DtPcgPB61HuqalfhjmHsY5ItvstWm0tl2CQZy7HwqRu0ZegPMkvMOM4zzdNj8iDlJYUhIE SNCqk8bg0ojbBnnINwcOhaqXhxuptFvqHoc7eXk4WFAefpJ/l9Vnj3YSsbB6vJO1tbJ6gqdqZPX5 TlotqoudhIVWX+ChZPW+wq8Gq9/vdvIf8vBH+bsDB8wgjekMSdNP0shUGnG2NE9TaWSURmySxg4d FS9DKQ0QUz1SDGzlcCOO4/O+eraTuJFXz2sABYD2yydve5WfPNGD3qKIZ5d0VmyEfWrdyaqh5yAr tRO1xTP8rlMBqE/BRUOn9sAEF6FxKHsULjfiMhStRqFPYZoOJF5MNqI1a9GZtVjDVoLEJKs3sBIM yRx6K6oRD1m9KAWMLY/1RsqCkNpSkUSmfQ9J//TVTnZA7RUeABN2TA9gSI/HO1RNsoLpk/QwdRp5 AqxctOzWeltiYbxdM2xrZh1hOyEMb8/CiLkwJO/rZZls16/JtGbY95CJAGK4IkAk07fLMrXteESm PBgJF4zuKVOuNEEyfZPKRK6Bmg7Bmhpm/UbPGDupu5Gu9DFyoYWzErmi6O93FKtgcAgXHCKfk/vC G+qdQMD8M83CyGBrdeuiSN3C2aH1aG1bmo4CTccFX1EWqYDlTiJuo4/LLao3b3fy8MFF8SmUmG4/ UB/xnGCiB8VEHrWlmOqxqr7Lt1wNDiJ2WZcO3A8ybJocGV2qBVUJpLyoqleXpAWkcHJ5zUGs1ogD wCLXBd+9AhqqIQsSRf8XkqFVq1B3oPFEDacYYzWC+IKEzTwpez+ISdnYtkO2gb2Yp73/awgzCLKU Jr4chqEUmO97k8AIaosCl4IaNKILQRHXmmFu9TNBX7SueoAkVET4h3EjCGpg6vAL+s0//JJxJ+g3 v8QTfOWHX2bcIu9cO7h00gUQsk8nXlNReWLbzk7MV8ctqnk5KaK1Z6iGk7TSXKLBs/jqqqEf/sMs mFUpM6Vs3faOgYtNpCUksNLgZ2H1OyRBDZNB9qMHWT8qErJ+aJ5yeJliKBSw8QeBnfGvynrUBXKZ N+O8zQVgOblVsAtMYrMLrIpdQsyOkIsLiHW3AeK/IEUjTVTX2QMRhSYPqDNg7O/cyD/8ysNO0G9+ iSf4qx9+nXHzFLMwFR1hOjc7wuZzszvk5z6uphhL3357Dfup4d9vX3/v/5pmcAoFA/v6+nom80i2 2yBB4dUW1QsGCdrPeJ/QG3yCkrWmuhv0R9P1zCWOpGt5NF2L2vsMP7PCLCRQNQyuFp8OtFiR0wu9 mC3YvY0hwsm5Ffpk+G/m4LKsmywqNNIBHBx1AJUgdFOBf1N5C63grchydvOiOvf2UorwbnMh63JO S6VcsRMvoRXhmrkxoyGdzN05CHlWPkuF/BU68cxwJicOpz0rl6WnXVHJzAU2uu5MUvRrybAVrIrt HL3XeZnhGgKZhbctvHW7oLEaChXQkXQ7sxtKt3CfpJB1zrghqLAnNoMjPemLM1jhixwPj/niDFNK tpO4SbLdEgTZJ3N5N5vA969D9H73w3r0zq56FOUoyUZxY5LdIi4n2VzcX6F/zo4c/TNY1Zlq4iSb n3uzmrYl2ZnM0VODzOyry56w5rHniHyWz74sY/3STXDmr/uW3vdb/kRm9lcWb7rG3w/UsO9sb7tw N3V5Dbcr+pelUirRwnU4puZOTQHPMUKGFmixYhZplqrvdY7osP4NxQ+1K39Iz+soSF6kSBognDad VMburRlDDYAqnX9zDydq75px1WdLoqJPP/GInT2F74hIzAVusZIzqBqopYeORI37gB9RO7htRIUr 2YDZleangsSF6GTbLSrbct9ZvHzBW6BAQblSt7iWXNET1xTE9BrveLj/ils67oaxNIjK0WiNhq2D gtfPSXX2XMEalhd4uOpLsGviVKX4ub1Auy/5NoXai3Cjfg/uuYtyoi8b9vBy0h62GacSb11s7POI 2kv4JIfgSPhP1mPQKg78YwXZLGhgdgTSAOMscODq99iHqkc6F2B3LRJcIEklK+o3Ixw/s1zGTzXj afxUuI3+BkLA/P6QHQ9yOeew8KCwRWLY/YYdCDk6UA5c5IxewJwzfYR3UvdPwJJuA0j1iUoi5wHe 5WFJVI63fqdZP6f3MSje0Y2mGh471GiEu6v7IKYxVqGqcrYH/UAeWrWiphYX2SCPNxE288FyB/uo +T2GV/qOWU13OrISsvYVUDuFWxnXiPPzN2e5FUUBah/FCk/wPSsETQp4KguaFKy3mP3FM/SgYOHB 4EmZGMIZlpSp0G/ctlEe4aor8J2HHDWO92KHSPDqQkHNgMS5rXNQvBSqYVekDzoEzGbxEEgxowOr PRIsT6aYwMMHSyCu0f886S97hBGyzy9cQvQPiEyvt2C07SjIlGHvCAr+BktX15XTaMSXXJI8xRWK WA79aKUWPOg0CLTlaXJu0MNIyANr+CbCEIsMWaEbekH647ICdI+eX64AbKd+gTBmcCErOHMK9g3x o879OQDm1Eux2L+VqHt+W4G2As5GwYi6VNEJ87e++C3sfTz3zEBkY+7BOuQgNl9vxcGofSq6gMFM Vi1iCUC5Yb79aVCrR9Dg4YMo3mFbtFAKdoQkf63imzGraArYxZ4qAYrKHMKBIh0NoRLTk/RJ48ci sCxsh+R5OiorsCa94By1gtus1EgtnC5s8csmzxaOUnAmrDZnfusCLkd4BADKKASTmH9Z0FKfkDJK 2O64oYUiZ2pAvYA2CCJvSwBuSRldg7eXC7t4VzqhkYocaR7r8SnyjCndH47U42Q7c0ZU3fc+eiQJ HAXFCcFglc/ZRpwP1xRUEYu5pIDN1OAbgmzpDVTaL+zZDCfrI1EN5AEoFii8EPYrdRI+eim3gA0t 5fA8fFQX7L/lNyj0cU4hMbHzXfzUdXN2AKkFQ0AEeWGXiDauwKEXVSv2okc0rv8/8RyJqeDMnnVm 8cgqjtWjYNWHMQeorHpc8gn6MDJIkjgd/seIMkUGp0MFjI+LVrzBogZZYGc2hLsnUA8UkzUOkjSQ eMeR4sbfeKkfPvcwi0okF+6Mmwx7GMx8xVYsfYXwMFuBwujLoDSTJHmwbaIx5uFhVszkmnLhAbZx PDywLf02DZzv/gc9kq9zCmVuZHN0cmVhbQplbmRvYmoKMzcgMCBvYmoKMzI3MwplbmRvYmoKMzUg MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM4IDAgUiAvQ29u dGVudHMgMzYgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA0NTAuNzFdID4+CmVuZG9iagozOCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+ IC9FeHRHU3RhdGUgPDwgL0dzMQoxMiAwIFIgL0dzMiAxMyAwIFIgPj4gL0ZvbnQgPDwgL1RUNCAx MSAwIFIgL1RUMiA5IDAgUiAvVFQ3IDM0IDAgUiA+PiA+PgplbmRvYmoKMyAwIG9iago8PCAvVHlw ZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNzIwIDQ1MC43MV0gL0NvdW50IDYgL0tpZHMgWyAyIDAg UiAxNiAwIFIgMjEgMCBSCjI1IDAgUiAyOSAwIFIgMzUgMCBSIF0gPj4KZW5kb2JqCjM5IDAgb2Jq Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiA+PgplbmRvYmoKMzQgMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvWUtMSkxBK0FyaWFsTVQgL0Zv bnREZXNjcmlwdG9yCjQwIDAgUiAvVG9Vbmljb2RlIDQxIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0 Q2hhciAzMyAvV2lkdGhzIFsgMzUwIF0gPj4KZW5kb2JqCjQxIDAgb2JqCjw8IC9MZW5ndGggNDIg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QsW7EIBBEe75iy7vihO0aIUUX neQiySlOPgDD2kKKF7TGhf8+QJyLlGILZubBsPLaP/fkE8g7BztggsmTY1zDxhZhxNmTaDtw3qbj VDW7mChkhod9Tbj0NAVQSgDI94ysiXc4Pbkw4rlob+yQPc1w+rwOVRm2GL9wQUrQCK3B4ZSvezHx 1SwIsqKX3mXfp/2Sqb/Exx4RcqNMtD+VbHC4RmORDc0oVNNodbtpgeT+WQcwTkeya7Wq03Rdzf86 BS1ffFSyG3NuU/dQi5YCnvCxqhhiebDON29qcBYKZW5kc3RyZWFtCmVuZG9iago0MiAwIG9iagoy MjIKZW5kb2JqCjQwIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1lL TEpMQStBcmlhbE1UIC9GbGFncyA0IC9Gb250QkJveCBbLTY2NSAtMzI1IDIwMDAgMTAzOV0KL0l0 YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAvQ2FwSGVpZ2h0IDcyOCAvU3Rl bVYgMCAvTGVhZGluZwozMyAvWEhlaWdodCA1MzAgL0F2Z1dpZHRoIDQ0MSAvTWF4V2lkdGggMjAw MCAvRm9udEZpbGUyIDQzIDAgUiA+PgplbmRvYmoKNDMgMCBvYmoKPDwgL0xlbmd0aCA0NCAwIFIg L0xlbmd0aDEgNTA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4ASspKk1l4GBoYGBm YEjOTSxgAAPGBCAllZ5TmQbltwDpsIzUxBQIn+EPkDbLAApA5U2AtEpGbkkFlB8BpDly8pNh8jVA PltuYgXUfIY7QL5CXmJuKlQ9mA9hQ8hcBi6GBce4WUA8luPcLAEh3AyMQDYTEgZLMjA0gMQYGKpc wRSc4GOAaGDaymDDcIqBHahVgEEfLAZSwwrkgwxkO3P2YQx7fTy/zVcOaQ6w7kWP1bVAjLMBV8V+ rf+bLsDAEQjkcsL1AvWx2/3zY3AWYPi1/leVAMQmsF4owcQGVMx0liEXyGeE6uNhYGPgAfIV4SIM DKIM2kARJpBDWIEQGAvsQAWCioKqQIKRgYXhjwLzgT8OrAy/GRRYDoDMymW8wJTBfJqBm4FB2MTM 2EhMVIRNWUktd2pG5tSpmRlTmc5lTpmSCWQDjQSpF4LazsYADJBIbx8vH0dtx6LMxBzfEAAr0Ebw CmVuZHN0cmVhbQplbmRvYmoKNDQgMCBvYmoKMzU1CmVuZG9iagoxMSAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9ZWkRTTkQrQ2FsaWJyaS1Cb2xkIC9G b250RGVzY3JpcHRvcgo0NSAwIFIgL1RvVW5pY29kZSA0NiAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFz dENoYXIgNjEgL1dpZHRocyBbIDI2NyA1MzIgNDczCjUwNyAyMjYgNTM3IDUzOCAzOTkgMzQ3IDUw NyAzNTUgMzE2IDI0NiA0NTkgNTAzIDQ5NCA0NzQgNTM3IDUwNyA1MDcgNTA3IDI2Nwo1MDcgNTA3 IDI3NiA1MDcgMzI1IDMyNSA1MDcgXSA+PgplbmRvYmoKNDYgMCBvYmoKPDwgL0xlbmd0aCA0NyAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZLdattAEEbv9RR7mV4EjSX/BYQg pAR80SbE7QNIuyMjqFdiLV/47Xtm81PoxTEczcx6P2nKp8P3QxwXV76myR91ccMYQ9LLdE1eXa+n MRaryoXRLx+Wn/lzNxclw8fbZdHzIQ6Ta5rCufKNkcuSbu7uMUy9frNnLyloGuPJ3f1+OuYnx+s8 /9GzxsVJ0bYu6MBxP7r5Z3dWV+bR+0OgPi63e6b+dfy6zeq4EROr9yv5Kehl7rymLp60aETa5vm5 LTSG/0rV/n2iHz5aq1XbGCLrh7ZoqgoFkY2Y1iiI7LamaxRE6rXpBgURybNbFES2e6vuUEAH0z36 YLqrTTsUOCqf3KNAtbKqR4HZXA0ooN6qigLN+Y8GFKhuqNaEN9CVKeEMmu2SNeEMqhahJpzBNXIz 4YhmmpsJV+eAjNBMOEOEf0cJZ9Bs1+Ang9qr44AM2pmS1UDzJcla57yb3qpkNXjtwZSsBs28K77i 5+eyD2qL97Uo/poSO5K3M6+PrcUY9WuB52m2AzJ/AaAsx7kKZW5kc3RyZWFtCmVuZG9iago0NyAw IG9iago0MDAKZW5kb2JqCjQ1IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5h bWUgL1laRFNORCtDYWxpYnJpLUJvbGQgL0ZsYWdzIDQgL0ZvbnRCQm94ClstNTE5IC0zMDYgMTI0 MCAxMDM5XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWln aHQKNjQ2IC9TdGVtViAwIC9YSGVpZ2h0IDQ4MyAvQXZnV2lkdGggNTM2IC9NYXhXaWR0aCAxMzI4 IC9Gb250RmlsZTIgNDggMCBSID4+CmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDQ5IDAgUiAv TGVuZ3RoMSA0ODkyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AW1YCZAc1Xl+fff0 9PRMzz2zc9/Xzrkzs/cxu9pTe2gPdKyuXUmLhHbZlbRopRWSMUYSJixgykQQG1AZQwKUYVMCmUJg XNgWMVYSgl3YwSknqVCVYJOqRIZSSmJm83fPzEqimKo37+p+73v///3H68XD9+xDLLoPEQjtmZta QPIP+x1Uo3fOHp8p93EY1zywf9/U3nIffQl1bj8MlPtYHdS+/XOLxyr9LVDfNzu/pzKPx6BfmJs6 Vlkf/Qv0XXdPze0rP6/9HOpQuV3+n0McOn9ZSUo98j0lOTKuRBi08VuKPAn7SGMILW+Qq/U/Ackv uDAX0qC3EQOvalAC7a48QMKstCCNP3ru0pW9u9TNXyALK09e+tO9V6TGP628P3Dj4+KK4jN2BJ5V yJtLE/Ae80zxY4S48zc+vn5G8Zm8kjRT/blIaft/BLwetEIW0ArxZ9RDDqABkkH9+IPIAu1T2DV0 ihxEvfjv0Ckihfrwy8hE/BIZiR8hF/E+MuJZdB73opP4U+hpKJthzXEoLVAaoHwXyhYoE1B8UHZD qc4XAEj5fAjxiEZd0HcjO5yAQAKqgTkWBMwjFYwpQTYKpIanSJAQhczIiSxIixzIhERkQzqkR9bK wRbRIjqHfoNFsXuxy7gJ34l/E3+LIIhpYpX4gmwn7yUvklfIG1SEepi6Sqfoe+j3mWbmfua3zL8y /8lKqCiESkeI31MCIGFQAxpEQwBVdIty0Qs4w9C01xPHs8FALpNJt+LZuoDXI+DyWF0u30pk0g6c gCfLI6241MeI3385TGwo+vDj7qaxFIVF/SanjmUJp0Plz7jUA4PeXMhKkSxNUCwTzBW8E0v9nn/g zEGbPWjmoLbboC6+SwnXr1LCjc1k14238P9q2NLqo4+rlDilYJ8OOQy+lK1lQKVWUUKNyWpjWFHg Ir1TxaesfhPHmfxWm19ay19sAgmvrF3HnqD0yICQv4pWrCvDNWBPqBzpYCDjUKmc6UAw7VD5OA1H 0/BHXq62JLrDKiQB0rKhMMhJWscr3lwtl3GnHSRVF5eGJWGRRNf9b983W1mcT4WwVHxscWk8Vvrv ZPdgeOFo20TORpye+5sjzaU91X3IhxMJxtS66xvTXVsiylKfp2UCdu5Z+5Q4SvwWZVC7dAJJK4FA NlvRjnSQTFbaeF03raSkCQMjjRj0xkw6lyeO6qOR2rCYX7mjZ2lzsuX4a0ubxWBHsm3PxoxGKSpp zta9c77pwBO7Y9d2t9yRs/S0ZbfGnYKGYTRCT1PB3zfbO3RkwJeLtEX0No9NsAZMTp/d69CFJ85s /1jry7jr23N1gHYA0F6h5lAAOHVT3reiTRtN6+InAjKnDHoHsKcVzxNXOHPY4QpZlBvObZ9Z2RrK TD++a2C5WWlP+v1JG389tyeX6okatOGuOmsqk3N5lGqOJDm1ck//6PCZC3uWfnKmt6UJ+w9Oo6Rp pYYr1nX1pkb3ZevvGkurPfkQIOwHhBdBnlEE3hLT0153ZXdZanqhzPoqQYI5GSFDXAz7iv9e07Sj o7C3L6lW8CyBk6yqcdtiYenCsabWoy/etfDsTPJzYnJXsidhwbHr8VjDjg6PzqRjtG6L0WlUC2aT 2Lz85smld053F+45v9N113Ffy1hC8hCWtev4k9Qx1FzhFtidrD1DGRN9K9lA/dmK1mUSk/iTJMvR jGjxmGqCVv45hZqj9LrneFva50vZlQs6HQVD877BpU3B7pCgIMmrdq+OYVhG9DdFRzlTyJ5PFOMc vEbBH/5hIm8PmbiByW9PxsHGLEEJ4am168SH1AJK36JVUaYd7HzTECpmJeZyMnLiQ96W8vlTNl7n awgkp7O8rEg7X607zvZNnhz0eKqbY8WO/qy9u7P4anWE8lZ1WdK1tzXv/4s9ZTTYMqD5epterq5e rdeXv7mYZNO9a5+SJDBBh6QjVg9R0bxszLIFlblJks3Lb5xYWl2sb1n+8Yljq0fqS0VDeqytfjxX Y0yNtzaM56zYp4fferC/cOqNo4ffPtvfceqNbxbmR+Ph4fkeqGvDQ/MVSeKXZHte31PS9ddI0SD7 WBq/BETjWL3FoTVEakGWFRly1rDTFTFx3tb6epvK4TIrKRInBnxxKyfp1tccK/6mKkXi3mprPt0R UBOMguMNEZBk39qn+FVA07cuAVJmF3iQstOP05U+bahIqOxXHDR+tWH/I2Ppyd6kkSdZXqGMtk/k PNmg3t8yuGmwxZ/eeXY8Mtwe07EkQTA8qwg0DCQ9aZcm0Dq8abg1gDk2Lg4F1SazoTZm9xoYi8Mq WENWR9Rl88Tat7W1H9wY4bUGtdrgNNV49IzBbBCsXr0z4rK5Y+1bJVma1j7DHyH/FjXKrCTlSCR+ 1UBww61mBP6wTFL8EaXWm8jbBu7u9RzU6SXq36W0l9n6riQtve5n8Sa9yyIytJKmlmMJnVpJB4aP jWK/LFvIe8BMigIv817Zhko7+voYBcMYfBI2I1jMBeIygpxL4haDCYSEL4hBTK1wzKQz5XWVQHoB Iyiy9DklBjtz2c6ASJU+pxlMaUv5w2k7T/6Kpv+OUNkSAX/CyhHPUoJoFL78Z9HAkxRv0BBBvUug ATRJKUS+eMhiwR/lRQUFnhGQuADJCiABV+M3QuSSUBBEGU5eBz64bK0mnYzFaKQZgjjNYrbGZG3e qSaff54U7HWRWJ0ZU1z7RIFZG1KxrEOgnn2G4K21wVjWhCn/UAd4KEKh4rCW0s84lQJipVHEfox9 X2sRaIJWcaWPsAjLsyQpWPSlg5J8Sk8QrwEqEJabKEezvC4QCGKBuiqejE5SldGoZ/BvzSpGBkNJ M84sqQxU6e9V5oZENG0TmA+Jn9K6WD7aUMOWfm4xMhqziEVpi0DUef0GluAtpuLL+JRVZFmj3yJZ /fm1P2NvEq9+vdWvu7KKhrA3BXcuHM65eb5cC1/tE8ZIvU+t9tVHoo0+jcbXWOyNNEgDDZFIk1RL OchJ2PMFLAQ5nhTBZYKCgzRiL3SMj7d3TIy1P7ajvW3LzvY2ePbp0it4gToL2R+ipOgk5WBywIQU A+K5FAsk34oXtGLpV6JNz/N6m4hlWXDsWvHcOan+v3SI07uMdNrgMigUBo81E7z+KGv0wOqbS69g perqwAV3NZqsm428DVZSwaql90UtpVCxTz5ZrrEc7KcqGV16LpS2eowsdSiYsXqkPVzginE0DrH1 A8oHkbX3Nn8iZSS3+Q+mzPqqk2UqIZj4oHnxpfltZ6Zb/YI6OnTi1WOBwUJczVI4wQocH8j1JTct dLswY0PnUGz64a2RUkkbKiRsubqkwZzoScQ3xM3Y6vRfH98QHrz7oR9Mbnzh/Hfm2hWCVqXR2fTO sIlTafjmOx/cKMA5cnsfWcgMZms4oOjBR8e9ntYxBNlwi3wGP8SEPOpZP4Vss/k4UTVdyRkyDgIr h0ApgTHlcjroBQWinHQRH7QsrR65+4WFenfHVFtmtNGRn/vh7MGnphPO+tG6lt0Fb+kP+mhbdHzU EOtO9g07LNmRbLw7btq3d3oKm9zy0K5UbOLkpvzUWJ/b1jG4PTf0jR3p+Pg9PYmtIz12V+/YTrzF Wx/UD3a5csm4NTpdvOhvyaWtlnS+xTs0Oi7powHO8hHlB65Hbz+JxCAQPnhMKUeUfT1JfJQ+9Pq3 Tr8yE84cev3+06/OhErXOIMzVu9pGqzVGhP9dcHmWoeOwR/+3vXVnZMvX/v+X92Q6xe3r+zvjWob Dr906KHXD0Yt6Y17T8F26LsgzlXKhOKVnEGmspy6gEulIYmFdt5fZoJBJjWxSisFRTHHCuBxofW/ H5jsIo2zAo8ZKbU56AwkzOyvFWoltdcWlFJ9+dqgJPqPKCkxEjA7jQL7GkkRGMQbxY1fK81y7gK3 YOItkELrV3Dk4RLzldSZltMWSbeMZAfwGiTnRTMwXkFrLPp/6xyNi4Zwa6RpckNcBZZBETRn6Zw+ 2r7v3N6UeeNDh89hJU7k6YP2sFXJmmJed8LvNfxP95FdIz53U8zi8Dt5W8JjcppEs99rzkye7G1b Xnn50Pd4SxgkNiHlpoAUEFfyEYi+cipVCcZwv5D8gSxE+U52W+J/E73BQRAX+x94Y66wuLVRq2AI jYZLbZzpyI832b0bDvQsqLQ8hC6RP9S4rcVljHbF67b3ZXjJQeO0Qt+680Tvzu/syTgaNzd0zQ6E sBNTfzmT1dkcGn1NGNKPGmeNNdEZru3N2Bhj0Gn369madE/U3RS1OP0uRh9wWNxGjS7gs8TGjm9s mhmpFwg2OwKfGXDkg2j0CdzHIhIvpPzbW00sstkqQ/LYTVYYMS/mJj4xaI/wjmRAymhLomBUMwQD weZxyhwtJDK9Uf0Rjal0AC+9jG3GFjPZP1bTnT8ylkTQlQh4dPgvFCoFCeFa+eUXKfyB4o9A3rtB 3qtwqwNm3JR3OT1YF7hH9tciqKHqgN2V9JZY7Tt96XDz7B15ETwUCXcCLty5u7NxV8HnaJ/pa9wV sVucHnyfAtIEg75U590QOPDcfCP2wwPPH2pWm0xqrSVgla67JpvJnB2pTw7UWXl7EE+HvLw16mjO lf5E4qldK2htrepZcVrKeaFf8VLQN8JtHkcFOMk7wJwkgts9nEXKhW7L5PK3XBird9V1488R72hq h09eWI5OdKeMHMRxBR9rG0mNL/Z68Pj943c+ti3cePilhW1npzr86tINc7I3meiqNerChUTjnfi7 wy/+4PG5dl6rN4R87pCREbRC88yZfns0N/P49qnnlgqRofkHn0kffOwOn7t5NJXdlLV6pU8ZGHzf kL7+wPcf8FFo67ausaGuaOfU7IHpwwdqC/Oze2Hq/wEXkIuCCmVuZHN0cmVhbQplbmRvYmoKNDkg MCBvYmoKMzY0MAplbmRvYmoKMjAgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVU eXBlIC9CYXNlRm9udCAvWE9VVlZKK0NvdXJpZXJOZXdQU01UIC9Gb250RGVzY3JpcHRvcgo1MCAw IFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEy MiAvV2lkdGhzIFsgNjAwCjAgMCAwIDAgMCAwIDAgMCAwIDYwMCAwIDYwMCAwIDYwMCAwIDAgNjAw IDYwMCAwIDAgMCAwIDAgMCAwIDYwMCAwIDAgMCAwIDAKMCAwIDAgMCA2MDAgMCA2MDAgMCAwIDYw MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMCAwIDAgNjAwIDAgMCAwIDAgMCAwIDAgMAowIDYwMCAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAg NjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgXSA+PgplbmRvYmoKNTAgMCBvYmoK PDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvWE9VVlZKK0NvdXJpZXJOZXdQU01U IC9GbGFncyAzMyAvRm9udEJCb3gKWy0xMjIgLTY4MCA2MjIgMTAyMV0gL0l0YWxpY0FuZ2xlIDAg L0FzY2VudCA4MzMgL0Rlc2NlbnQgLTMwMCAvQ2FwSGVpZ2h0IDU3MQovU3RlbVYgMCAvWEhlaWdo dCA0MjMgL0F2Z1dpZHRoIDYwMCAvTWF4V2lkdGggNjAwIC9Gb250RmlsZTIgNTEgMCBSID4+CmVu ZG9iago1MSAwIG9iago8PCAvTGVuZ3RoIDUyIDAgUiAvTGVuZ3RoMSAyMTkzMiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVfAd8VFW+/znn3qmZydyZudN7S5s00ghMIBdSLAgBBUmQ SACRIjyIgK5lBXdXUUDBuir65D3LrqIyJKABdEEX21pwV9a27sL6sK3Gsg99voXM/L/nzgQIW97n Pzenn9vOr//O72bV5asXEBNZSwSizF82dwVRf547Ubw5/4pV4VzbZCJEt/HSFQuX5dr2ewjRLF24 9KpLc21vmpCxixYtmHtJrk1OoGzgHbk2rUMZX7Rs1Y9ybY+IcvPS5fPz415+3rnL5v4of3/yIdrh f5u7bEFu/oyfoSxZsXzlqnzbjXLpissX5OfTTkKMO3Jjw3khIRT1OI2Sc8hPiYYwIpEqMoMQ4UHN TCKizcc1hJQdfP7WOZam7/QGvXryQ4lp6nO9WPDbf8/q/rZZPK5PYsCgzuczcJ72saF7CRHfyOqy vxOPnxxRz0cW30OmZ/cL+/tm1CoDKMaqRX9hvGYtmv0FZrXsM9Q2T6gS9pMVSNuRDiKJZA7yNfke gYRQa0bivZuQRLJV2EvSSPuR3kLiPXvQswc9e9CzBz3NwgChwjPC033xEJ5gZ78nXvP1BK/QT7JI TLhN2EAiuPbF+XJOvtyEsgz9m/PlLcKGvlTIMsGANiVfI88iMbzb/X1nddTsViujm9TKluGeLf3o CU3wCPfjqe7HU92Pp7ofT/U1coqrb0H/FvRvQf8WtX8LoeqlIqX5S+Ur9/dZnPkeVCYYhS7hQlKD S3Tmy5nChX01oX0TeoQZuPR2Nd8qTEd9k5rPUfMONV+jjq5R68vV+nK13qzWm/N1fm6VWs/lIbVu 4blwvnABKcXdpwnnquVUoY0k0O5Am5dThHPUcrJwllqeh343+icJbcSG8lyhXW2fg3Yr2mejzcuz hPa+1lD1hBVoz8EYIxaB97fiSVoBzFYsEu/ZhLQV6bDaMwf5GqSDSII6kwqtOFpwTBAm4AwF11Aw ohBBUHA04xgvjMfIOLzNOOSK0IT3DSGvQmpG6kCag7Qf6S0kndCEPCzUk2okBWkqUg+SBtcpx3nl eK5y3KFcqCBxXCvCNhIZZThfhtgGEkQ7yDb0BUPKBAPbSaYi9SCtQFrLdvZpbJYJMubxuVVIHUhz kNYgPYi0HUlPmpFjRClgzaxZ6GAdggjsLu1vaqpRy9qGXOkP5EqTt8Yy4XKhFMtUSh5EEvDIpXjk UrzqcCuEGgPqFJN9SAeRDiPxBS/GYhRjMYrxgsU4v1idpVXnfY1WFkkgy5GvQTp9Dl+aYrxyMe51 6iq8twQ9JbhmCc4pwfVKsIyHkVP1DD4+FWkT0j4kPhbF2CY1b0begcRwjSjegNcsyENCtI8ZLANY XzrWMmE01r0DCYPsFqzmLVi3WziGYPWA2xhpzs/YhHI7kkbYjaMURzGOEhxRHBEcYRwhHEFAbzOO TThuxXELjo04NgAa8vbkviSbU7+8fk39pvoH67fX76vX7WVzcfSwHsVInE7wRJtV750gMZHMJmb6 NzV/Us0vV3NFzV2Kd7b56GzzK7PN98423zXb3DnbPGW2uX22uWq2eYDOU1xJ8x+S5s1J84VJc0PS XJ801ybNpUnzBCvtojOJmfxKzSeqeY2aR9U8QGf2mYnhWXoRieiB8bR4Z+T60MeRAZH2hX4aGdCj +EmudVGuSPHOp0PVkYWh8lxPUa6IR54TcQUygz5BdDSplOte1c3RKboxukpdha5EV6yL6UI6WW/T S/pCvUlv1Ov1Wr2oZ3qilweyRxSIE0pkrcQLLWQhJaJalxivI0NOGNUzci5J24VJbNIFE+mk9P75 ZNK8cPr7C2ID1DhtVloTm0jTtklk0vSJ7vTo5KQBXfb8dGNyUtow9aLOHZTe2oVWmt00QMn0zgGa 5V03+NK2ls7dhNLyG27x5cuuLn5O5w6R3nJLF3Fe0exuto23jmlv/QdZj9rZ05o89XOfqiaT/EkC 6bsnXdCZfjzQla7hlWygaxLW+YLw7M7drJE1tLXuZqN50dW527iWNbadz/uNa1vxIMPzSBj9rbtJ hBfqPBLm80j4jHlBNprPS/AiNy+ozguOmLdjXKStdUcEWW7OOHXOuJFzFo6cs1CdszA/R1CfX73E 8HV0R0hEnRPRHVGf/fQ5wdy9/uWcxD+cc9pyLph4WuPvqnQ3OZe+s6Pl6rYFsbaeWNsCpJ70hisW udNr54XDu0kLfYcPhdNCUc+8+Yt4OXfBAH0ntqA13RJrDe84Vz115Hj6aj58bqx1B7m6bXrnjquV Ba195yrntsXmtnb1nzW37MkRt7t5+HY7yub+/c3Sc/nFyvi9zlLPO+NeT/Lhs/i9nuT3epLf6yzl LPVeKtYDLfVkYlfL7FzZzwqMQOAeX6RrolNaMV7F5lTEfZ1vj0joL0lBsittik1Mm5E4oldMqJjA h0BlfKgQ3Zb8kPu6VMS3h/4yPySh2xqbSNxti1vxt3JlvpJr/p/5ypUrV1288mIUK1epfytXrUbJ YUZWEmiueIMJJlW+hcCNOW/egLRR5dHCypVdq4gK35WrCb/7Kp6dvOmp2mpcnK48HRMIv+WIH0Zp kuQSLrdyNcUz8MdYnTuPrqQYxGVw6qp8H3iO+CnS7cSHMijMg8Qm2cP59FHmutx4ZiibZe9i8vR8 QqHWppO70IeDTs6V5BJyiCwjt5Gfo6+WvkkeIwqxYOwQESiBxt5E7iBXkt+TGdlv0RshD5GvSTkZ QxZlM8RK1pAM/TF5iDK+UqSRvE0WkM2sSUiKX4A5ltFqYRv9CanAVaaTu4mLHMQVy7JGtPtZgDXh rOnkNWGOvjxbnf0r3S++mp1H/pM2sXfEp8jrZJBGRZL5aXZDdkv2flJIjgmBoV9nR2WX4awZpIes JtfiCdaSfydv0C42ju3L3oxn6sQzrCHPkNdoEgjVA43ufMz+GbmH7Ca/IgfJe+RjSqmFltC19G16 SEOGDmQOZM/JzssuJ21kCplK1mI0QBN0ApslzBKeFN4d+q/MkWwQ155OriA/IteQTWQz2UbeJe+T P1CBGdl0NkN4kvjIODKLzMNq3oFneoy8Sg5TPa2jY6lCb6RPsCtEYegAJLxIHFjBs3G1SzB3C9b0 EbKdHCBvkd/imt9iTQXqAfBn0Nn0x/QGeiu9kz5Cn6BP0S+Yhr0nCML14kviF5l3ssbsfdnHcF8f 8ZMwdN1ywOA8wPMN8he8Xxktp830dyzJygUqmoYymdrsWdk12Rez75IYKcbccdBr28hkMhNPfRXs r73kJZz7BnmTfEL+B6skUCO1YS3CNEbPpxfQ1XiKJ+nXdIg5Ab9GtpT1sUNCUnhDnCk+NbQz48j0 Zb7OZLPbsunsr7Ovq/BtwH1aAIFusgIkxiG2C/d5kRwln5PvcA8tDeFZz6aT8L734PqH6Qmgk55d x55gWWi/m4VXRY94T2ZKZlnmnkx/ti47GbglQOnykDocY4FNM0gXrv0TrOZD5HFAph/Y8w75irpp kFbTc+iFtJP20EV0OV1Be+k19Fqs6mN0J91L36F/oF8xkWmZA+uUZPPZT9gdbCc7wN5hRwUiXAAb ple4RrhD2Cm8JXwmSmK5WC1OFnvEq8SrNVDJtE796ydcJ5YNzRu6b+jXmcpMa+ayzIbM85l3Mh9l C7L7sh8TLanGM3aRhXjGH+P9byS3kgeBH4/jGf9MPiVfAOZ/xVoI1EC9eOKQCrcWPPdkPPlMqEyX 4lhEl2D919JttI8+S/fT5+mr9DX6O/oh/ZpRPH0ljhSoYAa7FO9wH9vG0ux9HN+x/xWKoPXXCLWw KnrwNuuEm/A+Pxc+FD4WmegQR4kXiGvElzWC5hLN3ZotmgOaVzR/0Urai4ChuSPHP9RceJ09L44X lpKtsA4E4S/sd6yJ/pgdp79gAfo87hYQpgpTWQtLQTfaCyxfRmTdFm1EG2EykXQ9/CLsXlYhzBSL BBNZBXojbBa7kfWQR+mz5Dg7G5h2hfAG28rmCFvE28Xx9F3YF8/DFWCm35MJZAIdD9i9TXoBoQph u/gmv6JGL5zQLGPm7DrxUw0Tfgc+OI4y4Td0Fh2kU5kTq5Vit5IY2hIdRHkOKPB9YP5uqJ2N4hFh IzuX/QF9S8kd9Hm8416ylO2l/wm4NIIeL6dT6f3CKHId7cWKjCFL2J0kylawKPB5Bvlv+hPqAOUe B2zi7FIiCmY2nxxiXYD6W9TGKul1wNNlZANdT8rpEN1PXme3kQa6QPjVCc9QCaMnBukO4Wyygx4X XxVfhfJ9HCsZAObqqQIMeQg8YgYoMyIUAWsaiYbBjgM99YDWrew7ei1bShbTe4TP6SNsAukgC4SV rJ3enflOnCDUYsX2gJu0aMfoiaZJExDrAPFPyXhg40J4SBaJhzU/4XXhbeFYtisbyczRFGY+JFdj dc4Gd9sAWjqbfECd9GI6TcyySWI2eyHZxraLH2Zd1EQj5LdZUFhmF22i8WyY9mYL6DRg+MXc9yJu EG8QV4vXQj4dB9e8kdxO7iMvQJo8DLlVjHU8D6s5G7xnMWRENTwG9Xi78WQiuNI5GJtKLgQ/7QGX vJT8G+kF532APEF2QEJNwnpcjPMuJUvQvxIS6hpyHeh/HdkIHnA3eZT8lj3OHoSNexN7kV3BFpMP yAfCy4JCLySHxJvFNeQC2MDTqB13Hg0ohXDexuzbuFsp8YH714FKgfnZL7LvZH85dBDXexTPfrt2 IvlC20JKSAf9XvRSjTJhutI8flxTauyYxtH1dbU1o6qrKivKk2WlJcVFiXgsGgmHggG/z+txu5wO 2W6zSpZCs6nAaNDrtBpRYJSUt8Xae8Lpop60WBQ7++wK3o7NRcfc0zp60mF0tY+ckw7z8+ZiaMRM BTMvPWOmkpupnJxJpXATaaooD7fFwuk3WmPhATprWifqt7TGusLpQbU+Wa1vVutm1CMRnBBucy9q DadpT7gt3X7FovVtPa0V5XRHgbEl1rLAWFFOdhgLUC1ALe2KrdhBXeOpWmGutrE7GNGb8Yppb6y1 Le2J4VRcRki0zb0kPXVaZ1urLxLpqihP05b5sXlpwrXApDqFtKi3SWtb0jr1NuHFabwN2RDeUb5/ /cYBiczrSZouiV0yd3ZnWpiLa7SlrUnctzXtuvqo+1QTF4e+ue70UZ+wvs29OMwnr1+/LpzeOq3z tHN9EX6Fri5cA+eyRHvP+nbceiMgNYlbSml2Q1dnmt6AW0JnTqhvlXu/nEaf6FkSThtiE2OL1i/p AWi869Pk/KsifV6vsjt7hHjbwuund8Yi6WZfrGtuq3+HTNaff1W/Rwl7Ro5UlO+QrLmF3VFoyVdM 5tMrC7DouTG1pk7ntUnnn1xZyp8xdk5aAUbND+NJOmN4p0aeLWgk6+c3AgD4dVGclb4EEFmcNrT0 rJfG8n68Ik1rElIsvP47AgyIDX45smduvkebkL4jfJDjyUlUS9O5w/V0MpkuK+MoomsBTPGM49V2 fUX5FQNscWyFFEYBg4hMxdrO7RpbheWPRDiANwwoZB4a6bXTOnPtMJnn6yNKFewG1sNH9g+POGbw kbXDIydP74kBk3dCiSDEkdYXnfyzSE5726Kxaer8F8MLcuOTLohNmjarM9y2viePtZOmj2jlxvmC Yt0wlq+l7S2dgo+hj9eYT1BHgZSzZ52cgkanKS0m8KdVkfqSAZ0eWKn20HB7Wuo5O5d3GSORPM38 XycNZL/hZ6nFqdPyr5Eem8w/aO6x06kR7RGPZ1ovTJoOlsMmTZ+1fr1xxFg7mNn69e2xcPv6nvVz B7Jr58XCUmz9biggRetXtIEN5SA6kN2zwZdu39iFV1lExwJvGZm4I0ZvmrZDoTddMKtzNzwt4Zum d/ZBtWnpmdjVVSG+QRYiwZtPPhLfgG7/Bn0D9aNI2/L1f0f9QaSPkTYhJZA2I2GcXIe0FuldpB8j zUB6Dmkf0l4kB9JSpNuQ+L34OQeRbke6CCmF1Ii0AOkupEEgDwwk5AQ7M1qyH2WYXJTv4b2nftxV JCDBhMVPg9kjf7qRTbXFNzkMas34D0ZhJqu92PH5u58ZPYWwxiTYKzZih48XaE6csL7c0Ji9aHFr IcB9vXjiCInCFsj9RpPRkPPtdCn9lr0gaKDVb9IkNb/QzdbPMlgN+4wXF5gKjpq+MHdaqGWm9Bvr H2yP2dfJUx2/dJ7nKnT9t+clX6//ngDfRWJctxAXavh760j7Dq1ugJp2QtxpRF4RiFGrQeVpQWBe g473PU2JR99xjTs5RTrWNHmoaYr0fdNkaQjO7qahJp5GVddaI9ZExBpZKJITYWH/CUVDjpOwuB9r /hHTCf8lfkoqaJ3yU9kvxRT/d94f4poWzzr7WlkI+ULx8+JCWbzHfIl9Wfx113/bjvm+ievLy6IC KTHKhXo5YisvK7YYNWKCVFTEE3E5kYjHY/FELO73yX6/z+f1+b1xu022220GvT5us8o2m7UCQt6v ISVeiHaDplAfJzZDhUgSA4Kg2Kw620V6PdHFJ/vCtudIIS0coPcpFr3im2wL6zBX/N8SSgboOKWg o2R5CSvxVL78rHuAxm/gi9A9+ViTNIgV8HqkQa9bGuwe5DU3FoQXzUebx4yx2sZQq82F0jVGXFeZ LPyxdGBdYaU7qf+7iogeos6trcU5/FzXmFHVtLub9HZTa11DbY3TYU2ohazVabi+oo1Fi4t1yIvq 60aPThShwLiLNbrtNje12o2S2+rNfP2Y5LE6HY895nDYPNbHMl95rG5LgV3YREMhrzeU+XOX1mO1 OPVdn7nMNk/g888DHpvZ9dksvcNi9YAUKE1mDrHf0krge63ifoH8jhwh34BYnhbpf7Pnye8scNMy 3bP0HmIky2iAuJPS991Hh46SqkH+AjRC848Io8iaeddX5IkJtHLovZqYxwgCofSN7EcChY1lJn7F SPv0BeJ7BZ7CZbtpENfCUk8eJM24VIIvAV5afd8GNiPeOHXaaJ5929E4dgpPwLSjQOnPxB9AQzv6 bHrfQPYHxWLVEr3Bp/im2qb6RINlD3uMmOgWxSCZTBbpVwY94z0a9NioRsPor/R5dVBn88l74Kex soXPEI1Bb/IweS+7HnTrYm/CIb/QaqULiUSl59gKkOx/wD3jhkOYv/5gkzQ0KB3Dgzc1Dw6qSECk oXG2MVVuKn137MCIxqhq0t2IH7VGcm8Y4RBtqI1YNfmVaxjNNtNw0OsNDi3lOQ1nvpINFo9R7xF/ OD7bBXi7bXaXWH0hh6VZz3dZt2El3tVo4MEK79Cylumdz/gKkhoR7GaAXrTLaJLHRTVY1+ahHKbB i+3M/kkp98XrzrZcXXhj8Y0lN5Y+WvJo6V7TzjKD2WZ01psay8TSWFkwKRcHS2ImuWAg+6Vi/ott 0Pk325BTLNEPr+SHz+QXUvMcPQq0KaBmgPminQaD0eQdoP+7U733XnoR2CRDv/7P1nGJCWa2HGaG C71BzC9gy2CM3Ua1w2t6bFD6fhAZR4bBZqzvUWmQ5teU8DUdVd1yleIPxW1uZyJc5Ii4FWKPWRXq CskKtcWRcY8eftdfn1tvLDnppb3JrtERlXKcDkekPj56PKuvK4pFtTocOVzLU51WR3RD7AZOXScO UfLX3umhp675t8c9WoNJsroW7577wEdFF12ReW/P9AgH0uprP/lq+aKOkqWPXtft1hldUvXDF3+w fuzclasyH/4H35lQ8V6YB7z3kVGKwdLnLND3Ea1tL3VCEojUuaugwOPxnyIEcNzc+3NyoCPIwT6i dRpxqBSiZsK8qaNTU3ga2nSSYhg8YUS8Ah7LAJbbpERuNd5ccJPtZvvN8kbHptCm8PrILcXrSzeV mQpKaHG41B/hWy+Ge4t3RViL3hUYYA8rBd5S4vUGSMClZ7xdrylV4R/QWystoaDTGQi69MmgwcCC ehYvskA8WcIWZvFWlgeByrCIGfFU7KVjqD4HbM5e80Kmu1elfrDaZtAUp6QxI2hnREPFgLpwmdFR aDFbTJYCi6gtShQnShKlCVEL4WBj2kiizBivpGFHrJImLMlKGrWFKgkcuxw1ysrK8shBe7sT1hz0 a0GVLhwOMB9gRJ440dvQUF9fV1xUXFQUi9DAWSphHliyvbKjNHD5DfN/kmniPVvoqCW7uz3xifGN 0zIHpwt/cdntrs7GOUsmL151/V9nTeR0u/75i++ZMq5ravk5oNsHAY9VgEcd+Va5uEdDLQZTUpIC hogvWB+NBny1FZbqUDWrTtbVBSqYXtNAaUBv8ziSVmvAU1ROSqVSVppMJALl0ViRp44k4kWEeBgt MniYQV+XqEgUkXKpfGq5UD5AxyvlEKOEFknRIuIL+9hU31bfW74jvm98Gt/51rBEibRW2ix9I4mS p/773RxCqvTrBXy6e7n8a2oCtAAbqALNaILFDaGBGgWpSt91H+Jgk7471ETy5XB3bvzksCorzuCA tTkQjOa8kIu7ovp6KBh5Yh3uoffnWGPGx9e7tzfotRQEhQewsO6hH9MKTq68zuozoWFGqULBbMwc 5me8kZk0h5eZr3g+h+uNH4N3fg4YhMi7SkWVWKmJmcLmsBx2VPmrguM1taZqudrR7G8OTtG0mBRZ cUzydwQ6gg6+ewx6MDWooiVg8ITUtr+B+P0hEvDk6KMAMOOCJqB32/h4saPBCuFsDbhDRR5bkcfN WJHeUmSAHkNo0NoBCeMJbzycW3hOF5AqnBE0NyH7p1JlBGWMaPyjlcay5oVOTgSx286QN0f44rA7 eS6OP+EcsZIujtN83TYBd5uwbjFyq1IGxK3niBv1hxpisYAfuFrPcdXucTbYbAFPzBb0eYGSes8A Xf60JFmDuASqSljyV/l7/Af9osXf7O/wz/Gv8G/yb/cf9uv9nydeWK4qGL1Qv4BoR7mEhfp5BjKp OHY6alnz/HGYeqGr5hDqVIVt/oC/3dD/8PyDzC/5KwpP8lcb+cKZP3K9iV6ZuVktQT0kgfd+GO9d wr7NyVrF7XAzp0ujFamoL/HK2qKwiRnizFGa0wX4IzfhwfOyV7lguXe5b7l/eeAm542u/Zr98mdO Q4/UY+2x9djFg4xKTsmlOBWX6GY+V9ATCgRLSl0NrME5ytXO2p0TXF30Imen6ybXL12vslecH7hk s52jllWaCuyplyXJLgfMsiNSzHuD8XB8RZyRuBSfGt8ffyuuiW8uiceLSwKREmLSqlMMFkPIwCyG fYbDhq8NWYPGsFljMGg1AZNGDHv5FDkwJ0AD9Z5AwOsJhD1ughcOD2T+ptQ5RCEsa0Qx6JBlcM0S QoJuj+x2gwsxgQbdLtRdDO41IehwYoaTFbkG2BVK0F0EPUFwFAmivrgo4uV/4bC9yKwtMpugmNFy 2C5u2g3pSGi3UnPQQ0Me6lHK6j1KXUOdZ20VKrF4nUcpKq7zFCmWklDJnJI1JZtKHiw5WPJ1ib5k L7sKwsZFyxWXE6c5lSoknOpUvPUW59dO5hygnTuZUlQPSXZVnybseA63k7HZVg6BXKE4QjLdL1O5 SNLAWOrQbNIc1IjQcsB2SRudjoe7RNX/ege7e4995ZGOeqWh5FAv1zrcn3ikoV6ve5A3kr3dRzHq lr4C/oKKQc+84HUwz8GhwXWaypyVoBk2F3iFmw0o1v34AK5H9Cdp/9vuKuiUp7d7/88OTAAjmJQu umBSugyukmfYWuZ1eZ1erhY1dmHEi5E4RnYjVO3LPqZ3wTmxwynlx3tJdy/Mk65ITBBiwilRqaro dnut3X5Gn/Duz776/GfXhjh50UZOOweW/9f1ny97Ue1o4B0hofkEdi84zfF0IipUnfit8KfhNkC3 OXtYvFBYCx9vA52nTHtc93Do8UqhSJcIpcRV9iu9V/jWyjd4b5fv8m7TbZUf9j5VtUv3bOEOead3 d/C1wmOjHEY428uocJ/1Ti+7pnJ95ZbKxwu3Vb446vejPh6lL4kOsKcUb6IqkkhEI9ESW8DuKm2I kIZSKtSaDOUNA/SIMoveVEKMtRGhwBDhknQFJGlpymQqke+XIgEdHzCTcDiimJ3NlgitijRHOiJz Ig9Gtkf2RQ5H9BFvo2tTdUTLx5drH9Tu0x7WilrP6LK9MC5hPnDthyYnD30CGxtLnMxxfOg/g5Ct g1XdqDU3HRuEJgQTUbUVbWOsI7UiWBST0p48+PYRXfYHUpf9htQjebLH+m36Sj2giF8XgIipBZgq A9J7SRBT7Nn9fAR2Z3ekPq8Cg326VLV42N5sgFDmJmmerwpQgqI6rUN21tY0jBY6n3nr548feXfs TR1r187bETZILmPh/PunPti3goP5xdTPznlm4ZQrL1+2d/5V9927/OqnLdJNbZeOMbptVqPFW/bA /KFDnPvS/7RKHanzz1s0U5XK2wD7SYB9GflmV8RYYGl2DGS/V8pRednxYeL94iOhI5EvEn8p1sUd xc7W8OTE5OIZ4e7ErOIlliWexYmbPSbnQPavykq73GW/0HFZ4tLi770aLax2hxdKky3hXS9tke52 3+V9xPEI5saKbFaLR/ZhM1Nf6PG7LGYiWAvITdZIqa6gX9T6/9MViRUUpvRdW0N0c2h/iIW85XIE bMfQvLWIWopCRZvhV/MkD9x6CrCA5+RBFbCTuXUISwbHUdXwzzsLuO3PPQeAYS/MQiii3G4ZNlC0 HB5c44wOr3XOOOFgIfV1pLZGeJFrO9Rlt7qYdvude1945/F5r53vgIWy4KFXXsscpwWvPS+Y/RwO vwp5Xb6z1v7l5w8dOnuq7LImJ15GhZdfo7DKGbkOq70NPpsg1vvPT59TtqgMm76cPAphK2uqVA0m qg+6eZfkq3L5fG5XNGh0RksM3cYBOr+/JIL1pvOVcDQiB4mpQNaBe8MaM4TX8v19Sr3lichaiKcB urE/WbY2t0jS97359YGEVJXKZrDEQRh7R49xv8hJnjfSiu7m3GxS2pnH+f5CxI1xJJ6UNp3kYmXg YmG5eA+ooSj7aX9MH/ecpAI6jMgxFeO5/Y2FdQ2bAHbVIsxht8hySHz7ny//7VVX/Xblh3er7RXv 3XX3e+/dfdd74qfHl3Hs/cUrVx258keHr36FfqCajK9s/fDDrQ/+8Y9Y27VY2ypgsgcevreUxUbn vQ5Wwyay87G//RJ7yf4bzwe2Dzwf+v7L/XHob06zx1/mr2ONwXN954Vm+2aFlvuWhq7zbfTd6783 +IzGstq5x39AOGB71f9qUKt/0eoNhyFGrYGISydGrAWm6d7UVkJXQE8ZoB8rrmg4RVNbZbpc3icf lA/LouyJlD1xGopOHoSpDeUeuhWQE0wHyooEi/O0xexzylpIg50+ORRkcAOcZCYUHCviVJnAMGKe xEyiU/FWJ1ac+KXz48cufnOCvVByS9XfXf9e5jC1vPImNc70/P6OOw556QMPvTy+1uKxWqWamdT3 6jNUm/nv6zc89cQtwCDs5BJxFjCzjrymJBTTVM1azU9N14/aauoz7Uy+kDyUNLr0UD5fkaSooa6S jKKjBpj4NCHRSqigA1RRvJRG9fGSKEl0l0YCCKoMeyor3FqD3hgFLirGBpjCYe9BFTXvUsxVDsWx wvGWQ3R46lfvpq/nTaDJMFI5jn6iqqBNqDcPHVX58bClkythAQ13qAZqYVnSB4CWh0jSVxqiPMTo +uvhJ/vHtk9Dba1K+y5n3uOnkr4j7yliVRT2DpTW5Tx/7WmeP/3ErVeuq3W4Zb3954v+7Up6M+8U zENnDevsbDfHxzVL7nfqnTabS3AtbVvDezjV/zhznXgdMLOY1NKgMqpNXiGzDyNvJ76MHE0cjxyL ay8rXVYxv2p+7dXma0t7azeWrq19oPS22m2lW2v3BAuZnnODeSqDMGg0ekOUkWBylDssucKAZWHw jlGRsDEZIXcU6fQppkVwSUkgTMNGo2TYakgbBIuhwzDHsN1wEPqmt74ysja2ObY1lo6J+2IHY0di 38TEmKeubO4IZFW5KXeNABiwQQebj3KWmjORRnIMlUmchsV7iS97jHizx/rK9DVwFfYF9WQArXJ9 NS9KTbW8s8JZNZD9S45TDPMLLhtpfV72xayyrpDl/ZK1Lsg/OAaA9fAj2WprTmcdwvWqstMbd6+Y PVk1N78998pi57rfP3n8+JO/X/faLbf85je33PIae+U+lWPsnj6x/OISaD9uet45ZRNO7KZ01y5K MpPufP2NO+584w3QAr7EEJeBFhrp5UrFvd7jYSZSB71Eu1q7md7JttKHWZr2M+Mj2kd1OzW7dC/p 3tMd9uq8eisUbvBtixySmTzbLcsud9RaWsU7C8pnV5eXV1VHSyUjbxci0tg822A2Gw1RKachFSRm 5zWkxho+JVZfNaq+vmZUtJFyF5FYWlICcDcSUScZ9Yaw57CbQk48pBSMJZHwqH3VB+G/GKBf9I85 Kw9K8BvOZFSKAgw5y+fHoPWfMvwRPlQAdoSFe1oDQzmTDFG62f39cG9SeLD6rN46+Hy6VIKUvD6N TpvwaTwh6tX5cyTJvYST0raTwkObPbYrbArJQSfHgS5YBdwvz4UECHNYeJy0Lrm4gP/w7/rzKjE9 f+odF827efbFIY8nlPmay+KLf7p69oSqpad7IlTKFj8dOj7zrLZNHUP/c5J+hYuurghfOfTlcIc4 XiVfRp4DNjg1Vuzq+MkapSzqqfEonvM98z2rPD/z6OxmqVOWo2atydCp0URNTr/nLocj6hdeZAP0 zqf9WrPJSBBzNQfnMyi6haIIA6gD5o4nMG3NKfcD7G7VB9H8PUyWEa6dU3wO5OGI1dvP4GmRYXnK Nl+7hp7L33vIzdkTPfc7OANCGuv772emnfjr8IuBU0GX4Tx/H97sDuA57LLdpBSAdJqbSwdQyia1 VDpsBc0L7Y/a2YE6WiaXJSpLy+pK6sfEmxPjSpvrlshLYgWX2mnM3mBnSbmj9P3E+3VfJr6sO544 XqcfmxhbtyS+pH6bvC2mjdfHYohvUylBU5XnYn5uGOxEvHsoxG9qkpp5qUjQPUOzY6FQNBb1x0hF rUov1dXtddXVtXXRirp6a4F6ocIqY2FhgTFq9Tl4225xh9zM7b4XhrBDjvpke3kR7z+rtHR2orS0 KBEtT2CTKx6ur5PhY4whNMUeJjH47mPEXh+XNTEaTfn9jpRPW5Qqr01VVJSXs4KUzUr0KcqMMjdT DMtjNHZfIj6jfg/dShLoMa+oW1vHwnXVdT11Qh2nx8BoO6Qf+O8Kw1oDkwxhQzUqnBNrDZ6GvfQB sjZn0nKbhLv8uErGq9wRD68fN17zNqvqkMq7aF1j1omVSeyS74Ytcag/2NRsH0DpH50rPTW50lWh ln1ySTNoEb8uuk7z49wOmQam7ggL9wx7turvSP406/eMudCf/266rlBqahpmDPbskX5vvI5/VdBv sdbhYY/0oeQPBQ4BS/iUDhmDDinrE3uyf4VF9X2OFfR2c1MYtjKYxVTVXo5lf+hPeOrCOU4BS5k7 l+kw8ue9mpDsVnqGjUyHvfrDnITSZ3MiQ2UGL9IFSZVczJx05mYG6INzeS3zDe9NZX5Or8isB8nA Y6UKkL/Rck5AvJ75KtM1TFaIWaaI8SSiDIpyk26lbp5jpeOnDohfUyfXmqAndXIdyeZ23GW1Rt0E qhGhYaskdUj7JEHyeE7nB1z/+Rd84J/ygNtGcoC/cg4wrDyfeglO/Q486z5oJe2sTGmyjLY0Fo6x jLU0WcZZFEuLpc1gKzI1mHb6+srFYtpA2Qz/PN08/yrdKr+mQVfjb9O1+WfoNNX60eNU+jw8lo5t Hz927Ljx0dEOeGyfUoJhG51qe8t2xPaNTSQ2yabYBFt7oc1mKYw6EnDiQlSSqBRl0fZgNBoKRhMN 1bnOWqmW1bZX1dZWV0Ub2hXeueBwC21pb25pUZqjFVXaYFFlRUnAr6W6stFKirRryyKCN2IwCLrR DQ2JhMNoLgzDGRWqr3auhf/pRFEgGC4u4u2itUWs6MR4UhVuHs+dBWT8vvEH8eGZ56yyJ3PcOOcc ACUmc9KTF4AGl50nXcTctuRaKTZOTm5AjiSef9mCH+t02XqaONVyLqyK0zPFal6uhktK3djiFTUF iVKxOEQ1Wo/RhWBiTVmIuk1woYLAaFJq4jtyfNulGwLXlxe4E4zEmP2KiEi67AdEi0Szb3N6454J 2qsyFx1/Au94WCJqCcG+vw9tlW5pt93BhbNLteNOieiYVTXlTormXPs0WZ2nyJNE+tllSyfMizSu HHtRw1nqHs+WKbWVl05o5xS3pWNURfm4FrX7I96RmyHMm7Gyrb29LXXerKFdnOjYz5XpbQuG3lbr t7XMDJRekmtwNM+p48DypcDymcDyRrpOGf177e/17ID2gJ49pO/T9umFXt1aHZuvu0R/iU/Y4ntE y64J9dOdTPCHloTwFa7IsLtmy1njFkfIwRztHofD7YnaztTqciKpkAc8tOelUk6rk0hCSrAzVDtz fXtOtatJNWrpHnqEhGHT2wMRUQctDzEWRoMx7D0MNywXKJKq4G2u3goFz8O1O9WbxQUHkPQ05Bw6 Bh39JDqeiWEj1bfTWmdOHGbg/0yzk31+jV6Hz8aY1q8Bwvn0gZx2x7f5TiFbH7y6A9k/7fDJOfTq hWqH1A0dJoc9p6FPbpek9gwsGmbXwyyezuy8tauno/EiFTX+zHl0+0+WXXB17+n6nTomzFvT1Voa 3HDO0NfD7JkJXde03DD07cm2aq9x6+w2+A2agCEFcGGfrTTanKJTdjmFV+mrBb9nf9D8Uff7Au1l usVWtoAtEBfrFxuXmJdaF9gvdekdEcESMcBlqTNFYOPs77d4mtWy0KWWitlRnyZUQphvD9S/AbZO cdvgo8Q0rYI5y+GmPKg9ov1Gq9EO0I/63WBBqrcSmjuE2yA2A/kOKjSCZq4JqM4C7lXk/uO9iCw4 RuTssZ2SXCi79mQ/glrwUb85aA2qBK0uOlYcKjXIWilwypKvWeaZlTv47JZgc4GMTG9EpuMZ+r9U AtD4dHKBDYPInLLVNV7mmV22yHzGAcWGitEIZU3PMyZYQk38k56Rvy4qk2HfGdGd7udpygy+cCDz FbUdeIHaZ/x569Y/80S37898Q637eDDLN8//+58OP3D/kcOATQUsZ069CTgcKpTmUUbLmGKk+opp dAbrNl9CARPtZeZV9JqyyysLfq3db3xf977hg+L3R32i/RiBHPgE4BrdRuFe4Ql8s+DngqTAUxXA /n8g6sxJqQLbKyNE0oRoVV4aUXNplSXl8KdgixRWRQqMpRF6h6gjoVRCWxSx6KneW1tOCsNBS6AD uzbLA2LAU3PxaW5JVbXjhnRut101of+RBT2CAM9ojHQQlZiq9wDqFYB60mQOUw71Udk/7iiOnYS5 CnEgTY7KuH8DgCj+pzbTaaChZZOeWH3t71Zmhp7788bXOePNqA4QvvkLX8cDb99z76FD9/78kDDv 3otmrzp4+a5M9pmMltMT30oQU6pCtPi2g29tvu2tg+C8iJURZwlXwhXjUORrC2m5ocO4xHaV7Wbb 3doH7DpV+1cKQq/kNX2fYw97CoqxohjyCnwywQHWUTIlXlKSiEeTBYWyGkau0ZkRxC4XSsZ4IkWS WmOzBMYJvZ2r7z6jRfcNQqe8FUQOxy2xqbGcu+ObmDbmKR+69RTznCJ90g25Dh8Hj4OAyj2EnUPu JFbDxCis5H/GJM+A0b9kmOCI1jzJ7rLLhU6bP8cO8UmOygdzDqi891l3hlp3Ul4y9vBDbZOu99iN hfZYnWf0ln10lWroLQt6PaHXtvBcmHfozhkLvHbYpDFv57ZMnQoaGzzWz6qWLCUHs4eFDKiplX6r 3CQ3+ycw23n4RGdx6xPhJ0b/R+Pr9lcn/sn+jvOd8X+Y+IX9aN1nE0/Yj9X9MNFWYNc6NeMNE0N2 h9Mx3jdxQ/Suur2Wgpn2WY2LG5ekrm68LnVz482pR+Q+2XhraleITdMnS2NFo5RxTXVet6VQ5zCN IXU11TGxssFSaBKM8Pl7UuPGYX+8BV7t+p1CuJJWDtC7FX9RQyRCUroZYyIdwTnB5fi229s+anos VeqIKNw4dIJ3Kl3LS2mpp61FJ2iLjJGCi/Nebu7jaKbcqpp8jCaxiX9UJb6hIYRMAMbdyIas2O3h elsuflBV4Xh1DDQ51W3ROHqiLexP2BOu8Y4QSfnGhOjoMDLbRDSdze4QcbnHjxsbaILc86aaGkMN ISJPsKpqF9cQoXkh45YJfqo8HIb+zpRcZ/Q/m/2UuLJfklaYPOPl0WC5/VFnE8eJ3A8+kF44QVRN rBH82AAVNSUja+Tc2S050ELWytlxqwwG3CrDXPbz62Bl+KRnuBCSeZZ7CJ5jR4rmoh3VAEdgW7Hq S3FA0PEj7wWV1Y0Q2MY5LzP6se/Eo3Hi+TBI4dqc5cN3QRrPX3fLlFR79Y3bW+fOefPll9foHWbO CmweV+ze5Q9vnXZ+5uWbzjt0x1NCMgBJvTnodXqaihvHJOubSvwWuzt27dmX/WJBVC70Bp8E+joq Q9XNV7dOqaoK1y1qWrqGWyi3QzKnEAFQTl5V4sd91IyAVPawcZfxBePbxqNGzRWFNxbeVfho4UsF 7xRoXXqq4xxEhNPOoRdFnT5KJdngsFokq03WeEylA/QhxRpMxeO6FMXX7aaIp0C+CXG4jylyeTk8 akWRl4hf8ocRGbHPr4G0+Li/ghsF4OBHwRygbanOe76tjEBEbgKou0sj2UTOG+31GQsKvIYQMfpM IQRCcW80923hbzgc0Zrb1csttS638sOaTs477XRANXxFZcSNq3tnvDRaNktuc/h/eu94CgQPRZkD Q5jHiXvot+fMqw2beZxiZPL61ayKd/7AJ/F1vAjr2CXMI8XgxCajuMvJSpzUC3e+KhBNVXqTyaCP WnLbTgW+Kfltp+IIH8c/zqDx9nA8HglHi6nTIocjKVJsdLlToWDQojekJItWxvYs9keIy8n1VUOp ZA3rD+ooAqC/6C850x2JheSbdJzfcmLJRTpzEjy1CzXSePqH7BZBrQr3O4ZHOB1tdlGrSdhFa4jY tHJu5XNkaM8z4eeIA+TnhOC0ZT8CzfHNWnVDtrio/uTyq7AZfao5vB974xOvXKNckPMaLJryxjYV DF+rKuc197d0rmZBFRi3nL/k2Vw153XjMEhBGt4OGMToHGXUNrrN9oRdCBvDBWEeBFUYtoSh5ado o22s/VK20LpYXhzbjkmP221KiBolDgiHmZglc5VZME+xms2SNWq02nJCFG8LJ9opl5lB4PMLtdrZ TKsVGFwPNOcia3ZbVB/ZlJMuMiujNJyL65YREh+2ywj2hmeMEmPeGeaTUkYhZTRoYym4wJYoBXaW qrI2W7dbBeseuoTYqUExI8q32rbcthXmvmh7jm4HziRoJB+5AdfWJ/Br5SJ3wYhVAgL8q6p4QAbi LvLhFyNcU2cGX5zhfjpzmLfhVeJeowhcdCPCrmL4yPuMHpa+NfOLCzl90BTPN9C6BK3cqHY0cf/x DMHMQamC86ycMcnrHJKN2ax4JyBZIpQrj5Q4i103Co87H4Hrf7dzp0tPmMTWODc5tzt/5TzszDj1 W/FJ6kEm4J9sONyi21HCSsUSR7GrUWx0nC2e7ZgpzpQ7HZ2ezpJL6WXiIsdC10LPwpJrxB857nHe 7XqUbRN/6djq2sX2igOOtOsZzzMlrzpfdv3Becj1ufOoK1ng9DnxCa8z6VrnWVfyhHOv8yXNS/KH zs/oZ64f2HHnDy4rD1oCNkhSlRqxFM1HLD2llK+IU4KoJSUufMNrWxG0JKyIr40zHsLE4vF71fil aD5+6SmldI5hjWET31AKYUtJ+NpAt6uhTOigBsO9aihTNB/K9JRiDQSq1DimKOKY7lLjmLLnKjXD cUzhk3FM4dPimMKnxTGF83FM+2Afu+gqYNMRLL8DTteYiC/3qTBdNBanIt5U2J4ya1OmSDhsNpu0 y7Ev8msPgt42KkXkDo9SjfilkiTilxKIX1ICQWQeLzI4Iz0ppaeEluylv4Ct4aIbEMA0gymjxtQx Po/xeUyRrHVw5f9CMWvCPQ7q+LUs3iGnNNwtUl3Pi/7GMXVqM5lr4jZqN66gljhfLXExXio2p6tO ozjq1yDQifF4J4ZYp49I6WkU831390nhPchjmrp5yBN+Q2rAU/dwwFPyGOKfjnYTd849xbUcfjQj jA97+9i8+/8NeTqDyqpgrvdyX9XpfmD0/X1nPu5p2DrdVaL36EUe1ZRXaOjlEZ2Af+Az7AjKf3Vw ekjT8MafcNOi3QOLnirlxPgpzy67q/+SgU1LuCfzE670llDmx6bwaRR6KZOHvmTq/t4wlS4Av10C Km1htyt3hawhG7M1WmdamY/b46FoD11mWx5ZHutp+TX9tfSm7c3I67HXa16oe6HFgmhccg++kamh tharrSUmRWNSBN+50khdTUyySWFaI1NaU9dis9nCkTo5Eqlj2Py3pMAo7SlbKpIKp7yjUjWpeCqW KpuYaknVp+pSKaWlpbmxsTkWK66sLG7u0tQN0Mqd4Zb7mhGqcUTxUaoxRSJOk0lDnBTR3fQ+i2Y5 UMPbVoPx/th9xTZ1XuS+4i5LoCpvcmoCnlaj0Wss06a0n+yhOtAIgp1OU4SPeo65Bz0SMq4LeyYf dSP0oBtasAcJQreKjx71Drqlo7yTd+RLL8H3N/idkWnwyY2qndqyv+nHpoONb0Jg0wHlE/3YdED5 fb8txsuP+uHjQPmnPl/T+Bw+d+W5PXdJxKQGnC+V42RJwZmSEadJQZwjBaHwStGTZyX5aRb8cpbW LqvbbKnDNvJnfSih5vL9BHW/QH2w2uxHigFuDGsQHgzM+kg5FxWr0ekab4XIHN8yIWhrpjxrGe23 NlOetYz2Sagha5E9lmZszlmaI8ZAeHydBVmN7PGNl7jeXcMVbZR4K7VsgUekX5LHw9N1QDGjEmtC FuFZ3gY4Sceo5DRyroxTvsGJWNlhF9cZWxQNtdgoyOncw1RBh0VYrkMbwz709UWyBfsUf+VEsSGz O7NXFWCZrxGsbS+i12cej9sx/jGXZ5dQHw1cwknoYz4apy9mNumcUNi5s5SOybyc84uZnToYpmfr 1RHIu8zX1JqTgyYn4qbJXfDH3AOqqqHPKs1u4ra5o0lzxFVP660dZsV13P6/0QKDfZL93Ogiusj6 I/uPojfZb4rutj5n3xN9KfputBAC1FZjs9bgOyoulYJmc9VJZcYXDa4N0uC90SA8ML5oLIkQk6d2 VlartqFLKaiprBxVE03W2A25kCmN5t5cwJSBEq/ML2d1VbuoqwqBjrI96rXXlMV577Li4qpYcTE+ TS+LRe01NeFYVEZggRXkS+CnstkJrcGAzUqJPqixGbjq4/PJKa8XFM246hNPlY1K4UuGQhKcGmQr gkeC33DLtG6qBgGrkiasWaE5ovlGo9V4asv2UK73qCGHR7t74WPoPelkGA5KBYfOx6Wt01cm+a4c 14D+j825MzWeM1j1yWH1ayjEruLTt9O59rEDOr3UpMcnhSCVSB6ZsFuWZ8R/h15n7JlF2NLM1Z6g 1+xwfsJ5ci/+Rcf5qiL8ccgryZVDX/6Ud2f8PKc68Gab2WFQ1acOtiOHQkCu4y8O+4u4JoXvSYWv gE0u8rliLOTuRKovNLLnst8TM+LJjEQE9Ap0VYJOJwpRo1NFmVZ7lcVulyxRZyFlNhY2F8pmM/7B ACukTjMz0UJLmLig9YYLTEbaLaYsxmbjcqNg9Hqc3ctN1ORxr877C1RPQc5HwMOy8pYI9wbkA0DB 6qjKUhh4HHgVgrL2c16nluBYKN/rA7/iNM5ZFD5Dy7nf1U+nRjSw7NzAxz+4cdDhby10kXoayRnk 9fXCO0MbWKMaljJE2OVD3+eMu0lD41bxJX1lEnvhcl55GZqK+svE8N8a+Cqe+YujQ8D3TxZ8Uydj ly+AuCP+X3JG47/GtJJ2chb+t8U5+Pdtk/DfJqbgO6GpZBr+W9AFiHq5EP8TpxMOoVn4pnc2/tcG /1Fiy99Dy3cMOztmXHjhucmW5asvX7zg8ikLrpx6weTp5P8BOy0MoAplbmRzdHJlYW0KZW5kb2Jq CjUyIDAgb2JqCjE1MDEwCmVuZG9iago5IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9U cnVlVHlwZSAvQmFzZUZvbnQgL1RUQ05ISStDYWxpYnJpIC9Gb250RGVzY3JpcHRvcgo1MyAwIFIg L1RvVW5pY29kZSA1NCAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgOTAgL1dpZHRocyBbIDQ1 OSAzMzUgNDc5CjM0OSAyMjkgNTI1IDQ3MSAyMjYgNTMzIDUyNSA0OTggNDIzIDQ1NSAzOTEgNTI1 IDY0MiAzMDUgMzk1IDUxNyA1NjcgMjI5IDI1Mgo0ODggMzAzIDc5OSAyNTAgNTI1IDUyNyA3MTUg NDMzIDUyNSA1MDcgNTA3IDUwNyA1MjUgMzAzIDMwNiA0NTIgMjUyIDU0MyAyNTAKMzE5IDQ1OSA1 MDcgNTA3IDQyMCA1NzkgNTA3IDUwNyA1MDcgNTA3IDI2OCAzMDcgMzA3IDQ1MyA0OTggMzg2IDQ4 NyBdID4+CmVuZG9iago1NCAwIG9iago8PCAvTGVuZ3RoIDU1IDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAFdlMFum0AURfd8xSzTReQxM9iJhJCiRJG8SFvV7QdgGCykGhDGC/99 z31O0yqLs7i8mWHOG4bV8+5lN/SLW32fx2afFtf1Qzun83iZm+QO6dgP2Tp3bd8s78meNad6ylZM 3l/PSzrthm50ZZk5t/rBlPMyX93dUzse0hc9+za3ae6Ho7v79by3J/vLNP1OpzQszmdV5drUsdxb PX2tT8mtbOr9rqXeL9d7Zv0b8fM6JceOmLG+bakZ23Se6ibN9XBMWel9Vb6+Vlka2k+lwt9mHLr3 ofm6KoX3RaiyMs+J4P02KgYieL9ZK0YiUM0VCyJQfVTcEIGYFLdEIG4VH4jgvbfBj0TwPtp7ayIw +EGDD0QgFooNEYg2uCUC8aBqIgK7smpHBKpSCPRCIKilAq6C6kYRV8HcWhFXwWCviKsg2mBcw823 URVXgYKMAq6CaC/CNZgv1lRxFby3VcRV5H5tc3EN5ru19+Iabr6dBuMaboLqZEBOsGe9KCInvGdv ROQEUWcUkRNEdYNmG2zDqshFE+QsqCInvKe9ROQEL5J+RE5Q1flG5ATNsaWQow+qqjkROUE31NiI nCDaUshFE+QsqCIo2KROMOIqGGxL4RrNF6+s5GQMBmvPBa6CqJXZi0FU2/moDSKN5T78/fC3n+5B QRcEA7VfvhUDOX1iHL9BVGMKuiBojG2BLhSQe64OVbog6IROr6ALgrmcwH9b0O3UX+Tj1jeXeebC 26/G/gW64/2QPv5G0zhpAeMPf+ku0wplbmRzdHJlYW0KZW5kb2JqCjU1IDAgb2JqCjU3NwplbmRv YmoKNTMgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVFRDTkhJK0Nh bGlicmkgL0ZsYWdzIDQgL0ZvbnRCQm94IFstNTAzIC0zMDcgMTI0MCAxMDI2XQovSXRhbGljQW5n bGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWlnaHQgNjQ0IC9TdGVtViAwIC9Y SGVpZ2h0CjQ3NiAvQXZnV2lkdGggNTIxIC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNTYgMCBS ID4+CmVuZG9iago1NiAwIG9iago8PCAvTGVuZ3RoIDU3IDAgUiAvTGVuZ3RoMSA5MDE2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ1aB3RU15l+791Xp7yZ9970XjWjNmojjeqojSSE JECoC0kggcCAQAiBKVIA0zYuBBfsLLEDbguxD8YlxY4dr53EZx07sdd2jrGTdbx7dpN4nbKpG6+B Ge3/3sxIgJ2zRTpv7tw7mnv//v3/f7Vr5+5JjMUOYQjD1m8b34EpP0QnDHdsmtq3MT1HvRjmfuWm yfEN6Tl2FcaKm2AhPcejMAZu2rZrb2Y+COOfp6bXZz4n3of5/LbxvZn9sQ9g7tk+vm0y/fd+izxP v8+8amHkMR2mxwRMxCTMAHMjZsLMmAWzYjaY2TEH5sRcmBu+6cV8mD/zzczAYxgOb+twD+zxfYzB CBiLsOOZj0n4VP6cJk4acn+wYa2u9j8xK6t8+MKv538kv3n7xOttVy4nb+d+w1bAlIMd0j/wPeZM 8qcYpnrwyuXLD3K/UXbKfKgMdaR8/D9iGPkQ5icT2Dj6d+wCegK7QJDwnMAYNIpdIH3wDCrrbeiX mI7yYY+Tt2E+9C42Qkax02gCG4ZxHbqCjRIzWBC9gpXL6/gl7Bh6RBlP0xuw0/IaWan87Wnidfie F+smLmJeWD+Fvor5qOewcrQHy0VnYe9cbAhfwPKIAPYCQWFflt8jM4YTs1gLuop9l9iGHYNnP7EL ewmeYeBjKzyr4VkGz0V4dsKzCZ5ieCbhyX6+GjhPyxTDNBiNHYC5F6vG1KAfHejJDBozwl8g0KIE WrWA5kRMC5rNAdnyoFUaI7EI6DYP9OoAfQbg+1VYBVapaK4AdJyLqbAQ6JLCyrEY2C2B1cIJNVgU C2PFWAkWxAqxfDhd/tkFv1/HFvAGfA4/g79H4ESceAhhKIp2oidIklxDPkz+iaqjvkRL9DB9gv6A XmC2Ms8wv2Gb2dvYj7kYd4D7vqpAtU/1TdVf1D71iHqn+oz6e+oP1QuamGa75ozmR9pC7d3at3gD v4X/QOfX7dUd0n1R969AHZaaRe9QPPDKAAdd2AoQjeAVlMfAEwxjoP2+CFEeyqkoKyuNE+XRHL+P J5S1aEUsjspKXQSCv0yvxAl5jqN3rg6jlUmaOOCv7y+jXDadQUtThMMiFtYG9T1rgrURJ4MYGlEs E441+TqmWnw/ZQSn0eQUWVZ0moxOgUn+E8Vf/iPFX2kmp66cQnTNSH0A/a2KJUiafs5lsebVeNv7 dZKeVEt6wcQyoqAJJ0aSx40OeQ+H0ZjeK9mFgfT9C5fJA5QBNJODYUGTiVbYCiEv4pHfl5NTEcPT vJgZP/KSu1lcH3S7gxJHTid/uQWpJL/DGdThLP4MqbWGXJ48G0/O4f+Mf6/OZOdJxGg4vCb1Gqfl SIq3m8hn1DyLEKtTn0jOgSWNL/ye1FAukDAWNPBpiUYVWdHGjOxkqRoNLpBfWoakhqBYQ8PaufYD PzzZ1XPf2wcrtwy32lkKkaya5UtXzqzsP7EhVr7+zjVds91RHaOi0bN6i8gbckP23kf/8NWHrj45 YvTk2XnJJhocEhcqCrUc/+783IsHG3OKcmjBBXRdwDA0D9ovUOgi/F5fTrkQrSjzghIVwrzCDW/R PKnSssl7zLm5ZmIjq2UpCl5SNP4MC7yTHLxfQeCsVkW2iXaRdYfIwyE3K9oNol1gU1s4vUMSbXom VcIKdtkLLyxcRr1AQQgmsiSuOzBrVlmSUC8czqRy8JcZOEB538AaPDaLz8ACOa3K6iuSA05axujt RskucMlfMFqGouCFvChT4sycig+CNRgzfMsWLqQVQhjxQdbgtcp7ckav2eo1sDZWI2+hYcmfZt/J uzAL/4H/HHYJZ2j3RejyzCaKqyzt+HNHYnq1IxbxqRmKQKA/1uqPuH3FHn36KInDW7sODZdwOkGj EayiCcxfJ+qESHcjOiOfS8K5GX11wImAKmBHWX2lDcaoqAp1gA645CvmXNbgs8jE42/JVtlhsEsc aONiloErD3GCQ/YMWQOvggYcELPSOvALNwieZKIRwu8XZK7Qqw17nth7Dyd5rfLueTbcmNe1eVtn 7jdrBkYLzt6/YlNrAN0z/sD22lQkexb5eNjHmOtH9g2s3BLlk5+G29ZnTibVcHIFlljSQwhFEBx1 PQUmswvJ9si4kFkymfBoTignJ0MQqaYNAZfNa1CTe4yF8d6a2SxtuWZcKmm0dcyuCPmbRqo80cKw YRfPppKJVdb6sru+lljf5AbVgnQ5vQYviQ7U+5M/WaQZrIVC2sr+6ebGTSurDXx+7YqS1L8FnOhY 52YzQ6c6vTWrZCtoW/gtWk95sfZFKyCvs4LoolXc6Os0Wt+856HRxumBGrMaNMzyZatmlleONgdK V2/eftPqsprNd/XmD3TVSjRJIFrNqIsSo9UVq6K20p4t27f0lOFb13xpfanJ47ME3RA5GV/Y74qt KoutqCkpi/fOrOw+2F+os7oltWCRRAgBDr/TWdwUrFhRW1pW1zMjU68D7b8HOvBlqPcuSd4re4Vs z3IIQO8pvn0q6xqpU1nfR0cVz1fc7sqZRfFNsIJDktIhGM55fOG35D6w3PxFKV3jcUIm7i35ILmv 5dBzu7c+dSCR9m+JLejZ3d6xuztfIcALDvPhzd8+1BTf9609yJ899Oofh48PFRYMHh5A5uwanO2D 2H8TnB0AK5OjfYQM4RDxK2SoMuNlSuAHRGCIZ0neGnKavBZBw6DUEIuLYZ/DK3IkPovjmxELduYO aBHrkqM7TlLgyOQzSvyHgHflJbJeXpfjv2zdI2AX9eh1rAxrkK1bBpycnPLyNPAoci0rl91qEU3j pEyQkUkjgamstCKG6vUOu83N19zV3TbbXRjf9bXN86aSFVV14+0lGlbDkYy9qX9jdPyLvTmPnkhs aHIPrWqcrrNoNDSt0QzXtwZbNzZ27lgebI2uKrc7/U5Wb9VZnTa/UyroO9D7irmwPre1pykB1J4G at+lZiCjqVvSUCgLTkuKEdIoqQQEoJwRTEAoRIV3y9bfOZrf3toagmBvNDhEmpE8FqtHZMMdy5aF J24fCF80RvsbPPGGllBivjk+GLPiH+1+4WirkFOdux20RZIQ6KhKxR/hJfmL3Eq/fsWRp3a3HN5Q J+Y1laZO9wzUrp+TrXYYqPWg1yC3+hw8VeDV7wNvW0JT5CEoxlrbMVg0ft9keePM6aH87kS5haMJ UasL1fZV7znobRitreqvz9cwKgY9LFgFrTXoFBvmvr772Ev7a/Q2n4WXLGLI7Q17n704cGQwP5Dv ZyUnyG4dUPMAtQ0yizS+p3OhazVdajIvggGCyHUN1sfQA4zgMMhJS9vpNevvGAiXTty1duWRBsbg luXHnWv+QqIepAXSa/TWNbSGrFlh7enq7zry9MSuF462tTQT6izOJVtAThPzDYnDkyC35hKgcBQo PA22mA/5J8R42u+9Rjag5GszEsIYqlAoZNDpkDX5jKt1R3fDhvYiDaOmEYEYdUX/TMP0+Z3VtTMP rt9y77rCc2jfnrqRuI8giJC3Y29/xGgzMrxV1Eo6jdpqkeL7n9u/69u3tCRm7x+UDp+KdE7GZB0G Fy4Tx6m9kBenUQeijSIXo+IFQOM1IACuk/UYBexI4jh4H80YXbn2YNTDv8aqOUrUvcaCzVk8EntQ r5fj6UH/sm3L/U0BDXilTjLzFKfmLGXd1ROMYJMCnqu/lh1YTqeQ0ROQbAIzOvY3/blanUaC3ARh 5al70K3oB1gcsuK1abn5Taa0T+SEaDAwkzkDTNnsNwYuDmmx/CoTajJ7S2W0WnTpOCEBdoV4QLO0 39wq6W7xO0pHD62IrbeL5saKXzfvWB2Jbj03s+30RIHeW+IpKSoNugPRkVs6c9vcuF4QUqnJ0eK2 IvPkmpJlReaetd0fe3It3NGbOybjdrTL7w4MFK3Y21PgNIkRlz9CqAhv3VBNfEdfSbBhKOqNV5ZZ rZ0FdetygqNNXft7CznWm/rDyCZPZXt4aKM7tiw5Vl1PsNbC3LCxsdlZHJd1dRpQ4kGIDqWKv6Xt W1CCF80sAUY2gRLSodWIHmTFdAywRNqL4/MJmFpBPUw2NLTd2T481+m1ZtVA6LrGEoHBvuTt2ZVr 40FHe93GW8fBmo8tXMa7qSLI3rzX0aOYBmGU5JJFVgPIH4/feKZUUFOdLz+Lp6Kj2QwLL67Oy62C J8vzPPAMHqPkWmCfIfxzmM3UDUYDzeC4yYTmWclns/stOjp19MbD8V5WtEJa5jNyWl3qeXy7Vq0k IIjRcvgfU9rPsn31HfxmlZZD4HecxqJPPZ8KCnJtChrB40Dd52ewn+F6kdklgWZ4pN6CuACJTJZH CPWyI16n188sZCRtzGBoGhOM1FtpfUusoSARqZptkd3R7JUYU0FzpGrXovpp0WE2OfVM58n2yqFE sb6wu6MtMHBzu3uRSsJfdYMhfHYF8g41yIVTs3v6VtqKGsMliTwJLKQza6/A1//OXjNs/HV7XST4 y13/g71eRxQQs07OBGS0+hCokRarnGxmBXifRdIsWqEPq2ef2Dn9d9srqmYvzMIYu2iPb1nZvjnh tddvWblsS8KD/2L7t493NB34xk4Yl8M43354oiq69nDX8sPjVdGxw3Dm6dQp9C6ceT2ef9Z8jX8d z+8eCycaGwJZGwYhGIx2kcnt7OounLhNxvMyBc9bQ4n9zfGhmA3/+ObvHGnT+6L+VDwL4+THoCCo hNXcvrx4rrHz6JO7W27ZUCvlNpekvtIzWLthPmOHxHmgtgwmmcxfDpmfE1vS9NLEeYLmWNbsDBit xeXV/muIVEwr2Fhd5dR6A04NiXA0YXIJHMexhkhnLPlU1smWdHWkIhHSIVal4ng7WE/3wm+JN4Ga /0dGT7xZNnZ4RfFAS7FJRcoZe359f2VeotQealjV190Qyl09tzqwrDrXyCBwaRXN+Srai/Iaco3h htV9PQ0hnG+ZWp6jM1sNAbcEdbLdYxf9FcGcaNjty4/315aPtxdoRKNeozPpBaueMVlNkr/YESoP e3x5tb2yLL0LvyO2kU9At0n2aVJBJuFGACWM18KsAkUy7BLbWL0nN2Ju3dDgPKAT5dL+C9lg/ZGc b4q6j2Jt5oDDwFIcRa5x+vQ8RwehwiL4NIJegk4I1FMa5lIaY1Oq0bWciqN4aJzi2Ck5U0Lfuc4v s3nSYoKUrgYqYosLkCGJTqPZKdBd9ykOyBjSMG8uWlYcn2uBTAlgReQWw8eevhW1m26dIHzZCJH8 88q1zcHBPmJ3dkWmBuoCNAfUQPdDtjoGV4oDiPKZukcuDyRzTEq7CJrDCUSk3iC1trDLFbbyZOpN ksJZyW12+qFPlCLRFUIlee1ml8CgsySn0jBXH5MrApLlVWhAI3IIMjco/zVc0qbREL/kIC8hWDVQ Ur5wmToKlLTIlACOZAhBIUZpT8nIk00prqPpGvKooySV+gRpzWGXO8+qQS8SxJNIa8t1uUMwS31K kRCNzQ6fyKKfEMSrBCeC0NwiS0C/8RIBJbPNAk0HdJYx6JaoJk5wXHJ2iQedgeHUwALAVdLGccCC FgwZ4DNpyc4IViXLNhdk2wEcFYEVmpTiB5hAS822pQJMUuQr1184amalkNvlN6rJ998j1UYf9NwE nMMtqU9YXAp5nH6DinzjLVIluO3OoEhwqU8LeElDATgy+GTqfhgQpZF4/Fn8PC9pSUSrmNTT+EoY EKk26FJjstYhMs4DZVANelG6GotJOTkg4ehiSSgpyZvJwBBle+mSUptHIOh5To9SL7H6gMvlM3AU jqP/ogWfxxEQ6NQ39QKlMfB4FSmq0IjRwlPQ+9MmI8QlSU2B7Ytw7hBAwXvoWbkCXuzdyFliDJe7 btk626i0OXC55Cbeo1meTV4y2mUDwk+kDuolublDkGqoT+W11G78HBTfdCs0uhiH18ebTFY9scUb hGYbQ/MmwcNbzDZ98j5ohgEFeakP8VnsX6C7rVDAMGkzi0npZBX6trM0bxZupbSSVRLMKpw8prYE bNaAWX3SHY0UWt9kVBDLQd24dMju0dO03iPj2wsLn+An0L2fj2+LkJPJDvETnDXs9oTBYCxhjzts 5W6cI4+nwK5W2ws8vkJ5LEyGvekFr7cQHMdWCLx8Gc7cDryoZV6uyfe2F8VrI/Kzra0o0gKPzDfa jc9CpSE3HGU//z/wTeW4y4oKLW8y0BBQmrzSQZtHpGnRA/viqY+Qivp7OQczZ0SZSQaZr5Fag9No 9YokTYySWsllhFKOpP6g1bEko5W09JxWx8GGBi3s04J/g4gQdXD3IHu/0oTN9GCJiCikxkT4wR8G RVP4pyGXOyfHRQs2+N538VZUg14GuSt8ZWsQOZCjmpKBXU2Nu/uLS/p3N8JYQhyRX4th1jw7UFLS vwu+hB1Lncf/RN0u30jhNHR8RfNiZzyCFONMxz78d2tH166hcN5pFW2SBlWsrnS4q1aX4dDPNZkd eoKaeC01dOm91PAPNYKaImiW2vj2+z+bmfngJ+9sgnY9OKJePm8/nPcRnAd5u6IJWWpy771CLI8S oZx0Wmk2ifhHjsruCqSB1rXNqcWpkbGxMZLQO8xG6O0Sm3YT1pmfvf/2RigBCQqc4XX8/HuX8POv cXpogtM0+UZqpXzaS6mXCTu1B25vMnLNdnnTPW25wlRAz67jFzCNSVSrRZMGx2goCnX8I4/IY+qq 1w7OY6DzZRej9WbB47hcS+vM8v7DqZfxb6X3p+SsZRFkl+AWVGHEv6UWzZoFHjIMNfPII+lxQWMW 1ZcNdoB4r2DW0dQrDo9g1kPabQd1EthWQMoXKQ9UH8vSspLbVqARuUd0XR+RuSGByxT26MXo1LmZ 7vmRuqBejKzcc257sLOhgGdIAodKQp1T0VU2erwvF9kau/pLNt85lHPRXDHcFFzeUm/z1o/VN4zF nfgjfWf3tYeXT9326FjP42du31TL6US1Vifx0MFneYHvPPTYiM5l0VVN3rquem1TQGt2i7dc3FxY 3D0J1fNq4OB56IuG4P6rbZEHpaMYSxuXLHwl3LkQShcdchJsrqiQYJatkSvQ87Uz57ZuOLO9Otyx vaV2pMFbsv70xomTowVyx6ZtuiP0vrOyp3xq2l41UDs5ledr2ZSoX1vnPnb00BG8s/fIcCRv9d6u uo39HT53S/dIRWLPYFlR9/b6srHedo9/ed9aYm1eotg60Rdqrq1yRw8kH450NNZ53fGm9oLxLVtB F8uAk1eBE0mO3dn8NBszIX+HHGvx7oZErxZte+qW/ec35hdPPXVoDsaneHt+bVdx35Y6k6txclll Xx0EP+K2e//y9PjAY588eOoTZbww/pWb+2LWVXd8Z+quHx6qDjSP7TwGNnYRGhFnKTPcNmZRI9uU BXOk00lBLJi2AaNizugsDZckyRFGo6ZpuI/B+cty6wP6xxyeR2pEiwi5Ev0rlueohJxiMnobXMkI HHr/XhWpdZkFi15Dv4RIEieh43PlJKfEmp1AxwMgA2gHZNArTYecHd3QxqQX9cooneMHKE7HJct5 o45BKp3mysDmKtFRviqqNDEBskm46LLUDG2tGTsxGjG1HZ9+gyiDmzNqudyyZvQuk8FlNmtx1cjd eyfy87uqfb6wjxVdRkiBeWPAbykf2d8Snzv55M5LnCiHeGwT6OtuoBXu9jPaopVugEu5XFOoXYyV ykWNYnzgwOmybIl+Ixjm3fFdj29tnBms1rE04rVcec90omlDwpffs69rDshkaDXPzTRtbg/Zot3l 1eOdpSo5DYEQKFX3TTcMf3FNoSc+XNM8vaoQ3zl0cmPM6HTzPIBDwOEJenzxvtLYYIMPlGCUrDrG 1zAUC7dXuP1hP6Wzm3RmgZeAxUjv7ra6zd1VaoIpX7VVjg/FkF/9GHraebJlyKhxTbcs27jPXmnK dmHC/bgX/dgg3g0NdaUJk/yVRq+FUK1i8HcoyVXg8pa49HcLxtRDRGoNfh7f4c1J/T5bK+F6Wu+y SC6rWYtEqO3g4lbLXf0HP/FxshokPgkSvw9uEeRmUbp+A4mno/mSgBWUzl7lQbsE7vrSCRe6r/XQ 01O1U70VEAfl6zFGlde2eVnzju5IqHu+v24wx2FxO4k6VqeiDGLK6W8vnj43XYU/eNPD09WC1cJr BJsowP0itLY9iU3L42vr3RpbkNB5PRzYUCCcupciysdvwxYWsnGVoOUaBOaZKAVzqD1BrvL8HNhO Mdak8CLXT9fd58SuaeCXutI3Y4vuX4HOGYq75x7bkd/dWGDgwOdYdbhuddn47YMFRPmpdVP3DIVK tzy6s/sLIw0h4Ulf07r6xpEah7VyuKnjDuL53gtnb7+pRq0XRbfNZOMpuALsOHBuxF1cs/GOnv77 b27N7dp220Oth56cKi5auaG8ZiIRLASqcfjvBBxG+B8R+O8ErLe3ecWy9vzm8anNEzs3/zesTEiJ CmVuZHN0cmVhbQplbmRvYmoKNTcgMCBvYmoKNjMwMQplbmRvYmoKNTggMCBvYmoKKHVuZnJlZXpp bmcpCmVuZG9iago1OSAwIG9iagooTWFjIE9TIFggMTAuMTEuNSBRdWFydHogUERGQ29udGV4dCkK ZW5kb2JqCjYwIDAgb2JqCij+/1wwMDRcMDI1XDAwNDxcMDA0OFwwMDQ7XDAwMCBcMDA0XDAzMFww MDQyXDAwND5cMDA0MikKZW5kb2JqCjYxIDAgb2JqCigpCmVuZG9iago2MiAwIG9iagooUG93ZXJQ b2ludCkKZW5kb2JqCjYzIDAgb2JqCihEOjIwMTYwNzIxMDU0NjA1WjAwJzAwJykKZW5kb2JqCjY0 IDAgb2JqCigpCmVuZG9iago2NSAwIG9iagpbICgpIF0KZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxl IDU4IDAgUiAvQXV0aG9yIDYwIDAgUiAvU3ViamVjdCA2MSAwIFIgL1Byb2R1Y2VyIDU5IDAgUiAv Q3JlYXRvcgo2MiAwIFIgL0NyZWF0aW9uRGF0ZSA2MyAwIFIgL01vZERhdGUgNjMgMCBSIC9LZXl3 b3JkcyA2NCAwIFIgL0FBUEw6S2V5d29yZHMKNjUgMCBSID4+CmVuZG9iagp4cmVmCjAgNjYKMDAw MDAwMDAwMCA2NTUzNSBmIAowMDAwMDU0OTMxIDAwMDAwIG4gCjAwMDAwMDM2NTUgMDAwMDAgbiAK MDAwMDAyNTAwOCAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDM2MzUgMDAwMDAg biAKMDAwMDAwMzc2MiAwMDAwMCBuIAowMDAwMDA2NzU1IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDA0NjkzNCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMjYzNzIg MDAwMDAgbiAKMDAwMDAwMzkxMiAwMDAwMCBuIAowMDAwMDAzOTY2IDAwMDAwIG4gCjAwMDAwMDQw MTkgMDAwMDAgbiAKMDAwMDAwNjczNCAwMDAwMCBuIAowMDAwMDEwMzIwIDAwMDAwIG4gCjAwMDAw MDY3OTEgMDAwMDAgbiAKMDAwMDAxMDI5OSAwMDAwMCBuIAowMDAwMDEwNDMwIDAwMDAwIG4gCjAw MDAwMzExNDAgMDAwMDAgbiAKMDAwMDAxMzk4NSAwMDAwMCBuIAowMDAwMDEwNTkzIDAwMDAwIG4g CjAwMDAwMTM5NjQgMDAwMDAgbiAKMDAwMDAxNDA5NSAwMDAwMCBuIAowMDAwMDE3OTU5IDAwMDAw IG4gCjAwMDAwMTQyNTggMDAwMDAgbiAKMDAwMDAxNzkzOCAwMDAwMCBuIAowMDAwMDE4MDY5IDAw MDAwIG4gCjAwMDAwMjEwOTIgMDAwMDAgbiAKMDAwMDAxODIzMiAwMDAwMCBuIAowMDAwMDIxMDcx IDAwMDAwIG4gCjAwMDAwMjEyMDIgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDI1 MTc5IDAwMDAwIG4gCjAwMDAwMjQ3MzUgMDAwMDAgbiAKMDAwMDAyMTM2NSAwMDAwMCBuIAowMDAw MDI0NzE0IDAwMDAwIG4gCjAwMDAwMjQ4NDUgMDAwMDAgbiAKMDAwMDAyNTEyOSAwMDAwMCBuIAow MDAwMDI1NjYwIDAwMDAwIG4gCjAwMDAwMjUzNDIgMDAwMDAgbiAKMDAwMDAyNTY0MCAwMDAwMCBu IAowMDAwMDI1OTA4IDAwMDAwIG4gCjAwMDAwMjYzNTIgMDAwMDAgbiAKMDAwMDAyNzE0OCAwMDAw MCBuIAowMDAwMDI2NjUyIDAwMDAwIG4gCjAwMDAwMjcxMjggMDAwMDAgbiAKMDAwMDAyNzM4OSAw MDAwMCBuIAowMDAwMDMxMTE5IDAwMDAwIG4gCjAwMDAwMzE1NjkgMDAwMDAgbiAKMDAwMDAzMTgx MSAwMDAwMCBuIAowMDAwMDQ2OTEyIDAwMDAwIG4gCjAwMDAwNDc5OTcgMDAwMDAgbiAKMDAwMDA0 NzMyNCAwMDAwMCBuIAowMDAwMDQ3OTc3IDAwMDAwIG4gCjAwMDAwNDgyMzMgMDAwMDAgbiAKMDAw MDA1NDYyNCAwMDAwMCBuIAowMDAwMDU0NjQ1IDAwMDAwIG4gCjAwMDAwNTQ2NzQgMDAwMDAgbiAK MDAwMDA1NDcyNyAwMDAwMCBuIAowMDAwMDU0Nzk5IDAwMDAwIG4gCjAwMDAwNTQ4MTggMDAwMDAg biAKMDAwMDA1NDg0NyAwMDAwMCBuIAowMDAwMDU0ODg5IDAwMDAwIG4gCjAwMDAwNTQ5MDggMDAw MDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA2NiAvUm9vdCAzOSAwIFIgL0luZm8gMSAwIFIgL0lEIFsg PDU5NGQ4MTJhY2M2ZmRjMzNmYTcxYTFjMzI1OTE4MzA5Pgo8NTk0ZDgxMmFjYzZmZGMzM2ZhNzFh MWMzMjU5MTgzMDk+IF0gPj4Kc3RhcnR4cmVmCjU1MTA2CiUlRU9GCg== --94eb2c0c021013cdd005381ef1d6-- From nobody Wed Jul 20 22:59: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 0981712DA19 for ; Wed, 20 Jul 2016 22:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 xgZGP11XBgGR for ; Wed, 20 Jul 2016 22:59:05 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F137812D73E for ; Wed, 20 Jul 2016 22:59:03 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id q128so9192984wma.1 for ; Wed, 20 Jul 2016 22:59:03 -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=34OhDaxp7d/UYjZ5Ww78WjvhiyXeky3eZPW7pqq+I/c=; b=f6GXelLOkwWUz3KhDkGdmYbL2eAbnFc0LnIK2tA10KqqJBgiUroNOGUjvZnqwNG1OM m/atD/Evk8+getrV61UTuuVJSdreCOeZCF1/xyHCKdT+SvMQvaltEAJxr4El/5qKxmR2 P5eqr3SZRgzPRExW/rb94yqZcRuGLbAfERcZCzBCjwHbXQDgcjxCtUsR8OXaY+cH7vxP GWKqoSF/FZzUzRaWS2KJCoKyxGGK+64/gFsihHi0zrlD/4C/wXr1a1xrzgUDLDa+DGpi gSXpo0EgY1mgjxhRSv7Uhjfszc0/M57Gcrxmv2Cq21EEWOsujlEu5rBISdw9HoGpHfKS C6BQ== 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=34OhDaxp7d/UYjZ5Ww78WjvhiyXeky3eZPW7pqq+I/c=; b=Bdgm29wk9UDqWVoGYJC73aoRzz5yg6oGDP54fF3v1gP7+niJLOPIsaRjPMeDVRXt5U Dz6Z01N2oeP9Cbz/16f4t0Hk/BZou3ww5VJthCgX0P748VMx8+BES1R7Hp/U0QqFF77E WFfNdDJj4XyvCBldixRaMCYnIZSDbtTwLbXHwp+4oMDdVg3dxUwWVtPRlTCI3ToVvhi0 GYbVJmFYNnszmHBkq3RuKcH6r0NVLq96TXobJaEJVc/YBiSFoMGVEXxWX6CI1oBl2bpa W+wL6blUz8eE5OLpYK8dXUBxjnzkgr7H1v97EiOrP/iecU8OSTT6Io5NeE2/7ZmZibFv CPAA== X-Gm-Message-State: ALyK8tL2qIf7iBrJ435XePVik2R7YqXCTm5h+5e++mQ/Ym2IMHe/uo9iBZAN5omfLPvJI4ATGSa4yMkmYkXBb777 X-Received: by 10.194.99.11 with SMTP id em11mr4797367wjb.8.1469080742388; Wed, 20 Jul 2016 22:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.207.199 with HTTP; Wed, 20 Jul 2016 22:58:42 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 20 Jul 2016 22:58:42 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=089e0103e084cc37da05381f0394 Archived-At: Cc: Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Plan for handling trickle unfreezing 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, 21 Jul 2016 05:59:07 -0000 --089e0103e084cc37da05381f0394 Content-Type: text/plain; charset=UTF-8 It's the highest priority of what you've got, right? On Wed, Jul 20, 2016 at 10:53 PM, Emil Ivov wrote: > Hey Justin, > > Have a look at the attachment. The table there is probably the simplest > (or at least what I believe to be the simplest) way to represent the > current unfreezing algorithm of 5245. It's what Peter, Jonathan and I used > to support our discussion the other day and I am trying to make the case > that we should also use this representation to actually explain the > algorithm in 5245bis. > > So anyways, topmost therefore refers to the first candidate in a given > column. This is not necessarily the highest priority (priority mostly plays > in the ordering of foundations here) but the first pairs in any > component/stream to actually have a candidate pair for a given foundation. > > Emil > > > On Thursday, 21 July 2016, Justin Uberti wrote: > >> >> >> On Wed, Jul 20, 2016 at 4:47 PM, Peter Thatcher >> wrote: >> >>> Justin brought up an issue with trickle unfreezing mixed with the 5245 >>> "unfreeze the whole checklist" loop. We've had some off-list discussions >>> about what we can do and we've come up with the following plan: >>> >>> 1. Keep the "for every foundation, unfreeze the 'top' candidate you >>> have received so far" that we came up with in Buenos Aires. It's already >>> in the trickle draft. >>> >> >> In this context, I assume 'top' == 'highest priority candidate for the >> lowest-index m= line'? >> >>> >>> 2. Remove the "unfreeze the whole checklist" loop in 5245bis and >>> replace it with a new unfreezing rule to 5245bis: unfreeze the 'top' >>> candidate for every foundation. >>> >> >> Is 'top' the same definition here? And do 'non-top' candidates only get >> unfrozen when the 'top' one succeeds (or times out)? >> >> If so, this seems sensible to me, as it preserves the general goal of >> freezing (don't check things that are redundant) without adding extra delay. >> >> >> >>> This fixes the problem Justin brought up while maintaining the reason >>> that loop exists in the first place (as far as we can tell). It also makes >>> the behavior consistent between non-trickle and trickle when candidates are >>> trickled in order. It also makes 5245bis less complex. >>> >>> #1 is already. >>> >>> #2 will be discussed at the WG meeting during the time slot for 5245bis. >>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >> --089e0103e084cc37da05381f0394 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's the highest priority of what you've got, righ= t?

On Wed, J= ul 20, 2016 at 10:53 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey Justin,

=
Have a look at the attachment. The table there is probably the simples= t (or at least what I believe to be the simplest) way to represent the curr= ent unfreezing algorithm of 5245. It's what Peter, Jonathan and I used = to support our discussion the other day and I am trying to make the case th= at we should also use this representation to actually explain the algorithm= in 5245bis.

So anyways, topmost therefore refers = to the first candidate in a given column. This is not necessarily the highe= st priority (priority mostly plays in the ordering of foundations here) but= the first pairs in any component/stream to actually have a candidate pair = for a given foundation.

Emil


On Thursday, 21 Jul= y 2016, Justin Uberti <juberti@google.com> wrote:
=


On Wed, Jul 20, 2016 at 4:47 PM, Peter Thatcher <<= a>pthatcher@google.com> wrote:
= Justin brought up an issue with trickle unfreezing mixed with the 5245 &quo= t;unfreeze the whole checklist" loop. =C2=A0 We've had some off-li= st discussions about what we can do and we've come up with the followin= g plan:

1.=C2=A0 Keep the "for every foundation, unfreeze the = 9;top' candidate you have received so far" that we came up with in= Buenos Aires.=C2=A0 It's already in the trickle draft.

In this context, I assume 'top' = =3D=3D 'highest priority candidate for the lowest-index m=3D line'?=

=
2.=C2=A0 Remove the "unfreeze the whol= e checklist" loop in 5245bis and replace it with a=C2=A0new unfreezing rule to 5245bis: unfreeze the 'top= 9; candidate for every foundation.=C2=A0=C2=A0

Is 'top' the same definition here? And= do 'non-top' candidates only get unfrozen when the 'top' o= ne succeeds (or times out)?

If so, this seems sens= ible to me, as it preserves the general goal of freezing (don't check t= hings that are redundant) without adding extra delay.

<= div>

This fixes the problem Justin brought= up while maintaining the reason that loop exists in the first place (as fa= r as we can tell).=C2=A0 It also=C2= =A0makes the behavior consistent between non-trickle and trickle when candi= dates are trickled in order.=C2=A0 It also makes 5245bis less complex. =C2= =A0

#1 is already.
#2 will be discussed at the WG meeti= ng during the time slot for 5245bis.
<= br>

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



--089e0103e084cc37da05381f0394-- From nobody Wed Jul 20 23:02: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 162AA12DA37 for ; Wed, 20 Jul 2016 23:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDqRn4ABr3Py for ; Wed, 20 Jul 2016 23:02:51 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 579F212DA3D for ; Wed, 20 Jul 2016 23:02:46 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j12so58531061ywb.2 for ; Wed, 20 Jul 2016 23:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4IT5umD677aZhOCgpUZ3XHTMtYaOW4B/O9MClsffy18=; b=yNtZ+NBq1/HGbQS+IIxIOxdXp+BozrzfE2KiBovcaTRQqiMeRZ+ixn3RrHvP+UDMPE nVNl1d+F4PFW0Pv54Yx2i+uV4LHnGsNs2rbjeJ8v325zfre79+brv/nmOfFCw/deNSkn 7nDuDUgcG4dOpWYRgoN43+ZJ+Oo4RNr9UE68KXJ91eM2hk+QhknYn+EaOwAdvfmKVgEt 0wmcvYgBUxrwuhEBIlu4cKN/tld5Us5SRtbuVZcNX/+VnXwl1V5maFzW78UIhX23YxeZ wA8iqOICEaO07cOK879+4qEhDfQc3HxHPk6Kizn4VlW9e/2hpwpEE8Vb1Iyiq25LrG8m FoqQ== 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=4IT5umD677aZhOCgpUZ3XHTMtYaOW4B/O9MClsffy18=; b=V5+bY3/xocVqZJOzo9gymvuQcQKfr6+AEjj3MA/rn4jen8XCquVM3zYi3B1UBdmlFl 8Y9d7PN2QuyzcWj8j7n2tPit7/jx/WuxjB3ar+8xlhYhiUmKVgUokmrCWvNfAEwwEijz Yu0VxpIbAEK4fDV+OiJfFiu/KR8bwzDbnrQOQmpvqLcFnwyEcRcc38MDl71LyK67jah9 CFoLN6Itqd3Eq9Oyqll0eOFFVlR/g6E3l19QWDdjKs66eLnm/fQ0NC5m61i68YOgSRz0 vps4Jy3tfHKKz/mgYnVSudtLBp5h19qcFbRyyV2wZqqPYddyjkYgDuTvkpcCtcC+FmwZ TfXw== X-Gm-Message-State: ALyK8tIMWnIOmY2PySgmeLsHjPlhXhOIf0pctUrrCdH7XrNOR/xfZCUewiuZeFxTaYZB4w== X-Received: by 10.13.232.70 with SMTP id r67mr34578412ywe.184.1469080965374; Wed, 20 Jul 2016 23:02:45 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com. [209.85.161.174]) by smtp.gmail.com with ESMTPSA id c124sm2637292ywh.28.2016.07.20.23.02.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 23:02:45 -0700 (PDT) Received: by mail-yw0-f174.google.com with SMTP id j12so58530895ywb.2 for ; Wed, 20 Jul 2016 23:02:44 -0700 (PDT) X-Received: by 10.129.169.132 with SMTP id g126mr34412578ywh.179.1469080964764; Wed, 20 Jul 2016 23:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Wed, 20 Jul 2016 23:02:25 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 21 Jul 2016 08:02:25 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Plan for handling trickle unfreezing 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, 21 Jul 2016 06:02:58 -0000 Well, technically speaking, yes, but only because the component ID is part of the priority and all other factors (type and local preference) will be the same for a given foundation. Emil On Thu, Jul 21, 2016 at 7:58 AM, Justin Uberti wrote: > It's the highest priority of what you've got, right? > > On Wed, Jul 20, 2016 at 10:53 PM, Emil Ivov wrote: >> >> Hey Justin, >> >> Have a look at the attachment. The table there is probably the simplest >> (or at least what I believe to be the simplest) way to represent the current >> unfreezing algorithm of 5245. It's what Peter, Jonathan and I used to >> support our discussion the other day and I am trying to make the case that >> we should also use this representation to actually explain the algorithm in >> 5245bis. >> >> So anyways, topmost therefore refers to the first candidate in a given >> column. This is not necessarily the highest priority (priority mostly plays >> in the ordering of foundations here) but the first pairs in any >> component/stream to actually have a candidate pair for a given foundation. >> >> Emil >> >> >> On Thursday, 21 July 2016, Justin Uberti wrote: >>> >>> >>> >>> On Wed, Jul 20, 2016 at 4:47 PM, Peter Thatcher >>> wrote: >>>> >>>> Justin brought up an issue with trickle unfreezing mixed with the 5245 >>>> "unfreeze the whole checklist" loop. We've had some off-list discussions >>>> about what we can do and we've come up with the following plan: >>>> >>>> 1. Keep the "for every foundation, unfreeze the 'top' candidate you >>>> have received so far" that we came up with in Buenos Aires. It's already in >>>> the trickle draft. >>> >>> >>> In this context, I assume 'top' == 'highest priority candidate for the >>> lowest-index m= line'? >>>> >>>> >>>> 2. Remove the "unfreeze the whole checklist" loop in 5245bis and >>>> replace it with a new unfreezing rule to 5245bis: unfreeze the 'top' >>>> candidate for every foundation. >>> >>> >>> Is 'top' the same definition here? And do 'non-top' candidates only get >>> unfrozen when the 'top' one succeeds (or times out)? >>> >>> If so, this seems sensible to me, as it preserves the general goal of >>> freezing (don't check things that are redundant) without adding extra delay. >>> >>> >>>> >>>> This fixes the problem Justin brought up while maintaining the reason >>>> that loop exists in the first place (as far as we can tell). It also makes >>>> the behavior consistent between non-trickle and trickle when candidates are >>>> trickled in order. It also makes 5245bis less complex. >>>> >>>> #1 is already. >>>> >>>> #2 will be discussed at the WG meeting during the time slot for 5245bis. >>>> >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>> > -- https://jitsi.org From nobody Thu Jul 21 02:57: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 3E5E112DC56 for ; Thu, 21 Jul 2016 02:57:24 -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 JUEJcvokSEup for ; Thu, 21 Jul 2016 02:57:22 -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 A79CF12D08F for ; Thu, 21 Jul 2016 02:57:22 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id s63so68949301qkb.2 for ; Thu, 21 Jul 2016 02:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=KuKmoMjJZLCQYacBHaiUaNKmR0Y5R5rI9Ig3nZYlKnM=; b=0ehQ3eSBFh+RGX9js3lTIkMcYN7Ev8AiBUknBXkpsnipMj6jMVwQjqsV6DbTSZ+8hz xEUTqwjMGBdOKepFsi5GgTIkZxZ+2Y6StP65EHospc0Rng9LCQp5yLDkokCVppOB2Riq 3lIhlENju77ISkn70yNl2y8iG4GS9IVKQ7UAJ9IhWaVfhrGp6NHK9CfV8AbW6tj26iTI JB2jllSu3G+0C1Lv5hDFTLG1f7/856W2qiyISAo0sKzrfKRsMOPcnHETUBq+sMYCnpfU INlAlVEiAhPD2Xz1p6YBLYMhRIYsSiJCMvz0ID7jGPUlfu093+RUTqDSAzXpRQBVFC6h M2qA== 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=KuKmoMjJZLCQYacBHaiUaNKmR0Y5R5rI9Ig3nZYlKnM=; b=mhHTpFeIfzAJzsr9467sz79/aIZMePiPiYM9Kj3wauHrAwcrMglU4GStvKDFGpzYsV 5aLEmc3Dx9i1KUb9JALL7Lth92FMFMGAuEt4Qn46uvQEuJD5BifMQnWNUdj3JBqNrmEH ALVIsbXLzbrR5Oj3Qm3AYTgMYCH2eVKSDCYs3a4saL9PAm/3raZQDlUEZ6mtPnfY0UMz +ySWN2iwf7zV0FRQHuiCWfXoX5A10taR5n3w0HxYfxA77NGfhxBxO7SGIlc/SHJjTvAr iQl36LYBizSRC9dqLQ28+U8y7uOAwMr5fCQ/HynGAXe8ftUbri51bRUUQwN6Z6/DPhto KPfQ== X-Gm-Message-State: ALyK8tJ/Xi2Ci5Xpf4iXWrdvDGd72oW3M3xjczsXUe4Z8F1sQtTlfSorQTxedJwvqQG9uJnQXAaSiulALezjgg== X-Received: by 10.55.78.146 with SMTP id c140mr70258934qkb.48.1469095041725; Thu, 21 Jul 2016 02:57:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 21 Jul 2016 02:57:21 -0700 (PDT) From: Martin Thomson Date: Thu, 21 Jul 2016 11:57:21 +0200 Message-ID: To: ice@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Ice] Example of data transmission without congestion control 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, 21 Jul 2016 09:57:24 -0000 In HTTP/1.1, browsers will open 6 connections to the same site. Many sites are now deploying TCP stacks with an initial congestion window of 10. If we assume an MSS of 1400, that means that some sites will send 1400*10*6 bytes without congestion control. Most likely, these 840 kilobits will arrive in less than a second. 840kbps is more than we are asking for with ICE. In practice, this can be worse because with TLS you have a round trip over which the window is increased, though it's probably just one or two packets more. We also have examples of sites that use domain sharding to increase the connection limit to as much as 30. That does horrific things to the network, so I don't think that we should use that as an argument. I tend to think that 6*IW10 is also pretty dicey, but it's an example of something that is widely deployed. From nobody Thu Jul 21 03:01:10 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 5A99612D9CE for ; Thu, 21 Jul 2016 03:01:09 -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 O6L2aMoh2OVT for ; Thu, 21 Jul 2016 03:01:07 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 C9E1012DA12 for ; Thu, 21 Jul 2016 03:01:06 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u25so40881051qtb.1 for ; Thu, 21 Jul 2016 03:01:06 -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; bh=ow4D2CTd8D1BffRJ3X97XtZxsdfF8SaYzffSsRLaX8g=; b=t8FHl26Lw5i/D3PPUuDG4NteOPw/fNa2flcvtBBpoYY1EkmwFWBSLfjPIrgPS7n9vO gwngSwlezyPfTiNSWDdTmaa49lHlNXZkwuHhP5FH4LPpdDLSlOscy1seyofKiLlEJE9D mQu0u44BQxeiCq05hrcSElWBoSb25tnPluGSXGIdFyDYQGTjgvcqE5vkJXyfXW6n7U9a 51jJOO3znrDr8MA44gG6aW/9k2QwXpiIhE2TFTtojFfdCsznO4D2IbfVf3evdygfHK4Q 2xOirPf5PYtVusHCd9UGedgcYkilhsYh4f9Iu+Q7yhOzz/oKd5+dKr9qvuA/69leaQLO RCSw== 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=ow4D2CTd8D1BffRJ3X97XtZxsdfF8SaYzffSsRLaX8g=; b=L4iLKWXwWV3nwAGS7RVPcx+eFPO0nbp8u7Nlie3xh82fJKrspeM4wmR2jUxpCR2xCz E4aukejsD55FwcM0fg4T3MAZvkmby4+qmvt5jBRVw8FTEHMH95zQGZY7VI80DVBC93FK rfdUigpToZXktc4PvSAtEWuUpA0mtdsSOqeJs/JTaH2XZZlliH+jvdS/nnGqukRFBbx3 JSiVp8S1hRnmWUkRKa6USqa8yMHVv3wTZTSRqPs2168W4Gy3IEAvmbQMeEwtEHr/fB98 F9KfVZybta6JxC+yy0+8UXLYaOIaYOLd3uZRXSPxPDWuZj9v1EZeTU0Y1wrJ4GHcMdHn 472w== X-Gm-Message-State: ALyK8tIRBcDmYAZd9yyHI5c3KF7Yc+Gh556H5obSh7aXxDp2ueyWxJXZfVkg+dci/Id30p5b/JWt3K4ZpILKnw== X-Received: by 10.237.41.225 with SMTP id o88mr52522075qtd.18.1469095265852; Thu, 21 Jul 2016 03:01:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 21 Jul 2016 03:01:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 21 Jul 2016 12:01:05 +0200 Message-ID: To: ice@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Ice] Example of data transmission without congestion control 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, 21 Jul 2016 10:01:09 -0000 I forgot to add my sources: This is highly relevant: https://insouciant.org/tech/network-congestion-and-web-browsing/ On 21 July 2016 at 11:57, Martin Thomson wrote: > In HTTP/1.1, browsers will open 6 connections to the same site. Many > sites are now deploying TCP stacks with an initial congestion window > of 10. If we assume an MSS of 1400, that means that some sites will > send 1400*10*6 bytes without congestion control. Most likely, these > 840 kilobits will arrive in less than a second. 840kbps is more than > we are asking for with ICE. > > In practice, this can be worse because with TLS you have a round trip > over which the window is increased, though it's probably just one or > two packets more. > > We also have examples of sites that use domain sharding to increase > the connection limit to as much as 30. That does horrific things to > the network, so I don't think that we should use that as an argument. > I tend to think that 6*IW10 is also pretty dicey, but it's an example > of something that is widely deployed. From nobody Fri Jul 22 02:42:23 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 A313C12DF3E for ; Fri, 22 Jul 2016 02:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 W6UTxdB0k9jG for ; Fri, 22 Jul 2016 02:42:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815C112DF36 for ; Fri, 22 Jul 2016 02:42:11 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-f4-5791ea719260 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2D.0F.12926.17AE1975; Fri, 22 Jul 2016 11:42:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 11:42:09 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Appendix B Thread-Index: AdHj/VG9wB2uny6WTEWXXlO0WGinTg== Date: Fri, 22 Jul 2016 09:42:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476E1628@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B476E1628ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7mW7hq4nhBn8uWVh8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MhiknGQu+ylb8vHyUrYHxp2QXIyeHhICJxM9vN1ghbDGJC/fW s3UxcnEICRxhlHh/dB4rhLOEUWL/4QPsXYwcHGwCFhLd/7RBGkQEFCVmtjxjBrGFBWQkLk77 wwQTP9uzBMrWk2jungi2gEVAVeLGtEVsIDavgK9E87q5YDYj0OLvp9aA1TMLiEvcejKfCeIg AYkle84zQ9iiEi8f/4M6VEmicckTVpBzmAXyJeZ0sUCMFJQ4OfMJywRGoVlIJs1CqJqFpAqi REdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREY DQe3/FbdwXj5jeMhRgEORiUe3gW8E8OFWBPLiitzDzFKcDArifBeewoU4k1JrKxKLcqPLyrN SS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwGj65pJ5x5/mRbZ7T3AdMGJZ2qbK qZ4/e6JY/l7Gmd+3PT/o1frs3oRj0/0f/Nlq9VHA2zdyIpd6gfKsEx7h+8QX6dyazcaexu54 w+Aum/SNtb9OmXRcMtps+SfvqtjMy20z/6+a9U9vpflOPh7Zh2oXuK7WvXj/6a/z+sfnXz/i vVRjGN3tIeGvxFKckWioxVxUnAgAr4BtOYICAAA= Archived-At: Subject: [Ice] 5245bis: Appendix B 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, 22 Jul 2016 09:42:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476E1628ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As was noted during the ICE session in Berlin, we need to modify the Ta val= ue listed in Appendix B.1 of draft-5245bis. B.1 also contains text about the bandwidth rate, so we need to see whether = that's still aligned with the decisions we made in Berlin. Also, in general, we should take a look whether the text in Appendix B stil= l apply for 5245bis. I guess it mostly does, but it needs to be checked. Of course, we could also think of whether we should keep Appendix B (the wh= ole appendix, or certain parts of it) to begin with. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B476E1628ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As was noted during the ICE session in Berlin, we ne= ed to modify the Ta value listed in Appendix B.1 of draft-5245bis.

 

B.1 also contains text about the bandwidth rate, so = we need to see whether that’s still aligned with the decisions we mad= e in Berlin.

 

Also, in general, we should take a look whether the = text in Appendix B still apply for 5245bis. I guess it mostly does, but it = needs to be checked.

 

Of course, we could also think of whether we should = keep Appendix B (the whole appendix, or certain parts of it) to begin with.=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B476E1628ESESSMB209erics_--