From nobody Mon Oct 3 21:57: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 ACF24126FDC for ; Mon, 3 Oct 2016 21:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9A20IqXmlp for ; Mon, 3 Oct 2016 21:57:54 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d: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 B6F991200DF for ; Mon, 3 Oct 2016 21:57:54 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o68so41737784qkf.3 for ; Mon, 03 Oct 2016 21:57:54 -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=FMDjGMF2a5rAfGmDYrHTQ/+gho3HckEz6oipFg03NJ4=; b=XOf1IyEDOoHprLBb4nyvsqSy4988z/ygAB5LEd9bEZb1Z2r/f86eruAcH7i6Xod/wl nIsd9H3QwJk1EQGUJNIPmyI75VOzNWVMmGUbWun7ULeuX64+UG5vg4EwepmIxXOdZ2a5 sFTpyULEU78Ogq3vfDWEQ2cIC1YJOmQvbJRWIBpT29KLoUXVG7y2xU8tUpqcarSx/JGL MsCcV9fUGthlXjeGo4Np9gWnUg9B5PTjx+FcftBZ5ZWvNdr/2DgqkNbkTB8f7FZ2GzPd yKPlXIJs0rZrSHFAnPQMC/uKS8xEDFkEowRvoCywUcADHjoH7mDWMmbHYGfOd3t9Sbw9 bYvQ== 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=FMDjGMF2a5rAfGmDYrHTQ/+gho3HckEz6oipFg03NJ4=; b=WFo7wwhk3DTh3XYtziod1/J5tJ0Cm+k/bnNtsZqhIuiPPuC2ScHfRBdmuUrbj9olEr 0/iunJCPAMey2ginKPFT0xkQF96LwCUGAQO7RoB8RoGe3T8SSJcBtBgjXdlJU0CRf+Ag tZPx3yzg//0sRSIRspjpxPffb/kkHntcNhRLrXFfVMsKBS+XlAalNGH+FqMCx+ivMOSL IQdCkmZUUuMeyPtZbxSj/mVzj7/j1CWdqzc0oET9dhPkScDpYHER5yYkAM0jaSsj0YXT V1oSh1GD+Yap0Be3JLU+tyUFRoBCA7qvokApuM8S2m1cAhWkV/C4oJA3W0S3zfSZBtMv zPtQ== X-Gm-Message-State: AA6/9RllFnykPNLf2bFbpyaGLYaTF1xTDL6d4ktM9iMXeAZ++LQVn2zSQmwJ82kw0dEtXG4iFklczZCbgzVpJ/Ej X-Received: by 10.55.204.196 with SMTP id n65mr1839456qkl.200.1475557073560; Mon, 03 Oct 2016 21:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.135.195 with HTTP; Mon, 3 Oct 2016 21:57:13 -0700 (PDT) In-Reply-To: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> From: Peter Thatcher Date: Mon, 3 Oct 2016 21:57:13 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11499328378ce7053e02e7a8 Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , ice@ietf.org, Thomas Stach , Christer Holmberg Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 04:57:56 -0000 --001a11499328378ce7053e02e7a8 Content-Type: text/plain; charset=UTF-8 I proposed candidate removal as an extension to ICE in Berlin: https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can be published without it and it can be published later as an extension, if the ICE WG chooses to adopt it. On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba wrote: > I believe that removing candidates is very useful. Let me give an example. > With TURN mobility, it is possible to retain pairs involving TURN > candidates across interface changes. So if you leave a building and WLAN > host candidates become unavailable, if you have cellular connectivity you > can use TURN mobility to keep media flowing while looking for a better > candidate pair. To avoid loss of consent that would invalidate Pairs > involving the WLAN candidates, it is desirable to remove (and perhaps > later, renominate) the WLAN host and srvflx candidates. > > The package of TURN mobility, removal, renomination and aspects of > passive-aggressive nomination therefore enables efficient and effective ICE > mobility. > > Code is available for inspection in ORTC Lib (http://ortclib.org/) > > On Sep 23, 2016, at 1:47 PM, Thomas Stach wrote: > > All, > > in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a > question came up, if we need functionality for removing candidates. > > From list discussion in ICE, the minutes of the Berlin IETF and due to the > lack of corresponding text in draft-ietf-ice-trickle-04, I have the > impression that this is currently not in scope of the Trickle ICE work. > > Could anybody confirm that this impression is correct? > > If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice- > sip. > > > Regards > > Thomas > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a11499328378ce7053e02e7a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I proposed candidate removal as an extension to ICE in = Berlin:

https://tools.ietf.org/html/draft-thatcher-ice-= remove-candidate-00


But I b= elieve that trickle ICE documents (in both ICE and MMUSIC WGs) can be publi= shed without it and it can be published later as an extension, if the ICE W= G chooses to adopt it. =C2=A0
=C2= =A0


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <bernard= .aboba@gmail.com> wrote:
I believe that = removing candidates is very useful. Let me give an example. With TURN mobil= ity, it is possible to retain pairs involving TURN candidates across interf= ace changes. So if you leave a building and WLAN host candidates become una= vailable, if you have cellular connectivity you can use TURN mobility to ke= ep media flowing while looking for a better candidate pair. To avoid loss o= f consent that would invalidate Pairs involving the WLAN candidates, it is = desirable to remove (and perhaps later, renominate) the WLAN host and srvfl= x candidates.

The package of TURN mobility, removal, renomination and= aspects of passive-aggressive nomination therefore enables efficient and e= ffective ICE mobility.

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

On Sep 23, 2016, at 1:47 PM, Thomas St= ach <thomas= s.stach@gmail.com> wrote:

All,

in preparation of WGLC for dr= aft-ietf-mmusic-trickle-ice-sip in MMUSIC a question came up, if we ne= ed functionality for removing candidates.

= >From list discussion in ICE, the minutes of the Berlin IETF and due to the = lack of corresponding text in draft-ietf-ice-trickle-04, I have the impress= ion that this is currently not in scope of the Trickle ICE work.
=
Could anybody confirm that this impression is correc= t?

If yes, we would be about ready for WGL= C of draft-ietf-mmusic-trickle-ice-sip.


Regards

Thomas<= br>


_______________= ________________________________
Ice mailing list
Ice@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/ice<= br>

______________________________<= wbr>_________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice


--001a11499328378ce7053e02e7a8-- From nobody Tue Oct 4 02:58:42 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 67DE7129766 for ; Tue, 4 Oct 2016 02:58:40 -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 GkPmCePvBnoC for ; Tue, 4 Oct 2016 02:58:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41963129763 for ; Tue, 4 Oct 2016 02:58:38 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-43-57f37d4a9efc Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 4A.16.02458.A4D73F75; Tue, 4 Oct 2016 11:58:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 11:58:34 +0200 From: Christer Holmberg To: Nils Ohlmeier , "ice@ietf.org" Thread-Topic: [Ice] Triggered checks are missing peer reflexive Thread-Index: AQHSBVlPEOYY7CCEV0C+dqegwGP6+aCBttwAgBacroA= Date: Tue, 4 Oct 2016 09:58:34 +0000 Message-ID: References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> In-Reply-To: <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdRden9nO4wb/VGhbfLtRaXJ83mdGB yWPJkp9MHn0HulgDmKK4bFJSczLLUov07RK4MloufGUveCRfsaahi7WBcZtkFyM7h4SAicQ/ xy5GLg4hgfWMEu8Ov2LtYuQEchYxStydrdbFyMHBJmAh0f1PGyQsIuAh8X71JWYQW1jATmLl wTssEHF7iTO7OthBykUErCT+TckBCbMIqEg0zG0BK+EVsJZYdfwxI8T0YokjhzrZQWxOoNar hw6AbWUUEJP4fmoNE4jNLCAucevJfDBbQkBAYsme88wQtqjEy8f/wOpFBfQkvn+dDRVXlNh5 tp0ZotdA4v25+VC2tcTL2+cZIWxtiWULXzND3CMocXLmE5YJjGKzkKybhaR9FpL2WUjaZyFp X8DIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMJoObvlttYPx4HPHQ4wCHIxKPLwJKZ/C hVgTy4orcw8xSnAwK4nwMlZ8DhfiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2 ampBahFMlomDU6qBsX7hgj18H/8IhKwP4/IsrDh/PNvcZMmNLY3r+GXaZux8U3+5LiV88lOG txpb3+t5b1nzZEbpM4MTa0XCf+RvfHT4VvktiYMC3gyKXDaPH2x+uvoM5/b601vPLKp505GS 2ZWh1+s0e8Ofa84FX6L2L9F7u3/xfR2vX35HKhXV32yyWzXrEZvJ6itKLMUZiYZazEXFiQAk UpZYogIAAA== Archived-At: Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 09:58:40 -0000 Hi Nils, Sorry for the late reply. If I understand the issue correctly, this could only happen with trickle. Because, in normal cases pruning would take care of it. Or? Regards, Christer On 20/09/16 06:46, "Ice on behalf of Nils Ohlmeier" wrote: >After reading up on how the current Trickle ICE draft proposes to handle >peer reflexive candidates it appears to me that my scenario below is >relevant for ICE 5245bis if there is no STUN server. >And if there is a STUN server then it should only happen if B has >trickled his public host candidate to A already. And A receives its >binding response from B before it discovers his own server reflexive by >receiving a binding response from the STUN server. > >Even if we don=B9t bother do try to optimize the useless/redundant trigger >check away I think we should: >- include peer reflexive candidates into the paragraph of 5245 which >talks about trigger checks >- extend the paragraph in the trickle draft to not only mention >discovering peer reflexive candidates via STUN binding request, but also >from binding responses. > >I would appreciate some feedback on this before trying to propose >improved wording for both specs. > >Best > Nils Ohlmeier > >> On Sep 2, 2016, at 13:34, Nils Ohlmeier wrote: >>=20 >> Hello, >>=20 >> I have identified something which I would be interested to hear the >>opinions of the ICE experts about. >>=20 >> In RFC 5245 (section 7.2.1.4) and also in bis-04 (section 6.1.3.1.4) >>claim the following regarding receiving triggered checks: >> The local candidate will either be a host candidate (...) or a >>relayed candidate (=8A). The local candidate can never be a server >>reflexive candidate. >>=20 >> Which I think is missing the case where the local candidate can also a >>be a peer reflexive. And this is actually causing unnecessary extra >>checks to be made. >>=20 >> Consider the following scenario: >>=20 >> - A sits behind symmetric NAT >> - B is on a publicly routable address with no NAT or firewall >> - No STUN servers (just makes the scenario less complex) >> - Host candidates get exchanged and candidate pairs A:B and B:A get >>created on both sides >> - A sends binding request to B >> - B receives binding request with transport address A=B9 >> - B creates a peer reflexive candidate for A=B9 and the a new pair B:A= =B9 >>and puts that new pair into its trigger check queue >> - B sends binding response to A=B9 >> - A receives binding response, learns about A=B9 and creates A=B9:B and >>marks it as successful >> - Now B sends a binding request for it trigger check queue entry to A=B9 >> - When A receives this binding request is has no way to match this to >>the successful pair A=B9:B >> - Because of the wording in the above mentioned sections it will match >>the request to the pair A:B >> - Which then in turn causes another triggered check to be created >>because A:B is not in the success state >>=20 >> This additional triggered check from A is just waste of time and >>resources. It does not hurt. But I=B9m wondering how this could be avoide= d. >>=20 >> If people agree I think section 6.1.3.1.4 should at least mention the >>scenario that incoming binding requests can also match a peer reflexive >>candidate. >>=20 >> As the incoming binding request does not contain the destination >>address it got send to there is obviously no way for A to clearly >>distinguish if the request got send to A or A=B9. >>=20 >> For avoiding the additional triggered check on A=B9s side the only >>solution I see right now is to go through the pairs which have A as >>their foundation and if that list contains a pair which is marked as >>successful already assume no triggered check is needed. So far I have >>not been able to identify a scenario where it hurts to skip this extra >>round of triggered checks on A=B9s side. >>=20 >> Best >> Nils Ohlmeier >>=20 > From nobody Tue Oct 4 05:12:55 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 887A1129835 for ; Tue, 4 Oct 2016 05:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 54bT0krpE4r0 for ; Tue, 4 Oct 2016 05:12:50 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D775129827 for ; Tue, 4 Oct 2016 05:12:49 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id b201so141154629wmb.0 for ; Tue, 04 Oct 2016 05:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=wELzvwXQPkSiG2RvZO9UhbXgz48qP5TeAZtetrgzr6s=; b=EOouPfe70ubvXulkAoABDG3qkachTtI5ZLwm/Usxue/6GVJcLVDtANZIu/fHs15k9D x2oX763HjXCvy2ndkhrWEWavXVP9LupgURk0FKdUgj0TxGDzFKTnwWT7JCoyXVtTs2zw Mh98rwvQAy+SdG73US573niLqXdNfk0iYip0bECMitzZPTnT3E6opG1GBLf1TxbFjv1Q 25AtSqHU6IsNrBg5m79hOb/IIv7+xy5gpg3X5pvSdKB+ZR2rZiupfwHgvJzeQAs2kVLw KGm3PA5xWrAvpOrbjj+wmravHjYICxc7oyzZVNbRV9/coobrIepWeuds+jlPBg47jCt0 uvsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=wELzvwXQPkSiG2RvZO9UhbXgz48qP5TeAZtetrgzr6s=; b=PqSfDEkzgKvIexDbu1IIRhvWrsImXvRqvbp0fbo63HUwqqF7exb/2+0q/ZjR3pUCKo oVYJ5Dtp/WHVGXC/pIAQHXxaSf62BY0Jed+swo2O1+g5aE8AcKd6fToGOwOgkCkw4Wp4 mf+Q9p1Nrj9a74FNPaKTsOPxtq18t2av+sjyKBZoIaOTJW5QAeh99hErYf2K9mfeEvFD 0jYDtaVt1TVpXSBeI+sQ9IT6AN9nujKj3t/HeW3f0nim5+B7P1eJQM3dgb7pKvTNTOGZ 1EBayXv2ALVyJuxB/qhiTRIjCZ14kLckr8DR+DLMNyviK5P4DJNv2DE6et6pyTsv55K1 moRQ== X-Gm-Message-State: AA6/9RkDfU1BwwFT2979JxPSdDRms3BRovvTImMgpqdnRAomMscr0kxk6weDuAILcxX0EQ== X-Received: by 10.28.141.6 with SMTP id p6mr3622614wmd.110.1475583167886; Tue, 04 Oct 2016 05:12:47 -0700 (PDT) Received: from [78.104.7.219] ([78.104.7.219]) by smtp.googlemail.com with ESMTPSA id b8sm3233789wjq.40.2016.10.04.05.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 05:12:46 -0700 (PDT) To: Peter Thatcher , Bernard Aboba References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> From: Thomas Stach Message-ID: <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> Date: Tue, 4 Oct 2016 14:12:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------17EB0A6B8817A3BBA6A5C913" Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , ice@ietf.org, Christer Holmberg Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:12:53 -0000 This is a multi-part message in MIME format. --------------17EB0A6B8817A3BBA6A5C913 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Peter, thanks! That confirms my impression and looks like a good plan for finishing the ICE documents. Regards Thomas On 2016-10-04 06:57, Peter Thatcher wrote: > I proposed candidate removal as an extension to ICE in Berlin: > > https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 > > > But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) > can be published without it and it can be published later as an > extension, if the ICE WG chooses to adopt it. > > > On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba > > wrote: > > I believe that removing candidates is very useful. Let me give an > example. With TURN mobility, it is possible to retain pairs > involving TURN candidates across interface changes. So if you > leave a building and WLAN host candidates become unavailable, if > you have cellular connectivity you can use TURN mobility to keep > media flowing while looking for a better candidate pair. To avoid > loss of consent that would invalidate Pairs involving the WLAN > candidates, it is desirable to remove (and perhaps later, > renominate) the WLAN host and srvflx candidates. > > The package of TURN mobility, removal, renomination and aspects of > passive-aggressive nomination therefore enables efficient and > effective ICE mobility. > > Code is available for inspection in ORTC Lib (http://ortclib.org/) > > On Sep 23, 2016, at 1:47 PM, Thomas Stach > wrote: > >> All, >> >> in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in >> MMUSIC a question came up, if we need functionality for removing >> candidates. >> >> >From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in >> draft-ietf-ice-trickle-04, I have the impression that this is >> currently not in scope of the Trickle ICE work. >> >> Could anybody confirm that this impression is correct? >> >> If yes, we would be about ready for WGLC of >> draft-ietf-mmusic-trickle-ice-sip. >> >> >> Regards >> >> Thomas >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > --------------17EB0A6B8817A3BBA6A5C913 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing the ICE documents.

Regards

Thomas


On 2016-10-04 06:57, Peter Thatcher wrote:
I proposed candidate removal as an extension to ICE in Berlin:

https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00


But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can be published without it and it can be published later as an extension, if the ICE WG chooses to adopt it.  
 


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I believe that removing candidates is very useful. Let me give an example. With TURN mobility, it is possible to retain pairs involving TURN candidates across interface changes. So if you leave a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mobility to keep media flowing while looking for a better candidate pair. To avoid loss of consent that would invalidate Pairs involving the WLAN candidates, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, renomination and aspects of passive-aggressive nomination therefore enables efficient and effective ICE mobility.

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

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

All,

in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a question came up, if we need functionality for removing candidates.

>From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in draft-ietf-ice-trickle-04, I have the impression that this is currently not in scope of the Trickle ICE work.

Could anybody confirm that this impression is correct?

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-sip.


Regards

Thomas



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

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



--------------17EB0A6B8817A3BBA6A5C913-- From nobody Tue Oct 4 05:14:42 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 76AF212983B for ; Tue, 4 Oct 2016 05:14:40 -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 JV6H9p2om48y for ; Tue, 4 Oct 2016 05:14:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6536D129827 for ; Tue, 4 Oct 2016 05:14:36 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-14-57f39d281b3c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id E6.61.31035.82D93F75; Tue, 4 Oct 2016 14:14:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 14:14:31 +0200 From: Christer Holmberg To: Thomas Stach , Peter Thatcher , Bernard Aboba Thread-Topic: [Ice] Do we currently need functionality for removing candidates? Thread-Index: AQHSFZiYH/AZ2evYmE2PnZwiDXMDqqCHjbSAgBAdHoCAAHmvgIAANIYA Date: Tue, 4 Oct 2016 12:14:31 +0000 Message-ID: References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> In-Reply-To: <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D4197921105DCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7ma7W3M/hBk0NhhYb9v1ntvh2odbi 394ki2vLX7NafDqxlcmB1WPnrLvsHgs2lXosWfKTyePL5c9sASxRXDYpqTmZZalF+nYJXBkT XjazFDSFVfy+6djAeNeri5GTQ0LARKLxxnOmLkYuDiGB9YwSTasmsEE4ixglpj+8ytjFyMHB JmAh0f1PG6RBRKBG4uGr90wgNrNAksTOh4/ZQWxhgQCJm/umsULUBEr833SaBcJ2k1h07ARY PYuAisSS22vB4rwC1hI7erezQOx6ySjR+/QnG0iCU8BWYurzFjCbUUBM4vupNVDLxCVuPZnP BHG1gMSSPeeZIWxRiZeP/4EtFhXQk/j+dTZUXFHi46t9jBC9CRKX1uxhhFgsKHFy5hOWCYyi s5CMnYWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPIbqtZZYtWECO7KaBYwcqxhFi1OLk3LT jYz1Uosyk4uL8/P08lJLNjECY/bglt+qOxgvv3E8xCjAwajEw5uQ8ilciDWxrLgy9xCjBAez kghv1ezP4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUw xrQ9Y/5k5DZL98pGho2hPBq7Nfskj/0uVA/3nCWhezZVqWT2dW+5IJMdn8wn7/4YUNR4+U1X oO/9mA8f79UkbWhYbHBVzVNH/3LSU8sT6ul3RZx6+jL83s1/dTsldUN4/WJu8UrDGaFMj1eG vLj7115lxveuubmK0bnmiWft9qp41yy3/+GixFKckWioxVxUnAgAFr9PEdUCAAA= Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , "ice@ietf.org" Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:14:41 -0000 --_000_D4197921105DCchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My issue was not whether removing of candidates is documented in trickle or= not, but whether trickle assumes that candidates will not be removed. Regards, Christer From: Thomas Stach = > Date: Tuesday 4 October 2016 at 15:12 To: "pthatcher@google.com" >, Bernard Aboba > Cc: "mmusic-chairs@tools.ietf.org" >, Christer = Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Do we currently need functionality for removing candidat= es? Peter, thanks! That confirms my impression and looks like a good plan for finishing the IC= E documents. Regards Thomas On 2016-10-04 06:57, Peter Thatcher wrote: I proposed candidate removal as an extension to ICE in Berlin: https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can b= e published without it and it can be published later as an extension, if th= e ICE WG chooses to adopt it. On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba > wrote: I believe that removing candidates is very useful. Let me give an example. = With TURN mobility, it is possible to retain pairs involving TURN candidate= s across interface changes. So if you leave a building and WLAN host candid= ates become unavailable, if you have cellular connectivity you can use TURN= mobility to keep media flowing while looking for a better candidate pair. = To avoid loss of consent that would invalidate Pairs involving the WLAN can= didates, it is desirable to remove (and perhaps later, renominate) the WLAN= host and srvflx candidates. The package of TURN mobility, removal, renomination and aspects of passive-= aggressive nomination therefore enables efficient and effective ICE mobilit= y. Code is available for inspection in ORTC Lib (http://ortclib.org/) On Sep 23, 2016, at 1:47 PM, Thomas Stach > wrote: All, in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a qu= estion came up, if we need functionality for removing candidates. >From list discussion in ICE, the minutes of the Berlin IETF and due to the= lack of corresponding text in draft-ietf-ice-trickle-04, I have the impres= sion that this is currently not in scope of the Trickle ICE work. Could anybody confirm that this impression is correct? If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-s= ip. Regards Thomas _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D4197921105DCchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

My issue was not whether removing of candidates is documented in trick= le or not, but whether trickle assumes that candidates will not be removed.=

Regards,

Christer

From: Thomas Stach <thomass.stach@gmail.com>
Date: Tuesday 4 October 2016 at 15:= 12
To: "pthatcher@google.com" <pthatcher@google.com>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org&g= t;, Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Do we currently = need functionality for removing candidates?

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing= the ICE documents.

Regards

Thomas


On 2016-10-04 06:57, Peter Thatcher wrote:
I proposed candidate removal as an extension to ICE in Berlin:

https://tools.ietf.org= /html/draft-thatcher-ice-remove-candidate-00


But I believe that trickle ICE documents (in both I= CE and MMUSIC WGs) can be published without it and it can be published late= r as an extension, if the ICE WG chooses to adopt it.  
 


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.aboba@gmail.com> wrote:
I believe that removing candidates is very= useful. Let me give an example. With TURN mobility, it is possible to reta= in pairs involving TURN candidates across interface changes. So if you leav= e a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mob= ility to keep media flowing while looking for a better candidate pair. To a= void loss of consent that would invalidate Pairs involving the WLAN candida= tes, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, ren= omination and aspects of passive-aggressive nomination therefore enables ef= ficient and effective ICE mobility.

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

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

All,

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

>From list discussion in ICE, the minutes of the Berlin IETF and d= ue to the lack of corresponding text in draft-ietf-ice-trickle-04, I have t= he impression that this is currently not in scope of the Trickle ICE work.<= /span>

Could anybody confirm that this impression is correct?

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle= -ice-sip.


Regards

Thomas



_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice<= /a>

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



 --_000_D4197921105DCchristerholmbergericssoncom_-- From nobody Tue Oct 4 06:10:18 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570712984A for ; Tue, 4 Oct 2016 06:10:17 -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 c04cDLpY8MAa for ; Tue, 4 Oct 2016 06:10:12 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 24DFB12984E for ; Tue, 4 Oct 2016 06:10:12 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id p138so211353947wmb.1 for ; Tue, 04 Oct 2016 06:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=/v0vi5WIvdKCMSORlLoV7X56XtsCzLSZW33gB4xzaaI=; b=LPISe6ua/we8tKRpbIwZ56/v5W+NHy7ly0gKxYc+LlciKVRAivuQwUeNPwlH2Gva/p yDDfdCgZJ4a7XWoFUkZOY5qWhalD/GA54CqX0RgTuRPW+fBlPVpDZWER4+/M3hOT4aDg wJayoN5xQvWSr+IQG3U7U3m95ynAJJoCjb5vYskXW512lWzQY7DRgeRla2AT0Y0Ayc13 pXrzxabR17l6/ERMHQMytuDxAK9s1yySo3ITJnZJeMdsVqP2BAQw96aU1DqXdWJsXbXg Zvc+D+mNkXOzJakPDMK99lAmH9GCUB1csQrcsBjv7dm7ZFEf8CAcWQcP1d8JMQHj4fjC xSNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=/v0vi5WIvdKCMSORlLoV7X56XtsCzLSZW33gB4xzaaI=; b=Fe7SybOc7MwDVEyUnqNsf41UYQzKFBxu0kWdddD72HqC6jRfS71u+EwrineT7pYMdN O2kzHDFOajnW8mGBoMHDNQk5/mWPY2v7aek+XL2xV+pyU7SXgYiR5mNNmbSj5xKIoltH 4zebi8joJCwAY8NtdcvI5+LVAHpeaYsMau/Pj17fxiaX7ZQ83ZlpmgvKzqCWk8GwKdzi BJGBG/NS3QyxPOe+Db8JmNv1Q/upIhfzWOPh3LvACL5h8ksSBOQkPKKZgCKssTnwmuXe G0mwu1oLNcnHDkLFCDXlOpHNH746wab3VxdP2hyRwNwmr2FgVQnCICawYnjFTtmHKYE6 sjbQ== X-Gm-Message-State: AA6/9RkYg1l6nQ/KiqRO7LmQsTpzlqIRjS1HUH8+Yy+rc31KinXf307Yzwfv4gmHFhiw6Q== X-Received: by 10.28.92.82 with SMTP id q79mr3547451wmb.113.1475586610559; Tue, 04 Oct 2016 06:10:10 -0700 (PDT) Received: from ?IPv6:2001:62a:4:41c:4014:d08:a8ca:2206? ([2001:62a:4:41c:4014:d08:a8ca:2206]) by smtp.googlemail.com with ESMTPSA id o196sm23311463wmg.8.2016.10.04.06.10.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 06:10:09 -0700 (PDT) To: Christer Holmberg , Peter Thatcher References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> From: Thomas Stach Message-ID: Date: Tue, 4 Oct 2016 15:10:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D5ABA3E97FFCD63D2925E163" Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , "ice@ietf.org" Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:10:17 -0000 This is a multi-part message in MIME format. --------------D5ABA3E97FFCD63D2925E163 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Christer, isn't that implied when draft-ice-trickle does not mention removal of candidates and Peter's draft proposes that as an extension? Regards Thomas On 2016-10-04 14:14, Christer Holmberg wrote: > Hi, > > My issue was not whether removing of candidates is documented in > trickle or not, but whether trickle assumes that candidates will not > be removed. > > Regards, > > Christer > > From: Thomas Stach > > Date: Tuesday 4 October 2016 at 15:12 > To: "pthatcher@google.com " > >, Bernard Aboba > > > Cc: "mmusic-chairs@tools.ietf.org > " >, Christer Holmberg > >, "ice@ietf.org > " > > Subject: Re: [Ice] Do we currently need functionality for removing > candidates? > > Peter, > > thanks! > > That confirms my impression and looks like a good plan for finishing > the ICE documents. > > Regards > > Thomas > > > On 2016-10-04 06:57, Peter Thatcher wrote: >> I proposed candidate removal as an extension to ICE in Berlin: >> >> https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 >> >> >> But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) >> can be published without it and it can be published later as an >> extension, if the ICE WG chooses to adopt it. >> >> >> On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba >> > wrote: >> >> I believe that removing candidates is very useful. Let me give an >> example. With TURN mobility, it is possible to retain pairs >> involving TURN candidates across interface changes. So if you >> leave a building and WLAN host candidates become unavailable, if >> you have cellular connectivity you can use TURN mobility to keep >> media flowing while looking for a better candidate pair. To avoid >> loss of consent that would invalidate Pairs involving the WLAN >> candidates, it is desirable to remove (and perhaps later, >> renominate) the WLAN host and srvflx candidates. >> >> The package of TURN mobility, removal, renomination and aspects >> of passive-aggressive nomination therefore enables efficient and >> effective ICE mobility. >> >> Code is available for inspection in ORTC Lib (http://ortclib.org/) >> >> On Sep 23, 2016, at 1:47 PM, Thomas Stach >> > wrote: >> >>> All, >>> >>> in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in >>> MMUSIC a question came up, if we need functionality for removing >>> candidates. >>> >>> >From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding >>> text in draft-ietf-ice-trickle-04, I have the impression that >>> this is currently not in scope of the Trickle ICE work. >>> >>> Could anybody confirm that this impression is correct? >>> >>> If yes, we would be about ready for WGLC of >>> draft-ietf-mmusic-trickle-ice-sip. >>> >>> >>> Regards >>> >>> Thomas >>> >>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> >> > --------------D5ABA3E97FFCD63D2925E163 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Christer,

isn't that implied when draft-ice-trickle does not mention removal of candidates and Peter's draft proposes that as an extension?

Regards

Thomas


On 2016-10-04 14:14, Christer Holmberg wrote:
Hi,

My issue was not whether removing of candidates is documented in trickle or not, but whether trickle assumes that candidates will not be removed.

Regards,

Christer

From: Thomas Stach <thomass.stach@gmail.com>
Date: Tuesday 4 October 2016 at 15:12
To: "pthatcher@google.com" <pthatcher@google.com>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Do we currently need functionality for removing candidates?

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing the ICE documents.

Regards

Thomas


On 2016-10-04 06:57, Peter Thatcher wrote:
I proposed candidate removal as an extension to ICE in Berlin:

https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00


But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can be published without it and it can be published later as an extension, if the ICE WG chooses to adopt it.  
 


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I believe that removing candidates is very useful. Let me give an example. With TURN mobility, it is possible to retain pairs involving TURN candidates across interface changes. So if you leave a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mobility to keep media flowing while looking for a better candidate pair. To avoid loss of consent that would invalidate Pairs involving the WLAN candidates, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, renomination and aspects of passive-aggressive nomination therefore enables efficient and effective ICE mobility.

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

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

All,

in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a question came up, if we need functionality for removing candidates.

>From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in draft-ietf-ice-trickle-04, I have the impression that this is currently not in scope of the Trickle ICE work.

Could anybody confirm that this impression is correct?

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-sip.


Regards

Thomas



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

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

--------------D5ABA3E97FFCD63D2925E163-- From nobody Tue Oct 4 06:29: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 8296612985C for ; Tue, 4 Oct 2016 06:29:56 -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 sPhAQ3Kr4zEn for ; Tue, 4 Oct 2016 06:29:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1301C129688 for ; Tue, 4 Oct 2016 06:29:48 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-e7-57f3aecabdb6 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id BB.D6.03250.ACEA3F75; Tue, 4 Oct 2016 15:29:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 15:29:46 +0200 From: Christer Holmberg To: Thomas Stach , Peter Thatcher Thread-Topic: [Ice] Do we currently need functionality for removing candidates? Thread-Index: AQHSFZiYH/AZ2evYmE2PnZwiDXMDqqCHjbSAgBAdHoCAAHmvgIAANIYA///bgwCAADmCAA== Date: Tue, 4 Oct 2016 13:29:45 +0000 Message-ID: References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D41987B81062Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2J7uO7pdZ/DDV4+57X4dqHW4t/eJItr y1+zWnw6sZXJgcVj56y77B4LNpV6LFnyk8njy+XPbAEsUVw2Kak5mWWpRfp2CVwZt98fYiqY VVHxYdIZpgbGpWldjJwcEgImEldXTWPuYuTiEBJYzyhxa/sRNghnEaNE38XHjF2MHBxsAhYS 3f+0QUwRgWCJqctMQHqZBZIkdj58zA5iCwsESNzcN40VxBYRCJT4v+k0C0R5mMSp15EgYRYB FYnN1y+wgdi8AtYSx3eeYITYdI5J4svKBcwgCU4BW4mrC96DzWEUEJP4fmoNE8QucYlbT+Yz QdwsILFkz3lmCFtU4uXjf2D1ogJ6Et+/zmYG2SshoCixvF8OojVB4tiKd1B7BSVOznzCMoFR dBaSqbOQlM1CUgYRN5B4f24+M4StLbFs4WsoW19i45ezjBC2tcThI8dZkdUsYORYxShanFqc lJtuZKSXWpSZXFycn6eXl1qyiREYpQe3/DbYwfjyueMhRgEORiUe3oSUT+FCrIllxZW5hxgl OJiVRHg3rv4cLsSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwen VAPjnEdb+vPabNz5sicd2vNwh9dM/qBui52bWovuzcuVWbnxnVa91PWDS0tW/WXdJtorINOW eHSpb+2KLdZs+0sr1VJnH88M3ml27YrJvyrG1Kxj+n0ubX0Ni35xT9Xg7poVzZc2v5Q9+qEe l3h4q7nrcRYZTa95MTmbP3H87T55uu1FSObE0K9KLMUZiYZazEXFiQAbD+ZJzgIAAA== Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , "ice@ietf.org" Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:29:56 -0000 --_000_D41987B81062Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >isn't that implied when draft-ice-trickle does not mention removal of cand= idates and Peter's draft proposes that as an extension? The text in section 4.2 says: "In every INFO request agents MUST include all local candidates they have signaled previously. This is necessary in order to more easily avoid problems that would arise from unreliable transports. Mis- ordering can be detected through the CSeq: header field in the INFO request. As a consequence candidates cannot be removed unless an ICE restart is performed. Note that extension might be specified in the future that enable such removal without a restart.=94 Q1: Assuming someone does define an extension which allows removal of candi= dates without a restart, do such candidates still have to be included in th= e INFO, as they have been =93previously signalled"? What is the scope of = =93previously=94? Previously since when? Q2: What if an INFO does NOT contain a local candidate that has previously = been signaled? Do we assume it has been removed using some =93extension=94?= Do we assume it=92s still there? Q3: What if a candidate has bee removed using some =93extension=94, and the= n it still shows up in an INFO? Does it mean it=92s automatically added bac= k? At one point I suggested that the INFO should ONLY contain the added candid= ates, and would say nothing about existing candidates. But, as that was not= accepted I think Q1-Q3 needs to be clarified in the document. Thanks! Regards, Christer On 2016-10-04 14:14, Christer Holmberg wrote: Hi, My issue was not whether removing of candidates is documented in trickle or= not, but whether trickle assumes that candidates will not be removed. Regards, Christer From: Thomas Stach = > Date: Tuesday 4 October 2016 at 15:12 To: "pthatcher@google.com" >, Bernard Aboba > Cc: "mmusic-chairs@tools.ietf.org" >, Christer = Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Do we currently need functionality for removing candidat= es? Peter, thanks! That confirms my impression and looks like a good plan for finishing the IC= E documents. Regards Thomas On 2016-10-04 06:57, Peter Thatcher wrote: I proposed candidate removal as an extension to ICE in Berlin: https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can b= e published without it and it can be published later as an extension, if th= e ICE WG chooses to adopt it. On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba > wrote: I believe that removing candidates is very useful. Let me give an example. = With TURN mobility, it is possible to retain pairs involving TURN candidate= s across interface changes. So if you leave a building and WLAN host candid= ates become unavailable, if you have cellular connectivity you can use TURN= mobility to keep media flowing while looking for a better candidate pair. = To avoid loss of consent that would invalidate Pairs involving the WLAN can= didates, it is desirable to remove (and perhaps later, renominate) the WLAN= host and srvflx candidates. The package of TURN mobility, removal, renomination and aspects of passive-= aggressive nomination therefore enables efficient and effective ICE mobilit= y. Code is available for inspection in ORTC Lib (http://ortclib.org/) On Sep 23, 2016, at 1:47 PM, Thomas Stach > wrote: All, in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a qu= estion came up, if we need functionality for removing candidates. >From list discussion in ICE, the minutes of the Berlin IETF and due to the= lack of corresponding text in draft-ietf-ice-trickle-04, I have the impres= sion that this is currently not in scope of the Trickle ICE work. Could anybody confirm that this impression is correct? If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-s= ip. Regards Thomas _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D41987B81062Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>isn't that implied when draft-ice-trickle does not mention removal= of candidates and Peter's draft proposes that as an extension?

The text in section 4.2 says:
   "In every INFO request age=
nts MUST include all local candidates they
   have signaled previously.  This is necessary in order to more easily
   avoid problems that would arise from unreliable transports.  Mis-
   ordering can be detected through the CSeq: header field in the INFO
   request.  As a consequence candidates cannot be removed unless an ICE
   restart is performed.  Note that extension might be specified in the
   future that enable such removal without a restart.=94
Q1: Assuming someone does define an extension which allows removal of = candidates without a restart, do such candidates still have to be included = in the INFO, as they have been =93previously signalled"? What is the s= cope of =93previously=94? Previously since when?

Q2: What if an INFO does NOT= contain a local candidate that has previously been signaled? Do we assume = it has been removed using some =93extension=94? Do we assume it=92s still t= here?

Q3: What if a candidate has bee removed using some =93extension=94, an= d then it still shows up in an INFO? Does it mean it=92s automatically adde= d back?

At one point I suggested that the INFO should ONLY contain the added candidates, and would say nothing about = existing candidates. But, as that was not accepted I think Q1-Q3 needs to b= e clarified in the document.

Thanks!

Regards,

Christer




On 2016-10-04 14:14, Christer Holmberg wrote= :
Hi,

My issue was not whether removing of candidates is documented in trick= le or not, but whether trickle assumes that candidates will not be removed.=

Regards,

Christer

From: Thomas Stach <thomass.stach@gmail= .com>
Date: Tuesday 4 October 2016 at 15:= 12
To: "pthatcher@google.com" <= pthatcher@= google.com>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: "mmusic-chairs@tools.ietf.or= g" <mmusic-chairs@tools.ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Do we currently = need functionality for removing candidates?

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing= the ICE documents.

Regards

Thomas


On 2016-10-04 06:57, Peter Thatcher wrote:
I proposed candidate removal as an extension to ICE in Berlin:

https://tools.= ietf.org/html/draft-thatcher-ice-remove-candidate-00


But I believe that trickle ICE documents (i= n both ICE and MMUSIC WGs) can be published without it and it can be publis= hed later as an extension, if the ICE WG chooses to adopt it.  
 


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.aboba@gmail.com> wrote:
I believe that removing candidates is very= useful. Let me give an example. With TURN mobility, it is possible to reta= in pairs involving TURN candidates across interface changes. So if you leav= e a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mob= ility to keep media flowing while looking for a better candidate pair. To a= void loss of consent that would invalidate Pairs involving the WLAN candida= tes, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, ren= omination and aspects of passive-aggressive nomination therefore enables ef= ficient and effective ICE mobility.

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

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

All,

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

>From list discussion in ICE, the minutes of the Berlin IETF and d= ue to the lack of corresponding text in draft-ietf-ice-trickle-04, I have t= he impression that this is currently not in scope of the Trickle ICE work.<= /span>

Could anybody confirm that this impression is correct?

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle= -ice-sip.


Regards

Thomas



_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice<= /a>

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




 --_000_D41987B81062Cchristerholmbergericssoncom_-- From nobody Tue Oct 4 06:52:48 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08000129855 for ; Tue, 4 Oct 2016 06:52: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 hpZNyTSC-w3M for ; Tue, 4 Oct 2016 06:52:39 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 E9F2C129874 for ; Tue, 4 Oct 2016 06:52:38 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id b201so146617513wmb.0 for ; Tue, 04 Oct 2016 06:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=z6HxLWV17NwMRQc8rvOH9+dLdLDwE2yiXd0ZgiA1waY=; b=Hbe7PkqRzcWj/vJH7SadLhemByx/VmbsbP1wZ3d2B/Vn1Q9qMOd2q6lq4LjU8uZUdR bJw9GmOB2V7cSmtCTysa0BFk/owpXlfgen5TyxvY5zKA/hA69/wNoVsKLc+Qd6sIOafj DdV3sG0v7T7WccTPK8J1a09uIVvRqapPaGfeHtbnUiQeDtKv2nHGUYy76ttzaTLVLIuf IsATB0KqNiuEjh6TcX+hP3rWKs3/6OAB3fmv/hvg+fSwnuRGLZ8ABal18h/uWzGe5B1G I50G7ZwwslSlBejLYWeABYA6A4yJHIxdJflEL11LC4XqfQxfXw/oz4ZmknS+U12qFrbZ qQ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=z6HxLWV17NwMRQc8rvOH9+dLdLDwE2yiXd0ZgiA1waY=; b=ggthC/fss2aWlX59JHpbih27NHfKz3v0AfnEl2+P8tWQtuGi5SnvkXOEkRD7i9mOoP 0IRFEhLC5ZdsyeaoWTbFXgp61QyTDdeNY7HtFVsJUPSJHbg5BvT/5mIdfLjm7r7IdSal ITElkU8gGbyIY+/wAPBfeKDwTDkTxv3KLQymeAbCYkLJwW/WN032L72PXLnID6yoL1xt BqflzprzveFI7evdahtXGCiJidtzV+jymPZ2elv5ViPPz/vWS1GAeEVkoh9nBLMj1Lox 8MLexJ8TqM77g+YHYGM3AH94THWaFpRbw/xA8pKVOud2jtDgxbTI89MfLvQbyCEobz8W 294A== X-Gm-Message-State: AA6/9RkIys/LYhB5N1+h56P6+0eI2Y7e+Ex4jYQGBTwsyqQLBLKw4mwbhOzVhJPuRD6qgQ== X-Received: by 10.28.137.18 with SMTP id l18mr3799883wmd.70.1475589157406; Tue, 04 Oct 2016 06:52:37 -0700 (PDT) Received: from ?IPv6:2001:62a:4:41c:4014:d08:a8ca:2206? ([2001:62a:4:41c:4014:d08:a8ca:2206]) by smtp.googlemail.com with ESMTPSA id ya1sm3702064wjb.23.2016.10.04.06.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 06:52:36 -0700 (PDT) To: Christer Holmberg References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> From: Thomas Stach Message-ID: <462a1d25-125e-bac3-d2ac-5db5d28547f0@gmail.com> Date: Tue, 4 Oct 2016 15:52:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F80AEF975F582C762CB58825" Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , "ice@ietf.org" Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:52:48 -0000 This is a multi-part message in MIME format. --------------F80AEF975F582C762CB58825 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Christer, the cited text is from draft-ietf-mmusic-trickle-ice-sip-05, which is handled in MMUSIC. Would it be more appropriate to restate your questions there? Regards Thomas On 2016-10-04 15:29, Christer Holmberg wrote: > Hi, > > >isn't that implied when draft-ice-trickle does not mention removal of > candidates and Peter's draft proposes that as an extension? > > The text in section 4.2 says: > "In every INFO request agents MUST include all local candidates they > have signaled previously. This is necessary in order to more easily > avoid problems that would arise from unreliable transports. Mis- > ordering can be detected through the CSeq: header field in the INFO > request. As a consequence candidates cannot be removed unless an ICE > restart is performed. Note that extension might be specified in the > future that enable such removal without a restart.” > Q1: Assuming someone does define an extension which allows removal of > candidates without a restart, do such candidates still have to be > included in the INFO, as they have been “previously signalled"? What > is the scope of “previously”? Previously since when? > > Q2: What if an INFO does NOT contain a local candidate that has > previously been signaled? Do we assume it has been removed using some > “extension”? Do we assume it’s still there? > > Q3: What if a candidate has bee removed using some “extension”, and > then it still shows up in an INFO? Does it mean it’s automatically > added back? > > At one point I suggested that the INFO should ONLY contain the added > candidates, and would say nothing about existing candidates. But, as > that was not accepted I think Q1-Q3 needs to be clarified in the document. > > Thanks! > > Regards, > > Christer > > > > > On 2016-10-04 14:14, Christer Holmberg wrote: >> Hi, >> >> My issue was not whether removing of candidates is documented in >> trickle or not, but whether trickle assumes that candidates will not >> be removed. >> >> Regards, >> >> Christer >> >> From: Thomas Stach > > >> Date: Tuesday 4 October 2016 at 15:12 >> To: "pthatcher@google.com " >> >, Bernard Aboba >> > >> Cc: "mmusic-chairs@tools.ietf.org >> " > >, Christer Holmberg >> > >, "ice@ietf.org >> " > >> Subject: Re: [Ice] Do we currently need functionality for removing >> candidates? >> >> Peter, >> >> thanks! >> >> That confirms my impression and looks like a good plan for finishing >> the ICE documents. >> >> Regards >> >> Thomas >> >> >> On 2016-10-04 06:57, Peter Thatcher wrote: >>> I proposed candidate removal as an extension to ICE in Berlin: >>> >>> https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 >>> >>> >>> But I believe that trickle ICE documents (in both ICE and MMUSIC >>> WGs) can be published without it and it can be published later as an >>> extension, if the ICE WG chooses to adopt it. >>> >>> >>> On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba >>> > wrote: >>> >>> I believe that removing candidates is very useful. Let me give >>> an example. With TURN mobility, it is possible to retain pairs >>> involving TURN candidates across interface changes. So if you >>> leave a building and WLAN host candidates become unavailable, if >>> you have cellular connectivity you can use TURN mobility to keep >>> media flowing while looking for a better candidate pair. To >>> avoid loss of consent that would invalidate Pairs involving the >>> WLAN candidates, it is desirable to remove (and perhaps later, >>> renominate) the WLAN host and srvflx candidates. >>> >>> The package of TURN mobility, removal, renomination and aspects >>> of passive-aggressive nomination therefore enables efficient and >>> effective ICE mobility. >>> >>> Code is available for inspection in ORTC Lib (http://ortclib.org/) >>> >>> On Sep 23, 2016, at 1:47 PM, Thomas Stach >>> > wrote: >>> >>>> All, >>>> >>>> in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in >>>> MMUSIC a question came up, if we need functionality for >>>> removing candidates. >>>> >>>> >From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of >>>> corresponding text in draft-ietf-ice-trickle-04, I have the >>>> impression that this is currently not in scope of the Trickle >>>> ICE work. >>>> >>>> Could anybody confirm that this impression is correct? >>>> >>>> If yes, we would be about ready for WGLC of >>>> draft-ietf-mmusic-trickle-ice-sip. >>>> >>>> >>>> Regards >>>> >>>> Thomas >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >>> >> > --------------F80AEF975F582C762CB58825 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Christer,

the cited text is from draft-ietf-mmusic-trickle-ice-sip-05, which is handled in MMUSIC.

Would it be more appropriate to restate your questions there?

Regards

Thomas


On 2016-10-04 15:29, Christer Holmberg wrote:
Hi,

>isn't that implied when draft-ice-trickle does not mention removal of candidates and Peter's draft proposes that as an extension?

The text in section 4.2 says:
   "In every INFO request agents MUST include all local candidates they
   have signaled previously.  This is necessary in order to more easily
   avoid problems that would arise from unreliable transports.  Mis-
   ordering can be detected through the CSeq: header field in the INFO
   request.  As a consequence candidates cannot be removed unless an ICE
   restart is performed.  Note that extension might be specified in the
   future that enable such removal without a restart.”
Q1: Assuming someone does define an extension which allows removal of candidates without a restart, do such candidates still have to be included in the INFO, as they have been “previously signalled"? What is the scope of “previously”? Previously since when?

Q2: What if an INFO does NOT contain a local candidate that has previously been signaled? Do we assume it has been removed using some “extension”? Do we assume it’s still there?

Q3: What if a candidate has bee removed using some “extension”, and then it still shows up in an INFO? Does it mean it’s automatically added back?

At one point I suggested that the INFO should ONLY contain the added candidates, and would say nothing about existing candidates. But, as that was not accepted I think Q1-Q3 needs to be clarified in the document.

Thanks!

Regards,

Christer




On 2016-10-04 14:14, Christer Holmberg wrote:
Hi,

My issue was not whether removing of candidates is documented in trickle or not, but whether trickle assumes that candidates will not be removed.

Regards,

Christer

From: Thomas Stach <thomass.stach@gmail.com>
Date: Tuesday 4 October 2016 at 15:12
To: "pthatcher@google.com" <pthatcher@google.com>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Do we currently need functionality for removing candidates?

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing the ICE documents.

Regards

Thomas


On 2016-10-04 06:57, Peter Thatcher wrote:
I proposed candidate removal as an extension to ICE in Berlin:

https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00


But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can be published without it and it can be published later as an extension, if the ICE WG chooses to adopt it.  
 


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I believe that removing candidates is very useful. Let me give an example. With TURN mobility, it is possible to retain pairs involving TURN candidates across interface changes. So if you leave a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mobility to keep media flowing while looking for a better candidate pair. To avoid loss of consent that would invalidate Pairs involving the WLAN candidates, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, renomination and aspects of passive-aggressive nomination therefore enables efficient and effective ICE mobility.

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

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

All,

in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a question came up, if we need functionality for removing candidates.

>From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in draft-ietf-ice-trickle-04, I have the impression that this is currently not in scope of the Trickle ICE work.

Could anybody confirm that this impression is correct?

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-sip.


Regards

Thomas



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

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

--------------F80AEF975F582C762CB58825-- From nobody Tue Oct 4 06:56:04 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 32A5112987A for ; Tue, 4 Oct 2016 06:56:02 -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 Sjip509umkML for ; Tue, 4 Oct 2016 06:55:58 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8116A129879 for ; Tue, 4 Oct 2016 06:55:57 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-6e-57f3b4ebf286 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id DB.2E.02551.BE4B3F75; Tue, 4 Oct 2016 15:55:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 15:55:54 +0200 From: Christer Holmberg To: Thomas Stach Thread-Topic: [Ice] Do we currently need functionality for removing candidates? Thread-Index: AQHSFZiYH/AZ2evYmE2PnZwiDXMDqqCHjbSAgBAdHoCAAHmvgIAANIYA///bgwCAADmCAP//0lqAgAA09YA= Date: Tue, 4 Oct 2016 13:55:54 +0000 Message-ID: References: <20C420C9-D91E-425C-9AF7-DFE20CD8D716@gmail.com> <80f037fb-0297-1a2b-511f-037410a6c3eb@gmail.com> <462a1d25-125e-bac3-d2ac-5db5d28547f0@gmail.com> In-Reply-To: <462a1d25-125e-bac3-d2ac-5db5d28547f0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D419908610674christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2J7uO7rLZ/DDS6+tLD4dqHW4t/eJItP J7YyOTB77Jx1l91jyZKfTB5fLn9mC2CO4rJJSc3JLEst0rdL4Mr4vPw6a8GMCYwVW18vYWpg PFfdxcjJISFgInF3VwdzFyMXh5DAekaJHRf7mSCcRYwSrzYvAMpwcLAJWEh0/9MGaRAR0JL4 fWo2C4jNLJAksfPhY3YQW1ggQOLmvmmsEDWBEv83nWaBsJMk3m7tBYuzCKhIHPiwjw3E5hWw lvh7/DgjxK7NzBI9PZ8ZQRKcArYSJ0/NYgKxGQXEJL6fWsMEsUxc4taT+UwQVwtILNlznhnC FpV4+fgf2AJRAT2J719ng90sIaAosbxfDqI1QWLml7OsEHsFJU7OfMIygVF0FpKps5CUzUJS BhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMELa1xO87h1mR1Sxg5FjFKFqcWlycm25krJdalJlc XJyfp5eXWrKJERiZB7f81t3BuPq14yFGAQ5GJR7ehJRP4UKsiWXFlbmHGCU4mJVEeLM3fA4X 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgTHWJMTLZ/b9 7uvvgpMedzHKK33vPd9jcjjm3x+H6V/Y+a+uObPy3UZ/nqVdqueFj63a5XR8xTdTGc0tFiYi c5/usv68R/X5DZ74hi3Ldro2fDLcOemb/LWoLmkPjQdfrky8bKr5alOrkhCLnnp3mudCA9nP TeGTavYq1k/d8mTHjMeezy25JlQrsRRnJBpqMRcVJwIAsWf40cgCAAA= Archived-At: Cc: "mmusic-chairs@tools.ietf.org" , "ice@ietf.org" Subject: Re: [Ice] Do we currently need functionality for removing candidates? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:56:03 -0000 --_000_D419908610674christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My apologies. My main issues were with that document :) As far as I remember I don=92t have any removal-of-candidate issues with th= e base document, but I=92ll double check. Regards, Christer From: Thomas Stach = > Date: Tuesday 4 October 2016 at 16:52 To: Christer Holmberg > Cc: "mmusic-chairs@tools.ietf.org" >, "ice@ietf= .org" > Subject: Re: [Ice] Do we currently need functionality for removing candidat= es? Christer, the cited text is from draft-ietf-mmusic-trickle-ice-sip-05, which is handl= ed in MMUSIC. Would it be more appropriate to restate your questions there? Regards Thomas On 2016-10-04 15:29, Christer Holmberg wrote: Hi, >isn't that implied when draft-ice-trickle does not mention removal of cand= idates and Peter's draft proposes that as an extension? The text in section 4.2 says: "In every INFO request agents MUST include all local candidates they have signaled previously. This is necessary in order to more easily avoid problems that would arise from unreliable transports. Mis- ordering can be detected through the CSeq: header field in the INFO request. As a consequence candidates cannot be removed unless an ICE restart is performed. Note that extension might be specified in the future that enable such removal without a restart.=94 Q1: Assuming someone does define an extension which allows removal of candi= dates without a restart, do such candidates still have to be included in th= e INFO, as they have been =93previously signalled"? What is the scope of = =93previously=94? Previously since when? Q2: What if an INFO does NOT contain a local candidate that has previously = been signaled? Do we assume it has been removed using some =93extension=94?= Do we assume it=92s still there? Q3: What if a candidate has bee removed using some =93extension=94, and the= n it still shows up in an INFO? Does it mean it=92s automatically added bac= k? At one point I suggested that the INFO should ONLY contain the added candid= ates, and would say nothing about existing candidates. But, as that was not= accepted I think Q1-Q3 needs to be clarified in the document. Thanks! Regards, Christer On 2016-10-04 14:14, Christer Holmberg wrote: Hi, My issue was not whether removing of candidates is documented in trickle or= not, but whether trickle assumes that candidates will not be removed. Regards, Christer From: Thomas Stach = > Date: Tuesday 4 October 2016 at 15:12 To: "pthatcher@google.com" >, Bernard Aboba > Cc: "mmusic-chairs@tools.ietf.org" >, Christer = Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Do we currently need functionality for removing candidat= es? Peter, thanks! That confirms my impression and looks like a good plan for finishing the IC= E documents. Regards Thomas On 2016-10-04 06:57, Peter Thatcher wrote: I proposed candidate removal as an extension to ICE in Berlin: https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00 But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can b= e published without it and it can be published later as an extension, if th= e ICE WG chooses to adopt it. On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba > wrote: I believe that removing candidates is very useful. Let me give an example. = With TURN mobility, it is possible to retain pairs involving TURN candidate= s across interface changes. So if you leave a building and WLAN host candid= ates become unavailable, if you have cellular connectivity you can use TURN= mobility to keep media flowing while looking for a better candidate pair. = To avoid loss of consent that would invalidate Pairs involving the WLAN can= didates, it is desirable to remove (and perhaps later, renominate) the WLAN= host and srvflx candidates. The package of TURN mobility, removal, renomination and aspects of passive-= aggressive nomination therefore enables efficient and effective ICE mobilit= y. Code is available for inspection in ORTC Lib (http://ortclib.org/) On Sep 23, 2016, at 1:47 PM, Thomas Stach > wrote: All, in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a qu= estion came up, if we need functionality for removing candidates. >From list discussion in ICE, the minutes of the Berlin IETF and due to the= lack of corresponding text in draft-ietf-ice-trickle-04, I have the impres= sion that this is currently not in scope of the Trickle ICE work. Could anybody confirm that this impression is correct? If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-s= ip. Regards Thomas _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D419908610674christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
My apologies. My main issues were with that document :)

As far as I remember I don=92t have any removal-of-candidate issues wi= th the base document, but I=92ll double check.

Regards,

Christer

From: Thomas Stach <thomass.stach@gmail.com>
Date: Tuesday 4 October 2016 at 16:= 52
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org&g= t;, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Do we currently = need functionality for removing candidates?

Christer,

the cited text is from draft-ietf-mmusic-trickle-ice-sip-05= , which is handled in MMUSIC.

Would it be more appropriate to restate your questions there?

Regards

Thomas


On 2016-10-04 15:29, Christer Holmberg wrote= :
Hi,

>isn't that implied when draft-ice-trickle does not mention removal= of candidates and Peter's draft proposes that as an extension?

The text in section 4.2 says:
   "In every INFO request age=
nts MUST include all local candidates they
   have signaled previously.  This is necessary in order to more easily
   avoid problems that would arise from unreliable transports.  Mis-
   ordering can be detected through the CSeq: header field in the INFO
   request.  As a consequence candidates cannot be removed unless an ICE
   restart is performed.  Note that extension might be specified in the
   future that enable such removal without a restart.=94
Q1: Assuming someone does define an extension which allows removal of = candidates without a restart, do such candidates still have to be included = in the INFO, as they have been =93previously signalled"? What is the s= cope of =93previously=94? Previously since when?

Q2: What if an INFO does NOT= contain a local candidate that has previously been signaled? Do we assume = it has been removed using some =93extension=94? Do we assume it=92s still t= here?

Q3: What if a candidate has bee removed using some =93extension=94, an= d then it still shows up in an INFO? Does it mean it=92s automatically adde= d back?

At one point I suggested that the INFO should ONLY contain the added candidates, and would say nothing about = existing candidates. But, as that was not accepted I think Q1-Q3 needs to b= e clarified in the document.

Thanks!

Regards,

Christer




On 2016-10-04 14:14, Christer Holmberg wrote= :
Hi,

My issue was not whether removing of candidates is documented in trick= le or not, but whether trickle assumes that candidates will not be removed.=

Regards,

Christer

From: Thomas Stach <thomass.stach@gmail= .com>
Date: Tuesday 4 October 2016 at 15:= 12
To: "pthatcher@google.com" <= pthatcher@= google.com>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: "mmusic-chairs@tools.ietf.or= g" <mmusic-chairs@tools.ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Do we currently = need functionality for removing candidates?

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing= the ICE documents.

Regards

Thomas


On 2016-10-04 06:57, Peter Thatcher wrote:
I proposed candidate removal as an extension to ICE in Berlin:

https://tools.ietf.org/html/draft-thatcher-ice-rem= ove-candidate-00


But = I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can be pu= blished without it and it can be published later as an extension, if the IC= E WG chooses to adopt it.  
 


On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.aboba@gmail.com> wrote:
I believe that removing candidates is very= useful. Let me give an example. With TURN mobility, it is possible to reta= in pairs involving TURN candidates across interface changes. So if you leav= e a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mob= ility to keep media flowing while looking for a better candidate pair. To a= void loss of consent that would invalidate Pairs involving the WLAN candida= tes, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, ren= omination and aspects of passive-aggressive nomination therefore enables ef= ficient and effective ICE mobility.

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

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

All,

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

>From list discussion in ICE, the minutes of the Berlin IETF and d= ue to the lack of corresponding text in draft-ietf-ice-trickle-04, I have t= he impression that this is currently not in scope of the Trickle ICE work.<= /span>

Could anybody confirm that this impression is correct?

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle= -ice-sip.


Regards

Thomas



_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice<= /a>

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





 --_000_D419908610674christerholmbergericssoncom_-- From nobody Tue Oct 4 10:51:03 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 D0A0F1293FD; Tue, 4 Oct 2016 10:50:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147560345982.12839.18219985234948090442.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2016 10:50:59 -0700 Archived-At: Cc: ice-chairs@ietf.org, ari.keranen@ericsson.com, draft-ietf-ice-dualstack-fairness@ietf.org, ice@ietf.org Subject: [Ice] Alissa Cooper's No Objection on draft-ietf-ice-dualstack-fairness-05: (with COMMENT) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 17:51:00 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ice-dualstack-fairness-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Previous COMMENT: = Section 3 = "If the agent has access to information about the physical network it is connected to (Like SSID in a WiFi Network) this can be used as information regarding how that network interface should be prioritized at this point in time." I think this needs further elaboration, as it's not obvious how knowledge of the SSID correlates to knowledge of the stability of the network. "Candidates from an interface known to the application to provide unreliable connectivity should get a low candidate priority. This ensures they appear near the end of the candidate list, and would be the last to be tested during the connectivity check phase. This allows candidate pairs more likely to succeed to be tested first." All three of these sentences say more or less the same thing, so two of them could be dropped. = Section 8 = Doesn't following the recommendations in Section 3 potentially leak information to a remote peer about the quality of a local peer's connectivity on different interfaces? That is, if the remote peer maintains some state about past ICE interactions, would it be able to detect a change of priority that could indicate a change in connectivity quality? If so, this seems worth mentioning. From nobody Wed Oct 5 06:44:22 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 57177129705 for ; Wed, 5 Oct 2016 06:44:21 -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 wf3uQlaOC2oV for ; Wed, 5 Oct 2016 06:44:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40305129718 for ; Wed, 5 Oct 2016 06:44:19 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-b8-57f503b108b6 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 07.F9.02458.1B305F75; Wed, 5 Oct 2016 15:44:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 15:43:31 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Comments on draft-ietf-ice-trickle-04 Thread-Index: AQHSHw51n+601b7MjEmvuTEweizdcg== Date: Wed, 5 Oct 2016 13:43:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1CB6CC5FC821374391DA92EA5F120887@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7h+5G5q/hBjePqFp8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MXdOkC07KV6zruMTSwDhFoouRk0NCwETi78v5bF2MXBxCAusZ JXbf+8sM4SxilPi48j1QhoODTcBCovufNkiDiICixMyWZ8wgtrCAnsSZybOYIOLGEvf62pkh bD2JUzffsoDYLAIqEjue7QIbwytgLXFydQxImFFATOL7qTVgrcwC4hK3nsxngrhHQGLJnvPM ELaoxMvH/1hBbFGgkd+/zoaKK0q0P21ghOg1kHh/bj4zhG0tsflwCwuErS2xbOFrsDivgKDE yZlPWCYwisxCsm4WkvZZSNpnIWmfhaR9ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzA aDi45bfVDsaDzx0PMQpwMCrx8D7Y+jlciDWxrLgy9xCjBAezkgjvbKav4UK8KYmVValF+fFF pTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwboqc8/bo2+tBYpN23olacPF7 xWuz56+qz/OUyDw7d0LRdKbR3/erHSKNplbGzJvJ2vFzUU+InMdF9uczJs49Mi3kdbnJyyUm obXbkl8U1/F7RhT9atrfffjnYgk9xmLrDd1ZO24WWLrxZqxYLyMycUfzkkf7Tj7V8Ndy1H7y conaj1vGVTZFk5RYijMSDbWYi4oTAb51SviCAgAA Archived-At: Subject: [Ice] Comments on draft-ietf-ice-trickle-04 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, 05 Oct 2016 13:44:21 -0000 Hi, I took a look at draft-trickle-ice. In general, I think the document could use some editorial clean ups. However, I will only comments on the parts which I think are essential to correct: Q1: In general, you should use common terminology, e.g, when referring to the ICE spec. Sometimes you say =B3Vanilla ICE specifies=B2, sometimes "The ICE specification [rfc5245bis] specifies=B2, etc. Q2: In section 2, the definition of Trickled Candidate says: "Candidates that a Trickle ICE agent sends after an offer or answer but within the same context.=B2 1) What is the scope of =B3context=B2? Q3:=20 In section 2, the definition of Half Trickle says: "The mechanism is mostly meant for use in cases where support for Trickle ICE cannot be confirmed prior to sending an initial offer.=B2 1) I guess it should be support for Trickle ICE by the answerer. 2) Does this mean one MUST use half trickle in cases where the support is not known? Q4: Section 2 talks about =B3first generation of candidates=B2. It is unclear w= hat is meant by =B3first generation=B2. Q5: In section 3, why do we talk about SDP, and we do we use RFC 2119 terminology for SDP endpoints? That belongs to the ice-sip-sdp draft. Q6: In section 5, the text says: "If this is not the case, the agent MUST process the offer according to Vanilla ICE procedures [rfc5245bis] or offer/answer processing rules [RFC3264] if no ICE support is detected at all.=B2 1) Why do you now suddenly reference RFC 3264 for offer/answer, and even mandate agents to use it? In the introduction you said that =B3offer/answer= =B2 does NOT mean RFC 3364 within the scope of this document. Q7: In section 5.2, the text says: "With regard to pruning of duplicate candidate pairs, a Trickle ICE agent SHOULD follow a policy of "first one wins" and not re-apply the pruning procedure if a higher-priority candidate pair is received from the remote agent.=B2 1) Is there a specific reason for not =B3re-pruning=B2? Q8: In section 8, the text says: "After an offer or an answer has been sent, agents will most likely continue discovering new local candidates=8A=B2 1) I assume it should say =B3Trickle ICE agents will most likely=8A=B2 Q9: In section 8, the text says: "The new candidate is then checked for redundancy against the existing list of local candidates. If its transport address and base match those of an existing candidate,=8A=B2 1) In order to align with the 5245bis terminology, I assume =B3transport address=B2 and =B3base=B2 should be in uppercase? Q10: In section 8, the text says: "When trickle updates are sent, each candidate MUST be delivered to the receiving Trickle ICE implementation not more than once and in the same order that they were sent.=B2 1) It=B9s difficult for me to parse this, especially the =B3same order=B2 p= art. I think you should simply say that the signalling protocol must ensure that re-transmitted candidates are not treated as two separate candidates. Q11: In section 8, the text says: "Also, candidate trickling needs to be correlated to a specific ICE negotiation session,=B2 1) What is an =B3ICE negotiation session=B2? Q12: In section 9, the text says: "At any time during ICE processing, a Trickle ICE agent may receive new candidates from the remote agent. When this happens and no local candidates are currently known for this same stream,=B2 1) What is meant by =B3this same stream=B2? I assume you refer to the strea= m with which the candidate is associated. If so, please make it more clear. Q13: In section 13, you again reference to the rules in RFC 3264 regarding when an offer or answer can be sent. Q14: In section 13, I assume the second bullet also apply to ICE restart. If so, please make it clear. Regards, Christer From nobody Fri Oct 7 21:19:18 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADDD129435 for ; Fri, 7 Oct 2016 21:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWm2dOocyFtA for ; Fri, 7 Oct 2016 21:19:13 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 8D0F4128E18 for ; Fri, 7 Oct 2016 21:19:13 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id rz1so30295029pab.1 for ; Fri, 07 Oct 2016 21:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IQFDXHx9VLSF8HCTU3Iop278rAkWmUrHwm0h5Vn3KEY=; b=DQXkb0wARUJtAS+fHxtN6v60SHaajGilWzyMWUTFgvpK5UpOTGXxQdvOnh86DqkSHt 6dUVczkzYbH5KcjVDe4IQEMQcFf+lC3KGm1ZKujVg6ZumFpWrdAF5kR5l+vOtcM3uky+ ZCR9peHOwdAvENRcGftATvcicYyut9u4jVa1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IQFDXHx9VLSF8HCTU3Iop278rAkWmUrHwm0h5Vn3KEY=; b=IEqVrskYfTuoFOiPe05RVNT6YnxzJwjM7FmuxzoE6mQDUdUTnM+9uRmog9vv4NH2RR TZeYPO4D9RlvOFq1uE0BezPXzEb5y1pZy/6lzrk/gVwDdpAnJjXqI7fSC5IlxYpq3140 GzPzKduRovi/OrT/Opue2AE9wdrGKzOiYdmJSoGO0M2d0hs+eIPicsCOKbu16CqKuXo1 15XdVX7LQ4YC4oO3HNAq1a3RsJN8xowo70ETmYq+KXUutKFQKcCxVOYO1uvKguiXEucS WqPoyhOlGrOKT3+HN6VOa5ImExVGV3Za7ta8NxU1tQroZO9oeb8z6K0RrppLqiFCl8Ha ZIRw== X-Gm-Message-State: AA6/9Rn1aGveYn/LbjCeJDL+y9+MluSpknHJiLP19PaB+wNruvZIYmbfbbfZklLR0uE6FwOj X-Received: by 10.66.162.8 with SMTP id xw8mr36259901pab.174.1475900353080; Fri, 07 Oct 2016 21:19:13 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:1489:ff01:3cc7:77ed? ([2601:647:4601:ec84:1489:ff01:3cc7:77ed]) by smtp.gmail.com with ESMTPSA id ad15sm34535822pac.33.2016.10.07.21.19.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 21:19:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Nils Ohlmeier In-Reply-To: Date: Fri, 7 Oct 2016 21:19:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 04:19:16 -0000 Hi Christer, Thanks for your reply. I don=E2=80=99t think that there is any pruning = happening when you discover peer reflexive candidates (you are suppose = to check for an existing equal pair, not sure if you consider that as = pruning at that step). But the repeated reading of the sections about discovering peer = reflexive candidates made me actually realize that we have a not = standard compliant implementation and therefore my whole scenario is = void if your implementation adheres to either version of the standard. = So please dis-regard my concerns. The only bit left is that if it took me that many readings to understand = the difference between the check list and the valid list we might be = interested in making the wording in that sections a little bit stronger = or more clear to prevent other readers from wasting more time on this = like I did. Best regards Nils Ohlmeier > On Oct 4, 2016, at 02:58, Christer Holmberg = wrote: >=20 > Hi Nils, >=20 > Sorry for the late reply. >=20 > If I understand the issue correctly, this could only happen with = trickle. > Because, in normal cases pruning would take care of it. >=20 > Or? >=20 > Regards, >=20 > Christer >=20 > On 20/09/16 06:46, "Ice on behalf of Nils Ohlmeier" = on behalf of nohlmeier@mozilla.com> wrote: >=20 >> After reading up on how the current Trickle ICE draft proposes to = handle >> peer reflexive candidates it appears to me that my scenario below is >> relevant for ICE 5245bis if there is no STUN server. >> And if there is a STUN server then it should only happen if B has >> trickled his public host candidate to A already. And A receives its >> binding response from B before it discovers his own server reflexive = by >> receiving a binding response from the STUN server. >>=20 >> Even if we don=C2=B9t bother do try to optimize the useless/redundant = trigger >> check away I think we should: >> - include peer reflexive candidates into the paragraph of 5245 which >> talks about trigger checks >> - extend the paragraph in the trickle draft to not only mention >> discovering peer reflexive candidates via STUN binding request, but = also >> from binding responses. >>=20 >> I would appreciate some feedback on this before trying to propose >> improved wording for both specs. >>=20 >> Best >> Nils Ohlmeier >>=20 >>> On Sep 2, 2016, at 13:34, Nils Ohlmeier = wrote: >>>=20 >>> Hello, >>>=20 >>> I have identified something which I would be interested to hear the >>> opinions of the ICE experts about. >>>=20 >>> In RFC 5245 (section 7.2.1.4) and also in bis-04 (section 6.1.3.1.4) >>> claim the following regarding receiving triggered checks: >>> The local candidate will either be a host candidate (...) or a >>> relayed candidate (=C5=A0). The local candidate can never be a = server >>> reflexive candidate. >>>=20 >>> Which I think is missing the case where the local candidate can also = a >>> be a peer reflexive. And this is actually causing unnecessary extra >>> checks to be made. >>>=20 >>> Consider the following scenario: >>>=20 >>> - A sits behind symmetric NAT >>> - B is on a publicly routable address with no NAT or firewall >>> - No STUN servers (just makes the scenario less complex) >>> - Host candidates get exchanged and candidate pairs A:B and B:A get >>> created on both sides >>> - A sends binding request to B >>> - B receives binding request with transport address A=C2=B9 >>> - B creates a peer reflexive candidate for A=C2=B9 and the a new = pair B:A=C2=B9 >>> and puts that new pair into its trigger check queue >>> - B sends binding response to A=C2=B9 >>> - A receives binding response, learns about A=C2=B9 and creates = A=C2=B9:B and >>> marks it as successful >>> - Now B sends a binding request for it trigger check queue entry to = A=C2=B9 >>> - When A receives this binding request is has no way to match this = to >>> the successful pair A=C2=B9:B >>> - Because of the wording in the above mentioned sections it will = match >>> the request to the pair A:B >>> - Which then in turn causes another triggered check to be created >>> because A:B is not in the success state >>>=20 >>> This additional triggered check from A is just waste of time and >>> resources. It does not hurt. But I=C2=B9m wondering how this could = be avoided. >>>=20 >>> If people agree I think section 6.1.3.1.4 should at least mention = the >>> scenario that incoming binding requests can also match a peer = reflexive >>> candidate. >>>=20 >>> As the incoming binding request does not contain the destination >>> address it got send to there is obviously no way for A to clearly >>> distinguish if the request got send to A or A=C2=B9. >>>=20 >>> For avoiding the additional triggered check on A=C2=B9s side the = only >>> solution I see right now is to go through the pairs which have A as >>> their foundation and if that list contains a pair which is marked as >>> successful already assume no triggered check is needed. So far I = have >>> not been able to identify a scenario where it hurts to skip this = extra >>> round of triggered checks on A=C2=B9s side. >>>=20 >>> Best >>> Nils Ohlmeier >>>=20 >>=20 >=20 From nobody Mon Oct 10 20:11:26 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 0784E129430 for ; Mon, 10 Oct 2016 20:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, 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 Dla68N67ic0j for ; Mon, 10 Oct 2016 20:11:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 36034128B37 for ; Mon, 10 Oct 2016 20:11:23 -0700 (PDT) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0489740325; Mon, 10 Oct 2016 21:14:00 -0600 (MDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <4243ec31-584a-9724-3d43-8f86357e684a@stpeter.im> Date: Mon, 10 Oct 2016 21:11:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 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, 11 Oct 2016 03:11:25 -0000 Thanks for the review. Comments inline. On 10/5/16 7:43 AM, Christer Holmberg wrote: > Hi, > > I took a look at draft-trickle-ice. > > In general, I think the document could use some editorial clean ups. > However, I will only comments on the parts which I think are essential to > correct: > > > Q1: > > In general, you should use common terminology, e.g, when referring to the > ICE spec. Sometimes you say ³Vanilla ICE specifies², sometimes "The ICE > specification [rfc5245bis] specifies², etc. In general I feel that the term "Vanilla ICE" is cute but not all that helpful. We could say "ICE core" instead. (BTW, as far as I can see, there is no instance of "Vanilla ICE specifies" in this document and all references are to the actual specification.) > Q2: > > In section 2, the definition of Trickled Candidate says: > > "Candidates that a Trickle ICE agent sends after > an offer or answer but within the same context.² > > 1) What is the scope of ³context²? Perhaps "session" or even "ICE negotiation session" would be clearer. > Q3: > > In section 2, the definition of Half Trickle says: > > "The mechanism is mostly meant for use in cases where > support for Trickle ICE cannot be confirmed prior to sending an > initial offer.² > > 1) I guess it should be support for Trickle ICE by the answerer. Yes, that's better. > 2) Does this mean one MUST use half trickle in cases where the support is > not known? That is discussed in section 14. I see no reason to use MUST here or even SHOULD - it's up to the implementation. > Q4: > > Section 2 talks about ³first generation of candidates². It is unclear what > is meant by ³first generation². I suggest "set" instead of "generation". We can also clarify that this is the set of candidates that is sent with the initial offer. > Q5: > > In section 3, why do we talk about SDP, and we do we use RFC 2119 > terminology for SDP endpoints? That belongs to the ice-sip-sdp draft. Yes, that paragraph belongs in draft-ietf-mmusic-trickle-ice-sip. > Q6: > > In section 5, the text says: > > > "If this is not the case, the agent MUST process the offer > according to Vanilla ICE procedures [rfc5245bis] or offer/answer > processing rules [RFC3264] if no ICE support is detected at all.² > > > 1) Why do you now suddenly reference RFC 3264 for offer/answer, and even > mandate agents to use it? In the introduction you said that ³offer/answer² > does NOT mean RFC 3364 within the scope of this document. I suggest that we remove the clause "or offer/answer processing rules [RFC3264]". > Q7: > > In section 5.2, the text says: > > "With regard to pruning of duplicate candidate pairs, a Trickle ICE > agent SHOULD follow a policy of "first one wins" and not re-apply the > pruning procedure if a higher-priority candidate pair is received > from the remote agent.² > > > 1) Is there a specific reason for not ³re-pruning²? Hmm, it seems that this is perhaps not consistent with some text that we recently modified in section 8.1: ### Once this is done, the agent examines the check list looking for another pair that would be redundant with the new one. If such a pair exists and its type is not peer reflexive, the pair with the higher priority is kept and the one with the lower priority is discarded. If, on the other hand, the type of the pre-existing pair is peer reflexive, the agent MUST replace it with the new candidate it received (regardless of their respective priorities); this is done by setting the priority of the new candidate to the priority of the pre-existing candidate and then re-sorting the check list. Note: Replacing pre-existing pairs with seemingly equivalent higher-priority ones helps guarantee that both agents will have the same view of candidate priorities. This is particularly important during aggressive nomination, when priority is sometimes the only way a controlled agent can determine the selected pair. It is for that same reason that peer-reflexive candidates need to always be updated if equivalent alternatives are received through signaling. ### > Q8: > > In section 8, the text says: > > "After an offer or an answer has been sent, agents will most likely > continue discovering new local candidatesŠ² > > > 1) I assume it should say ³Trickle ICE agents will most likelyŠ² Correct. Will fix. > Q9: > > In section 8, the text says: > > "The new candidate is then checked for redundancy against the existing > list of local candidates. If its transport address and base match > those of an existing candidate,Š² > > > 1) In order to align with the 5245bis terminology, I assume ³transport > address² and ³base² should be in uppercase? 5245bis does not seem to be consistent in this regard, e.g.: We call the host candidate associated with a given server reflexive candidate the BASE. Note: "Base" refers to the address an agent sends from for a particular candidate. Thus, as a degenerate case host candidates also have a base, but it's the same as the host candidate. Most instances are lowercase, so I'd leave it as-is for now. > Q10: > > In section 8, the text says: > > "When trickle updates are sent, each candidate MUST be delivered to > the receiving Trickle ICE implementation not more than once and in > the same order that they were sent.² > > 1) It¹s difficult for me to parse this, especially the ³same order² part. > I think you should simply say that the signalling protocol must ensure > that re-transmitted candidates are not treated as two separate candidates. It strikes me as sensible to specify that: (a) the signalling protocol must provide in-order delivery (b) the Trickle ICE agent must not treat re-transmitted candidates as distinct candidates (i.e., it must effectively de-dupe candidates) (I'm not sure what it would mean for something like (b) to apply to the protocol, not the agent.) > Q11: > > In section 8, the text says: > > "Also, candidate trickling needs to be correlated to a specific ICE > negotiation session,² > > 1) What is an ³ICE negotiation session²? That should be defined. As I understand it, an ICE negotiation session consists of all the exchanges that occur before an ICE restart (if any) is sent. > Q12: > > In section 9, the text says: > > "At any time during ICE processing, a Trickle ICE agent may receive > new candidates from the remote agent. When this happens and no local > candidates are currently known for this same stream,² > > > 1) What is meant by ³this same stream²? I assume you refer to the stream > with which the candidate is associated. If so, please make it more clear. Will do. > Q13: > > In section 13, you again reference to the rules in RFC 3264 regarding when > an offer or answer can be sent. I think this is better phrase along the lines of "If a Trickle ICE agent supports offer/answer semantics [RFC3264], it MAY generate a subsequent offer at any time that is allowed by [RFC3264]." > Q14: > > In section 13, I assume the second bullet also apply to ICE restart. If > so, please make it clear. Correct. Thanks again for the review. Peter From nobody Sat Oct 15 22:21: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 1E3D612959C for ; Sat, 15 Oct 2016 22:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 bkmBVaDxZ_9A for ; Sat, 15 Oct 2016 22:21:09 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDB0129408 for ; Sat, 15 Oct 2016 22:21:09 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id f128so184795489qkb.1 for ; Sat, 15 Oct 2016 22:21:09 -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=YmFElNDtbnjJ+re1N8NVp/7WjuISeq9ittEyhtpU9OQ=; b=DFNHRLS4cQ7w6wYP8QVFree7Ru2+vQpt6AfoeuM4X1iKp7k9cIpN9WPZYN7/zCcU5l F4bXRXuh7LgR2fbcuzi2INtD+rOMetX3Tv7SEhDDVfYCBcqynArxhgw+5W7lSruRK0um Py4gvvjuG9OgFbROjqpDUFx++aBIW+499olzM0LJihczZdN5BnWfKZDNwlPYZ8nQKWlf hnLgajHaQ/29LPjJltT3tOp6RS+pSmmPmlfnLOskHla4E4M+JYPIP5RQp/GU5sHVigb9 pJR24m9BvbHem4lP9YDxglREvZlrVe8PXXZ+mHcooTCLCP1qbnNG8EQzY/VFf/KfvHd5 6gLw== 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=YmFElNDtbnjJ+re1N8NVp/7WjuISeq9ittEyhtpU9OQ=; b=FE6zmT/ua/xppOxSchvgOgVjlQNxBw4cxDdtqjcT6L+by7SPk6Tn48Gw9plxuDGY++ yTFoVdUItWQ5lukUNTQ0dSEkqnk3Ib24BamMeCc8jduBTBInBSuvrKEJlQqJzCNtsOg4 CphZRi3FU0L71Tl0XS33YhP8wVD+4jfeLy/EE3HhEqsqL8rG3aMdZba+Pm27vqgcX+m8 F740zH/CMyiAP9rzHb4ZS0FVtucrv50jWWhXayW3bgap1DXAVH4gFCElT6HdaeAikH5h rxpq755kovFHYjOYqdUkOl4mbe02j7z79Q4FzRS8I7rokEZ1AlPbbwp+nbFAgGZRDWTc bHSA== X-Gm-Message-State: AA6/9RkwkaAyqFHwyITI9kFHpDiPrN9Qo+Ue0aFxpEkm+wJp0SSd8N3hZbJXUwGHI7HWBNltotagL2gWGugMS7S4 X-Received: by 10.55.204.196 with SMTP id n65mr22086595qkl.200.1476595268273; Sat, 15 Oct 2016 22:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.122.130 with HTTP; Sat, 15 Oct 2016 22:20:27 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Sat, 15 Oct 2016 22:20:27 -0700 Message-ID: To: "Black, David" Content-Type: multipart/alternative; boundary=001a1149932871a98e053ef4a049 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 05:21:12 -0000 --001a1149932871a98e053ef4a049 Content-Type: text/plain; charset=UTF-8 Assuming ICE checks are around 100 octets (which they are, almost), then a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packets/sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the Ta value would end up being more strict. Does that mean the Ta value of 5ms is sufficiently strict to render the HTO/MaxPacket rules unnecessary? Could we just reduce the ruleset down to a min Ta value of 5ms? Or do you think those rules still have value? And as for the packet rate, previous to discussing with you "transport guys", there was a lot of discussion in the WG about packet rates, in particular rates of opening new NAT bindings with residential equipment. After a lot of discussion and experimenting in the the real world, we agreed that a lower bound of 5ms on the Ta was sufficient to cover packet rates and rates of opening NAT bindings. I can give more history on that if you'd like. But that still left a concern over bit rates, which is how we ended up talking to you :). On Wed, Sep 28, 2016 at 8:45 AM, Black, David wrote: > I'm apparently one of the "transport guys" referred to in the subject line > ;-). > > In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter > Thatcher > described the current proposal: > > ---------------------- > 1. A maximum number of outstanding request packets, call it MaxPackets > which SHOULD be 10. > > 2. A timeout for request packets, call it handshake timeout or HTO which > SHOULD be 2*RTT if the RTT is known and 500ms otherwise. > > 3. A global pacing rate of 5ms (like a global Ta). > > If all packets are dropped and the RTT is not known, then 1+2 are > effectively 20 packets per second, > well below what you would get with the bitrate limits we were asking for. > ---------------------- > > There's been some further discussion with the "transport guys" about > packet size and bit rate. In essence, the rationale for 10 as the maximum > number of outstanding request packets (item 1 above) is based on the > typical TCP segment size of about 1500 bytes. ICE request packets tend to > be much smaller, 100 bytes or less, which suggests that a factor of 15 > could be available if bit rate matters but packet count doesn't. That > may well be the case ... > > RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view > by recommending that AQM implementations count octets (i.e., forwarding > resources are bit-congestible) as opposed to counting packets (i.e., > forwarding resources are not packet-congestible). That RFC effectively > asserts that the current Internet is bit-congestible only: > https://tools.ietf.org/html/rfc7141 > > That would suggest a value of 150 for MaxPackets *when* all the packets > are 100 octets or less, as should be case for ICE request packets. A > possible area of concern (based on ICE use by Web RTC) is residential > gateway/NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient > to avoid overrunning them. > > What do people with more knowledge of and/or experience with residential > gateway boxes think of this line of reasoning? > > Thanks, --David > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a1149932871a98e053ef4a049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Assuming ICE checks are around 100 octets (which they a= re, almost), then a MaxPackets of 150 with a HTO of 500ms gives a maximum o= f about 300 packets/sec.=C2=A0 But a Ta of 5ms gives a maximum of 200 packe= ts/sec.=C2=A0 So the Ta value would end up being more strict.=C2=A0=C2=A0

Does that mean the Ta value of 5ms is sufficiently stri= ct to render the HTO/MaxPacket rules unnecessary?=C2=A0 Could we just reduc= e the ruleset down to a min Ta value of 5ms?=C2=A0 Or do you think those ru= les still have value?

And as for the packet rate, pre= vious to discussing with you "transport guys", there was a lot of= discussion in the WG about packet rates, in particular rates of opening ne= w NAT bindings with residential equipment.=C2=A0 After a lot of discussion = and experimenting in the the real world, we agreed that a lower bound of 5m= s on the Ta was sufficient to cover packet rates and rates of opening NAT b= indings.=C2=A0 I can give more history on that if you'd like. =C2=A0 = =C2=A0But that still left a concern over bit rates, which is how we ended u= p talking to you :).




<= /div>





On Wed, Sep 28, 2016 at 8:45 AM, Bl= ack, David <David.Black@dell.com> wrote:
I'm apparently one of the "tr= ansport guys" referred to in the subject line ;-).

In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
described the current proposal:

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

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

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

If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second,
well below what you would get with the bitrate limits we were asking for. ----------------------

There's been some further discussion with the "transport guys"= ; about packet size and bit rate.=C2=A0 =C2=A0In essence, the rationale for= 10 as the maximum number of outstanding request packets (item 1 above) is = based on the typical TCP segment size of about 1500 bytes.=C2=A0 ICE reques= t packets tend to be much smaller, 100 bytes or less, which suggests that a= factor of 15 could be available if bit rate matters but packet count doesn= 't.=C2=A0 =C2=A0 That may well be the case ...

RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).=C2=A0 That RFC effectively asserts= that the current Internet is bit-congestible only: https://tools= .ietf.org/html/rfc7141

That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.=C2=A0 A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoi= d overrunning them.

What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

Thanks, --David

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

--001a1149932871a98e053ef4a049-- From nobody Sun Oct 16 05:22: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 566511297CA for ; Sun, 16 Oct 2016 05:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=Hb0h8WwH; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ZCRtVnLy 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 UKIiBsnzOBVq for ; Sun, 16 Oct 2016 05:22:34 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322CD1295BB for ; Sun, 16 Oct 2016 05:22:34 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=m8CYIeUxOHj71/lBPQQ5PrjD5TnNPKUgMrvZvDnBcoYEuO+yAiIGpoGd BK2tLSQzRMSxnUMFrYJHIh6zMhcfvCFqzj+GhKWgbXdXWGSY53eeWK6CB 3JkBYg4ejVAAsaSaPuvGODY4ACJCWnNNRxuwNHjrCJ2FU1yQoKEeQ6rir Y=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1476620554; x=1508156554; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=aXsjedK41fnHo2LzlUWVoqlIxkoSacxA8ya/nNygICo=; b=Hb0h8WwHqlwxKSbbP4sXm57rto5O0rmHcNs9Xl7AadEF9hvMk4B8nleT T/OmMi83C2RdmaxJNubKhilScSG6iIJx80Xmoc3uK0JsuyiUUrWL7lF5t AEUPBFO/o9YF6qKRFoS/JmQXNI0Ol/N02pxavCnh5wPDLjejMEiU7Iq6u k=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2016 07:22:32 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2016 18:22:32 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9GCMVqt019586 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Oct 2016 08:22:31 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u9GCMVqt019586 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1476620551; bh=3O1v9jyvBwJE3GCGynXbFkqZ55k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ZCRtVnLyUiPHkUBGIg7vSLUFqMw1pfQL7pBT4XEjOxo5YiQRn07B8DSUzw3oCZAl3 slKRAcoAwC651BhCtJtqsQMdy8a6pQlL4bpc3JexRy4iqNUFxa56k4srnBvTNutFzz RQuI11OLh5g1jy/bc7QORZHqfqJ7+IKqCzTlC/A4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u9GCMVqt019586 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Sun, 16 Oct 2016 08:22:16 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9GCMGCv003863 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 16 Oct 2016 08:22:17 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0266.001; Sun, 16 Oct 2016 08:22:16 -0400 To: Peter Thatcher Thread-Topic: [Ice] Continue discussion of global pacing based on feedback from "transport guys" Thread-Index: AdIZn0w0rTSbKKnYS/edYVNC+EY2GgN7zvuAAAZZkB8= Date: Sun, 16 Oct 2016 12:22:15 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_uti7fsbpkibctgphffwxkle11476620532224emailandroidcom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 12:22:37 -0000 --_000_uti7fsbpkibctgphffwxkle11476620532224emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It looks like the Ta value suffices, and the prior discussion provides assu= rance that residential equipment won't be overrun ... but given the subtlet= y of the discussion that reached this result, I strongly recommend that we = show our work ;-). In other words, the draft should provide a complete ex= planation of our reasoning, as both the ICE packet size and the 500ms value= are specific to this discussion, making the conclusion *not* generally app= licable. Thanks, --David ++Sent from my Android not-so-smartphone ... -------- Original message -------- From: Peter Thatcher Date: 10/16/16 7:21 AM (GMT+01:00) To: "Black, David" Cc: ice@ietf.org Subject: Re: [Ice] Continue discussion of global pacing based on feedback f= rom "transport guys" Assuming ICE checks are around 100 octets (which they are, almost), then a = MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packets/= sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the Ta value = would end up being more strict. Does that mean the Ta value of 5ms is sufficiently strict to render the HTO= /MaxPacket rules unnecessary? Could we just reduce the ruleset down to a m= in Ta value of 5ms? Or do you think those rules still have value? And as for the packet rate, previous to discussing with you "transport guys= ", there was a lot of discussion in the WG about packet rates, in particula= r rates of opening new NAT bindings with residential equipment. After a lo= t of discussion and experimenting in the the real world, we agreed that a l= ower bound of 5ms on the Ta was sufficient to cover packet rates and rates = of opening NAT bindings. I can give more history on that if you'd like. = But that still left a concern over bit rates, which is how we ended up tal= king to you :). On Wed, Sep 28, 2016 at 8:45 AM, Black, David > wrote: I'm apparently one of the "transport guys" referred to in the subject line = ;-). In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter T= hatcher described the current proposal: ---------------------- 1. A maximum number of outstanding request packets, call it MaxPackets whi= ch SHOULD be 10. 2. A timeout for request packets, call it handshake timeout or HTO which S= HOULD be 2*RTT if the RTT is known and 500ms otherwise. 3. A global pacing rate of 5ms (like a global Ta). If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second, well below what you would get with the bitrate limits we were asking for. ---------------------- There's been some further discussion with the "transport guys" about packet= size and bit rate. In essence, the rationale for 10 as the maximum numbe= r of outstanding request packets (item 1 above) is based on the typical TCP= segment size of about 1500 bytes. ICE request packets tend to be much sma= ller, 100 bytes or less, which suggests that a factor of 15 could be availa= ble if bit rate matters but packet count doesn't. That may well be the c= ase ... RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible). That RFC effectively asserts that= the current Internet is bit-congestible only: https://tools.ietf.org/html/= rfc7141 That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets. A possible= area of concern (based on ICE use by Web RTC) is residential gateway/NAT b= oxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid ove= rrunning them. What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning? Thanks, --David _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_uti7fsbpkibctgphffwxkle11476620532224emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It looks like the Ta value suffices, and the prior discussion provides= assurance that residential equipment won't be overrun ... but given the su= btlety of the discussion that reached this result, I strongly recommend tha= t we show our work ;-).   In other words, the draft should provide a complete explanation of our reasoning, a= s both the ICE packet size and the 500ms value are specific to this discuss= ion, making the conclusion *not* generally applicable. 

Thanks, --David ++Sent = from my Android not-so-smartphone ...


-------- Original message --------
From: Peter Thatcher <pthatcher@google.com>
Date: 10/16/16 7:21 AM (GMT+01:00)
To: "Black, David" <david.black@emc.com>
Cc: ice@ietf.org
Subject: Re: [Ice] Continue discussion of global pacing based on feedb= ack from "transport guys"

Assuming ICE checks are around 100 octets (which they are, almost), then= a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packe= ts/sec.  But a Ta of 5ms gives a maximum of 200 packets/sec.  So the Ta value would end up being more strict.&= nbsp; 

Does that mean the Ta value of 5ms is sufficiently strict to render the = HTO/MaxPacket rules unnecessary?  Could we just reduce the ruleset dow= n to a min Ta value of 5ms?  Or do you think those rules still have value?

And as for the packet rate, previous to discussing with you "transp= ort guys", there was a lot of discussion in the WG about packet rates,= in particular rates of opening new NAT bindings with residential equipment.  After a lot of discussion and experiment= ing in the the real world, we agreed that a lower bound of 5ms on the Ta wa= s sufficient to cover packet rates and rates of opening NAT bindings. = I can give more history on that if you'd like.    But that still left a concern over bit rates, which is = how we ended up talking to you :).









On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@d= ell.com> wrote:
I'm apparently one of the "transport guys" referred to in the sub= ject line ;-).

In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
described the current proposal:

----------------------
1.  A maximum number of outstanding request packets, call it MaxPacket= s which SHOULD be 10.

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

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

If all packets are dropped and the RTT is not known, then 1+2 are effec= tively 20 packets per second,
well below what you would get with the bitrate limits we were asking for. ----------------------

There's been some further discussion with the "transport guys" ab= out packet size and bit rate.   In essence, the rationale for 10 = as the maximum number of outstanding request packets (item 1 above) is base= d on the typical TCP segment size of about 1500 bytes.  ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.    That may well be the case ...

RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).  That RFC effectively asserts that the current Internet is bit-congestible = only: https://tools.ietf.org/html/rfc7141

That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.  A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

Thanks, --David

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

--_000_uti7fsbpkibctgphffwxkle11476620532224emailandroidcom_-- From nobody Wed Oct 19 09:17:45 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D902912946D for ; Wed, 19 Oct 2016 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 yEIPnVvEhy7x for ; Wed, 19 Oct 2016 09:17:41 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215151295D2 for ; Wed, 19 Oct 2016 09:17:41 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f128so41996151qkb.1 for ; Wed, 19 Oct 2016 09:17:41 -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=vmWqqdGiveN1g5CkNQ69OWIGExVt4ao3/IXGWk6DVwM=; b=RHdToLB55Nd0a53V1+d/qa83hM9s2tSOB+FkQh4yWT56uQx2U2UBbQG/7GQrIL5wF2 QlL8OvJ0Ncsx2HaR9qJElME1TXLgWKsCwPBLAGAf2Vo9g0DaQrWaTWjvhnKB5qPZGZSS 0swPw8r5nc2+uXF35Y/II5TLZTaJDK71Q2M1yihI+ZeVzvaytNNcf+ihc7IXl43UcMii 3JSCca0+DIc/GLoBWUs62ca8fEbNoP+pE/5VNS1Mgui2L5fHgT2s+4VKj+fcsztDdWea BtiXfegbVRhxYGOp7XqmBajcsqd+yyPENhbrpkaNnvYOBLFIxDpBqN2QHuvu5cuAutFz 0EfQ== 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=vmWqqdGiveN1g5CkNQ69OWIGExVt4ao3/IXGWk6DVwM=; b=jnx4fcQZnpiyf0NVgUm4mwhQw0wPOj3VpsqMV0XKAWB6mcOk8citBNIiTkubZV+3zI GFN/x/hkBn8GMSzyky1Efg+nShrR8EU8++XdYSQc//oiw8FgB9CfxOa+NhYcAuIXVdID 05IfJ5ZcavoKvsggUZr/ZoskzjbAZisJ5/w1fFwYEeH4WJerM5UPFC0ky6B4YS4+xaJc pjIadhEaZmguRiRoHgYQN4NJJoKwkr6yKI6XZvExNn9gkTKR0R00oXzQ9y1hLPPzRAs8 z5XOnk3V4Ut8JjLXxH9Az46PMWutqTbmzE9yjTnpvGKt2FLaJzqG3PIPDqmXZKRok3KR KM/g== X-Gm-Message-State: ABUngvei1UAxSS3fpU6IAKkPJd3Vwx7/JwgpLD87P6fzwmgk6zKhIOodmRehRTjum7ES+btL6mNpHVkFHu49aj+w X-Received: by 10.55.79.71 with SMTP id d68mr7576647qkb.95.1476893859737; Wed, 19 Oct 2016 09:17:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.122.130 with HTTP; Wed, 19 Oct 2016 09:16:59 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 19 Oct 2016 09:16:59 -0700 Message-ID: To: "Black, David" , Jana Iyengar Content-Type: multipart/alternative; boundary=001a114a6b3ce1e586053f3a252f Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 16:17:44 -0000 --001a114a6b3ce1e586053f3a252f Content-Type: text/plain; charset=UTF-8 Jana, are you OK with a global Ta value with text explaining how we arrived at that value? On Sun, Oct 16, 2016 at 5:22 AM, Black, David wrote: > It looks like the Ta value suffices, and the prior discussion provides > assurance that residential equipment won't be overrun ... but given the > subtlety of the discussion that reached this result, I strongly recommend > that we show our work ;-). In other words, the draft should provide a > complete explanation of our reasoning, as both the ICE packet size and the > 500ms value are specific to this discussion, making the conclusion *not* > generally applicable. > > Thanks, --David ++Sent from my Android not-so-smartphone ... > > > -------- Original message -------- > From: Peter Thatcher > Date: 10/16/16 7:21 AM (GMT+01:00) > To: "Black, David" > Cc: ice@ietf.org > Subject: Re: [Ice] Continue discussion of global pacing based on feedback > from "transport guys" > > Assuming ICE checks are around 100 octets (which they are, almost), then a > MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 > packets/sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the > Ta value would end up being more strict. > > Does that mean the Ta value of 5ms is sufficiently strict to render the > HTO/MaxPacket rules unnecessary? Could we just reduce the ruleset down to > a min Ta value of 5ms? Or do you think those rules still have value? > > And as for the packet rate, previous to discussing with you "transport > guys", there was a lot of discussion in the WG about packet rates, in > particular rates of opening new NAT bindings with residential equipment. > After a lot of discussion and experimenting in the the real world, we > agreed that a lower bound of 5ms on the Ta was sufficient to cover packet > rates and rates of opening NAT bindings. I can give more history on that > if you'd like. But that still left a concern over bit rates, which is > how we ended up talking to you :). > > > > > > > > > > On Wed, Sep 28, 2016 at 8:45 AM, Black, David > wrote: > >> I'm apparently one of the "transport guys" referred to in the subject >> line ;-). >> >> In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, >> Peter Thatcher >> described the current proposal: >> >> ---------------------- >> 1. A maximum number of outstanding request packets, call it MaxPackets >> which SHOULD be 10. >> >> 2. A timeout for request packets, call it handshake timeout or HTO which >> SHOULD be 2*RTT if the RTT is known and 500ms otherwise. >> >> 3. A global pacing rate of 5ms (like a global Ta). >> >> If all packets are dropped and the RTT is not known, then 1+2 are >> effectively 20 packets per second, >> well below what you would get with the bitrate limits we were asking for. >> ---------------------- >> >> There's been some further discussion with the "transport guys" about >> packet size and bit rate. In essence, the rationale for 10 as the maximum >> number of outstanding request packets (item 1 above) is based on the >> typical TCP segment size of about 1500 bytes. ICE request packets tend to >> be much smaller, 100 bytes or less, which suggests that a factor of 15 >> could be available if bit rate matters but packet count doesn't. That >> may well be the case ... >> >> RFC 7141 (2014 BCP on AQM configuration/implementation) supports that >> view by recommending that AQM implementations count octets (i.e., >> forwarding resources are bit-congestible) as opposed to counting packets >> (i.e., forwarding resources are not packet-congestible). That RFC >> effectively asserts that the current Internet is bit-congestible only: >> https://tools.ietf.org/html/rfc7141 >> >> That would suggest a value of 150 for MaxPackets *when* all the packets >> are 100 octets or less, as should be case for ICE request packets. A >> possible area of concern (based on ICE use by Web RTC) is residential >> gateway/NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient >> to avoid overrunning them. >> >> What do people with more knowledge of and/or experience with residential >> gateway boxes think of this line of reasoning? >> >> Thanks, --David >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > > --001a114a6b3ce1e586053f3a252f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jana, are you OK with a global Ta value with text expla= ining how we arrived at that value? =C2=A0=C2=A0


<= /div>

On Sun, Oct = 16, 2016 at 5:22 AM, Black, David <David.Black@dell.com> = wrote:
It looks like the Ta value suffices, and the prior discussion provides= assurance that residential equipment won't be overrun ... but given th= e subtlety of the discussion that reached this result, I strongly recommend= that we show our work ;-). =C2=A0 In other words, the draft should provide a complete explanation of our reasoning, a= s both the ICE packet size and the 500ms value are specific to this discuss= ion, making the conclusion *not* generally applicable.=C2=A0

Thanks, --David ++Sent from my A= ndroid not-so-smartphone ...


-------- Original message --------
From: Peter Thatcher <pthatcher@google.com>
Date: 10/16/16 7:21 AM (GMT+01:00)
To: "Black, David" <david.black@emc.com>
Subject: Re: [Ice] Continue discussion of global pacing based on feedb= ack from "transport guys"

Assuming ICE checks are around 100 octets (which they are, almost), then= a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packe= ts/sec.=C2=A0 But a Ta of 5ms gives a maximum of 200 packets/sec.=C2=A0 So the Ta value would end up being more strict.= =C2=A0=C2=A0

Does that mean the Ta value of 5ms is sufficiently strict to render the = HTO/MaxPacket rules unnecessary?=C2=A0 Could we just reduce the ruleset dow= n to a min Ta value of 5ms?=C2=A0 Or do you think those rules still have value?

And as for the packet rate, previous to discussing with you "transp= ort guys", there was a lot of discussion in the WG about packet rates,= in particular rates of opening new NAT bindings with residential equipment.=C2=A0 After a lot of discussion and experiment= ing in the the real world, we agreed that a lower bound of 5ms on the Ta wa= s sufficient to cover packet rates and rates of opening NAT bindings.=C2=A0= I can give more history on that if you'd like. =C2=A0 =C2=A0But that still left a concern over bit rates, which is = how we ended up talking to you :).









On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@d= ell.com> wrote:
I'm apparently one of the "transport guys" referred to in the= subject line ;-).

In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
described the current proposal:

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

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

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

If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second,
well below what you would get with the bitrate limits we were asking for. ----------------------

There's been some further discussion with the "transport guys"= ; about packet size and bit rate.=C2=A0 =C2=A0In essence, the rationale for= 10 as the maximum number of outstanding request packets (item 1 above) is = based on the typical TCP segment size of about 1500 bytes.=C2=A0 ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.=C2=A0 =C2=A0 That may well be the case ...

RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).=C2=A0 That RFC effectively asserts that the current Internet is bit-congestible = only: https://tools.ietf.org/html/rfc7141

That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.=C2=A0 A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

Thanks, --David

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


--001a114a6b3ce1e586053f3a252f-- From nobody Wed Oct 19 10:09: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 B003F129589 for ; Wed, 19 Oct 2016 10:09:50 -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 MQkng6EO9zyE for ; Wed, 19 Oct 2016 10:09:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E577C129686 for ; Wed, 19 Oct 2016 10:09:44 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-64-5807a8d6de07 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 68.B7.02458.4D8A7085; Wed, 19 Oct 2016 19:09:43 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.208]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Wed, 19 Oct 2016 19:09:40 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ice@ietf.org" Thread-Topic: Agenda requests for ICE WG at IETF 97 Thread-Index: AQHSKiuTczr6Uu7kQk6gOUowaGnTvA== Date: Wed, 19 Oct 2016 17:09:39 +0000 Message-ID: <3C4631AE-6932-453F-B3F6-48D83C2A52BA@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdVPf6CvYIg4YjPBbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlzLv9lbVgKntFz+4LbA2M11i7GDk5JARMJF6/ nwpkc3EICaxnlFh2bgWUs4RR4unl+2BVbAL2EpPXfGQEsUUEFCVmtjxjBrGZBTQl7p9cyA5i CwvoSfzd2cEEUWMssf/fQVYIW0/i3rt9YDUsAqoS99acA5vDCzTz8q/PYLaQgKnEyxu7wOoZ BcQkvp9awwQxX1zi1pP5TBCXCkgs2XOeGcIWlXj5+B/UB0oSK7ZfYoSo15O4MXUKG4RtLXHz 915WCFtbYtnC18wQewUlTs58wjKBUXQWkhWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWF+emGxnp pRZlJhcX5+fp5aWWbGIERs/BLb+tdjAefO54iFGAg1GJhzehhj1CiDWxrLgy9xCjBAezkgiv 7nKgEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYzhR8VY LpX/XqWtcGddjHqLAnPuLt9dAh+jffns8zWlJN43HZrh31i/84PORK0E503yAuvy7lTIbPzZ N98qydZySd6T9qLvelMfXPkunbjn37wn740uTD4wJcRU3mUV659vrp88nh8KFnGM9Lx7reXf NbE9oY9P9At9i7lW+GtF9s+q3EiTtypKLMUZiYZazEXFiQBJmQW2mgIAAA== Archived-At: Cc: Peter Thatcher Subject: [Ice] Agenda requests for ICE WG at IETF 97 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "ice-chairs@ietf.org" List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 17:09:50 -0000 ICE WG, In the preliminary agenda we have a 2-hour session on Monday, November 14th= at the IETF 97: https://datatracker.ietf.org/meeting/97/agenda.html If you would like to have a slot at the ICE WG meeting, please let the chai= rs know as soon as possible, but latest Friday 28th of October. In the face-to-face meeting we will prioritize work that has been already d= iscussed on the mailing list, so please raise open issues on the ICE list a= lready well before the meeting. We are planning to discuss also future work= for the ICE WG and proposals around that topic are welcomed. In your agenda request e-mail please specify the following: - name of the draft (if any) and the presenter - how much time you would like to have - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Peter (ICE WG co-chairs) From nobody Wed Oct 19 11:53: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 291561293E3 for ; Wed, 19 Oct 2016 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgsJLFkfs7mK for ; Wed, 19 Oct 2016 11:53:20 -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 064431295DE for ; Wed, 19 Oct 2016 11:53:19 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id q7so32663506qtq.1 for ; Wed, 19 Oct 2016 11:53:19 -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:cc; bh=Dc1+GMByVQlSNFXFgawwivScvv/HqkY7pUfCCmwnAKE=; b=f6646srL7C3KIC0mkrTIyC1Ty1DXkOnVuU4td3OcikS9P0IYKGwWxQAVAx4/v4E+1A y7eZMFvSWxesnBhi6AuI+cXopnAuYLdm6TAsvfY7G4YqKpAX94O6zf5lSaVLE56kJBWy 6JR+MEOUuLn8gPYPw+x9Z6AwelHYoh/bR7iGwUNtosszxxnNmdeMbwlsDDeXsT9xatBB KFANsdnATZ0F+D5BZPurqWcG0svi+yTG3MS59aaiCM7Jq0PT1EVMAtj+xBOK5zQoryC3 yBgj1N4MB06s87qFSLX9Wv2DbSDKJ44+dBQGMbHUT5dUxeY6YzML6VdMQobippeXzFC2 ywTQ== 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:cc; bh=Dc1+GMByVQlSNFXFgawwivScvv/HqkY7pUfCCmwnAKE=; b=LEHe9QqThAqGnfwZnihyNQMouD8ks0FMp+Top6HGsyLeg+UXBAgMAGaZrolWxh8e9M 7PBH6hqa7wSoFGr90Xb2chaQkL/iOS55knqFOtRAFFb8ZMnYufyJxbCsJc52bjsPiT47 exIJod6Mon+ovdXEhbKXm/GcFCLA+asLpW31ye3/XaE0E+hr32FEuHbV2DeGqAd2zpsb qGiIPf4D7Szm9zG9SYooob5goll+YFT+5//Gm4vDpXsOIOQ0EMO3YvR/YTJFVRH2RfKW p07lghdv+Hd3ydKkZr4vkcp2T+GRsY/rLvj3o+FQKhV6GdoY3ee+rf6YXp2yk2xYEZ/F MAUA== X-Gm-Message-State: AA6/9Rk2fmewwUqOPAtHf3hEWpPCZH+okAI3NWtD026XN8mYXdfTnKC4MYneWijCN8mO2OeLG0uqG3YOkH+N0W4b X-Received: by 10.200.41.201 with SMTP id 9mr7492896qtt.138.1476903198531; Wed, 19 Oct 2016 11:53:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.149 with HTTP; Wed, 19 Oct 2016 11:53:17 -0700 (PDT) From: Taylor Brandstetter Date: Wed, 19 Oct 2016 11:53:17 -0700 Message-ID: To: draft-ietf-ice-trickle@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1139743a846d0e053f3c5292 Archived-At: Cc: ice@ietf.org Subject: [Ice] Comments on draft-ietf-ice-trickle-04 (Taylor) 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, 19 Oct 2016 18:53:23 -0000 --001a1139743a846d0e053f3c5292 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I reviewed draft-ietf-ice-trickle-04 and noted various comments/questions as I went along. Looking back, many of these are the same things Christer mentioned a week ago, or are purely editorial. But my major takeaways were: 1. Many sections need to be changed in order to not directly prescribe the SDP offer/answer model. Though I feel it's fine to use SDP offer/answer in examples. 2. There are still some problems with the freezing/unfreezing rules as I understand them. Anyway, here are my comments, grouped by section: *Section 2 - Terminology* - Here and throughout the document, UPnP based port allocation and XMPP Jingle Relay Nodes are mentioned, which not even ICEbis references. Shou= ld these be removed? - The concept of a =E2=80=9Cgeneration of candidates=E2=80=9D is not def= ined anywhere, even though I intuitively know what it means. I recommend defining it in ICEbis. The phrase =E2=80=9CICE negotiation session=E2=80=9D is also use= d later, referring to (I think) the same thing. - It=E2=80=99s stated that Trickle ICE is not defined =E2=80=9Cin terms = of SDP or the offer/answer model=E2=80=9D. But it is, throughout the entire document. = The document needs to be changed to refer to =E2=80=9Ccandidate exchanges=E2= =80=9D, for example, instead of offers/answers. *Section 4 - Sending the Initial Offer* - =E2=80=9CAn agent starts gathering candidates as soon as it has an ind= ication that communication is imminent=E2=80=9D. This isn=E2=80=99t always true.= There are even examples later of the opposite happening (candidates being gathered well= in advance). Maybe just say =E2=80=9Can agent *generally* starts gathering= =E2=80=A6=E2=80=9D - =E2=80=9CA host candidate at a media relay=E2=80=9D. Is that really a = host candidate? Where is this described in ICEbis? - There is discussion around hiding host candidates for privacy implications. This isn=E2=80=99t specific to Trickle ICE though, so it s= hould go in ICEbis or somewhere else. - =E2=80=9CMethods for calculating priorities and foundations, as well a= s determining redundancy of candidates, work just as with ICEbis.=E2=80=9D= Not the redundancy part, since there are the special prflx rules. *Section 5.2 - Forming Check Lists and Beginning Connectivity Checks* - There is talk about unfreezing candidates. But the concept of freezing a candidate doesn't make sense to me; only pairs are unfrozen. Is this meant to say =E2=80=9Ccandidate pairs=E2=80=9D? I actually notice the sa= me problem in ICEbis. - The "first checklist with a candidate pair wins" unfreezing rule means that the initial unfrozen checklist could be different between the initiating and responding agents due to racy trickling, leading to at le= ast one of the checklists failing. Suppose for example that checklist 1 has only pairs with foundation A and checklist 2 has only pairs with foundat= ion B; there's no guarantee on ordering between foundations. Why not just "first checklist starts as active, all others frozen"? - =E2=80=9CWith regard to pruning of duplicate candidate pairs, a Trickl= e ICE agent SHOULD follow a policy of =E2=80=98first one wins=E2=80=99.=E2=80= =9D Is this out of date? In =E2=80=9CPairing Newly Learned Candidates and Updating Check Lists=E2=80= =9D there are rules for handling duplicate candidates. There are other places where this =E2= =80=9Cfirst one wins=E2=80=9D policy is mentioned that should be updated. - The concepts of =E2=80=9Cactive=E2=80=9D and =E2=80=9Cfrozen=E2=80=9D = check lists are used here, but the definitions are only elaborated upon in =E2=80=9CCheck List and Time= r State Updates=E2=80=9D. *Section 7.2 - Check List and Timer State Updates* - The definitions of active/frozen are a SHOULD rather than a MUST. If the unfreezing algorithm is vital, as stated elsewhere, shouldn=E2=80=99= t it be a MUST? - =E2=80=9CA Trickle ICE agent SHOULD consider a check list to be active= =E2=80=A6 when the check list is empty.=E2=80=9D Wouldn=E2=80=99t that mean that everyt= hing begins as active, in the common case where you start with 0 pairs? I think the int= ent here is that an empty check list may be considered active or frozen, but that=E2=80=99s not exactly what=E2=80=99s written. Also, if that *is* th= e intent, the specification should explain exactly when an empty frozen checklist beco= mes an empty active checklist. I believe those conditions are: - Another checklist is completely finished (every pair Successful or Failed). - Another checklist has a valid pair for all components. *Section 8 - Discovering and Sending Additional Local Candidates* - In my opinion, the rule that you MUST NOT pair a local candidate until it's been trickled is not clear enough. Though it's heavily implied. - The rule that you must trickle candidates in the order of components, to protect the freezing algorithm, is not enough. I believe you'd also n= eed to trickle them in order of media stream and priority since this also affects which pair is initially unfrozen. *Section 8.1 - Pairing Newly Learned Candidates and Updating Check Lists* - If a checklist is active, the new pair is set to =E2=80=9CWaiting=E2= =80=9D if it=E2=80=99s the first pair in that list with that foundation. This puts pairs in the Waiting state much more aggressively than ICEbis; if a pair for the firs= t media stream/component is still in the Waiting state, it will basically = be ignored when pairs with that foundation are added for other media stream= s, and they'll all end up as "Waiting". Should we effectively replace =E2= =80=9Cif no pair in this checklist has a matching foundation=E2=80=9D with =E2=80=9C= if no pair in *any* checklist has a matching foundation=E2=80=9D? - Even with the above change, the unfreezing rules don=E2=80=99t exactly= match ICEbis. So a race between candidate signaling and connectivity checks co= uld cause a pair to be Frozen on one side and Waiting on the other. Are we o= k with this? *Section 8.2 - Announcing End of Candidates* - =E2=80=9CWhen an end-of-candidates indication is sent as part of an of= fer of an answer, it can be considered to apply to the session as a whole, whic= h is equivalent to having it apply to all media streams.=E2=80=9D Again, s= houldn=E2=80=99t be getting into offer/answer semantics in this document. But even so, this = is incorrect. =E2=80=9Ca=3Dend-of-candidates=E2=80=9D is media-level. *Section 11 - Trickle ICE and Peer Reflexive Candidates* - This section doesn=E2=80=99t seem to take into account the recent chan= ges, where peer reflexive candidates can be replaced by server reflexive candidates. *Section 18 - Acknowledgements* - I don=E2=80=99t think I deserve my own paragraph, I hardly did anythin= g. :) --001a1139743a846d0e053f3c5292 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I reviewed draft-ietf-ice-trickle-04 and noted various com= ments/questions as I went along. Looking back, many of these are the same t= hings Christer mentioned a week ago, or are purely editorial. But my major = takeaways were:

1. Many sections need to be changed in o= rder to not directly prescribe the SDP offer/answer model. Though I feel it= 's fine to use SDP offer/answer in examples.
2. There are sti= ll some problems with the freezing/unfreezing rules as I understand them.

Anyway, here are my comments, grouped by section:

Section 2 - Terminology
    • Here and throughou= t the document, UPnP based port allocation and XMPP Jingle Relay Nodes are = mentioned, which not even ICEbis references. Should these be removed?
    • The concept of a =E2=80=9Cgeneration of candidates=E2=80=9D is not d= efined anywhere, even though I intuitively know what it means. I recommend = defining it in ICEbis. The phrase =E2=80=9CICE negotiation session=E2=80=9D= is also used later, referring to (I think) the same thing.
    • It= =E2=80=99s stated that Trickle ICE is not defined =E2=80=9Cin terms of SDP = or the offer/answer model=E2=80=9D. But it is, throughout the entire docume= nt. The document needs to be changed to refer to =E2=80=9Ccandidate exchang= es=E2=80=9D, for example, instead of offers/answers.
      Section 4 - Sending the Initial Offer
      • =E2=80=9CAn agent star= ts gathering candidates as soon as it has an indication that communication = is imminent=E2=80=9D. This isn=E2=80=99t always true. There are even exampl= es later of the opposite happening (candidates being gathered well in advan= ce). Maybe just say =E2=80=9Can agent *generally* starts gathering=E2=80=A6= =E2=80=9D
      • =E2=80=9CA host candidate at a media relay=E2=80=9D. = Is that really a host candidate? Where is this described in ICEbis?
      • There is discussion around hiding host candidates for privacy implicat= ions. This isn=E2=80=99t specific to Trickle ICE though, so it should go in= ICEbis or somewhere else.
      • =E2=80=9CMethods for calculating pri= orities and foundations, as well as determining redundancy of candidates, w= ork just as with ICEbis.=E2=80=9D Not the redundancy part, since there are = the special prflx rules.

      <= b>Section 5.2 - Forming Check Lists and Beginning Connectivity Checks
        • There is talk about unfree= zing candidates. But the concept of freezing a candidate doesn't make s= ense to me; only pairs are unfrozen. Is this meant to say =E2=80=9Ccandidat= e pairs=E2=80=9D? I actually notice the same problem in ICEbis.
          • The "first checklist with a candidate pair wins" unfreezing rule= means that the initial unfrozen checklist could be different between the i= nitiating and responding agents due to racy trickling, leading to at least = one of the checklists failing. Suppose for example that checklist 1 has onl= y pairs with foundation A and checklist 2 has only pairs with foundation B;= there's no guarantee on ordering between foundations. Why not just &qu= ot;first checklist starts as active, all others frozen"?
        • = =E2=80=9CWith regard to pruning of duplicate candidate pairs, a Trickle ICE= agent SHOULD follow a policy of =E2=80=98first one wins=E2=80=99.=E2=80=9D= Is this out of date? In =E2=80=9CPairing Newly Learned Candidates and Upda= ting Check Lists=E2=80=9D there are rules for handling duplicate candidates= . There are other places where this =E2=80=9Cfirst one wins=E2=80=9D policy= is mentioned that should be updated.
        • The concepts of =E2=80=9C= active=E2=80=9D and =E2=80=9Cfrozen=E2=80=9D check lists are used here, but= the definitions are only elaborated upon in =E2=80=9CCheck List and Timer = State Updates=E2=80=9D.

          Section 7.2 - Check List and Timer State Updates
          =
            • The d= efinitions of active/frozen are a SHOULD rather than a MUST. If the unfreez= ing algorithm is vital, as stated elsewhere, shouldn=E2=80=99t it be a MUST= ?
            • =E2=80=9CA Trickle ICE agent SHOULD consider a check list to = be active =E2=80=A6 when the check list is empty.=E2=80=9D Wouldn=E2=80=99t= that mean that everything begins as active, in the common case where you s= tart with 0 pairs? I think the intent here is that an empty check list may = be considered active or frozen, but that=E2=80=99s not exactly what=E2=80= =99s written. Also, if that *is* the intent, the specification should expla= in exactly when an empty frozen checklist becomes an empty active checklist= . I believe those conditions are:
              • Another checklist is comp= letely finished (every pair Successful or Failed).
              • Another checklis= t has a valid pair for all components.

            Section 8 - Discovering and Sending Additional Local= Candidates
            • In my opin= ion, the rule that you MUST NOT pair a local candidate until it's been = trickled is not clear enough. Though it's heavily implied.
            • = The rule that you must trickle candidates in the order of components, to pr= otect the freezing algorithm, is not enough. I believe you'd also need = to trickle them in order of media stream and priority since this also affec= ts which pair is initially unfrozen.

            Section 8.1 -= Pairing Newly Learned Candidates and Updating Check Lists
          • If a checklist is active, the new pair is set= to =E2=80=9CWaiting=E2=80=9D if it=E2=80=99s the first pair in that list w= ith that foundation. This puts pairs in the Waiting state much more aggress= ively than ICEbis; if a pair for the first media stream/component is still = in the Waiting state, it will basically be ignored when pairs with that fou= ndation are added for other media streams, and they'll all end up as &q= uot;Waiting". Should we effectively replace =E2=80=9Cif no pair in thi= s checklist has a matching foundation=E2=80=9D with =E2=80=9Cif no pair in = *any* checklist has a matching foundation=E2=80=9D?
          • Even with t= he above change, the unfreezing rules don=E2=80=99t exactly match ICEbis. S= o a race between candidate signaling and connectivity checks could cause a = pair to be Frozen on one side and Waiting on the other. Are we ok with this= ?

              • Section 8.2 - A= nnouncing End of Candidates
              • = =E2=80=9CWhen an end-of-candidates indication is sent as part of an offer o= f an answer, it can be considered to apply to the session as a whole, which= is equivalent to having it apply to all media streams.=E2=80=9D Again, sho= uldn=E2=80=99t be getting into offer/answer semantics in this document. But= even so, this is incorrect. =E2=80=9Ca=3Dend-of-candidates=E2=80=9D is med= ia-level.

                Section= 11 - Trickle ICE and Peer Reflexive Candidates
                  • This section doesn=E2= =80=99t seem to take into account the recent changes, where peer reflexive = candidates can be replaced by server reflexive candidates.

                  <= /span>
                • I don=E2=80=99t think I d= eserve my own paragraph, I hardly did anything. :)

                                --001a1139743a846d0e053f3c5292-- From nobody Wed Oct 19 11:56:50 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 AB395129434 for ; Wed, 19 Oct 2016 11:56:48 -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 VxyjdzNrAZ-U for ; Wed, 19 Oct 2016 11:56:46 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218E11293E3 for ; Wed, 19 Oct 2016 11:56:46 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id q7so32772348qtq.1 for ; Wed, 19 Oct 2016 11:56: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:content-transfer-encoding; bh=/gZEvSyp2/be62YNeUfxyFgv+8DrmnndfxmrVItNT0Q=; b=W3V9JYNkhfTexagvy25wwsGlFuirmDbQ0xI9/zjqvD9qxJfsnMxRMaePN+FQTS5AJQ iuQPnrCLBdnVL6N6iBgapaSMRsBjlmKS+pQuZG0HgnD5Cozl1gYbZ127q4uwB5xKgScX Y/N9pj1exXiRJUZq+L1uzSTGHP5kBLXoa/ug6juru8iuY63d2YLsDomzrCSZj95cBehb LpCHioU8QD0g3PZHLzY9pFbxJHVoRTGh7hVpCl1sIEZPSsk/Kk/tVi626pL/VPqRVJ7F PCLdBwOXdXwi4epI5Kr6j7KbdtB9mivTNY+5hVeqwcchpif5bbtqMnGynrwRAdfiN5vV 5NUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/gZEvSyp2/be62YNeUfxyFgv+8DrmnndfxmrVItNT0Q=; b=JqmI7Adcz0OKoYhOIXbhS82nbDlh898y8NRd5eNpQesJmiyjy6wAuwU6u/gJSxNsR1 DdN18AlepQGR8pAJJUCanwJoCFQNvKJi3kb34yTm2GxbQ7IY205GRfJNMP4Wlkoz+WQt T+xO4WOj791rVyTaeaNCc3w9NdV8ZdFuxPg7L4pbGodkfCRCFa25KqnQD2azL9NYJ8MA 5ZXSUBNhL+ZlpDsVPopMfZpyAZy7pUnrlfqHP88vHCmM9Yp4mYTaFzfOlJc+XoBfYOXj vpdIWzNIs0uce/PCJw0MhoSDkd126sdPqnnuw1Dgy+RZpixtZxGBsCTXioUnfnOTN5I1 +1TA== X-Gm-Message-State: AA6/9RnElN4/aKCidrGiK+3qo+Neb359p/WhSjWZVZ5bjq2D94q/XXqhZmUKCLPNTw7lVA== X-Received: by 10.200.38.78 with SMTP id v14mr8002896qtv.81.1476903404808; Wed, 19 Oct 2016 11:56:44 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com. [209.85.220.173]) by smtp.gmail.com with ESMTPSA id n14sm5622066qtn.37.2016.10.19.11.56.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 11:56:44 -0700 (PDT) Received: by mail-qk0-f173.google.com with SMTP id z190so52854573qkc.2 for ; Wed, 19 Oct 2016 11:56:44 -0700 (PDT) X-Received: by 10.194.104.98 with SMTP id gd2mr5293665wjb.216.1476903403810; Wed, 19 Oct 2016 11:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.144.250 with HTTP; Wed, 19 Oct 2016 11:56:23 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Wed, 19 Oct 2016 13:56:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Taylor Brandstetter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-ice-trickle@tools.ietf.org, ice@ietf.org Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 (Taylor) 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, 19 Oct 2016 18:56:49 -0000 Thanks Taylor, I'll be looking at those this week! Emil On Wed, Oct 19, 2016 at 1:53 PM, Taylor Brandstetter wrote: > I reviewed draft-ietf-ice-trickle-04 and noted various comments/questions= as > I went along. Looking back, many of these are the same things Christer > mentioned a week ago, or are purely editorial. But my major takeaways wer= e: > > 1. Many sections need to be changed in order to not directly prescribe th= e > SDP offer/answer model. Though I feel it's fine to use SDP offer/answer i= n > examples. > 2. There are still some problems with the freezing/unfreezing rules as I > understand them. > > Anyway, here are my comments, grouped by section: > > Section 2 - Terminology > > Here and throughout the document, UPnP based port allocation and XMPP Jin= gle > Relay Nodes are mentioned, which not even ICEbis references. Should these= be > removed? > The concept of a =E2=80=9Cgeneration of candidates=E2=80=9D is not define= d anywhere, even > though I intuitively know what it means. I recommend defining it in ICEbi= s. > The phrase =E2=80=9CICE negotiation session=E2=80=9D is also used later, = referring to (I > think) the same thing. > It=E2=80=99s stated that Trickle ICE is not defined =E2=80=9Cin terms of = SDP or the > offer/answer model=E2=80=9D. But it is, throughout the entire document. T= he document > needs to be changed to refer to =E2=80=9Ccandidate exchanges=E2=80=9D, fo= r example, instead > of offers/answers. > > > Section 4 - Sending the Initial Offer > > =E2=80=9CAn agent starts gathering candidates as soon as it has an indica= tion that > communication is imminent=E2=80=9D. This isn=E2=80=99t always true. There= are even examples > later of the opposite happening (candidates being gathered well in advanc= e). > Maybe just say =E2=80=9Can agent *generally* starts gathering=E2=80=A6=E2= =80=9D > =E2=80=9CA host candidate at a media relay=E2=80=9D. Is that really a hos= t candidate? Where > is this described in ICEbis? > There is discussion around hiding host candidates for privacy implication= s. > This isn=E2=80=99t specific to Trickle ICE though, so it should go in ICE= bis or > somewhere else. > =E2=80=9CMethods for calculating priorities and foundations, as well as d= etermining > redundancy of candidates, work just as with ICEbis.=E2=80=9D Not the redu= ndancy > part, since there are the special prflx rules. > > > Section 5.2 - Forming Check Lists and Beginning Connectivity Checks > > There is talk about unfreezing candidates. But the concept of freezing a > candidate doesn't make sense to me; only pairs are unfrozen. Is this mean= t > to say =E2=80=9Ccandidate pairs=E2=80=9D? I actually notice the same prob= lem in ICEbis. > The "first checklist with a candidate pair wins" unfreezing rule means th= at > the initial unfrozen checklist could be different between the initiating = and > responding agents due to racy trickling, leading to at least one of the > checklists failing. Suppose for example that checklist 1 has only pairs w= ith > foundation A and checklist 2 has only pairs with foundation B; there's no > guarantee on ordering between foundations. Why not just "first checklist > starts as active, all others frozen"? > =E2=80=9CWith regard to pruning of duplicate candidate pairs, a Trickle I= CE agent > SHOULD follow a policy of =E2=80=98first one wins=E2=80=99.=E2=80=9D Is t= his out of date? In > =E2=80=9CPairing Newly Learned Candidates and Updating Check Lists=E2=80= =9D there are rules > for handling duplicate candidates. There are other places where this =E2= =80=9Cfirst > one wins=E2=80=9D policy is mentioned that should be updated. > The concepts of =E2=80=9Cactive=E2=80=9D and =E2=80=9Cfrozen=E2=80=9D che= ck lists are used here, but the > definitions are only elaborated upon in =E2=80=9CCheck List and Timer Sta= te > Updates=E2=80=9D. > > > Section 7.2 - Check List and Timer State Updates > > The definitions of active/frozen are a SHOULD rather than a MUST. If the > unfreezing algorithm is vital, as stated elsewhere, shouldn=E2=80=99t it = be a MUST? > =E2=80=9CA Trickle ICE agent SHOULD consider a check list to be active = =E2=80=A6 when the > check list is empty.=E2=80=9D Wouldn=E2=80=99t that mean that everything = begins as active, > in the common case where you start with 0 pairs? I think the intent here = is > that an empty check list may be considered active or frozen, but that=E2= =80=99s not > exactly what=E2=80=99s written. Also, if that *is* the intent, the specif= ication > should explain exactly when an empty frozen checklist becomes an empty > active checklist. I believe those conditions are: > > Another checklist is completely finished (every pair Successful or Failed= ). > Another checklist has a valid pair for all components. > > > Section 8 - Discovering and Sending Additional Local Candidates > > In my opinion, the rule that you MUST NOT pair a local candidate until it= 's > been trickled is not clear enough. Though it's heavily implied. > The rule that you must trickle candidates in the order of components, to > protect the freezing algorithm, is not enough. I believe you'd also need = to > trickle them in order of media stream and priority since this also affect= s > which pair is initially unfrozen. > > > Section 8.1 - Pairing Newly Learned Candidates and Updating Check Lists > > If a checklist is active, the new pair is set to =E2=80=9CWaiting=E2=80= =9D if it=E2=80=99s the first > pair in that list with that foundation. This puts pairs in the Waiting st= ate > much more aggressively than ICEbis; if a pair for the first media > stream/component is still in the Waiting state, it will basically be igno= red > when pairs with that foundation are added for other media streams, and > they'll all end up as "Waiting". Should we effectively replace =E2=80=9Ci= f no pair > in this checklist has a matching foundation=E2=80=9D with =E2=80=9Cif no = pair in *any* > checklist has a matching foundation=E2=80=9D? > Even with the above change, the unfreezing rules don=E2=80=99t exactly ma= tch ICEbis. > So a race between candidate signaling and connectivity checks could cause= a > pair to be Frozen on one side and Waiting on the other. Are we ok with th= is? > > > Section 8.2 - Announcing End of Candidates > > =E2=80=9CWhen an end-of-candidates indication is sent as part of an offer= of an > answer, it can be considered to apply to the session as a whole, which is > equivalent to having it apply to all media streams.=E2=80=9D Again, shoul= dn=E2=80=99t be > getting into offer/answer semantics in this document. But even so, this i= s > incorrect. =E2=80=9Ca=3Dend-of-candidates=E2=80=9D is media-level. > > > Section 11 - Trickle ICE and Peer Reflexive Candidates > > This section doesn=E2=80=99t seem to take into account the recent changes= , where > peer reflexive candidates can be replaced by server reflexive candidates. > > > Section 18 - Acknowledgements > > I don=E2=80=99t think I deserve my own paragraph, I hardly did anything. = :) > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --=20 https://jitsi.org From nobody Wed Oct 19 12:26:56 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4988912967E for ; Wed, 19 Oct 2016 12:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 gULrGdvCnVzO for ; Wed, 19 Oct 2016 12:26:52 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 A62DF1295A3 for ; Wed, 19 Oct 2016 12:26:52 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id w3so24532176ywg.1 for ; Wed, 19 Oct 2016 12:26:52 -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=72XfLlX8lSzwmZ7yXcKLc4gE5jzA3EkeLNNh3bZeKPY=; b=V/CvBo2LqJKCvj0LulGYtiVHfq2r+B429DOhiZARy3NxlCqBGs5FE47J9C6U2tcl7f Munw/Ts0wd/9Xl8fdOclTOcAHIxHw3zg74rYVnByMVChFPzNeiWQH7aElNzUn9E5QXou Kv2LDdGO+bgUA2IQCVuvhVy3UXvS+CkmtY8IsdhK0A/jVR7FcGqDyDEDbofklTlpwsQk zG0qTDF0cAhccFajQhWHfpvdkYk0F9ssYU0YoLdQfC+r948IL4zgR6cj14/TzNMgnEzG fXOP4CH03GgcOcd+OfqW/R4Gp6ZP3ZCIFb9XQ9/9Z3jLL6GERbbvDQ42WFE9Q2N4kyZe LVcQ== 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=72XfLlX8lSzwmZ7yXcKLc4gE5jzA3EkeLNNh3bZeKPY=; b=HLEP4s9hbuFISZ2Kio6o17lQtUqGnOjchSgJxiWsxAvPXSDhBF3HYhhOhF8BR49TeN hedxvHG1UQnZqTmFyGZ6JCCOu7LVOYDrHaX0uWEctd5XrjKyE6T/1tncLoEKxi/pE/lF Tm9PqJViO2uPxQj6+jzOOwTPUL8m1BKIN8zftDhAhrOoio/T0iO7Y1UcJehDMxW6Gjd/ qPW3B6Zk2jy6tIBzi7s69nQOpLfOlZ31IDbiSpF6AU5b616OQWI6+r+nJn/+svCmLoAX uCXAkEt8S2AxW+XDZdohhwivAiQ+Bbi6k8YpqqhWBksiQ0RJeOvdA0vfe9Id/ANXgpje jiCg== X-Gm-Message-State: AA6/9Rk8K7cnKcNv6g3qP2kv8PrFKl1Lgv5Rd4tmhBPT//4IcpK+AalYJOR7FBh0xuYBVRJ6nvffu1r22I1/mzm/ X-Received: by 10.107.128.28 with SMTP id b28mr9818526iod.134.1476905211673; Wed, 19 Oct 2016 12:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.76 with HTTP; Wed, 19 Oct 2016 12:26:50 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 19 Oct 2016 12:26:50 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a113f9a62829bc0053f3ccada Archived-At: Cc: "Black, David" , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 19:26:55 -0000 --001a113f9a62829bc0053f3ccada Content-Type: text/plain; charset=UTF-8 Sounds good to me. Thanks for taking the time to think this through, even though it seems to have "collapsed" to the same answer. I definitely think it's worthwhile putting the reasoning into the draft. On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher wrote: > Jana, are you OK with a global Ta value with text explaining how we > arrived at that value? > > > > On Sun, Oct 16, 2016 at 5:22 AM, Black, David > wrote: > >> It looks like the Ta value suffices, and the prior discussion provides >> assurance that residential equipment won't be overrun ... but given the >> subtlety of the discussion that reached this result, I strongly recommend >> that we show our work ;-). In other words, the draft should provide a >> complete explanation of our reasoning, as both the ICE packet size and the >> 500ms value are specific to this discussion, making the conclusion *not* >> generally applicable. >> >> Thanks, --David ++Sent from my Android not-so-smartphone ... >> >> >> -------- Original message -------- >> From: Peter Thatcher >> Date: 10/16/16 7:21 AM (GMT+01:00) >> To: "Black, David" >> Cc: ice@ietf.org >> Subject: Re: [Ice] Continue discussion of global pacing based on feedback >> from "transport guys" >> >> Assuming ICE checks are around 100 octets (which they are, almost), then >> a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 >> packets/sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the >> Ta value would end up being more strict. >> >> Does that mean the Ta value of 5ms is sufficiently strict to render the >> HTO/MaxPacket rules unnecessary? Could we just reduce the ruleset down to >> a min Ta value of 5ms? Or do you think those rules still have value? >> >> And as for the packet rate, previous to discussing with you "transport >> guys", there was a lot of discussion in the WG about packet rates, in >> particular rates of opening new NAT bindings with residential equipment. >> After a lot of discussion and experimenting in the the real world, we >> agreed that a lower bound of 5ms on the Ta was sufficient to cover packet >> rates and rates of opening NAT bindings. I can give more history on that >> if you'd like. But that still left a concern over bit rates, which is >> how we ended up talking to you :). >> >> >> >> >> >> >> >> >> >> On Wed, Sep 28, 2016 at 8:45 AM, Black, David >> wrote: >> >>> I'm apparently one of the "transport guys" referred to in the subject >>> line ;-). >>> >>> In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, >>> Peter Thatcher >>> described the current proposal: >>> >>> ---------------------- >>> 1. A maximum number of outstanding request packets, call it MaxPackets >>> which SHOULD be 10. >>> >>> 2. A timeout for request packets, call it handshake timeout or HTO >>> which SHOULD be 2*RTT if the RTT is known and 500ms otherwise. >>> >>> 3. A global pacing rate of 5ms (like a global Ta). >>> >>> If all packets are dropped and the RTT is not known, then 1+2 are >>> effectively 20 packets per second, >>> well below what you would get with the bitrate limits we were asking for. >>> ---------------------- >>> >>> There's been some further discussion with the "transport guys" about >>> packet size and bit rate. In essence, the rationale for 10 as the maximum >>> number of outstanding request packets (item 1 above) is based on the >>> typical TCP segment size of about 1500 bytes. ICE request packets tend to >>> be much smaller, 100 bytes or less, which suggests that a factor of 15 >>> could be available if bit rate matters but packet count doesn't. That >>> may well be the case ... >>> >>> RFC 7141 (2014 BCP on AQM configuration/implementation) supports that >>> view by recommending that AQM implementations count octets (i.e., >>> forwarding resources are bit-congestible) as opposed to counting packets >>> (i.e., forwarding resources are not packet-congestible). That RFC >>> effectively asserts that the current Internet is bit-congestible only: >>> https://tools.ietf.org/html/rfc7141 >>> >>> That would suggest a value of 150 for MaxPackets *when* all the packets >>> are 100 octets or less, as should be case for ICE request packets. A >>> possible area of concern (based on ICE use by Web RTC) is residential >>> gateway/NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient >>> to avoid overrunning them. >>> >>> What do people with more knowledge of and/or experience with residential >>> gateway boxes think of this line of reasoning? >>> >>> Thanks, --David >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> >> > --001a113f9a62829bc0053f3ccada Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
                                Sounds good to me. Thanks for taking the time to think thi= s through, even though it seems to have "collapsed" to the same a= nswer. I definitely think it's worthwhile putting the reasoning into th= e draft.

                                On = Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher <pthatcher@google.com= > wrote:
                                Ja= na, are you OK with a global Ta value with text explaining how we arrived a= t that value? =C2=A0=C2=A0



                                On Sun, Oct 16, 2016 at 5:22 AM, B= lack, David <David.Black@dell.com> wrote:
                                It looks like the Ta value suffices, and the prior discussion provides= assurance that residential equipment won't be overrun ... but given th= e subtlety of the discussion that reached this result, I strongly recommend= that we show our work ;-). =C2=A0 In other words, the draft should provide a complete explanation of our reasoning, a= s both the ICE packet size and the 500ms value are specific to this discuss= ion, making the conclusion *not* generally applicable.=C2=A0

                                Thanks, --David ++Sent from my A= ndroid not-so-smartphone ...


                                -------- Original message --------
                                From: Peter Thatcher <pthatcher@google.com>
                                Date: 10/16/16 7:21 AM (GMT+01:00)
                                To: "Black, David" <david.black@emc.com>
                                Subject: Re: [Ice] Continue discussion of global pacing based on feedb= ack from "transport guys"

                                Assuming ICE checks are around 100 octets (which they are, almost), then= a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packe= ts/sec.=C2=A0 But a Ta of 5ms gives a maximum of 200 packets/sec.=C2=A0 So the Ta value would end up being more strict.= =C2=A0=C2=A0

                                Does that mean the Ta value of 5ms is sufficiently strict to render the = HTO/MaxPacket rules unnecessary?=C2=A0 Could we just reduce the ruleset dow= n to a min Ta value of 5ms?=C2=A0 Or do you think those rules still have value?

                                And as for the packet rate, previous to discussing with you "transp= ort guys", there was a lot of discussion in the WG about packet rates,= in particular rates of opening new NAT bindings with residential equipment.=C2=A0 After a lot of discussion and experiment= ing in the the real world, we agreed that a lower bound of 5ms on the Ta wa= s sufficient to cover packet rates and rates of opening NAT bindings.=C2=A0= I can give more history on that if you'd like. =C2=A0 =C2=A0But that still left a concern over bit rates, which is = how we ended up talking to you :).









                                On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@d= ell.com> wrote:
                                I'm apparently one of the "transport guys" referred to in the= subject line ;-).

                                In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
                                described the current proposal:

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

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

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

                                If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second,
                                well below what you would get with the bitrate limits we were asking for. ----------------------

                                There's been some further discussion with the "transport guys"= ; about packet size and bit rate.=C2=A0 =C2=A0In essence, the rationale for= 10 as the maximum number of outstanding request packets (item 1 above) is = based on the typical TCP segment size of about 1500 bytes.=C2=A0 ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.=C2=A0 =C2=A0 That may well be the case ...

                                RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).=C2=A0 That RFC effectively asserts that the current Internet is bit-congestible = only:                                 https://tools.ietf.org/html/rfc7141

                                That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.=C2=A0 A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

                                What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

                                Thanks, --David

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



                                --001a113f9a62829bc0053f3ccada-- From nobody Fri Oct 21 03:39:38 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 700C21296FD; Fri, 21 Oct 2016 03:39:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147704637345.23689.1830985250636960424.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 03:39:33 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-06.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 10:39:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines Authors : Paal-Erik Martinsen Tirumaleswar Reddy Prashanth Patil Filename : draft-ietf-ice-dualstack-fairness-06.txt Pages : 10 Date : 2016-10-21 Abstract: This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-dualstack-fairness-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-dualstack-fairness-06 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 Fri Oct 21 16:30:31 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 703B51299D2; Fri, 21 Oct 2016 16:21:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208745.28214.8245278604405480832.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:27 -0700 Archived-At: Cc: ben@nostrum.com, ice@ietf.org Subject: [Ice] ice - Requested session has been scheduled for IETF 97 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:27 -0000 Dear Ari Keränen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ice Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keränen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm Second Priority: perc httpbis rmcat netvc sipbrandy Third Priority: ace 6lo lwig clue xrblock sipcore Special Requests: --------------------------------------------------------- From nobody Wed Oct 26 07:01: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 8081C129BA4 for ; Wed, 26 Oct 2016 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 dEqF-bAq5shf for ; Wed, 26 Oct 2016 07:01:19 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 D5016129BBA for ; Wed, 26 Oct 2016 07:01:11 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n189so7119329qke.0 for ; Wed, 26 Oct 2016 07:01:11 -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=oTEGF/1vaIiW8/FuyDgD6fywfnKT7i0km57Gpy2gD04=; b=S/FbckIYK3WQgeJ+gtTummXoaBwJnmh/cuGSAG8+J6Yn0tGp/0drKJCgR51M2AZGkK B4yMVrENrKtt1XycLe1bbptxk5XoXBa1G1PSNXp+OcU59S7DIEWWMkysCWY7TMRfxhuL PcAj6ypc9LF5aUnypDdiAYnUq87RVqj9Kyy9Bw1OboQ440OPGG0HKRP9vYSO/KASjsjH g0aStRJgG+0/OapszUgZEILIxSPc+5tBZSITFTZ69/OagdHx1ShOx5cKvXlxg6QXSEo7 +VyDtgro71bB/1xYBl72QkVDSsK/OokT1V59m7XUA4hkVInjF1Ywzqw8lKyaT274p9Lg V36A== 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=oTEGF/1vaIiW8/FuyDgD6fywfnKT7i0km57Gpy2gD04=; b=i7B9vEJShesR6pfD4DThHmoFc7qVn1WcJRp3xD9OHSotCsJnxOp1HMelwMlMC+4Y2j LUVTr/A0//lx5ZzWOjTWA1ub73nLqLral/7cxLW8bJY9et/cfVMAdWkBdcginTdhyExg ItUSsS9ZLiaON5NyI1LgvjV6iQAAsFzRiZpUIG3lYmd2yBKkfqFR+rOYcEPf5GvCAI1R yckhu1qfSFc+yeZ5gVPmDeSNXCAdv7unsVbGoMilyL+bFEb7tgrIwXU2jJMzOg90/wGt QB/VabQBj1sXQG9DfOTxvc/pJGvv8k7k4IhVLcLYsbZCwNzi7FofEUKP1Onl95OmIeja 3mpg== X-Gm-Message-State: ABUngvdPV+LKQKUF+MDmLWc+TIhg7RVGqmoImSopfNV8M/o0VFrxE5CZGpCPUpJL3d37OSMdO710KMQI/SfbIeCl X-Received: by 10.55.87.6 with SMTP id l6mr1891050qkb.95.1477490470374; Wed, 26 Oct 2016 07:01:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.122.130 with HTTP; Wed, 26 Oct 2016 07:00:29 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 26 Oct 2016 07:00:29 -0700 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114e5ee2a58d55053fc50e55 Archived-At: Cc: "Black, David" , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 14:01:23 -0000 --001a114e5ee2a58d55053fc50e55 Content-Type: text/plain; charset=UTF-8 OK, based on the discussion, I have made the following PR for 5245bis: https://github.com/ice-wg/rfc5245bis/pull/19 Please let me know if the logic and wording are right. On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar wrote: > Sounds good to me. Thanks for taking the time to think this through, even > though it seems to have "collapsed" to the same answer. I definitely think > it's worthwhile putting the reasoning into the draft. > > On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher > wrote: > >> Jana, are you OK with a global Ta value with text explaining how we >> arrived at that value? >> >> >> >> On Sun, Oct 16, 2016 at 5:22 AM, Black, David >> wrote: >> >>> It looks like the Ta value suffices, and the prior discussion provides >>> assurance that residential equipment won't be overrun ... but given the >>> subtlety of the discussion that reached this result, I strongly recommend >>> that we show our work ;-). In other words, the draft should provide a >>> complete explanation of our reasoning, as both the ICE packet size and the >>> 500ms value are specific to this discussion, making the conclusion *not* >>> generally applicable. >>> >>> Thanks, --David ++Sent from my Android not-so-smartphone ... >>> >>> >>> -------- Original message -------- >>> From: Peter Thatcher >>> Date: 10/16/16 7:21 AM (GMT+01:00) >>> To: "Black, David" >>> Cc: ice@ietf.org >>> Subject: Re: [Ice] Continue discussion of global pacing based on >>> feedback from "transport guys" >>> >>> Assuming ICE checks are around 100 octets (which they are, almost), then >>> a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 >>> packets/sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the >>> Ta value would end up being more strict. >>> >>> Does that mean the Ta value of 5ms is sufficiently strict to render the >>> HTO/MaxPacket rules unnecessary? Could we just reduce the ruleset down to >>> a min Ta value of 5ms? Or do you think those rules still have value? >>> >>> And as for the packet rate, previous to discussing with you "transport >>> guys", there was a lot of discussion in the WG about packet rates, in >>> particular rates of opening new NAT bindings with residential equipment. >>> After a lot of discussion and experimenting in the the real world, we >>> agreed that a lower bound of 5ms on the Ta was sufficient to cover packet >>> rates and rates of opening NAT bindings. I can give more history on that >>> if you'd like. But that still left a concern over bit rates, which is >>> how we ended up talking to you :). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Sep 28, 2016 at 8:45 AM, Black, David >>> wrote: >>> >>>> I'm apparently one of the "transport guys" referred to in the subject >>>> line ;-). >>>> >>>> In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, >>>> Peter Thatcher >>>> described the current proposal: >>>> >>>> ---------------------- >>>> 1. A maximum number of outstanding request packets, call it MaxPackets >>>> which SHOULD be 10. >>>> >>>> 2. A timeout for request packets, call it handshake timeout or HTO >>>> which SHOULD be 2*RTT if the RTT is known and 500ms otherwise. >>>> >>>> 3. A global pacing rate of 5ms (like a global Ta). >>>> >>>> If all packets are dropped and the RTT is not known, then 1+2 are >>>> effectively 20 packets per second, >>>> well below what you would get with the bitrate limits we were asking >>>> for. >>>> ---------------------- >>>> >>>> There's been some further discussion with the "transport guys" about >>>> packet size and bit rate. In essence, the rationale for 10 as the maximum >>>> number of outstanding request packets (item 1 above) is based on the >>>> typical TCP segment size of about 1500 bytes. ICE request packets tend to >>>> be much smaller, 100 bytes or less, which suggests that a factor of 15 >>>> could be available if bit rate matters but packet count doesn't. That >>>> may well be the case ... >>>> >>>> RFC 7141 (2014 BCP on AQM configuration/implementation) supports that >>>> view by recommending that AQM implementations count octets (i.e., >>>> forwarding resources are bit-congestible) as opposed to counting packets >>>> (i.e., forwarding resources are not packet-congestible). That RFC >>>> effectively asserts that the current Internet is bit-congestible only: >>>> https://tools.ietf.org/html/rfc7141 >>>> >>>> That would suggest a value of 150 for MaxPackets *when* all the packets >>>> are 100 octets or less, as should be case for ICE request packets. A >>>> possible area of concern (based on ICE use by Web RTC) is residential >>>> gateway/NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient >>>> to avoid overrunning them. >>>> >>>> What do people with more knowledge of and/or experience with >>>> residential gateway boxes think of this line of reasoning? >>>> >>>> Thanks, --David >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>> >>> >> > --001a114e5ee2a58d55053fc50e55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
                                OK, based on the discussion, I have made the following = PR for 5245bis:

                                https://github.com/ice-wg/rfc5245bis/pull/19
                                =


                                Please let me know if the logic and wordi= ng are right. =C2=A0

                                On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar <jri@goo= gle.com> wrote:
                                Sounds good to me. Thanks for taking the time to think this through, = even though it seems to have "collapsed" to the same answer. I de= finitely think it's worthwhile putting the reasoning into the draft.

                                <= div class=3D"gmail_quote">On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher <= span dir=3D"ltr"><pthatcher@google.com> wrote:
                                Jana, are you OK with a global Ta value with text= explaining how we arrived at that value? =C2=A0=C2=A0



                                On Sun= , Oct 16, 2016 at 5:22 AM, Black, David <David.Black@dell.com> wrote:
                                It looks like the Ta value suffices, and the prior discussion provides= assurance that residential equipment won't be overrun ... but given th= e subtlety of the discussion that reached this result, I strongly recommend= that we show our work ;-). =C2=A0 In other words, the draft should provide a complete explanation of our reasoning, a= s both the ICE packet size and the 500ms value are specific to this discuss= ion, making the conclusion *not* generally applicable.=C2=A0

                                Thanks, --David ++Sent from my A= ndroid not-so-smartphone ...


                                -------- Original message --------
                                From: Peter Thatcher <pthatcher@google.com>
                                Date: 10/16/16 7:21 AM (GMT+01:00)
                                To: "Black, David" <david.black@emc.com>
                                Subject: Re: [Ice] Continue discussion of global pacing based on feedb= ack from "transport guys"

                                Assuming ICE checks are around 100 octets (which they are, almost), then= a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packe= ts/sec.=C2=A0 But a Ta of 5ms gives a maximum of 200 packets/sec.=C2=A0 So the Ta value would end up being more strict.= =C2=A0=C2=A0

                                Does that mean the Ta value of 5ms is sufficiently strict to render the = HTO/MaxPacket rules unnecessary?=C2=A0 Could we just reduce the ruleset dow= n to a min Ta value of 5ms?=C2=A0 Or do you think those rules still have value?

                                And as for the packet rate, previous to discussing with you "transp= ort guys", there was a lot of discussion in the WG about packet rates,= in particular rates of opening new NAT bindings with residential equipment.=C2=A0 After a lot of discussion and experiment= ing in the the real world, we agreed that a lower bound of 5ms on the Ta wa= s sufficient to cover packet rates and rates of opening NAT bindings.=C2=A0= I can give more history on that if you'd like. =C2=A0 =C2=A0But that still left a concern over bit rates, which is = how we ended up talking to you :).









                                On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@d= ell.com> wrote:
                                I'm apparently one of the "transport guys" referred to in the= subject line ;-).

                                In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
                                described the current proposal:

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

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

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

                                If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second,
                                well below what you would get with the bitrate limits we were asking for. ----------------------

                                There's been some further discussion with the "transport guys"= ; about packet size and bit rate.=C2=A0 =C2=A0In essence, the rationale for= 10 as the maximum number of outstanding request packets (item 1 above) is = based on the typical TCP segment size of about 1500 bytes.=C2=A0 ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.=C2=A0 =C2=A0 That may well be the case ...

                                RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).=C2=A0 That RFC effectively asserts that the current Internet is bit-congestible = only:                                 https://tools.ietf.org/html/rfc7141

                                That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.=C2=A0 A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

                                What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

                                Thanks, --David

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




                                --001a114e5ee2a58d55053fc50e55-- From nobody Thu Oct 27 13:49: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 70D8B129508 for ; Thu, 27 Oct 2016 13:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=bLBxq5Bt; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=k/oPdv6q 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 jeIv4MgTKDqw for ; Thu, 27 Oct 2016 13:49:27 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E147D1293DA for ; Thu, 27 Oct 2016 13:49:26 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=D8IsNdqnHC92CujIkXva58tMTHFpSb+x1q2fzfoS/UxKJV1ZGJlLvAIo w2yq5MtFlpBWq1ZN/rFClGLVTogkc82msowDJo7syAcgsjthAkiBaCHtk +nQyprk9o148+mVZ120hXgFyPpNSsk6QI21d+EINy051L6fh8I0LGFxx0 0=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477601366; x=1509137366; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=GKlruxSFMJIXj7EpGFwWTPDWqo+GKrFZ0PtzX6cOxY8=; b=bLBxq5BtHLRBfOztKMlst7+aJJ84MKHt0deiIOhA76wb6a782jKVSpPR xoYSa70OoIBZDLkV9Sq7RtB+mG2CcsE7Xc7iD5TqUOBh5Saago9SsxGOh 2ydmro8rd+DHCPhpGRGOb0xw+8nmHaJ643MgCGdPOwefl6qUB6FEH/lkq c=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2016 15:49:26 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 02:49:24 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9RKnMPF029099 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Oct 2016 16:49:23 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u9RKnMPF029099 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477601364; bh=HTaJ2QuhfuqrrbHpjzh7UaKCwlc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=k/oPdv6q/jpsyom0Ad372A9TIP0sl09i7SUu+h363z/6EGvBQZVqgDfDx4BRaiS4J tAYjK0U6i4QSleGcHWVfYTNPQyDfyJ2Pp2SCrMDID1tnVWv78RJ6ce/wsBdKbQVwkv E4MHFhArnHinTU4XZRl0TrKXBycGG+evAx8CF7nk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u9RKnMPF029099 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 27 Oct 2016 16:47:52 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9RKnAcc022548 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 27 Oct 2016 16:49:10 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0266.001; Thu, 27 Oct 2016 16:49:09 -0400 To: Peter Thatcher , Jana Iyengar Thread-Topic: [Ice] Continue discussion of global pacing based on feedback from "transport guys" Thread-Index: AdIZn0w0rTSbKKnYS/edYVNC+EY2GgN7zvuAAAZZkB8Ap3QdgAAGoWQAAVSkbYAAN7NzUA== Date: Thu, 27 Oct 2016 20:49:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F6FC3E0MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 20:49:31 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F6FC3E0MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNClNvbWUgY29tbWVudHMgLi4uDQoNCisgIDx0PlN0YXJ0IHdpdGggdGhlIGZv bGxvd2luZyBydWxlcyB3aGljaCB3b3VsZCBiZSBnZW5lcmFsbHkNCisgIGFwcGxpY2FibGUgdG8g dHJhbnNwb3J0IHByb3RvY29sczoNCisgIDxsaXN0IHN0eWxlPSJudW1iZXJzIj4NCisgICAgPHQ+ TGV0IE1heFBhY2tldHMgYmUgdGhlIG1heGltdW0gbnVtYmVyIG9mIHRyYW5zYWN0aW9ucyBhbGxv d2VkIHRvIGJlIG91dHN0YW5kaW5nIGluIHRoZSBuZXR3b3JrIGF0IGFueSB0aW1lLCB3aGljaCBT SE9VTEQgYmUgMTAuPC90Pg0KKyAgICA8dD5MZXQgSFRPIGJlIHRoZSB0cmFuc2FjdGlvbiB0aW1l b3V0LCB3aGljaCBTSE9VTEQgYmUgMipSVFQgaWYgUlRUIGlzIGtub3duIGFuZCA1MDBtcyBvdGhl cndpc2UuPC90Pg0KKyAgICA8dD5MZXQgTWluUGFjaW5nIGJlIHRoZSBtaW5pbXVtIHBhY2luZyBp bnRlcnZhbCBiZXR3ZWVuIHRyYW5zYWN0aW9ucywgd2hpY2ggU0hPVUxEIGJlIDVtcy48L3Q+DQor ICA8L2xpc3Q+DQoNCknigJlkIGNpdGUgcmVmZXJlbmNlcyBmb3IgYXQgbGVhc3QgdGhlIGZpcnN0 IHR3byBvZiB0aGUgbGlzdCBpdGVtcywgaWYgbm90IGFsbCB0aHJlZS4gIFRoZSBmaXJzdCBpdGVt IGlzIGJhc2VkIG9uIFRDUCBJbml0aWFsIFdpbmRvdyBvZiAxMCBzZWdtZW50cywgd2hpY2ggSSBi ZWxpZXZlIGlzIFJGQyA2OTI4IChKYW5hIHdpbGwga25vdyBmb3IgY2VydGFpbikuICBUaGUgc2Vj b25kIGl0ZW0gaXMgKm5vdCogZ2VuZXJhbCAtIDUwMG1zIGlzIHNwZWNpZmljIHRvIFNUVU4sIGFu ZCBjb21lcyBmcm9tIFJGQyA1Mzg5IChjcmVkaXQgdG8gQmVybmFyZCBBYm9iYSBmb3IgZmluZGlu ZyB0aGlzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ljZS9jdXJyZW50 L21zZzAwMzc5Lmh0bWwpIC0gdGhhdOKAmXMgaW1wb3J0YW50IGJlY2F1c2UgdGhlIGdlbmVyYWxs eSBhcHBsaWNhYmxlIG51bWJlciBpcyBsYXJnZXIgLSBib3RoIFJGQyA2Mjk4IGFuZCBkcmFmdC1p ZXRmLXRzdndnLXJmYzU0MDViaXMgdXNlIDEgc2Vjb25kIGZvciBUQ1AgYW5kIFVEUCwgcmVzcGVj dGl2ZWx5LiAgRm9yIHRoZSB0aGlyZCBpdGVtLCBJIGhvcGUgdGhlIHJhdGlvbmFsZSBmb3IgdGhl IDVtcyBwYWNpbmcgaW50ZXJ2YWwgaXMgZXhwbGFpbmVkIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQu DQoNCisgICAgT2JzZXJ2ZSB0aGF0IElDRSB0cmFuc2FjdGlvbnMgYXJlIHR5cGljYWxseSBhcm91 bmQgMTAwIGJ5dGVzIG9yDQorICAgIGxlc3MsIHdoaWNoIG1ha2VzIGl0IHJlYXNvbmFibGUgdG8g aW5jcmVhc2UgTWF4UGFja2V0cyB0byBhYm91dA0KKyAgICAxNTAuDQoNCkFkZCDigJxiZWNhdXNl IDE1MDAgYnl0ZXMgaXMgYSB0eXBpY2FsIFRDUCBzZWdtZW50IHNpemXigJ0gdG8gdGhlIGVuZCBv ZiB0aGlzLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KRnJvbTogUGV0ZXIgVGhhdGNoZXIgW21haWx0 bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyNiwgMjAx NiAxMDowMCBBTQ0KVG86IEphbmEgSXllbmdhcg0KQ2M6IEJsYWNrLCBEYXZpZDsgaWNlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0ljZV0gQ29udGludWUgZGlzY3Vzc2lvbiBvZiBnbG9iYWwgcGFj aW5nIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gInRyYW5zcG9ydCBndXlzIg0KDQpPSywgYmFzZWQg b24gdGhlIGRpc2N1c3Npb24sIEkgaGF2ZSBtYWRlIHRoZSBmb2xsb3dpbmcgUFIgZm9yIDUyNDVi aXM6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9wdWxsLzE5DQoNCg0K UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZSBsb2dpYyBhbmQgd29yZGluZyBhcmUgcmlnaHQuDQoN Ck9uIFdlZCwgT2N0IDE5LCAyMDE2IGF0IDEyOjI2IFBNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29n bGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KU291bmRzIGdvb2QgdG8gbWUu IFRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHRoaW5rIHRoaXMgdGhyb3VnaCwgZXZlbiB0 aG91Z2ggaXQgc2VlbXMgdG8gaGF2ZSAiY29sbGFwc2VkIiB0byB0aGUgc2FtZSBhbnN3ZXIuIEkg ZGVmaW5pdGVseSB0aGluayBpdCdzIHdvcnRod2hpbGUgcHV0dGluZyB0aGUgcmVhc29uaW5nIGlu dG8gdGhlIGRyYWZ0Lg0KDQpPbiBXZWQsIE9jdCAxOSwgMjAxNiBhdCA5OjE2IEFNLCBQZXRlciBU aGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29t Pj4gd3JvdGU6DQpKYW5hLCBhcmUgeW91IE9LIHdpdGggYSBnbG9iYWwgVGEgdmFsdWUgd2l0aCB0 ZXh0IGV4cGxhaW5pbmcgaG93IHdlIGFycml2ZWQgYXQgdGhhdCB2YWx1ZT8NCg0KDQoNCk9uIFN1 biwgT2N0IDE2LCAyMDE2IGF0IDU6MjIgQU0sIEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVs bC5jb208bWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tPj4gd3JvdGU6DQpJdCBsb29rcyBsaWtl IHRoZSBUYSB2YWx1ZSBzdWZmaWNlcywgYW5kIHRoZSBwcmlvciBkaXNjdXNzaW9uIHByb3ZpZGVz IGFzc3VyYW5jZSB0aGF0IHJlc2lkZW50aWFsIGVxdWlwbWVudCB3b24ndCBiZSBvdmVycnVuIC4u LiBidXQgZ2l2ZW4gdGhlIHN1YnRsZXR5IG9mIHRoZSBkaXNjdXNzaW9uIHRoYXQgcmVhY2hlZCB0 aGlzIHJlc3VsdCwgSSBzdHJvbmdseSByZWNvbW1lbmQgdGhhdCB3ZSBzaG93IG91ciB3b3JrIDst KS4gICBJbiBvdGhlciB3b3JkcywgdGhlIGRyYWZ0IHNob3VsZCBwcm92aWRlIGEgY29tcGxldGUg ZXhwbGFuYXRpb24gb2Ygb3VyIHJlYXNvbmluZywgYXMgYm90aCB0aGUgSUNFIHBhY2tldCBzaXpl IGFuZCB0aGUgNTAwbXMgdmFsdWUgYXJlIHNwZWNpZmljIHRvIHRoaXMgZGlzY3Vzc2lvbiwgbWFr aW5nIHRoZSBjb25jbHVzaW9uICpub3QqIGdlbmVyYWxseSBhcHBsaWNhYmxlLg0KDQpUaGFua3Ms IC0tRGF2aWQgKytTZW50IGZyb20gbXkgQW5kcm9pZCBub3Qtc28tc21hcnRwaG9uZSAuLi4NCg0K DQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tDQpGcm9tOiBQZXRlciBUaGF0Y2hl ciA8cHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPj4NCkRh dGU6IDEwLzE2LzE2IDc6MjEgQU0gKEdNVCswMTowMCkNClRvOiAiQmxhY2ssIERhdmlkIiA8ZGF2 aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbT4+DQpDYzogaWNlQGll dGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0ljZV0gQ29udGludWUg ZGlzY3Vzc2lvbiBvZiBnbG9iYWwgcGFjaW5nIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gInRyYW5z cG9ydCBndXlzIg0KDQpBc3N1bWluZyBJQ0UgY2hlY2tzIGFyZSBhcm91bmQgMTAwIG9jdGV0cyAo d2hpY2ggdGhleSBhcmUsIGFsbW9zdCksIHRoZW4gYSBNYXhQYWNrZXRzIG9mIDE1MCB3aXRoIGEg SFRPIG9mIDUwMG1zIGdpdmVzIGEgbWF4aW11bSBvZiBhYm91dCAzMDAgcGFja2V0cy9zZWMuICBC dXQgYSBUYSBvZiA1bXMgZ2l2ZXMgYSBtYXhpbXVtIG9mIDIwMCBwYWNrZXRzL3NlYy4gIFNvIHRo ZSBUYSB2YWx1ZSB3b3VsZCBlbmQgdXAgYmVpbmcgbW9yZSBzdHJpY3QuDQoNCkRvZXMgdGhhdCBt ZWFuIHRoZSBUYSB2YWx1ZSBvZiA1bXMgaXMgc3VmZmljaWVudGx5IHN0cmljdCB0byByZW5kZXIg dGhlIEhUTy9NYXhQYWNrZXQgcnVsZXMgdW5uZWNlc3Nhcnk/ICBDb3VsZCB3ZSBqdXN0IHJlZHVj ZSB0aGUgcnVsZXNldCBkb3duIHRvIGEgbWluIFRhIHZhbHVlIG9mIDVtcz8gIE9yIGRvIHlvdSB0 aGluayB0aG9zZSBydWxlcyBzdGlsbCBoYXZlIHZhbHVlPw0KDQpBbmQgYXMgZm9yIHRoZSBwYWNr ZXQgcmF0ZSwgcHJldmlvdXMgdG8gZGlzY3Vzc2luZyB3aXRoIHlvdSAidHJhbnNwb3J0IGd1eXMi LCB0aGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBpbiB0aGUgV0cgYWJvdXQgcGFja2V0IHJh dGVzLCBpbiBwYXJ0aWN1bGFyIHJhdGVzIG9mIG9wZW5pbmcgbmV3IE5BVCBiaW5kaW5ncyB3aXRo IHJlc2lkZW50aWFsIGVxdWlwbWVudC4gIEFmdGVyIGEgbG90IG9mIGRpc2N1c3Npb24gYW5kIGV4 cGVyaW1lbnRpbmcgaW4gdGhlIHRoZSByZWFsIHdvcmxkLCB3ZSBhZ3JlZWQgdGhhdCBhIGxvd2Vy IGJvdW5kIG9mIDVtcyBvbiB0aGUgVGEgd2FzIHN1ZmZpY2llbnQgdG8gY292ZXIgcGFja2V0IHJh dGVzIGFuZCByYXRlcyBvZiBvcGVuaW5nIE5BVCBiaW5kaW5ncy4gIEkgY2FuIGdpdmUgbW9yZSBo aXN0b3J5IG9uIHRoYXQgaWYgeW91J2QgbGlrZS4gICAgQnV0IHRoYXQgc3RpbGwgbGVmdCBhIGNv bmNlcm4gb3ZlciBiaXQgcmF0ZXMsIHdoaWNoIGlzIGhvdyB3ZSBlbmRlZCB1cCB0YWxraW5nIHRv IHlvdSA6KS4NCg0KDQoNCg0KDQoNCg0KDQoNCk9uIFdlZCwgU2VwIDI4LCAyMDE2IGF0IDg6NDUg QU0sIEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVsbC5jb208bWFpbHRvOkRhdmlkLkJsYWNr QGRlbGwuY29tPj4gd3JvdGU6DQpJJ20gYXBwYXJlbnRseSBvbmUgb2YgdGhlICJ0cmFuc3BvcnQg Z3V5cyIgcmVmZXJyZWQgdG8gaW4gdGhlIHN1YmplY3QgbGluZSA7LSkuDQoNCkluIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWNlL2N1cnJlbnQvbXNnMDAzNzguaHRtbCwg UGV0ZXIgVGhhdGNoZXINCmRlc2NyaWJlZCB0aGUgY3VycmVudCBwcm9wb3NhbDoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KMS4gIEEgbWF4aW11bSBudW1iZXIgb2Ygb3V0c3RhbmRpbmcgcmVx dWVzdCBwYWNrZXRzLCBjYWxsIGl0IE1heFBhY2tldHMgd2hpY2ggU0hPVUxEIGJlIDEwLg0KDQoy LiAgQSB0aW1lb3V0IGZvciByZXF1ZXN0IHBhY2tldHMsIGNhbGwgaXQgaGFuZHNoYWtlIHRpbWVv dXQgb3IgSFRPIHdoaWNoIFNIT1VMRCBiZSAyKlJUVCBpZiB0aGUgUlRUIGlzIGtub3duIGFuZCA1 MDBtcyBvdGhlcndpc2UuDQoNCjMuICBBIGdsb2JhbCBwYWNpbmcgcmF0ZSBvZiA1bXMgKGxpa2Ug YSBnbG9iYWwgVGEpLg0KDQpJZiBhbGwgcGFja2V0cyBhcmUgZHJvcHBlZCBhbmQgdGhlIFJUVCBp cyBub3Qga25vd24sIHRoZW4gMSsyIGFyZSBlZmZlY3RpdmVseSAyMCBwYWNrZXRzIHBlciBzZWNv bmQsDQp3ZWxsIGJlbG93IHdoYXQgeW91IHdvdWxkIGdldCB3aXRoIHRoZSBiaXRyYXRlIGxpbWl0 cyB3ZSB3ZXJlIGFza2luZyBmb3IuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoZXJlJ3Mg YmVlbiBzb21lIGZ1cnRoZXIgZGlzY3Vzc2lvbiB3aXRoIHRoZSAidHJhbnNwb3J0IGd1eXMiIGFi b3V0IHBhY2tldCBzaXplIGFuZCBiaXQgcmF0ZS4gICBJbiBlc3NlbmNlLCB0aGUgcmF0aW9uYWxl IGZvciAxMCBhcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygb3V0c3RhbmRpbmcgcmVxdWVzdCBwYWNr ZXRzIChpdGVtIDEgYWJvdmUpIGlzIGJhc2VkIG9uIHRoZSB0eXBpY2FsIFRDUCBzZWdtZW50IHNp emUgb2YgYWJvdXQgMTUwMCBieXRlcy4gIElDRSByZXF1ZXN0IHBhY2tldHMgdGVuZCB0byBiZSBt dWNoIHNtYWxsZXIsIDEwMCBieXRlcyBvciBsZXNzLCB3aGljaCBzdWdnZXN0cyB0aGF0IGEgZmFj dG9yIG9mIDE1IGNvdWxkIGJlIGF2YWlsYWJsZSBpZiBiaXQgcmF0ZSBtYXR0ZXJzIGJ1dCBwYWNr ZXQgY291bnQgZG9lc24ndC4gICAgVGhhdCBtYXkgd2VsbCBiZSB0aGUgY2FzZSAuLi4NCg0KUkZD IDcxNDEgKDIwMTQgQkNQIG9uIEFRTSBjb25maWd1cmF0aW9uL2ltcGxlbWVudGF0aW9uKSBzdXBw b3J0cyB0aGF0IHZpZXcgYnkgcmVjb21tZW5kaW5nIHRoYXQgQVFNIGltcGxlbWVudGF0aW9ucyBj b3VudCBvY3RldHMgKGkuZS4sIGZvcndhcmRpbmcgcmVzb3VyY2VzIGFyZSBiaXQtY29uZ2VzdGli bGUpIGFzIG9wcG9zZWQgdG8gY291bnRpbmcgcGFja2V0cyAoaS5lLiwgZm9yd2FyZGluZyByZXNv dXJjZXMgYXJlIG5vdCBwYWNrZXQtY29uZ2VzdGlibGUpLiAgVGhhdCBSRkMgZWZmZWN0aXZlbHkg YXNzZXJ0cyB0aGF0IHRoZSBjdXJyZW50IEludGVybmV0IGlzIGJpdC1jb25nZXN0aWJsZSBvbmx5 OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE0MQ0KDQpUaGF0IHdvdWxkIHN1Z2dl c3QgYSB2YWx1ZSBvZiAxNTAgZm9yIE1heFBhY2tldHMgKndoZW4qIGFsbCB0aGUgcGFja2V0cyBh cmUgMTAwIG9jdGV0cyBvciBsZXNzLCBhcyBzaG91bGQgYmUgY2FzZSBmb3IgSUNFIHJlcXVlc3Qg cGFja2V0cy4gIEEgcG9zc2libGUgYXJlYSBvZiBjb25jZXJuIChiYXNlZCBvbiBJQ0UgdXNlIGJ5 IFdlYiBSVEMpIGlzIHJlc2lkZW50aWFsIGdhdGV3YXkvTkFUIGJveGVzLCBidXQgdGhlIDVtcyBw YWNpbmcgKGl0ZW0gMyBhYm92ZSkgb3VnaHQgdG8gYmUgc3VmZmljaWVudCB0byBhdm9pZCBvdmVy cnVubmluZyB0aGVtLg0KDQpXaGF0IGRvIHBlb3BsZSB3aXRoIG1vcmUga25vd2xlZGdlIG9mIGFu ZC9vciBleHBlcmllbmNlIHdpdGggcmVzaWRlbnRpYWwgZ2F0ZXdheSBib3hlcyB0aGluayBvZiB0 aGlzIGxpbmUgb2YgcmVhc29uaW5nPw0KDQpUaGFua3MsIC0tRGF2aWQNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCklj ZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pY2UNCg0KDQoNCg0K --_000_CE03DB3D7B45C245BCA0D243277949362F6FC3E0MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5v bmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUGV0ZXIsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Tb21lIGNvbW1lbnRzIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsmbmJzcDsgJmx0O3QmZ3Q7U3RhcnQg d2l0aCB0aGUgZm9sbG93aW5nIHJ1bGVzIHdoaWNoIHdvdWxkIGJlIGdlbmVyYWxseTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOyZuYnNwOyBhcHBsaWNhYmxlIHRvIHRyYW5zcG9y dCBwcm90b2NvbHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7Jm5ic3A7ICZs dDtsaXN0IHN0eWxlPSZxdW90O251bWJlcnMmcXVvdDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt0Jmd0O0xldCBNYXhQYWNrZXRz IGJlIHRoZSBtYXhpbXVtIG51bWJlciBvZiB0cmFuc2FjdGlvbnMgYWxsb3dlZCB0byBiZSBvdXRz dGFuZGluZyBpbiB0aGUgbmV0d29yayBhdCBhbnkgdGltZSwgd2hpY2ggU0hPVUxEIGJlIDEwLiZs dDsvdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0O3QmZ3Q7TGV0IEhUTyBiZSB0aGUgdHJhbnNhY3Rpb24gdGltZW91dCwgd2hpY2gg U0hPVUxEIGJlIDIqUlRUIGlmIFJUVCBpcyBrbm93biBhbmQgNTAwbXMgb3RoZXJ3aXNlLiZsdDsv dCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0O3QmZ3Q7TGV0IE1pblBhY2luZyBiZSB0aGUgbWluaW11bSBwYWNpbmcgaW50ZXJ2YWwg YmV0d2VlbiB0cmFuc2FjdGlvbnMsIHdoaWNoIFNIT1VMRCBiZSA1bXMuJmx0Oy90Jmd0OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOyZuYnNwOyAmbHQ7L2xpc3QmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5J4oCZZCBjaXRlIHJlZmVyZW5jZXMgZm9yIGF0IGxlYXN0IHRoZSBmaXJzdCB0d28gb2Yg dGhlIGxpc3QgaXRlbXMsIGlmIG5vdCBhbGwgdGhyZWUuJm5ic3A7IFRoZSBmaXJzdCBpdGVtIGlz IGJhc2VkIG9uIFRDUCBJbml0aWFsIFdpbmRvdyBvZiAxMCBzZWdtZW50cywgd2hpY2ggSSBiZWxp ZXZlDQogaXMgUkZDIDY5MjggKEphbmEgd2lsbCBrbm93IGZvciBjZXJ0YWluKS4mbmJzcDsgVGhl IHNlY29uZCBpdGVtIGlzICo8Yj5ub3Q8L2I+KiBnZW5lcmFsIC0gNTAwbXMgaXMgc3BlY2lmaWMg dG8gU1RVTiwgYW5kIGNvbWVzIGZyb20gUkZDIDUzODkgKGNyZWRpdCB0byBCZXJuYXJkIEFib2Jh IGZvciBmaW5kaW5nIHRoaXM6DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2ljZS9jdXJyZW50L21zZzAwMzc5Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvaWNlL2N1cnJlbnQvbXNnMDAzNzkuaHRtbDwvYT4pIC0gdGhhdOKA mXMgaW1wb3J0YW50IGJlY2F1c2UgdGhlIGdlbmVyYWxseSBhcHBsaWNhYmxlIG51bWJlciBpcyBs YXJnZXIgLSBib3RoIFJGQyA2Mjk4IGFuZCBkcmFmdC1pZXRmLXRzdndnLXJmYzU0MDViaXMNCiB1 c2UgMSBzZWNvbmQgZm9yIFRDUCBhbmQgVURQLCByZXNwZWN0aXZlbHkuICZuYnNwO0ZvciB0aGUg dGhpcmQgaXRlbSwgSSBob3BlIHRoZSByYXRpb25hbGUgZm9yIHRoZSA1bXMgcGFjaW5nIGludGVy dmFsIGlzIGV4cGxhaW5lZCBlbHNld2hlcmUgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0Mzsm bmJzcDsmbmJzcDsmbmJzcDsgT2JzZXJ2ZSB0aGF0IElDRSB0cmFuc2FjdGlvbnMgYXJlIHR5cGlj YWxseSBhcm91bmQgMTAwIGJ5dGVzIG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlc3MsIHdoaWNoIG1ha2VzIGl0IHJlYXNvbmFibGUgdG8g aW5jcmVhc2UgTWF4UGFja2V0cyB0byBhYm91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyAxNTAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZGQg4oCcYmVjYXVzZSAx NTAwIGJ5dGVzIGlzIGEgdHlwaWNhbCBUQ1Agc2VnbWVudCBzaXpl4oCdIHRvIHRoZSBlbmQgb2Yg dGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBQZXRlciBUaGF0Y2hlciBbbWFpbHRvOnB0aGF0Y2hlckBnb29n bGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAyNiwgMjAxNiAx MDowMCBBTTxicj4NCjxiPlRvOjwvYj4gSmFuYSBJeWVuZ2FyPGJyPg0KPGI+Q2M6PC9iPiBCbGFj aywgRGF2aWQ7IGljZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0ljZV0gQ29u dGludWUgZGlzY3Vzc2lvbiBvZiBnbG9iYWwgcGFjaW5nIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20g JnF1b3Q7dHJhbnNwb3J0IGd1eXMmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PSywgYmFzZWQgb24gdGhl IGRpc2N1c3Npb24sIEkgaGF2ZSBtYWRlIHRoZSBmb2xsb3dpbmcgUFIgZm9yIDUyNDViaXM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v aWNlLXdnL3JmYzUyNDViaXMvcHVsbC8xOSI+aHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9yZmM1 MjQ1YmlzL3B1bGwvMTk8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QbGVhc2UgbGV0IG1lIGtub3cgaWYg dGhlIGxvZ2ljIGFuZCB3b3JkaW5nIGFyZSByaWdodC4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9jdCAx OSwgMjAxNiBhdCAxMjoyNiBQTSwgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJp QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvdW5kcyBnb29k IHRvIG1lLiBUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byB0aGluayB0aGlzIHRocm91Z2gs IGV2ZW4gdGhvdWdoIGl0IHNlZW1zIHRvIGhhdmUgJnF1b3Q7Y29sbGFwc2VkJnF1b3Q7IHRvIHRo ZSBzYW1lIGFuc3dlci4gSSBkZWZpbml0ZWx5IHRoaW5rIGl0J3Mgd29ydGh3aGlsZSBwdXR0aW5n IHRoZSByZWFzb25pbmcgaW50byB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDE5LCAyMDE2IGF0 IDk6MTYgQU0sIFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SmFuYSwgYXJlIHlvdSBPSyB3aXRoIGEgZ2xvYmFsIFRhIHZhbHVlIHdpdGggdGV4 dCBleHBsYWluaW5nIGhvdyB3ZSBhcnJpdmVkIGF0IHRoYXQgdmFsdWU/ICZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBPY3QgMTYsIDIwMTYgYXQg NToyMiBBTSwgQmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJtYWlsdG86RGF2aWQuQmxhY2tAZGVs bC5jb20iIHRhcmdldD0iX2JsYW5rIj5EYXZpZC5CbGFja0BkZWxsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBs b29rcyBsaWtlIHRoZSBUYSB2YWx1ZSBzdWZmaWNlcywgYW5kIHRoZSBwcmlvciBkaXNjdXNzaW9u IHByb3ZpZGVzIGFzc3VyYW5jZSB0aGF0IHJlc2lkZW50aWFsIGVxdWlwbWVudCB3b24ndCBiZSBv dmVycnVuIC4uLiBidXQgZ2l2ZW4gdGhlIHN1YnRsZXR5IG9mIHRoZSBkaXNjdXNzaW9uIHRoYXQg cmVhY2hlZCB0aGlzIHJlc3VsdCwgSSBzdHJvbmdseSByZWNvbW1lbmQgdGhhdCB3ZSBzaG93IG91 ciB3b3JrDQogOy0pLiAmbmJzcDsgSW4gb3RoZXIgd29yZHMsIHRoZSBkcmFmdCBzaG91bGQgcHJv dmlkZSBhIGNvbXBsZXRlIGV4cGxhbmF0aW9uIG9mIG91ciByZWFzb25pbmcsIGFzIGJvdGggdGhl IElDRSBwYWNrZXQgc2l6ZSBhbmQgdGhlIDUwMG1zIHZhbHVlIGFyZSBzcGVjaWZpYyB0byB0aGlz IGRpc2N1c3Npb24sIG1ha2luZyB0aGUgY29uY2x1c2lvbiAqbm90KiBnZW5lcmFsbHkgYXBwbGlj YWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy02Njc5MjY0 OTg3MzE1NTM5ODcwbV8tMTU2ODMxMjg0NzYzNzUxNjg2NW1fODIwNDk2MDQ4NjExOTk5MjAyNG1f LTIzNjc5ODU4NTI5OTAyNjQ0NTdjb21wb3Nlcl9zaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiM1NzU3NTci PlRoYW5rcywgLS1EYXZpZCAmIzQzOyYjNDM7U2VudCBmcm9tIG15IEFuZHJvaWQgbm90LXNvLXNt YXJ0cGhvbmUgLi4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZyb206IFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86 cHRoYXRjaGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5wdGhhdGNoZXJAZ29vZ2xlLmNv bTwvYT4mZ3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRhdGU6IDEwLzE2LzE2IDc6MjEgQU0gKEdNVCYjNDM7MDE6MDApIDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG86ICZxdW90O0JsYWNr LCBEYXZpZCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20iIHRh cmdldD0iX2JsYW5rIj5kYXZpZC5ibGFja0BlbWMuY29tPC9hPiZndDsNCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2M6IDxhIGhyZWY9Im1haWx0 bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2VAaWV0Zi5vcmc8L2E+DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YmplY3Q6IFJl OiBbSWNlXSBDb250aW51ZSBkaXNjdXNzaW9uIG9mIGdsb2JhbCBwYWNpbmcgYmFzZWQgb24gZmVl ZGJhY2sgZnJvbSAmcXVvdDt0cmFuc3BvcnQgZ3V5cyZxdW90Ow0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkFzc3VtaW5nIElDRSBjaGVja3MgYXJlIGFyb3VuZCAxMDAgb2N0ZXRzICh3aGljaCB0aGV5 IGFyZSwgYWxtb3N0KSwgdGhlbiBhIE1heFBhY2tldHMgb2YgMTUwIHdpdGggYSBIVE8gb2YgNTAw bXMgZ2l2ZXMgYSBtYXhpbXVtIG9mIGFib3V0IDMwMCBwYWNrZXRzL3NlYy4mbmJzcDsgQnV0IGEg VGEgb2YgNW1zIGdpdmVzIGEgbWF4aW11bSBvZg0KIDIwMCBwYWNrZXRzL3NlYy4mbmJzcDsgU28g dGhlIFRhIHZhbHVlIHdvdWxkIGVuZCB1cCBiZWluZyBtb3JlIHN0cmljdC4mbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRvZXMgdGhhdCBtZWFuIHRoZSBUYSB2YWx1 ZSBvZiA1bXMgaXMgc3VmZmljaWVudGx5IHN0cmljdCB0byByZW5kZXIgdGhlIEhUTy9NYXhQYWNr ZXQgcnVsZXMgdW5uZWNlc3Nhcnk/Jm5ic3A7IENvdWxkIHdlIGp1c3QgcmVkdWNlIHRoZSBydWxl c2V0IGRvd24gdG8gYSBtaW4gVGEgdmFsdWUgb2YgNW1zPyZuYnNwOyBPciBkbyB5b3UgdGhpbmsg dGhvc2UNCiBydWxlcyBzdGlsbCBoYXZlIHZhbHVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+QW5kIGFzIGZvciB0aGUgcGFja2V0IHJhdGUsIHByZXZpb3VzIHRvIGRpc2N1c3Npbmcg d2l0aCB5b3UgJnF1b3Q7dHJhbnNwb3J0IGd1eXMmcXVvdDssIHRoZXJlIHdhcyBhIGxvdCBvZiBk aXNjdXNzaW9uIGluIHRoZSBXRyBhYm91dCBwYWNrZXQgcmF0ZXMsIGluIHBhcnRpY3VsYXIgcmF0 ZXMgb2Ygb3BlbmluZyBuZXcgTkFUIGJpbmRpbmdzIHdpdGgNCiByZXNpZGVudGlhbCBlcXVpcG1l bnQuJm5ic3A7IEFmdGVyIGEgbG90IG9mIGRpc2N1c3Npb24gYW5kIGV4cGVyaW1lbnRpbmcgaW4g dGhlIHRoZSByZWFsIHdvcmxkLCB3ZSBhZ3JlZWQgdGhhdCBhIGxvd2VyIGJvdW5kIG9mIDVtcyBv biB0aGUgVGEgd2FzIHN1ZmZpY2llbnQgdG8gY292ZXIgcGFja2V0IHJhdGVzIGFuZCByYXRlcyBv ZiBvcGVuaW5nIE5BVCBiaW5kaW5ncy4mbmJzcDsgSSBjYW4gZ2l2ZSBtb3JlIGhpc3Rvcnkgb24g dGhhdCBpZiB5b3UnZCBsaWtlLg0KICZuYnNwOyAmbmJzcDtCdXQgdGhhdCBzdGlsbCBsZWZ0IGEg Y29uY2VybiBvdmVyIGJpdCByYXRlcywgd2hpY2ggaXMgaG93IHdlIGVuZGVkIHVwIHRhbGtpbmcg dG8geW91IDopLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBTZXAg MjgsIDIwMTYgYXQgODo0NSBBTSwgQmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJtYWlsdG86RGF2 aWQuQmxhY2tAZGVsbC5jb20iIHRhcmdldD0iX2JsYW5rIj5EYXZpZC5CbGFja0BkZWxsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGFw cGFyZW50bHkgb25lIG9mIHRoZSAmcXVvdDt0cmFuc3BvcnQgZ3V5cyZxdW90OyByZWZlcnJlZCB0 byBpbiB0aGUgc3ViamVjdCBsaW5lIDstKS48YnI+DQo8YnI+DQpJbiA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ljZS9jdXJyZW50L21zZzAwMzc4Lmh0bWwi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv aWNlL2N1cnJlbnQvbXNnMDAzNzguaHRtbDwvYT4sIFBldGVyIFRoYXRjaGVyPGJyPg0KZGVzY3Jp YmVkIHRoZSBjdXJyZW50IHByb3Bvc2FsOjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQoxLiZuYnNwOyBBIG1heGltdW0gbnVtYmVyIG9mIG91dHN0YW5kaW5nIHJlcXVlc3Qg cGFja2V0cywgY2FsbCBpdCBNYXhQYWNrZXRzIHdoaWNoIFNIT1VMRCBiZSAxMC48YnI+DQo8YnI+ DQoyLiZuYnNwOyBBIHRpbWVvdXQgZm9yIHJlcXVlc3QgcGFja2V0cywgY2FsbCBpdCBoYW5kc2hh a2UgdGltZW91dCBvciBIVE8gd2hpY2ggU0hPVUxEIGJlIDIqUlRUIGlmIHRoZSBSVFQgaXMga25v d24gYW5kIDUwMG1zIG90aGVyd2lzZS48YnI+DQo8YnI+DQozLiZuYnNwOyBBIGdsb2JhbCBwYWNp bmcgcmF0ZSBvZiA1bXMgKGxpa2UgYSBnbG9iYWwgVGEpLjxicj4NCjxicj4NCklmIGFsbCBwYWNr ZXRzIGFyZSBkcm9wcGVkIGFuZCB0aGUgUlRUIGlzIG5vdCBrbm93biwgdGhlbiAxJiM0MzsyIGFy ZSBlZmZlY3RpdmVseSAyMCBwYWNrZXRzIHBlciBzZWNvbmQsPGJyPg0Kd2VsbCBiZWxvdyB3aGF0 IHlvdSB3b3VsZCBnZXQgd2l0aCB0aGUgYml0cmF0ZSBsaW1pdHMgd2Ugd2VyZSBhc2tpbmcgZm9y Ljxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaGVyZSdzIGJlZW4gc29t ZSBmdXJ0aGVyIGRpc2N1c3Npb24gd2l0aCB0aGUgJnF1b3Q7dHJhbnNwb3J0IGd1eXMmcXVvdDsg YWJvdXQgcGFja2V0IHNpemUgYW5kIGJpdCByYXRlLiZuYnNwOyAmbmJzcDtJbiBlc3NlbmNlLCB0 aGUgcmF0aW9uYWxlIGZvciAxMCBhcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygb3V0c3RhbmRpbmcg cmVxdWVzdCBwYWNrZXRzIChpdGVtIDEgYWJvdmUpIGlzIGJhc2VkIG9uIHRoZSB0eXBpY2FsIFRD UCBzZWdtZW50IHNpemUgb2YgYWJvdXQgMTUwMCBieXRlcy4mbmJzcDsNCiBJQ0UgcmVxdWVzdCBw YWNrZXRzIHRlbmQgdG8gYmUgbXVjaCBzbWFsbGVyLCAxMDAgYnl0ZXMgb3IgbGVzcywgd2hpY2gg c3VnZ2VzdHMgdGhhdCBhIGZhY3RvciBvZiAxNSBjb3VsZCBiZSBhdmFpbGFibGUgaWYgYml0IHJh dGUgbWF0dGVycyBidXQgcGFja2V0IGNvdW50IGRvZXNuJ3QuJm5ic3A7ICZuYnNwOyBUaGF0IG1h eSB3ZWxsIGJlIHRoZSBjYXNlIC4uLjxicj4NCjxicj4NClJGQyA3MTQxICgyMDE0IEJDUCBvbiBB UU0gY29uZmlndXJhdGlvbi9pbXBsZW1lbnRhdGlvbikgc3VwcG9ydHMgdGhhdCB2aWV3IGJ5IHJl Y29tbWVuZGluZyB0aGF0IEFRTSBpbXBsZW1lbnRhdGlvbnMgY291bnQgb2N0ZXRzIChpLmUuLCBm b3J3YXJkaW5nIHJlc291cmNlcyBhcmUgYml0LWNvbmdlc3RpYmxlKSBhcyBvcHBvc2VkIHRvIGNv dW50aW5nIHBhY2tldHMgKGkuZS4sIGZvcndhcmRpbmcgcmVzb3VyY2VzIGFyZSBub3QgcGFja2V0 LWNvbmdlc3RpYmxlKS4mbmJzcDsNCiBUaGF0IFJGQyBlZmZlY3RpdmVseSBhc3NlcnRzIHRoYXQg dGhlIGN1cnJlbnQgSW50ZXJuZXQgaXMgYml0LWNvbmdlc3RpYmxlIG9ubHk6IDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTQxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE0MTwvYT48YnI+DQo8YnI+DQpUaGF0IHdvdWxk IHN1Z2dlc3QgYSB2YWx1ZSBvZiAxNTAgZm9yIE1heFBhY2tldHMgKndoZW4qIGFsbCB0aGUgcGFj a2V0cyBhcmUgMTAwIG9jdGV0cyBvciBsZXNzLCBhcyBzaG91bGQgYmUgY2FzZSBmb3IgSUNFIHJl cXVlc3QgcGFja2V0cy4mbmJzcDsgQSBwb3NzaWJsZSBhcmVhIG9mIGNvbmNlcm4gKGJhc2VkIG9u IElDRSB1c2UgYnkgV2ViIFJUQykgaXMgcmVzaWRlbnRpYWwgZ2F0ZXdheS9OQVQgYm94ZXMsIGJ1 dCB0aGUgNW1zIHBhY2luZyAoaXRlbSAzDQogYWJvdmUpIG91Z2h0IHRvIGJlIHN1ZmZpY2llbnQg dG8gYXZvaWQgb3ZlcnJ1bm5pbmcgdGhlbS48YnI+DQo8YnI+DQpXaGF0IGRvIHBlb3BsZSB3aXRo IG1vcmUga25vd2xlZGdlIG9mIGFuZC9vciBleHBlcmllbmNlIHdpdGggcmVzaWRlbnRpYWwgZ2F0 ZXdheSBib3hlcyB0aGluayBvZiB0aGlzIGxpbmUgb2YgcmVhc29uaW5nPzxicj4NCjxicj4NClRo YW5rcywgLS1EYXZpZDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KSWNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949362F6FC3E0MX307CL04corpem_-- From nobody Thu Oct 27 15:19:46 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140041297BE for ; Thu, 27 Oct 2016 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, 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 Zt2OCzVcqoIy for ; Thu, 27 Oct 2016 15:19:43 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DBC129973 for ; Thu, 27 Oct 2016 15:19:42 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 51so22958222uai.1 for ; Thu, 27 Oct 2016 15:19:42 -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=uzDt3Fz40dr8mBjq0Ji14BE+nuY0FFk2rrmgm4uV+GA=; b=evjh57oUIoFwHQfF2+tNmuvqui2m3H8shFMpcjgyuQT9271Darzkj+ipCQ8/iO+B8B V33zaerMZ8GECZJuQ7OKc84rY6H5NwURsMDaFkHncS63ots0bEYoiTVkAAZMEBlKCNK0 vxPOH4M9mXTH/+dFPmIaP8LK99lXRnqmQSADfdh2LhuxpR/w1m3MXRHV9PbKcQ5FE78B UBEPyh9VZy3msFk4w2VXhGlU2NEV2h+LlqRzGyIv6S75cWGZGEs54ds0oQY6FNbc+V1C bUjs++g8jmSW8eb4G9GGJZQM48bixsUM4Pymw1P7TQ3QuKrL6ZTaNpWoKmYwgSsiGYqK Tm+A== 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=uzDt3Fz40dr8mBjq0Ji14BE+nuY0FFk2rrmgm4uV+GA=; b=H5DE0vQ7whju4PmdmVxeV1dRfkEZf2pOI2d+xSnDubSyrkDSyGVzLwCCrF8xCpFRcE HP2iQ0WtaCN0fpJDVHvlpIB/gz6s6VUuBlyaNBCEkgugekWCnuTMVICbyov791C8p3uY xoLL/ZraagL0Xi4fLgBs4to5qgV5hOLMKUN9SXwHP2B4s3fnC1cPepFmMcWEqni/lATS F7bLDjoX0Tpty4Ue2oqQ3WXotzTLyZbHdqbKE4dXfINNTUJJL54gIhgmzVzs+CH768Rn mLYXINMrQwIA0vcBIaAEpGd+0UTf5kcLk+3ZfgUrTgKWQx7dzqWD5Nnowf9y+/FzNq+S lWCg== X-Gm-Message-State: ABUngveBEQjLt7qOfvxQGJA9OJUUpXIL0jfxIjgNOYfvIyNtkwj/uZRF8zGGKUB9cSrRLSnw4/tQzy25K7b2DoAK X-Received: by 10.176.86.81 with SMTP id z17mr412341uaa.77.1477606781630; Thu, 27 Oct 2016 15:19:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Thu, 27 Oct 2016 15:19:41 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 27 Oct 2016 15:19:41 -0700 Message-ID: To: "Black, David" Content-Type: multipart/alternative; boundary=f403045ddd9256779c053fe02380 Archived-At: Cc: Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 22:19:45 -0000 --f403045ddd9256779c053fe02380 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2016 at 1:49 PM, Black, David wrote: > Hi Peter, > > > > Some comments ... > > > > + Start with the following rules which would be generally > > + applicable to transport protocols: > > + > > + Let MaxPackets be the maximum number of transactions allowed to b= e > outstanding in the network at any time, which SHOULD be 10. > > + Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT > is known and 500ms otherwise. > > + Let MinPacing be the minimum pacing interval between transactions= , > which SHOULD be 5ms. > > + > > > > I=E2=80=99d cite references for at least the first two of the list items,= if not > all three. The first item is based on TCP Initial Window of 10 segments, > which I believe is RFC 6928 (Jana will know for certain). The second > Yes, RFC 6928 is right. I think this text could be made more precise: "Let MaxBytes be the maximum number of bytes allowed to be outstanding in the network at start-up, which SHOULD be 14600 bytes [RFC6928]." > item is **not** general - 500ms is specific to STUN, and comes from RFC > 5389 (credit to Bernard Aboba for finding this: https://www.ietf.org/mail= - > archive/web/ice/current/msg00379.html) - that=E2=80=99s important because= the > generally applicable number is larger - both RFC 6298 and > draft-ietf-tsvwg-rfc5405bis use 1 second for TCP and UDP, respectively. > Additionally, my reasoning for this was as follows (if you want to add this to the rationale.) The TCP initial RTO is 1 sec (RFC 6298), and the HTO can be less conservative, since an expected case is that no responses are received even if the network is perfect. For the third item, I hope the rationale for the 5ms pacing interval is > explained elsewhere in the draft. > > > > + Observe that ICE transactions are typically around 100 bytes or > > + less, which makes it reasonable to increase MaxPackets to about > > + 150. > > > > Add =E2=80=9Cbecause 1500 bytes is a typical TCP segment size=E2=80=9D to= the end of this. > If you use the byte-limit from RFC 6928 above you won't need to specify TCP segment size, and you would change MaxPackets to MaxBytes. - jana > Thanks, --David > > > > *From:* Peter Thatcher [mailto:pthatcher@google.com] > *Sent:* Wednesday, October 26, 2016 10:00 AM > *To:* Jana Iyengar > *Cc:* Black, David; ice@ietf.org > > *Subject:* Re: [Ice] Continue discussion of global pacing based on > feedback from "transport guys" > > > > OK, based on the discussion, I have made the following PR for 5245bis: > > > > https://github.com/ice-wg/rfc5245bis/pull/19 > > > > > > Please let me know if the logic and wording are right. > > > > On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar wrote: > > Sounds good to me. Thanks for taking the time to think this through, even > though it seems to have "collapsed" to the same answer. I definitely thin= k > it's worthwhile putting the reasoning into the draft. > > > > On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher > wrote: > > Jana, are you OK with a global Ta value with text explaining how we > arrived at that value? > > > > > > > > On Sun, Oct 16, 2016 at 5:22 AM, Black, David > wrote: > > It looks like the Ta value suffices, and the prior discussion provides > assurance that residential equipment won't be overrun ... but given the > subtlety of the discussion that reached this result, I strongly recommend > that we show our work ;-). In other words, the draft should provide a > complete explanation of our reasoning, as both the ICE packet size and th= e > 500ms value are specific to this discussion, making the conclusion *not* > generally applicable. > > > > Thanks, --David ++Sent from my Android not-so-smartphone ... > > > > > > -------- Original message -------- > > From: Peter Thatcher > > Date: 10/16/16 7:21 AM (GMT+01:00) > > To: "Black, David" > > Cc: ice@ietf.org > > Subject: Re: [Ice] Continue discussion of global pacing based on feedback > from "transport guys" > > > > Assuming ICE checks are around 100 octets (which they are, almost), then = a > MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 > packets/sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the > Ta value would end up being more strict. > > > > Does that mean the Ta value of 5ms is sufficiently strict to render the > HTO/MaxPacket rules unnecessary? Could we just reduce the ruleset down t= o > a min Ta value of 5ms? Or do you think those rules still have value? > > > > And as for the packet rate, previous to discussing with you "transport > guys", there was a lot of discussion in the WG about packet rates, in > particular rates of opening new NAT bindings with residential equipment. > After a lot of discussion and experimenting in the the real world, we > agreed that a lower bound of 5ms on the Ta was sufficient to cover packet > rates and rates of opening NAT bindings. I can give more history on that > if you'd like. But that still left a concern over bit rates, which is > how we ended up talking to you :). > > > > > > > > > > > > > > > > > > > > On Wed, Sep 28, 2016 at 8:45 AM, Black, David > wrote: > > I'm apparently one of the "transport guys" referred to in the subject lin= e > ;-). > > In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter > Thatcher > described the current proposal: > > ---------------------- > 1. A maximum number of outstanding request packets, call it MaxPackets > which SHOULD be 10. > > 2. A timeout for request packets, call it handshake timeout or HTO which > SHOULD be 2*RTT if the RTT is known and 500ms otherwise. > > 3. A global pacing rate of 5ms (like a global Ta). > > If all packets are dropped and the RTT is not known, then 1+2 are > effectively 20 packets per second, > well below what you would get with the bitrate limits we were asking for. > ---------------------- > > There's been some further discussion with the "transport guys" about > packet size and bit rate. In essence, the rationale for 10 as the maxim= um > number of outstanding request packets (item 1 above) is based on the > typical TCP segment size of about 1500 bytes. ICE request packets tend t= o > be much smaller, 100 bytes or less, which suggests that a factor of 15 > could be available if bit rate matters but packet count doesn't. That > may well be the case ... > > RFC 7141 (2014 BCP on AQM configuration/implementation) supports that vie= w > by recommending that AQM implementations count octets (i.e., forwarding > resources are bit-congestible) as opposed to counting packets (i.e., > forwarding resources are not packet-congestible). That RFC effectively > asserts that the current Internet is bit-congestible only: > https://tools.ietf.org/html/rfc7141 > > That would suggest a value of 150 for MaxPackets *when* all the packets > are 100 octets or less, as should be case for ICE request packets. A > possible area of concern (based on ICE use by Web RTC) is residential > gateway/NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficie= nt > to avoid overrunning them. > > What do people with more knowledge of and/or experience with residential > gateway boxes think of this line of reasoning? > > Thanks, --David > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > > > > > > > --f403045ddd9256779c053fe02380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
                                On T= hu, Oct 27, 2016 at 1:49 PM, Black, David <David.Black@dell.com>= wrote:

                                Hi Peter,

                                =C2=A0

                                Some comments ...

                                =C2=A0

                                +=C2=A0 <t>Start with the following ru= les which would be generally

                                +=C2=A0 applicable to transport protocols:

                                +=C2=A0 <list style=3D"numbers"= >

                                +=C2=A0=C2=A0=C2=A0 <t>Let MaxPackets = be the maximum number of transactions allowed to be outstanding in the netw= ork at any time, which SHOULD be 10.</t>

                                +=C2=A0=C2=A0=C2=A0 <t>Let HTO be the = transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms otherw= ise.</t>

                                +=C2=A0=C2=A0=C2=A0 <t>Let MinPacing b= e the minimum pacing interval between transactions, which SHOULD be 5ms.<= ;/t>

                                +=C2=A0 </list>

                                =C2=A0

                                I=E2=80=99d cite references for at least the= first two of the list items, if not all three.=C2=A0 The first item is bas= ed on TCP Initial Window of 10 segments, which I believe is RFC 6928 (Jana will know for certain).=C2=A0 The second


                                Yes, RFC 6928 is right. I think th= is text could be made more precise: "Let MaxBytes be the maximum numbe= r of bytes allowed to be outstanding in the network at start-up, which SHOU= LD be 14600 bytes [RFC6928]."
                                =C2=A0

                                item is *not* general - 500ms is specific to STUN, and comes from RFC 5389 (cre= dit to Bernard Aboba for finding this: https://www.ietf.org/mail-archive/web/ice/current/<= wbr>msg00379.html) - that=E2=80=99s important because the generally app= licable number is larger - both RFC 6298 and draft-ietf-tsvwg-rfc5405bis use 1 second for TCP and UDP, respectively. =C2=A0

                                <= /blockquote>

                                Additionally, my reasoning for this was as = follows (if you want to add this to the rationale.) The TCP initial RTO is = 1 sec (RFC 6298), and the HTO can be less conservative, since an expected c= ase is that no responses are received even if the network is perfect.
                                =

                                For the third item, I hope the rationale for the 5ms= pacing interval is explained elsewhere in the draft.<= /p>

                                =C2=A0

                                +=C2=A0=C2=A0=C2=A0 Observe that ICE transac= tions are typically around 100 bytes or

                                +=C2=A0=C2=A0=C2=A0 less, which makes it rea= sonable to increase MaxPackets to about

                                +=C2=A0=C2=A0=C2=A0 150.

                                =C2=A0

                                Add =E2=80=9Cbecause 1500 bytes is a typical= TCP segment size=E2=80=9D to the end of this.


                                If you use the byte-limit from RFC 6928 above yo= u won't need to specify TCP segment size, and you would change MaxPacke= ts to MaxBytes.

                                - jana
                                =C2=A0

                                Thanks, --David

                                =C2=A0

                                From: Peter Thatcher [mailto:pthatcher@google.com]
                                Sent: Wednesday, October 26, 2016 10:00 AM
                                To: Jana Iyengar
                                Cc: Black, David; = ice@ietf.org


                                Subject: Re: [Ice] Continue discussion of global pacing based on fee= dback from "transport guys"

                                =C2=A0

                                OK, bas= ed on the discussion, I have made the following PR for 5245bis:

                                = =C2=A0

                                =C2=A0

                                =C2=A0

                                Please = let me know if the logic and wording are right. =C2=A0=

                                =C2=A0

                                On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar <<= a href=3D"mailto:jri@google.com" target=3D"_blank">jri@google.com> w= rote:

                                Sounds good to me. Thanks for taking the time to thi= nk this through, even though it seems to have "collapsed" to the = same answer. I definitely think it's worthwhile putting the reasoning i= nto the draft.

                                =C2=A0

                                On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher <= pthatcher@google.= com> wrote:

                                Jana, a= re you OK with a global Ta value with text explaining how we arrived at tha= t value? =C2=A0=C2=A0

                                = =C2=A0

                                = =C2=A0

                                =C2=A0

                                On Sun, Oct 16, 2016 at 5:22 AM, Black, David <David.Black@dell.co= m> wrote:

                                It looks like the Ta value suffices, and the prior d= iscussion provides assurance that residential equipment won't be overru= n ... but given the subtlety of the discussion that reached this result, I = strongly recommend that we show our work ;-). =C2=A0 In other words, the draft should provide a complete explanatio= n of our reasoning, as both the ICE packet size and the 500ms value are spe= cific to this discussion, making the conclusion *not* generally applicable.= =C2=A0

                                =C2=A0

                                T= hanks, --David ++Sent from my Android not-so-smartphone ...

                                =C2=A0

                                =C2=A0

                                -------- Original message --------

                                From: Peter Thatcher <pthatcher@google.com>

                                Date: 10/16/16 7:21 AM (GMT+01:00)

                                To: "Black, David" <david.black@emc.com>

                                Subject: Re: [Ice] Continue discussion of global pac= ing based on feedback from "transport guys"

                                =C2=A0

                                Assumin= g ICE checks are around 100 octets (which they are, almost), then a MaxPack= ets of 150 with a HTO of 500ms gives a maximum of about 300 packets/sec.=C2= =A0 But a Ta of 5ms gives a maximum of 200 packets/sec.=C2=A0 So the Ta value would end up being more strict.=C2= =A0=C2=A0

                                = =C2=A0

                                Does th= at mean the Ta value of 5ms is sufficiently strict to render the HTO/MaxPac= ket rules unnecessary?=C2=A0 Could we just reduce the ruleset down to a min= Ta value of 5ms?=C2=A0 Or do you think those rules still have value?

                                = =C2=A0

                                And as = for the packet rate, previous to discussing with you "transport guys&q= uot;, there was a lot of discussion in the WG about packet rates, in partic= ular rates of opening new NAT bindings with residential equipment.=C2=A0 After a lot of discussion and experimenting i= n the the real world, we agreed that a lower bound of 5ms on the Ta was suf= ficient to cover packet rates and rates of opening NAT bindings.=C2=A0 I ca= n give more history on that if you'd like. =C2=A0 =C2=A0But that still left a concern over bit rates, which is how we= ended up talking to you :).

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                =C2=A0

                                On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@dell.co= m> wrote:

                                I'm apparently one of the "transport guys&q= uot; referred to in the subject line ;-).

                                In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
                                described the current proposal:

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

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

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

                                If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second,
                                well below what you would get with the bitrate limits we were asking for. ----------------------

                                There's been some further discussion with the "transport guys"= ; about packet size and bit rate.=C2=A0 =C2=A0In essence, the rationale for= 10 as the maximum number of outstanding request packets (item 1 above) is = based on the typical TCP segment size of about 1500 bytes.=C2=A0 ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.=C2=A0 =C2=A0 That may well be the case ...

                                RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).=C2=A0 That RFC effectively asserts that the current Internet is bit-congestible = only:                                 https://tools.ietf.org/html/rfc7141

                                That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.=C2=A0 A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

                                What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

                                Thanks, --David

                                _______________________________________________
                                Ice mailing list
                                Ice@ietf.org
                                htt= ps://www.ietf.org/mailman/listinfo/ice

                                =C2=A0

                                =C2=A0

                                =C2=A0

                                =C2=A0


                                --f403045ddd9256779c053fe02380-- From nobody Thu Oct 27 15:33: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 D8F1112941C for ; Thu, 27 Oct 2016 15:33:35 -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 mjkX-QCYuSHk for ; Thu, 27 Oct 2016 15:33:31 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F9212959B for ; Thu, 27 Oct 2016 15:33:31 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p136so27520595oic.1 for ; Thu, 27 Oct 2016 15:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=2ij37WfBmres6oaU6JmsiMIvSjeqGLrGr1ksg0iJck0=; b=VsOHaH66LRasb746Jlz/uppBs1Phw6QZAr7lCO+n6UzeBIl13Hp1lrPTkiNQOS8edz bmq/L+9UG3iz9cXXTCWHbRcQJFZU43v9/OUE9Furb6aAS5D31m/eJ0SQN7eBrznKVfc5 pXYbVR5Zlb13OZNx4fyE+wfJsgDNCNRXRw1HmIcJ6vt2B/3nGi9+vacKFvEJPF+5JzAe n80aIH5BpQYKbVyokTXkTstiUslPS0b1Ib3YvGN213tH58HZmJcYtPXmYmBxCBGcWsnf /eUpxE37oXdiGpz/VXFKlSVcLBW6fmyL2AEL6KUbASg4RdGjX37l2L4QRuavDTjr1i2w e7wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2ij37WfBmres6oaU6JmsiMIvSjeqGLrGr1ksg0iJck0=; b=d1IY4Y4tRydBYKXzKZbT0AmCfbsXOaVPyqYylEEESCzErwqQf7jcsw1ae+mdDiBAxe XIckEusFibz0VPzqrjQtLjurqB83e+N02QsX9Q7rrqHql0w6WwEY1ND8JzfHl3k4wSSO zd7Pyl85FlQU7tbR+RCTp+Si/8bzjtCz3LXJI5P3aYThxzyn8k9RNR+t1PRUFp3RzZr4 qGfFmqeqF/p/lWsD1UjQnMHxFj3kdfbUbS6nlqjfi6p3YeSKrZe2FGF+dt2KL+WMzAwP /P2N27iha2Hs/t2sq+Yo08I1AZDuCYkp0PKVBborGJEegUgEZwDyy38gct2Ts4OyJ+oW kkRg== X-Gm-Message-State: ABUngvceccChQd8LnS66VZgoPprtVAhdEULhP1upNyp7+UIoGglPTSp4RN5sXJ7vdistYQ== X-Received: by 10.202.50.69 with SMTP id y66mr10507001oiy.164.1477607610360; Thu, 27 Oct 2016 15:33:30 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id f36sm2095222otf.3.2016.10.27.15.33.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 15:33:29 -0700 (PDT) To: Peter Saint-Andre , Christer Holmberg , "ice@ietf.org" References: <4243ec31-584a-9724-3d43-8f86357e684a@stpeter.im> From: Emil Ivov Message-ID: <48174af7-0700-3fce-d828-573ea740d72f@jitsi.org> Date: Thu, 27 Oct 2016 17:33:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4243ec31-584a-9724-3d43-8f86357e684a@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 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, 27 Oct 2016 22:33:36 -0000 On 10/10/16 10:11 PM, Peter Saint-Andre wrote: > Thanks for the review. Comments inline. > > On 10/5/16 7:43 AM, Christer Holmberg wrote: >> Hi, >> >> I took a look at draft-trickle-ice. >> >> In general, I think the document could use some editorial clean ups. >> However, I will only comments on the parts which I think are essential to >> correct: >> >> >> Q1: >> >> In general, you should use common terminology, e.g, when referring to the >> ICE spec. Sometimes you say ³Vanilla ICE specifies², sometimes "The ICE >> specification [rfc5245bis] specifies², etc. > > In general I feel that the term "Vanilla ICE" is cute but not all that > helpful. We could say "ICE core" instead. (BTW, as far as I can see, > there is no instance of "Vanilla ICE specifies" in this document and all > references are to the actual specification.) I don't share the concern about vanilla ICE but I don't feel strongly about it. > >> Q2: >> >> In section 2, the definition of Trickled Candidate says: >> >> "Candidates that a Trickle ICE agent sends after >> an offer or answer but within the same context.² >> >> 1) What is the scope of ³context²? > > Perhaps "session" or even "ICE negotiation session" would be clearer. session sounds good. > >> Q3: >> >> In section 2, the definition of Half Trickle says: >> >> "The mechanism is mostly meant for use in cases where >> support for Trickle ICE cannot be confirmed prior to sending an >> initial offer.² >> >> 1) I guess it should be support for Trickle ICE by the answerer. > > Yes, that's better. SGTM. > >> 2) Does this mean one MUST use half trickle in cases where the >> support is >> not known? > > That is discussed in section 14. I see no reason to use MUST here or > even SHOULD - it's up to the implementation. > >> Q4: >> >> Section 2 talks about ³first generation of candidates². It is unclear >> what >> is meant by ³first generation². > > I suggest "set" instead of "generation". We can also clarify that this > is the set of candidates that is sent with the initial offer. I think "set" can be ambiguous here and mistakenly perceived as the first batch of candidates. Generation is a term that was initially used in Jingle which is why I felt it was a good way to refer to "all candidates within the same ICE session" > >> Q5: >> >> In section 3, why do we talk about SDP, and we do we use RFC 2119 >> terminology for SDP endpoints? That belongs to the ice-sip-sdp draft. > > Yes, that paragraph belongs in draft-ietf-mmusic-trickle-ice-sip. Actually that one is intentionally there. There was a decision taken very early on that this draft will use jsep style SDP to facilitate understanding. At this point of the document's life cycle I'd be reluctant to revise this decision especially as I don't see what problem it would be solving. > >> Q6: >> >> In section 5, the text says: >> >> >> "If this is not the case, the agent MUST process the offer >> according to Vanilla ICE procedures [rfc5245bis] or offer/answer >> processing rules [RFC3264] if no ICE support is detected at all.² >> >> >> 1) Why do you now suddenly reference RFC 3264 for offer/answer, and >> even >> mandate agents to use it? In the introduction you said that >> ³offer/answer² >> does NOT mean RFC 3364 within the scope of this document. > > I suggest that we remove the clause "or offer/answer processing rules > [RFC3264]". The text is there for completeness. 5245 bis says that you fall back to 3264 if ICE is not supported. What we are saying here is: if trickle is not supported you can fallback to vanilla ICE or (in case even vanilla ICE is not supported) fallback to 3264 as per 5245. I still think this adds a marginal amount of clarity to implementers but I don't feel strongly about it. >> Q7: >> >> In section 5.2, the text says: >> >> "With regard to pruning of duplicate candidate pairs, a Trickle ICE >> agent SHOULD follow a policy of "first one wins" and not re-apply the >> pruning procedure if a higher-priority candidate pair is received >> from the remote agent.² >> >> >> 1) Is there a specific reason for not ³re-pruning²? > > Hmm, it seems that this is perhaps not consistent with some text that we > recently modified in section 8.1: That's actually part of the text we added. This is what we talked about in the past two meetings and in between. > ### > > Once this is done, the agent examines the check list looking for > another pair that would be redundant with the new one. If such a > pair exists and its type is not peer reflexive, the pair with the > higher priority is kept and the one with the lower priority is > discarded. If, on the other hand, the type of the pre-existing pair > is peer reflexive, the agent MUST replace it with the new candidate > it received (regardless of their respective priorities); this is done > by setting the priority of the new candidate to the priority of the > pre-existing candidate and then re-sorting the check list. > > Note: Replacing pre-existing pairs with seemingly equivalent > higher-priority ones helps guarantee that both agents will have > the same view of candidate priorities. This is particularly > important during aggressive nomination, when priority is sometimes > the only way a controlled agent can determine the selected pair. > It is for that same reason that peer-reflexive candidates need to > always be updated if equivalent alternatives are received through > signaling. > > ### > >> Q8: >> >> In section 8, the text says: >> >> "After an offer or an answer has been sent, agents will most likely >> continue discovering new local candidatesŠ² >> >> >> 1) I assume it should say ³Trickle ICE agents will most likelyŠ² > > Correct. Will fix. This is the trickle ICE spec ... Trickle ICE is assumed by default. But fine. >> Q9: >> >> In section 8, the text says: >> >> "The new candidate is then checked for redundancy against the >> existing >> list of local candidates. If its transport address and base match >> those of an existing candidate,Š² >> >> >> 1) In order to align with the 5245bis terminology, I assume ³transport >> address² and ³base² should be in uppercase? > > 5245bis does not seem to be consistent in this regard, e.g.: > > We call > the host candidate associated with a given server reflexive candidate > the BASE. > > Note: "Base" refers to the address an agent sends from for a > particular candidate. Thus, as a degenerate case host candidates > also have a base, but it's the same as the host candidate. > > Most instances are lowercase, so I'd leave it as-is for now. > >> Q10: >> >> In section 8, the text says: >> >> "When trickle updates are sent, each candidate MUST be delivered to >> the receiving Trickle ICE implementation not more than once and in >> the same order that they were sent.² >> >> 1) It¹s difficult for me to parse this, especially the ³same order² >> part. >> I think you should simply say that the signalling protocol must ensure >> that re-transmitted candidates are not treated as two separate >> candidates. > > It strikes me as sensible to specify that: > > (a) the signalling protocol must provide in-order delivery I like this wording! > (b) the Trickle ICE agent must not treat re-transmitted candidates as > distinct candidates (i.e., it must effectively de-dupe candidates) I agree but I don't think we need to mention that. I'd rather go with UNDEFINED for "what happens if an agent gets a candidate twice" becaue we don't have an use case for why this would happen. > (I'm not sure what it would mean for something like (b) to apply to the > protocol, not the agent.) It would just mean: if I am a Trickle ICE stack and you (the signalling protocol stack or the app) feed me the same candidate twice, I am going to throw an exception or behave in an unpredictable way. >> Q11: >> >> In section 8, the text says: >> >> "Also, candidate trickling needs to be correlated to a specific ICE >> negotiation session,² >> >> 1) What is an ³ICE negotiation session²? > > That should be defined. As I understand it, an ICE negotiation session > consists of all the exchanges that occur before an ICE restart (if any) > is sent. Yes. Thanks for the review Christer and for the edits to Peter! Emil > >> Q12: >> >> In section 9, the text says: >> >> "At any time during ICE processing, a Trickle ICE agent may receive >> new candidates from the remote agent. When this happens and no local >> candidates are currently known for this same stream,² >> >> >> 1) What is meant by ³this same stream²? I assume you refer to the >> stream >> with which the candidate is associated. If so, please make it more clear. > > Will do. > >> Q13: >> >> In section 13, you again reference to the rules in RFC 3264 regarding >> when >> an offer or answer can be sent. > > I think this is better phrase along the lines of "If a Trickle ICE agent > supports offer/answer semantics [RFC3264], it MAY generate a subsequent > offer at any time that is allowed by [RFC3264]." > > >> Q14: >> >> In section 13, I assume the second bullet also apply to ICE restart. If >> so, please make it clear. > > Correct. > > Thanks again for the review. > > Peter > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > -- https://jitsi.org From nobody Fri Oct 28 00:43: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 28493129418 for ; Fri, 28 Oct 2016 00:43:25 -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 iOjzi7Ps7Kbo for ; Fri, 28 Oct 2016 00:43:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB7F129484 for ; Fri, 28 Oct 2016 00:43:21 -0700 (PDT) X-AuditID: c1b4fb2d-1dbff700000009f7-49-58130197871b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 8A.8F.02551.79103185; Fri, 28 Oct 2016 09:43:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Fri, 28 Oct 2016 09:43:19 +0200 From: Christer Holmberg To: Emil Ivov , Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Comments on draft-ietf-ice-trickle-04 Thread-Index: AQHSHw51n+601b7MjEmvuTEweizdcqCieqSAgBpp/gCAAM32AA== Date: Fri, 28 Oct 2016 07:43:17 +0000 Message-ID: References: <4243ec31-584a-9724-3d43-8f86357e684a@stpeter.im> <48174af7-0700-3fce-d828-573ea740d72f@jitsi.org> In-Reply-To: <48174af7-0700-3fce-d828-573ea740d72f@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7se50RuEIg5mn9S3W7JzAYvHtQq3F sT39zA7MHkuW/GTy+P8m0GPunhfMAcxRXDYpqTmZZalF+nYJXBndHZ/ZCuY5V/TcO8fawHjA sYuRk0NCwESifd0Spi5GLg4hgfWMEj3rT7FDOEsYJS4/+8raxcjBwSZgIdH9TxukQUQgQ6Jl w10WkLAwUPjZGzcQU0TAUuLOqWAI00lixZ0YkGIWAVWJ3q/dLCA2r4C1ROuGlWC2kMAiRomu 6dog5ZwCthJT34DNZhQQk/h+ag0TiM0sIC5x68l8JogjBSSW7DnPDGGLSrx8/A/sLFEBPYk1 98NATAkBRYnl/XIgJrOApsT6XfoQQ6wlJi78wwZhK0pM6X7IDnGLoMTJmU9YJjCKzUKyaxZC 9ywk3bOQdM9C0r2AkXUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBcHdzyW3cH4+rXjocY BTgYlXh4EziEIoRYE8uKK3MPMUpwMCuJ8DL/BwrxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5 P1xIID2xJDU7NbUgtQgmy8TBKdXAuGRH8q9f+9aXJa07ulgl01nwb0PmkadnG3u2Xf8pz5P3 40in9+SG9weV/6x9UFnLK/I7xpFvyYnZcbXJNWs3qDba3lrXVrvr5IfMqTI6/Xybl6kl3rbb 7repNOnA71iLdZUMxROu50ZVRuhVnXiwZJJ9x0wV0+XzjJ8mZDQmKv//2ZBVEzB/mxJLcUai oRZzUXEiABwOSZ+nAgAA Archived-At: Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 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, 28 Oct 2016 07:43:25 -0000 SGksDQoNCj4+PlEyOg0KPj4+DQo+Pj4gSW4gc2VjdGlvbiAyLCB0aGUgZGVmaW5pdGlvbiBvZiBU cmlja2xlZCBDYW5kaWRhdGUgc2F5czoNCj4+Pg0KPj4+ICAgICJDYW5kaWRhdGVzIHRoYXQgYSBU cmlja2xlIElDRSBhZ2VudCBzZW5kcyBhZnRlcg0KPj4+ICAgICBhbiBvZmZlciBvciBhbnN3ZXIg YnV0IHdpdGhpbiB0aGUgc2FtZSBjb250ZXh0LsKyDQo+Pj4NCj4+PiAxKSAgICBXaGF0IGlzIHRo ZSBzY29wZSBvZiDCs2NvbnRleHTCsj8NCj4+DQo+PiBQZXJoYXBzICJzZXNzaW9uIiBvciBldmVu ICJJQ0UgbmVnb3RpYXRpb24gc2Vzc2lvbiIgd291bGQgYmUgY2xlYXJlci4NCj4NCj5zZXNzaW9u IHNvdW5kcyBnb29kLg0KDQpXaGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIOKAnHNlc3Npb27igJ0/ DQoNCg0KPj4+IDIpICAgIERvZXMgdGhpcyBtZWFuIG9uZSBNVVNUIHVzZSBoYWxmIHRyaWNrbGUg aW4gY2FzZXMgd2hlcmUgdGhlDQo+Pj4gc3VwcG9ydCBpcw0KPj4+IG5vdCBrbm93bj8NCj4+DQo+ PiBUaGF0IGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDE0LiBJIHNlZSBubyByZWFzb24gdG8gdXNl IE1VU1QgaGVyZSBvcg0KPj4gZXZlbiBTSE9VTEQgLSBpdCdzIHVwIHRvIHRoZSBpbXBsZW1lbnRh dGlvbi4NCj4+DQo+Pj4gUTQ6DQo+Pj4NCj4+PiBTZWN0aW9uIDIgdGFsa3MgYWJvdXQgwrNmaXJz dCBnZW5lcmF0aW9uIG9mIGNhbmRpZGF0ZXPCsi4gSXQgaXMgdW5jbGVhcg0KPj4+IHdoYXQNCj4+ PiBpcyBtZWFudCBieSDCs2ZpcnN0IGdlbmVyYXRpb27Csi4NCj4+DQo+PiBJIHN1Z2dlc3QgInNl dCIgaW5zdGVhZCBvZiAiZ2VuZXJhdGlvbiIuIFdlIGNhbiBhbHNvIGNsYXJpZnkgdGhhdCB0aGlz DQo+PiBpcyB0aGUgc2V0IG9mIGNhbmRpZGF0ZXMgdGhhdCBpcyBzZW50IHdpdGggdGhlIGluaXRp YWwgb2ZmZXIuDQo+DQo+SSB0aGluayAic2V0IiBjYW4gYmUgYW1iaWd1b3VzIGhlcmUgYW5kIG1p c3Rha2VubHkgcGVyY2VpdmVkIGFzIHRoZQ0KPmZpcnN0IGJhdGNoIG9mIGNhbmRpZGF0ZXMuIEdl bmVyYXRpb24gaXMgYSB0ZXJtIHRoYXQgd2FzIGluaXRpYWxseSB1c2VkDQo+aW4gSmluZ2xlIHdo aWNoIGlzIHdoeSBJIGZlbHQgaXQgd2FzIGEgZ29vZCB3YXkgdG8gcmVmZXIgdG8gImFsbA0KPmNh bmRpZGF0ZXMgd2l0aGluIHRoZSBzYW1lIElDRSBzZXNzaW9uIg0KDQpTbywgd2hhdCBleGFjdGx5 IGRvIHlvdSB3YW50IHRvIHNheT8NCg0KDQo+Pj4gUTU6DQo+Pj4NCj4+PiBJbiBzZWN0aW9uIDMs IHdoeSBkbyB3ZSB0YWxrIGFib3V0IFNEUCwgYW5kIHdlIGRvIHdlIHVzZSBSRkMgMjExOQ0KPj4+ IHRlcm1pbm9sb2d5IGZvciBTRFAgZW5kcG9pbnRzPyBUaGF0IGJlbG9uZ3MgdG8gdGhlIGljZS1z aXAtc2RwIGRyYWZ0Lg0KPj4NCj4+IFllcywgdGhhdCBwYXJhZ3JhcGggYmVsb25ncyBpbiBkcmFm dC1pZXRmLW1tdXNpYy10cmlja2xlLWljZS1zaXAuDQo+DQo+QWN0dWFsbHkgdGhhdCBvbmUgaXMg aW50ZW50aW9uYWxseSB0aGVyZS4gVGhlcmUgd2FzIGEgZGVjaXNpb24gdGFrZW4NCj52ZXJ5IGVh cmx5IG9uIHRoYXQgdGhpcyBkcmFmdCB3aWxsIHVzZSBqc2VwIHN0eWxlIFNEUCB0byBmYWNpbGl0 YXRlDQo+dW5kZXJzdGFuZGluZy4NCg0KV2hhdCBpcyDigJxqc2VwIHN0eWxlIFNEUOKAnT8/Pw0K DQoNCj5BdCB0aGlzIHBvaW50IG9mIHRoZSBkb2N1bWVudCdzIGxpZmUgY3ljbGUgSSdkIGJlIHJl bHVjdGFudCB0byByZXZpc2UNCj50aGlzIGRlY2lzaW9uIGVzcGVjaWFsbHkgYXMgSSBkb24ndCBz ZWUgd2hhdCBwcm9ibGVtIGl0IHdvdWxkIGJlIHNvbHZpbmcuDQoNCg0KSSB3YXMgdmVyeSBza2Vw dGljYWwgdG8gc3BsaXR0aW5nIElDRSBhbmQgU0RQIHRvIGJlZ2luIHdpdGguIE5vdyB3aGVuIGl0 4oCZcw0KZG9uZSB3ZSBzaG91bGQgc3RpY2sgdG8gaXQuDQoNCg0KPj4+IFE2Og0KPj4+DQo+Pj4g SW4gc2VjdGlvbiA1LCB0aGUgdGV4dCBzYXlzOg0KPj4+DQo+Pj4NCj4+PiAgICAgIklmIHRoaXMg aXMgbm90IHRoZSBjYXNlLCB0aGUgYWdlbnQgTVVTVCBwcm9jZXNzIHRoZSBvZmZlcg0KPj4+ICAg ICBhY2NvcmRpbmcgdG8gVmFuaWxsYSBJQ0UgcHJvY2VkdXJlcyBbcmZjNTI0NWJpc10gb3Igb2Zm ZXIvYW5zd2VyDQo+Pj4gICAgIHByb2Nlc3NpbmcgcnVsZXMgW1JGQzMyNjRdIGlmIG5vIElDRSBz dXBwb3J0IGlzIGRldGVjdGVkIGF0IGFsbC7Csg0KPj4+DQo+Pj4NCj4+PiAxKSAgICBXaHkgZG8g eW91IG5vdyBzdWRkZW5seSByZWZlcmVuY2UgUkZDIDMyNjQgZm9yIG9mZmVyL2Fuc3dlciwgYW5k DQo+Pj4gZXZlbg0KPj4+IG1hbmRhdGUgYWdlbnRzIHRvIHVzZSBpdD8gSW4gdGhlIGludHJvZHVj dGlvbiB5b3Ugc2FpZCB0aGF0DQo+Pj4gwrNvZmZlci9hbnN3ZXLCsg0KPj4+IGRvZXMgTk9UIG1l YW4gUkZDIDMzNjQgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPj4NCj4+IEkg c3VnZ2VzdCB0aGF0IHdlIHJlbW92ZSB0aGUgY2xhdXNlICJvciBvZmZlci9hbnN3ZXIgcHJvY2Vz c2luZyBydWxlcw0KPj4gW1JGQzMyNjRdIi4NCj4NCj5UaGUgdGV4dCBpcyB0aGVyZSBmb3IgY29t cGxldGVuZXNzLiA1MjQ1IGJpcyBzYXlzIHRoYXQgeW91IGZhbGwgYmFjayB0bw0KPjMyNjQgaWYg SUNFIGlzIG5vdCBzdXBwb3J0ZWQuDQoNCllvdSBvbmx5IGZhbGwgYmFjayBpZiB5b3Ugc3VwcG9y dCAzMjY0IHRvIGJlZ2luIHdpdGggLSB3aGljaCBzaG91bGQgbm90IGJlDQphIHJlcXVpcmVtZW50 IGluIDUyNDViaXMgYXMgaXTigJlzIHN1cHBvc2VkIHRvIGJlIOKAnHByb3RvY29sIGluZGVwZW5k ZW504oCdLg0KDQo+V2hhdCB3ZSBhcmUgc2F5aW5nIGhlcmUgaXM6IGlmIHRyaWNrbGUgaXMgbm90 IHN1cHBvcnRlZCB5b3UgY2FuIGZhbGxiYWNrDQo+dG8gdmFuaWxsYSBJQ0Ugb3IgKGluIGNhc2Ug ZXZlbiB2YW5pbGxhIElDRSBpcyBub3Qgc3VwcG9ydGVkKSBmYWxsYmFjaw0KPnRvIDMyNjQgYXMg cGVyIDUyNDUuDQoNClRoYXQgaXMgd3JvbmcuIFdlIGNhbiBub3QgbWFuZGF0ZSA1MjQ1YmlzIGVu ZHBvaW50cyB0byBzdXBwb3J0IFNEUC4gSW4NCnRoYXQgY2FzZSB3ZSBzaG91bGQgbWFrZSA1MjQ1 YmlzIFNEUCBkZXBlbmRlbnQgYWdhaW4uDQoNCg0KPj4NCj4+PiBRODoNCj4+Pg0KPj4+IEluIHNl Y3Rpb24gOCwgdGhlIHRleHQgc2F5czoNCj4+Pg0KPj4+ICAgICAiQWZ0ZXIgYW4gb2ZmZXIgb3Ig YW4gYW5zd2VyIGhhcyBiZWVuIHNlbnQsIGFnZW50cyB3aWxsIG1vc3QgbGlrZWx5DQo+Pj4gICAg IGNvbnRpbnVlIGRpc2NvdmVyaW5nIG5ldyBsb2NhbCBjYW5kaWRhdGVzxaDCsg0KPj4+DQo+Pj4N Cj4+PiAxKSAgICBJIGFzc3VtZSBpdCBzaG91bGQgc2F5IMKzVHJpY2tsZSBJQ0UgYWdlbnRzIHdp bGwgbW9zdCBsaWtlbHnFoMKyDQo+Pg0KPj4gQ29ycmVjdC4gV2lsbCBmaXguDQo+DQo+VGhpcyBp cyB0aGUgdHJpY2tsZSBJQ0Ugc3BlYyAuLi4gVHJpY2tsZSBJQ0UgaXMgYXNzdW1lZCBieSBkZWZh dWx0LiBCdXQNCj5maW5lLg0KDQoNCuKAnEFnZW50c+KAnSwg4oCcSUNFIGFnZW50c+KAneKApiB3 aGF0ZXZlci4gQXMgbG9uZyBhcyB0aGUgZHJhZnQgdXNlcyBjb25zaXN0ZW50DQp0ZXJtaW5vbG9n eSwgYW5kIGl0IGlzIGNsZWFyIHdoYXQgaXMgbWVhbnQuDQoNCg0KDQo+Pj4gUTk6DQo+Pj4NCj4+ PiBJbiBzZWN0aW9uIDgsIHRoZSB0ZXh0IHNheXM6DQo+Pj4NCj4+PiAgICAgIlRoZSBuZXcgY2Fu ZGlkYXRlIGlzIHRoZW4gY2hlY2tlZCBmb3IgcmVkdW5kYW5jeSBhZ2FpbnN0IHRoZQ0KPj4+IGV4 aXN0aW5nDQo+Pj4gICAgIGxpc3Qgb2YgbG9jYWwgY2FuZGlkYXRlcy4gIElmIGl0cyB0cmFuc3Bv cnQgYWRkcmVzcyBhbmQgYmFzZSBtYXRjaA0KPj4+ICAgICB0aG9zZSBvZiBhbiBleGlzdGluZyBj YW5kaWRhdGUsxaDCsg0KPj4+DQo+Pj4NCj4+PiAxKSAgICBJbiBvcmRlciB0byBhbGlnbiB3aXRo IHRoZSA1MjQ1YmlzIHRlcm1pbm9sb2d5LCBJIGFzc3VtZQ0KPj4+wrN0cmFuc3BvcnQNCj4+PiBh ZGRyZXNzwrIgYW5kIMKzYmFzZcKyIHNob3VsZCBiZSBpbiB1cHBlcmNhc2U/DQo+Pg0KPj4gNTI0 NWJpcyBkb2VzIG5vdCBzZWVtIHRvIGJlIGNvbnNpc3RlbnQgaW4gdGhpcyByZWdhcmQsIGUuZy46 DQo+Pg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBXZSBjYWxsDQo+PiAgICB0aGUgaG9zdCBjYW5kaWRhdGUgYXNzb2NpYXRl ZCB3aXRoIGEgZ2l2ZW4gc2VydmVyIHJlZmxleGl2ZSBjYW5kaWRhdGUNCj4+ICAgIHRoZSBCQVNF Lg0KPj4NCj4+ICAgICAgIE5vdGU6ICJCYXNlIiByZWZlcnMgdG8gdGhlIGFkZHJlc3MgYW4gYWdl bnQgc2VuZHMgZnJvbSBmb3IgYQ0KPj4gICAgICAgcGFydGljdWxhciBjYW5kaWRhdGUuICBUaHVz LCBhcyBhIGRlZ2VuZXJhdGUgY2FzZSBob3N0IGNhbmRpZGF0ZXMNCj4+ICAgICAgIGFsc28gaGF2 ZSBhIGJhc2UsIGJ1dCBpdCdzIHRoZSBzYW1lIGFzIHRoZSBob3N0IGNhbmRpZGF0ZS4NCj4+DQo+ PiBNb3N0IGluc3RhbmNlcyBhcmUgbG93ZXJjYXNlLCBzbyBJJ2QgbGVhdmUgaXQgYXMtaXMgZm9y IG5vdy4NCg0KDQpJIHdhbnQgdG8gYmUgY29uc2lzdGVudC4gSWYgc29tZXRoaW5nIG5lZWRzIHRv IGJlIGNoYW5nZWQgaW4gNTI0NWJpcywNCndl4oCZbGwgY2hhbmdlIGl0Lg0KDQoNCj4+PiBRMTA6 DQo+Pj4NCj4+PiBJbiBzZWN0aW9uIDgsIHRoZSB0ZXh0IHNheXM6DQo+Pj4NCj4+PiAgICAgICJX aGVuIHRyaWNrbGUgdXBkYXRlcyBhcmUgc2VudCwgZWFjaCBjYW5kaWRhdGUgTVVTVCBiZSBkZWxp dmVyZWQNCj4+PnRvDQo+Pj4gICAgIHRoZSByZWNlaXZpbmcgVHJpY2tsZSBJQ0UgaW1wbGVtZW50 YXRpb24gbm90IG1vcmUgdGhhbiBvbmNlIGFuZCBpbg0KPj4+ICAgICB0aGUgc2FtZSBvcmRlciB0 aGF0IHRoZXkgd2VyZSBzZW50LsKyDQo+Pj4NCj4+PiAxKSAgICBJdMK5cyBkaWZmaWN1bHQgZm9y IG1lIHRvIHBhcnNlIHRoaXMsIGVzcGVjaWFsbHkgdGhlIMKzc2FtZSBvcmRlcsKyDQo+Pj4gcGFy dC4NCj4+PiBJIHRoaW5rIHlvdSBzaG91bGQgc2ltcGx5IHNheSB0aGF0IHRoZSBzaWduYWxsaW5n IHByb3RvY29sIG11c3QgZW5zdXJlDQo+Pj4gdGhhdCByZS10cmFuc21pdHRlZCBjYW5kaWRhdGVz IGFyZSBub3QgdHJlYXRlZCBhcyB0d28gc2VwYXJhdGUNCj4+PiBjYW5kaWRhdGVzLg0KPj4NCj4+ IEl0IHN0cmlrZXMgbWUgYXMgc2Vuc2libGUgdG8gc3BlY2lmeSB0aGF0Og0KPj4NCj4+IChhKSB0 aGUgc2lnbmFsbGluZyBwcm90b2NvbCBtdXN0IHByb3ZpZGUgaW4tb3JkZXIgZGVsaXZlcnkNCj4N Cj5JIGxpa2UgdGhpcyB3b3JkaW5nIQ0KPg0KPj4gKGIpIHRoZSBUcmlja2xlIElDRSBhZ2VudCBt dXN0IG5vdCB0cmVhdCByZS10cmFuc21pdHRlZCBjYW5kaWRhdGVzIGFzDQo+PiBkaXN0aW5jdCBj YW5kaWRhdGVzIChpLmUuLCBpdCBtdXN0IGVmZmVjdGl2ZWx5IGRlLWR1cGUgY2FuZGlkYXRlcykN Cj4NCj5JIGFncmVlIGJ1dCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gbWVudGlvbiB0aGF0LiBJ J2QgcmF0aGVyIGdvIHdpdGgNCj5VTkRFRklORUQgZm9yICJ3aGF0IGhhcHBlbnMgaWYgYW4gYWdl bnQgZ2V0cyBhIGNhbmRpZGF0ZSB0d2ljZSIgYmVjYXVlDQo+d2UgZG9uJ3QgaGF2ZSBhbiB1c2Ug Y2FzZSBmb3Igd2h5IHRoaXMgd291bGQgaGFwcGVuLg0KDQpJdCBjYW4gaGFwcGVuIHdoZW4geW91 IHVzZSB0cmlja2xlLXNpcC1zZXAuDQoNCg0KPj4+IFExMToNCj4+Pg0KPj4+IEluIHNlY3Rpb24g OCwgdGhlIHRleHQgc2F5czoNCj4+Pg0KPj4+ICAgICAiQWxzbywgY2FuZGlkYXRlIHRyaWNrbGlu ZyBuZWVkcyB0byBiZSBjb3JyZWxhdGVkIHRvIGEgc3BlY2lmaWMgSUNFDQo+Pj4gbmVnb3RpYXRp b24gc2Vzc2lvbizCsg0KPj4+DQo+Pj4gMSkgICAgV2hhdCBpcyBhbiDCs0lDRSBuZWdvdGlhdGlv biBzZXNzaW9uwrI/DQo+Pg0KPj4gVGhhdCBzaG91bGQgYmUgZGVmaW5lZC4gQXMgSSB1bmRlcnN0 YW5kIGl0LCBhbiBJQ0UgbmVnb3RpYXRpb24gc2Vzc2lvbg0KPj4gY29uc2lzdHMgb2YgYWxsIHRo ZSBleGNoYW5nZXMgdGhhdCBvY2N1ciBiZWZvcmUgYW4gSUNFIHJlc3RhcnQgKGlmIGFueSkNCj4+ IGlzIHNlbnQuDQo+DQo+WWVzLg0KDQpZb3Ugc2hvdWxkIHRoZW4gYWRkIGEgZGVmaW5pdGlvbiBm b3IgaXQsIGluIGFkZGl0aW9uIHRvIOKAnHNlc3Npb27igJ0sIOKAnElDRQ0Kc2Vzc2lvbuKAnSwg YW5kIHdoYXRldmVyIG90aGVyIHNlc3Npb25zIHlvdSBtYXkgcmVmZXIgdG8uDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg== From nobody Mon Oct 31 06:23:42 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 332E8129722 for ; Mon, 31 Oct 2016 06:23:39 -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 6sOesYLw0aHN for ; Mon, 31 Oct 2016 06:23:36 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3433129410 for ; Mon, 31 Oct 2016 06:23:33 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-ba-581745d3d039 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id DB.20.03250.3D547185; Mon, 31 Oct 2016 14:23:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 14:23:31 +0100 From: Christer Holmberg To: Jana Iyengar , "Black, David" Thread-Topic: [Ice] Continue discussion of global pacing based on feedback from "transport guys" Thread-Index: AdIZn0w0rTSbKKnYS/edYVNC+EY2GgNvPFWAAA67L4AAnxJ9gAAGoWUAAVSkbYAAQJA4AAADKZSAALrkWoA= Date: Mon, 31 Oct 2016 13:23:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D43D13DB122EDchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7k+4VV/EIg3OHRCw+zlrMYvHtQq3F pKMLWSyuLX/N6sDiMWnmDGaPBZtKPZYs+ckUwBzFZZOSmpNZllqkb5fAlbHtrFTB9OeMFbO3 zWNqYNxynLGLkYNDQsBE4m53QhcjF4eQwDpGic1n5rN3MXICOUsYJc4ctgWpYROwkOj+pw0S FhHwkNiy5CATiM0MZH/Z0ghWLiyQKLFsxUw2iJokifutW5lg7MXzNrOA2CwCqhKdW6aC1fMK WEvsOf2aHWLvRhaJpu8bWUESnAKBEm1vIQYxCohJfD+1BmqZuMStJ/PBbAkBAYkle84zQ9ii Ei8f/2MFuVNUQE9izf0wiLCixM6z7cwQrQkS357+Y4LYKyhxcuYTlgmMorOQTJ2FpGwWkjKI uIHE+3PzmSFsbYllC19D2foSG7+cZYSwrSWWT37KhqxmASPHKkbR4tTipNx0IyO91KLM5OLi /Dy9vNSSTYzA+Dy45bfBDsaXzx0PMQpwMCrx8Bo4i0UIsSaWFVfmHmKU4GBWEuH97CIeIcSb klhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVAPjzE/HX1Zu2V2s MkOjhq9wZtR390mzVZSXbmSuv7wm6O2vj1fyHde7R1z9HxU6982DNQe2TTy3hnXR3fcrg2+d OKR8UH3WNm+pxYZHTqg3NPZ6G/1fP6/qa0OzTO7GRS8Pfb89YZpWafbGz7E9pWdKDglPmCjd ue7qB+O4wqlv7jt7aW5/ZnzYvVCJpTgj0VCLuag4EQBr84SfywIAAA== Archived-At: Cc: Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 13:23:39 -0000 --_000_D43D13DB122EDchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Can we expect an update to the pull request today, so I can generate and su= bmit a new version of the draft before the submission deadline? Yes, there are still some other issues that we need to do, but at least we= =92d have a version with the Ta issue (which has been ongoing for a while) = solved. Regards, Christer From: Ice > on behalf of = Jana Iyengar > Date: Friday 28 October 2016 at 01:19 To: "Black, David" > Cc: "pthatcher@google.com" >, "ice@ietf.org" > Subject: Re: [Ice] Continue discussion of global pacing based on feedback f= rom "transport guys" On Thu, Oct 27, 2016 at 1:49 PM, Black, David > wrote: Hi Peter, Some comments ... + Start with the following rules which would be generally + applicable to transport protocols: + + Let MaxPackets be the maximum number of transactions allowed to be = outstanding in the network at any time, which SHOULD be 10. + Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT is= known and 500ms otherwise. + Let MinPacing be the minimum pacing interval between transactions, = which SHOULD be 5ms. + I=92d cite references for at least the first two of the list items, if not = all three. The first item is based on TCP Initial Window of 10 segments, w= hich I believe is RFC 6928 (Jana will know for certain). The second Yes, RFC 6928 is right. I think this text could be made more precise: "Let = MaxBytes be the maximum number of bytes allowed to be outstanding in the ne= twork at start-up, which SHOULD be 14600 bytes [RFC6928]." item is *not* general - 500ms is specific to STUN, and comes from RFC 5389 = (credit to Bernard Aboba for finding this: https://www.ietf.org/mail-archiv= e/web/ice/current/msg00379.html) - that=92s important because the generally= applicable number is larger - both RFC 6298 and draft-ietf-tsvwg-rfc5405bi= s use 1 second for TCP and UDP, respectively. Additionally, my reasoning for this was as follows (if you want to add this= to the rationale.) The TCP initial RTO is 1 sec (RFC 6298), and the HTO ca= n be less conservative, since an expected case is that no responses are rec= eived even if the network is perfect. For the third item, I hope the rationale for the 5ms pacing interval is exp= lained elsewhere in the draft. + Observe that ICE transactions are typically around 100 bytes or + less, which makes it reasonable to increase MaxPackets to about + 150. Add =93because 1500 bytes is a typical TCP segment size=94 to the end of th= is. If you use the byte-limit from RFC 6928 above you won't need to specify TCP= segment size, and you would change MaxPackets to MaxBytes. - jana Thanks, --David From: Peter Thatcher [mailto:pthatcher@google.com] Sent: Wednesday, October 26, 2016 10:00 AM To: Jana Iyengar Cc: Black, David; ice@ietf.org Subject: Re: [Ice] Continue discussion of global pacing based on feedback f= rom "transport guys" OK, based on the discussion, I have made the following PR for 5245bis: https://github.com/ice-wg/rfc5245bis/pull/19 Please let me know if the logic and wording are right. On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar > wrote: Sounds good to me. Thanks for taking the time to think this through, even t= hough it seems to have "collapsed" to the same answer. I definitely think i= t's worthwhile putting the reasoning into the draft. On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher > wrote: Jana, are you OK with a global Ta value with text explaining how we arrived= at that value? On Sun, Oct 16, 2016 at 5:22 AM, Black, David > wrote: It looks like the Ta value suffices, and the prior discussion provides assu= rance that residential equipment won't be overrun ... but given the subtlet= y of the discussion that reached this result, I strongly recommend that we = show our work ;-). In other words, the draft should provide a complete ex= planation of our reasoning, as both the ICE packet size and the 500ms value= are specific to this discussion, making the conclusion *not* generally app= licable. Thanks, --David ++Sent from my Android not-so-smartphone ... -------- Original message -------- From: Peter Thatcher > Date: 10/16/16 7:21 AM (GMT+01:00) To: "Black, David" > Cc: ice@ietf.org Subject: Re: [Ice] Continue discussion of global pacing based on feedback f= rom "transport guys" Assuming ICE checks are around 100 octets (which they are, almost), then a = MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 packets/= sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So the Ta value = would end up being more strict. Does that mean the Ta value of 5ms is sufficiently strict to render the HTO= /MaxPacket rules unnecessary? Could we just reduce the ruleset down to a m= in Ta value of 5ms? Or do you think those rules still have value? And as for the packet rate, previous to discussing with you "transport guys= ", there was a lot of discussion in the WG about packet rates, in particula= r rates of opening new NAT bindings with residential equipment. After a lo= t of discussion and experimenting in the the real world, we agreed that a l= ower bound of 5ms on the Ta was sufficient to cover packet rates and rates = of opening NAT bindings. I can give more history on that if you'd like. = But that still left a concern over bit rates, which is how we ended up tal= king to you :). On Wed, Sep 28, 2016 at 8:45 AM, Black, David > wrote: I'm apparently one of the "transport guys" referred to in the subject line = ;-). In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter T= hatcher described the current proposal: ---------------------- 1. A maximum number of outstanding request packets, call it MaxPackets whi= ch SHOULD be 10. 2. A timeout for request packets, call it handshake timeout or HTO which S= HOULD be 2*RTT if the RTT is known and 500ms otherwise. 3. A global pacing rate of 5ms (like a global Ta). If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second, well below what you would get with the bitrate limits we were asking for. ---------------------- There's been some further discussion with the "transport guys" about packet= size and bit rate. In essence, the rationale for 10 as the maximum numbe= r of outstanding request packets (item 1 above) is based on the typical TCP= segment size of about 1500 bytes. ICE request packets tend to be much sma= ller, 100 bytes or less, which suggests that a factor of 15 could be availa= ble if bit rate matters but packet count doesn't. That may well be the c= ase ... RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible). That RFC effectively asserts that= the current Internet is bit-congestible only: https://tools.ietf.org/html/= rfc7141 That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets. A possible= area of concern (based on ICE use by Web RTC) is residential gateway/NAT b= oxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid ove= rrunning them. What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning? Thanks, --David _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D43D13DB122EDchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
                                Hi,

                                Can we expect an update to the pull request today, so I can generate a= nd submit a new version of the draft before the submission deadline?

                                Yes, there are still some other issues that we need to do, but at leas= t we=92d have a version with the Ta issue (which has been ongoing for a whi= le) solved.

                                Regards,

                                Christer

                                From: Ice <ice-bounces@ietf.org> on behalf of Jana Iyengar &= lt;jri@google.com>
                                Date: Friday 28 October 2016 at 01:= 19
                                To: "Black, David" <David.Black@dell.com>
                                Cc: "pthatcher@google.com" <pthatcher@google.com>, "ice@ietf.org" <ice@ietf= .org>
                                Subject: Re: [Ice] Continue discuss= ion of global pacing based on feedback from "transport guys"

                                On Thu, Oct 27, 2016 at 1:49 PM, Black, David <David.Black@d= ell.com> wrote:

                                Hi Peter,

                                 

                                Some comments ...

                                 

                                +  <t>Start with the followin= g rules which would be generally

                                +  applicable to transport protocol= s:

                                +  <list style=3D"numbers&q= uot;>

                                +    <t>Let MaxPack= ets be the maximum number of transactions allowed to be outstanding in the = network at any time, which SHOULD be 10.</t>

                                +    <t>Let HTO be = the transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms ot= herwise.</t>

                                +    <t>Let MinPaci= ng be the minimum pacing interval between transactions, which SHOULD be 5ms= .</t>

                                +  </list>

                                 

                                I=92d cite references for at least the first= two of the list items, if not all three.  The first item is based on = TCP Initial Window of 10 segments, which I believe is RFC 6928 (Jana will know for certain).  The second =


                                Yes, RFC 6928 is right. I think this text could be made more precise: = "Let MaxBytes be the maximum number of bytes allowed to be outstanding= in the network at start-up, which SHOULD be 14600 bytes [RFC6928]."
                                 

                                Additionally, my reasoning for this was as follows (if you want to add= this to the rationale.) The TCP initial RTO is 1 sec (RFC 6298), and the H= TO can be less conservative, since an expected case is that no responses ar= e received even if the network is perfect.

                                For the third item, I hope the rationale for= the 5ms pacing interval is explained elsewhere in the draft.=

                                 

                                +    Observe that ICE tra= nsactions are typically around 100 bytes or

                                +    less, which makes it= reasonable to increase MaxPackets to about

                                +    150.

                                 

                                Add =93because 1500 bytes is a typical TCP s= egment size=94 to the end of this.


                                If you use the byte-limit from RFC 6928 above you won't need to specif= y TCP segment size, and you would change MaxPackets to MaxBytes.

                                - jana
                                 

                                Thanks, --David

                                 

                                From: Peter Thatcher [mailto:pthatcher@google.com]
                                Sent: Wednesday, October 26, 2016 10:00 AM
                                To: Jana Iyengar
                                Cc: Black, David; = ice@ietf.org


                                Subject: Re: [Ice] Continue discussion of global pacing based on fee= dback from "transport guys"

                                 

                                OK, bas= ed on the discussion, I have made the following PR for 5245bis:

                                =  

                                 

                                 

                                Please = let me know if the logic and wording are right.  =

                                 

                                On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar <<= a href=3D"mailto:jri@google.com" target=3D"_blank">jri@google.com> w= rote:

                                Sounds good to me. Thanks for taking the time to thi= nk this through, even though it seems to have "collapsed" to the = same answer. I definitely think it's worthwhile putting the reasoning into = the draft.

                                 

                                On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher <= pthatcher@google.= com> wrote:

                                Jana, a= re you OK with a global Ta value with text explaining how we arrived at tha= t value?   

                                =  

                                =  

                                 

                                On Sun, Oct 16, 2016 at 5:22 AM, Black, David <David.Black@dell.co= m> wrote:

                                It looks like the Ta value suffices, and the prior d= iscussion provides assurance that residential equipment won't be overrun ..= . but given the subtlety of the discussion that reached this result, I stro= ngly recommend that we show our work ;-).   In other words, the draft should provide a complete explanatio= n of our reasoning, as both the ICE packet size and the 500ms value are spe= cific to this discussion, making the conclusion *not* generally applicable.=  

                                 

                                T= hanks, --David ++Sent from my Android not-so-smartphone ...

                                 

                                 

                                -------- Original message --------

                                From: Peter Thatcher <pthatcher@google.com>

                                Date: 10/16/16 7:21 AM (GMT+01:00)

                                To: "Black, David" <david.black@emc.com>

                                Subject: Re: [Ice] Continue discussion of global pac= ing based on feedback from "transport guys"

                                 

                                Assumin= g ICE checks are around 100 octets (which they are, almost), then a MaxPack= ets of 150 with a HTO of 500ms gives a maximum of about 300 packets/sec.&nb= sp; But a Ta of 5ms gives a maximum of 200 packets/sec.  So the Ta value would end up being more strict. &n= bsp;

                                =  

                                Does th= at mean the Ta value of 5ms is sufficiently strict to render the HTO/MaxPac= ket rules unnecessary?  Could we just reduce the ruleset down to a min= Ta value of 5ms?  Or do you think those rules still have value?

                                =  

                                And as = for the packet rate, previous to discussing with you "transport guys&q= uot;, there was a lot of discussion in the WG about packet rates, in partic= ular rates of opening new NAT bindings with residential equipment.  After a lot of discussion and experimenting in the the re= al world, we agreed that a lower bound of 5ms on the Ta was sufficient to c= over packet rates and rates of opening NAT bindings.  I can give more = history on that if you'd like.    But that still left a concern over bit rates, which is how we ended up talking to y= ou :).

                                =  

                                =  

                                =  

                                =  

                                =  

                                =  

                                =  

                                =  

                                 

                                On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@dell.co= m> wrote:

                                I'm apparently one of the "transport guys"= referred to in the subject line ;-).

                                In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
                                described the current proposal:

                                ----------------------
                                1.  A maximum number of outstanding request packets, call it MaxPacket= s which SHOULD be 10.

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

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

                                If all packets are dropped and the RTT is not known, then 1+2 are effec= tively 20 packets per second,
                                well below what you would get with the bitrate limits we were asking for. ----------------------

                                There's been some further discussion with the "transport guys" ab= out packet size and bit rate.   In essence, the rationale for 10 = as the maximum number of outstanding request packets (item 1 above) is base= d on the typical TCP segment size of about 1500 bytes.  ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.    That may well be the case ...

                                RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).  That RFC effectively asserts that the current Internet is bit-congestible = only:                                 https://tools.ietf.org/html/rfc7141

                                That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.  A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

                                What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

                                Thanks, --David

                                _______________________________________________
                                Ice mailing list
                                Ice@ietf.org
                                htt= ps://www.ietf.org/mailman/listinfo/ice

                                 

                                 

                                 

                                 


                                --_000_D43D13DB122EDchristerholmbergericssoncom_-- From nobody Mon Oct 31 07:30: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 D29631294C5 for ; Mon, 31 Oct 2016 07:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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.497, 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 HJQd3tj2kMaQ for ; Mon, 31 Oct 2016 07:30:46 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 40F89129407 for ; Mon, 31 Oct 2016 07:30:46 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id o68so164042262qkf.3 for ; Mon, 31 Oct 2016 07:30:46 -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=iwIThqp5gvpW36hd8gHuKcgQvcXbqHeROqKS0WwcQ4Q=; b=QQ1VTBDdqo0eEHvrA1iCVeSz1fznmtFrQ7S5xNJzxxLBNaSOXy716Bnb9b+FP1G4ET RDKZHpie5Opf6JHu1WWXq81rJLdNe8KEHqP7wkchGtKQfOYbXXiX/XwvB3gdpRbWbHed /k0QLmRd+3cb9AKlvdG8/t8JqLmJxT7CMHcXpqUC6dc8T1ALKYHSdsL3o9s8+2o1joyi irUO/M2F4RRbbMen9snkxMdRCJl7O4Ub0UMALiM+U6JloN8yP+lZFF8KKM43GbMUgONX dfEJi+IrnAU29DqfYtOApVJHg+S/+1X19bEdyt2jjsrYQeluoaZ/0U5MtKEfzM3qCsy4 gQNQ== 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=iwIThqp5gvpW36hd8gHuKcgQvcXbqHeROqKS0WwcQ4Q=; b=eTi37iIdSG82U5bGEfBkTCgXFo8eeAAekXp4F7Xxokdd9tSSMCOOHqDTaW8S8dUydW MUEbERsNPgQv0aP+MJP8ShU51klFbBT8M3fQPOr4lgbXdAF+wybpmhoSUIZu+FDNWTxP Iluh95YAnuBLcFVcYuQONX4sEKcG+75scHFMRzUpZ5w7PvWJKxgJwKGGksosG4+fAnj5 vOyhBldm8kAbMn1kLwspcNgKcACoof/+LJ+Za2K7voS8m/W5L0v+lq5ukvwzF9kumDg0 9lqmju2YMNc1sjD8EES2UeHJZUPoDLZX91zGIl5gXMhdr6P7MdSLc9JZygw0mdortcvw PABA== X-Gm-Message-State: ABUngvfHADDsiRtB1dilScehWUcpbmT64Fr3/ThnESshRYSpewExYLfm2iStpVRSp/h/QyBG78tuwttnMbYwVpgj X-Received: by 10.55.19.97 with SMTP id d94mr27703943qkh.200.1477924245108; Mon, 31 Oct 2016 07:30:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.122.130 with HTTP; Mon, 31 Oct 2016 07:30:04 -0700 (PDT) From: Peter Thatcher Date: Mon, 31 Oct 2016 07:30:04 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114009c0a2e70e05402a0d16 Archived-At: Subject: [Ice] Review of trickle ICE 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, 31 Oct 2016 14:30:48 -0000 --001a114009c0a2e70e05402a0d16 Content-Type: text/plain; charset=UTF-8 I reviewed the latest draft of ICE (in github) and have the following comments, many of them similar to Taylor's recent comments: - There are lots of references to offers and answers. 5245bis no longer uses that terminology and I think trickle ICE should be updated to reflect the new terminology. - Also, there are lots of references still to SDP that I think we can get rid of. - The handling of duplicate candidates seems to still be "first one wins", and we've decided to change that to "highest priority wins, except for peer-reflexive" or something like that. Either way, the doc needs to be updated to match the decision. - Why is session-level end-of-candidates restricted to offers/answers. Better yet, if you don't talk about offers/answers at all, this should just go away. - It says ICE "will conclude" after nomination, but it should probably say "may conclude". - It seems like ICE restarts are basically re-defined. But why do that? Why not just say that ICE restarts work just like 5245bis, except that you can assume trickle ICE is supporte if it was previously? Or, better yet, why not just leave that to signaling to decide? - "ICE harvester" is strange term. "Gatherer" might be a better one. --001a114009c0a2e70e05402a0d16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
                                I reviewed the latest draft of ICE (in github) and have= the following comments, many of them similar to Taylor's recent commen= ts:

                                - There are lots of references to offers and answe= rs. =C2=A05245bis no longer uses that terminology and I think trickle ICE s= hould be updated to reflect the new terminology.

                                - Als= o, there are lots of references still to SDP that I think we can get rid of= .=C2=A0

                                - The handling of duplicate candidates seems t= o still be "first one wins", and we've decided to change that= to "highest priority wins, except for peer-reflexive" or somethi= ng like that.=C2=A0 Either way, the doc needs to be updated to match the de= cision.

                                - Why is session-level end-of-candidates restr= icted to offers/answers. =C2=A0 Better yet, if you don't talk about off= ers/answers at all, this should just go away.

                                - It sa= ys ICE "will conclude" after nomination, but it should probably s= ay "may conclude".

                                - It seems like ICE resta= rts are basically re-defined.=C2=A0 But why do that?=C2=A0 Why not just say= that ICE restarts work just like 5245bis, except that you can assume trick= le ICE is supporte if it was previously? =C2=A0 Or, better yet, why not jus= t leave that to signaling to decide?

                                - "ICE harve= ster" is strange term. =C2=A0"Gatherer" might be a better on= e.

                                --001a114009c0a2e70e05402a0d16-- From nobody Mon Oct 31 07:49:26 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 17B81128874 for ; Mon, 31 Oct 2016 07:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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.497, 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 qIug4sSPSXHZ for ; Mon, 31 Oct 2016 07:49:21 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1740129481 for ; Mon, 31 Oct 2016 07:49:20 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id c47so27870796qtc.2 for ; Mon, 31 Oct 2016 07:49:20 -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=C44rmv6xSEOEk7KNpGiNd2XvNSAp4v07+ESqc8Kn2zg=; b=OYlCiB6EN+NVvncSE0XIwbsxyuCfzCfJ/cmP8JOLbtP9AD82lg2Q4vqRRmawM6c9ax WAueJ7hlNtt1V6pVhfKOLQRG4DZzVbqXCn6UzMIPj7l6DXaQ9IUNynRBnG+fK8yAtyRY wFCYMpo3Xl4px/rh4GW0flrNp54bDuOqKtszbxWBwOTNQqc6BUfUDNDWJzrP66HYiPrv BE2TRmGjQmfyrc0owYbvlhXy1ZBuAyaAunrhijTarVWPY+stTsr5Y9jYKBl/MvEevLF6 C+i5tu9BotILshrQ0bEPVyad+gUk+RhuuFmGTUtjngijO04zR0/oOlaZxXkM9pA1X66D k0Dg== 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=C44rmv6xSEOEk7KNpGiNd2XvNSAp4v07+ESqc8Kn2zg=; b=T+D+MUZAALc7O4kMUMz/H0ZiIyNyg4NCpcHcTcxoAPIuxz5AXkIXzzHnZd+fCEU2p0 siDzAj5D/GgJhozrSAAeGz8yhLmq3uSN4TnddvV5hSk1/bVkSrHQuB5wILpMuCrSSR9R 1O7+0jXGk/S93h29SnPSXYINTrhcFo+rlx3MXbb9ZT+3eaTb1gVLCXJHcwoaQBiNTmDA o2zAMJpWczNhYHRBycKcDH0/LrH/DwZBmLUpLh2L0sNxXeQc9/pxT19jCxPE/Rbo3vXx VotFMjcyh6D7113KP23/wG8eYnZmvXKFvsHdckgfA5Xa84e90KzzcvVau3RnKoBnE59B fM4w== X-Gm-Message-State: ABUngvcOo/21oVMKm2wP/hCk4AezbWXGbcKtFThtsv4/Vj3o6Iaw1u51v6ER3hz8qLCgQN1XLwpN2s7Lgwg+Y3AQ X-Received: by 10.237.51.3 with SMTP id u3mr11654599qtd.12.1477925359443; Mon, 31 Oct 2016 07:49:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.122.130 with HTTP; Mon, 31 Oct 2016 07:48:38 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 31 Oct 2016 07:48:38 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c1257b20ec2f905402a505b Archived-At: Cc: Jana Iyengar , "Black, David" , "ice@ietf.org" Subject: Re: [Ice] Continue discussion of global pacing based on feedback from "transport guys" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 14:49:24 -0000 --94eb2c1257b20ec2f905402a505b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I can update the PR today. Then you can merge it and push an update. On Mon, Oct 31, 2016 at 6:23 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Can we expect an update to the pull request today, so I can generate and > submit a new version of the draft before the submission deadline? > > Yes, there are still some other issues that we need to do, but at least > we=E2=80=99d have a version with the Ta issue (which has been ongoing for= a while) > solved. > > Regards, > > Christer > > From: Ice on behalf of Jana Iyengar > > Date: Friday 28 October 2016 at 01:19 > To: "Black, David" > Cc: "pthatcher@google.com" , "ice@ietf.org" < > ice@ietf.org> > > Subject: Re: [Ice] Continue discussion of global pacing based on feedback > from "transport guys" > > On Thu, Oct 27, 2016 at 1:49 PM, Black, David > wrote: > >> Hi Peter, >> >> >> >> Some comments ... >> >> >> >> + Start with the following rules which would be generally >> >> + applicable to transport protocols: >> >> + >> >> + Let MaxPackets be the maximum number of transactions allowed to >> be outstanding in the network at any time, which SHOULD be 10. >> >> + Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT >> is known and 500ms otherwise. >> >> + Let MinPacing be the minimum pacing interval between >> transactions, which SHOULD be 5ms. >> >> + >> >> >> >> I=E2=80=99d cite references for at least the first two of the list items= , if not >> all three. The first item is based on TCP Initial Window of 10 segments= , >> which I believe is RFC 6928 (Jana will know for certain). The second >> > > Yes, RFC 6928 is right. I think this text could be made more precise: "Le= t > MaxBytes be the maximum number of bytes allowed to be outstanding in the > network at start-up, which SHOULD be 14600 bytes [RFC6928]." > > >> item is **not** general - 500ms is specific to STUN, and comes from RFC >> 5389 (credit to Bernard Aboba for finding this: >> https://www.ietf.org/mail-archive/web/ice/current/msg00379.html) - >> that=E2=80=99s important because the generally applicable number is larg= er - both >> RFC 6298 and draft-ietf-tsvwg-rfc5405bis use 1 second for TCP and UDP, >> respectively. >> > > Additionally, my reasoning for this was as follows (if you want to add > this to the rationale.) The TCP initial RTO is 1 sec (RFC 6298), and the > HTO can be less conservative, since an expected case is that no responses > are received even if the network is perfect. > > For the third item, I hope the rationale for the 5ms pacing interval is >> explained elsewhere in the draft. >> >> >> >> + Observe that ICE transactions are typically around 100 bytes or >> >> + less, which makes it reasonable to increase MaxPackets to about >> >> + 150. >> >> >> >> Add =E2=80=9Cbecause 1500 bytes is a typical TCP segment size=E2=80=9D t= o the end of this. >> > > If you use the byte-limit from RFC 6928 above you won't need to specify > TCP segment size, and you would change MaxPackets to MaxBytes. > > - jana > > >> Thanks, --David >> >> >> >> *From:* Peter Thatcher [mailto:pthatcher@google.com] >> *Sent:* Wednesday, October 26, 2016 10:00 AM >> *To:* Jana Iyengar >> *Cc:* Black, David; ice@ietf.org >> >> *Subject:* Re: [Ice] Continue discussion of global pacing based on >> feedback from "transport guys" >> >> >> >> OK, based on the discussion, I have made the following PR for 5245bis: >> >> >> >> https://github.com/ice-wg/rfc5245bis/pull/19 >> >> >> >> >> >> Please let me know if the logic and wording are right. >> >> >> >> On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar wrote: >> >> Sounds good to me. Thanks for taking the time to think this through, eve= n >> though it seems to have "collapsed" to the same answer. I definitely thi= nk >> it's worthwhile putting the reasoning into the draft. >> >> >> >> On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher >> wrote: >> >> Jana, are you OK with a global Ta value with text explaining how we >> arrived at that value? >> >> >> >> >> >> >> >> On Sun, Oct 16, 2016 at 5:22 AM, Black, David >> wrote: >> >> It looks like the Ta value suffices, and the prior discussion provides >> assurance that residential equipment won't be overrun ... but given the >> subtlety of the discussion that reached this result, I strongly recommen= d >> that we show our work ;-). In other words, the draft should provide a >> complete explanation of our reasoning, as both the ICE packet size and t= he >> 500ms value are specific to this discussion, making the conclusion *not* >> generally applicable. >> >> >> >> Thanks, --David ++Sent from my Android not-so-smartphone ... >> >> >> >> >> >> -------- Original message -------- >> >> From: Peter Thatcher >> >> Date: 10/16/16 7:21 AM (GMT+01:00) >> >> To: "Black, David" >> >> Cc: ice@ietf.org >> >> Subject: Re: [Ice] Continue discussion of global pacing based on feedbac= k >> from "transport guys" >> >> >> >> Assuming ICE checks are around 100 octets (which they are, almost), then >> a MaxPackets of 150 with a HTO of 500ms gives a maximum of about 300 >> packets/sec. But a Ta of 5ms gives a maximum of 200 packets/sec. So th= e >> Ta value would end up being more strict. >> >> >> >> Does that mean the Ta value of 5ms is sufficiently strict to render the >> HTO/MaxPacket rules unnecessary? Could we just reduce the ruleset down = to >> a min Ta value of 5ms? Or do you think those rules still have value? >> >> >> >> And as for the packet rate, previous to discussing with you "transport >> guys", there was a lot of discussion in the WG about packet rates, in >> particular rates of opening new NAT bindings with residential equipment. >> After a lot of discussion and experimenting in the the real world, we >> agreed that a lower bound of 5ms on the Ta was sufficient to cover packe= t >> rates and rates of opening NAT bindings. I can give more history on tha= t >> if you'd like. But that still left a concern over bit rates, which is >> how we ended up talking to you :). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Sep 28, 2016 at 8:45 AM, Black, David >> wrote: >> >> I'm apparently one of the "transport guys" referred to in the subject >> line ;-). >> >> In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, >> Peter Thatcher >> described the current proposal: >> >> ---------------------- >> 1. A maximum number of outstanding request packets, call it MaxPackets >> which SHOULD be 10. >> >> 2. A timeout for request packets, call it handshake timeout or HTO whic= h >> SHOULD be 2*RTT if the RTT is known and 500ms otherwise. >> >> 3. A global pacing rate of 5ms (like a global Ta). >> >> If all packets are dropped and the RTT is not known, then 1+2 are >> effectively 20 packets per second, >> well below what you would get with the bitrate limits we were asking for= . >> ---------------------- >> >> There's been some further discussion with the "transport guys" about >> packet size and bit rate. In essence, the rationale for 10 as the maxi= mum >> number of outstanding request packets (item 1 above) is based on the >> typical TCP segment size of about 1500 bytes. ICE request packets tend = to >> be much smaller, 100 bytes or less, which suggests that a factor of 15 >> could be available if bit rate matters but packet count doesn't. That >> may well be the case ... >> >> RFC 7141 (2014 BCP on AQM configuration/implementation) supports that >> view by recommending that AQM implementations count octets (i.e., >> forwarding resources are bit-congestible) as opposed to counting packets >> (i.e., forwarding resources are not packet-congestible). That RFC >> effectively asserts that the current Internet is bit-congestible only: >> https://tools.ietf.org/html/rfc7141 >> >> That would suggest a value of 150 for MaxPackets *when* all the packets >> are 100 octets or less, as should be case for ICE request packets. A >> possible area of concern (based on ICE use by Web RTC) is residential >> gateway/NAT boxes, but the 5ms pacing (item 3 above) ought to be suffici= ent >> to avoid overrunning them. >> >> What do people with more knowledge of and/or experience with residential >> gateway boxes think of this line of reasoning? >> >> Thanks, --David >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> >> >> >> >> >> >> >> > > --94eb2c1257b20ec2f905402a505b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
                                Yes, I can update the PR today.=C2=A0 Then you can merg= e it and push an update.

                                On Mon, Oct 31, 2016 at 6:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
                                Hi,

                                Can we expect an update to the pull request today, so I can generate a= nd submit a new version of the draft before the submission deadline?

                                Yes, there are still some other issues that we need to do, but at leas= t we=E2=80=99d have a version with the Ta issue (which has been ongoing for= a while) solved.

                                Regards,

                                Christer

                                From: Ice <ice-bounces@ietf.org> on behalf= of Jana Iyengar <jr= i@google.com>
                                Date: Friday 28 October 2016 at 01:= 19
                                To: "Black, David" <David.Black@dell.co= m>
                                Cc: "pthatcher@google.com" <pthatcher@google.com= >, "ice@ietf.org<= /a>" <ice@ietf.or= g>

                                Subject: Re: [Ice] Continue discuss= ion of global pacing based on feedback from "transport guys"

                                On Thu, Oct 27, 2016 at 1:49 PM, Black, David <David.Black@d= ell.com> wrote:

                                Hi Peter,

                                =C2=A0

                                Some comments ...

                                =C2=A0

                                +=C2=A0 <t>Start with the following ru= les which would be generally

                                +=C2=A0 applicable to transport protocols:

                                +=C2=A0 <list style=3D"numbers"= >

                                +=C2=A0=C2=A0=C2=A0 <t>Let MaxPackets = be the maximum number of transactions allowed to be outstanding in the netw= ork at any time, which SHOULD be 10.</t>

                                +=C2=A0=C2=A0=C2=A0 <t>Let HTO be the = transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms otherw= ise.</t>

                                +=C2=A0=C2=A0=C2=A0 <t>Let MinPacing b= e the minimum pacing interval between transactions, which SHOULD be 5ms.<= ;/t>

                                +=C2=A0 </list>

                                =C2=A0

                                I=E2=80=99d cite references for at least the= first two of the list items, if not all three.=C2=A0 The first item is bas= ed on TCP Initial Window of 10 segments, which I believe is RFC 6928 (Jana will know for certain).=C2=A0 The second =


                                Yes, RFC 6928 is right. I think this text could be made more precise: = "Let MaxBytes be the maximum number of bytes allowed to be outstanding= in the network at start-up, which SHOULD be 14600 bytes [RFC6928]."
                                =C2=A0

                                Additionally, my reasoning for this was as follows (if you want to add= this to the rationale.) The TCP initial RTO is 1 sec (RFC 6298), and the H= TO can be less conservative, since an expected case is that no responses ar= e received even if the network is perfect.

                                For the third item, I hope the rationale for= the 5ms pacing interval is explained elsewhere in the draft.=

                                =C2=A0

                                +=C2=A0=C2=A0=C2=A0 Observe that ICE transac= tions are typically around 100 bytes or

                                +=C2=A0=C2=A0=C2=A0 less, which makes it rea= sonable to increase MaxPackets to about

                                +=C2=A0=C2=A0=C2=A0 150.

                                =C2=A0

                                Add =E2=80=9Cbecause 1500 bytes is a typical= TCP segment size=E2=80=9D to the end of this.


                                If you use the byte-limit from RFC 6928 above you won't need to sp= ecify TCP segment size, and you would change MaxPackets to MaxBytes.

                                - jana
                                =C2=A0

                                Thanks, --David

                                =C2=A0

                                From: Peter Thatcher [mailto:pthatcher@google.com]
                                Sent: Wednesday, October 26, 2016 10:00 AM
                                To: Jana Iyengar
                                Cc: Black, David; = ice@ietf.org


                                Subject: Re: [Ice] Continue discussion of global pacing based on fee= dback from "transport guys"

                                =C2=A0

                                OK, bas= ed on the discussion, I have made the following PR for 5245bis:

                                = =C2=A0

                                =C2=A0

                                =C2=A0

                                Please = let me know if the logic and wording are right. =C2=A0=

                                =C2=A0

                                On Wed, Oct 19, 2016 at 12:26 PM, Jana Iyengar <<= a href=3D"mailto:jri@google.com" target=3D"_blank">jri@google.com> w= rote:

                                Sounds good to me. Thanks for taking the time to thi= nk this through, even though it seems to have "collapsed" to the = same answer. I definitely think it's worthwhile putting the reasoning i= nto the draft.

                                =C2=A0

                                On Wed, Oct 19, 2016 at 9:16 AM, Peter Thatcher <= pthatcher@google.= com> wrote:

                                Jana, a= re you OK with a global Ta value with text explaining how we arrived at tha= t value? =C2=A0=C2=A0

                                = =C2=A0

                                = =C2=A0

                                =C2=A0

                                On Sun, Oct 16, 2016 at 5:22 AM, Black, David <David.Black@dell.co= m> wrote:

                                It looks like the Ta value suffices, and the prior d= iscussion provides assurance that residential equipment won't be overru= n ... but given the subtlety of the discussion that reached this result, I = strongly recommend that we show our work ;-). =C2=A0 In other words, the draft should provide a complete explanatio= n of our reasoning, as both the ICE packet size and the 500ms value are spe= cific to this discussion, making the conclusion *not* generally applicable.= =C2=A0

                                =C2=A0

                                T= hanks, --David ++Sent from my Android not-so-smartphone ...

                                =C2=A0

                                =C2=A0

                                -------- Original message --------

                                From: Peter Thatcher <pthatcher@google.com>

                                Date: 10/16/16 7:21 AM (GMT+01:00)

                                To: "Black, David" <david.black@emc.com>

                                Subject: Re: [Ice] Continue discussion of global pac= ing based on feedback from "transport guys"

                                =C2=A0

                                Assumin= g ICE checks are around 100 octets (which they are, almost), then a MaxPack= ets of 150 with a HTO of 500ms gives a maximum of about 300 packets/sec.=C2= =A0 But a Ta of 5ms gives a maximum of 200 packets/sec.=C2=A0 So the Ta value would end up being more strict.=C2=A0= =C2=A0

                                = =C2=A0

                                Does th= at mean the Ta value of 5ms is sufficiently strict to render the HTO/MaxPac= ket rules unnecessary?=C2=A0 Could we just reduce the ruleset down to a min= Ta value of 5ms?=C2=A0 Or do you think those rules still have value?

                                = =C2=A0

                                And as = for the packet rate, previous to discussing with you "transport guys&q= uot;, there was a lot of discussion in the WG about packet rates, in partic= ular rates of opening new NAT bindings with residential equipment.=C2=A0 After a lot of discussion and experimenting in the the re= al world, we agreed that a lower bound of 5ms on the Ta was sufficient to c= over packet rates and rates of opening NAT bindings.=C2=A0 I can give more = history on that if you'd like. =C2=A0 =C2=A0But that still left a concern over bit rates, which is how we ended up talking to y= ou :).

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                = =C2=A0

                                =C2=A0

                                On Wed, Sep 28, 2016 at 8:45 AM, Black, David <David.Black@dell.co= m> wrote:

                                I'm apparently one of the "transport guys&q= uot; referred to in the subject line ;-).

                                In https://www.ietf.org/mail-archive/web/ice/current/msg00378.html, Peter Thatcher
                                described the current proposal:

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

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

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

                                If all packets are dropped and the RTT is not known, then 1+2 are effective= ly 20 packets per second,
                                well below what you would get with the bitrate limits we were asking for. ----------------------

                                There's been some further discussion with the "transport guys"= ; about packet size and bit rate.=C2=A0 =C2=A0In essence, the rationale for= 10 as the maximum number of outstanding request packets (item 1 above) is = based on the typical TCP segment size of about 1500 bytes.=C2=A0 ICE request packets tend to be much smaller, 100 bytes or less, which sugg= ests that a factor of 15 could be available if bit rate matters but packet = count doesn't.=C2=A0 =C2=A0 That may well be the case ...

                                RFC 7141 (2014 BCP on AQM configuration/implementation) supports that view = by recommending that AQM implementations count octets (i.e., forwarding res= ources are bit-congestible) as opposed to counting packets (i.e., forwardin= g resources are not packet-congestible).=C2=A0 That RFC effectively asserts that the current Internet is bit-congestible = only:                                 https://tools.ietf.org/html/rfc7141

                                That would suggest a value of 150 for MaxPackets *when* all the packets are= 100 octets or less, as should be case for ICE request packets.=C2=A0 A pos= sible area of concern (based on ICE use by Web RTC) is residential gateway/= NAT boxes, but the 5ms pacing (item 3 above) ought to be sufficient to avoid overrunning them.

                                What do people with more knowledge of and/or experience with residential ga= teway boxes think of this line of reasoning?

                                Thanks, --David

                                _______________________________________________
                                Ice mailing list
                                Ice@ietf.org
                                htt= ps://www.ietf.org/mailman/listinfo/ice

                                =C2=A0

                                =C2=A0

                                =C2=A0

                                =C2=A0



                                --94eb2c1257b20ec2f905402a505b-- From nobody Mon Oct 31 13:22:57 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 9E423129ADE; Mon, 31 Oct 2016 13:22:53 -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.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147794537359.23271.7339238645048422806.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 13:22:53 -0700 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-05.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:22:53 -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 : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Christer Holmberg Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-05.txt Pages : 94 Date : 2016-10-31 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 13:26:39 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CCA129AFD for ; Mon, 31 Oct 2016 13:26:36 -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 BdPbp-YKu-QI for ; Mon, 31 Oct 2016 13:26:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC8C129AA9 for ; Mon, 31 Oct 2016 13:26:34 -0700 (PDT) X-AuditID: c1b4fb2d-1c7ff700000009f7-f9-5817a8f71964 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id CA.E7.02551.7F8A7185; Mon, 31 Oct 2016 21:26:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 21:26:30 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Draft new version: 5245bis-05 Thread-Index: AdIztQENDS4zuzTmTi6eoFeqCqHi3w== Date: Mon, 31 Oct 2016 20:26:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE114EB@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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE114EBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7n+6PFeIRBodmaFt8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MvTPWshU8FauYcHgGSwPjdJEuRk4OCQETifePL7J3MXJxCAms Y5RYu3sRG4SzhFFi8a5FrF2MHBxsAhYS3f+0QRpEBBQlZrY8YwaxhQXUJObeaWWFiGtLTL84 mw3C1pO483srmM0ioCrxelMPC4jNK+ArsfjiXyYQm1FATOL7qTVgNrOAuMStJ/OZIA4SkFiy 5zwzhC0q8fLxP1YIW0lixfZLjBD1+RJLTrUwQcwUlDg58wnLBEbBWUhGzUJSNgtJGURcR2LB 7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERj4B7f8 1t3BuPq14yFGAQ5GJR7eghjxCCHWxLLiytxDjBIczEoivFbLgEK8KYmVValF+fFFpTmpxYcY pTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwztw14xFz7ymPEz/nMDBJHPl5I3T1twXf tN+3CfbfmPXu3LyyiZxXeU61Jsm/dVtVdNymf9Ek/SNvHbtKpHdeqPXce0RRc/Zc7gP5r2V3 7D8jyn79z4L6kKX+lyrVbk7tud/xZ+t/5Yq5O1w/v59ldeaXtqrLTqH8etUN01emz78Uxduu ciA76rYSS3FGoqEWc1FxIgDVucDSeAIAAA== Archived-At: Subject: [Ice] Draft new version: 5245bis-05 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, 31 Oct 2016 20:26:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE114EBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-05) of draft-5245bis. The only change from the previous version is regarding the Ta value, based = on the discussions with the transport folks. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE114EBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                                Hi,

                                 

                                I’ve submitted a new version (-05) of draft-52= 45bis.

                                 

                                The only change from the previous version is regardi= ng the Ta value, based on the discussions with the transport folks.

                                 

                                Regards,

                                 

                                Christer

                                --_000_7594FB04B1934943A5C02806D1A2204B4BE114EBESESSMB209erics_-- From nobody Mon Oct 31 14:03:09 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7A12949F for ; Mon, 31 Oct 2016 14:03:08 -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 qrhqeBjWIuec for ; Mon, 31 Oct 2016 14:03:06 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 EECF512711D for ; Mon, 31 Oct 2016 14:03:05 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id p9so13196837vkd.3 for ; Mon, 31 Oct 2016 14:03:05 -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=MDi/EIE35jIJussmLx01y84o376wj3rxWHdwk0vDvPo=; b=tJRwlR9/oce1PwZlvWu+byuuP7p6tOlX7NUUsSk3x7gNADujnz2TgFa00SsLTRVo6N r6n9YiYyXdMZ/5Rk66ZzYwQlHHA2BOW9fyqpYzzMMvLgTWG+r58McgSSYQRH8FJu2QSB WRyPlVRq4RIGtPHCJ5Ju/VlEy6bIwMbb1+1XvNU2EeE7dCjRc3c3zZaMD1NVBZSajUs1 CRAppdV/3+gXfuI0nrSumGkSqSty/yBwvaJa1gaybjvCGTab9ad/HOPqcGhti7tFqJqs Ed3cdS1NP7G5x+p6IyAjbTWGZljzRoSsGs6tGpYFBvKB8BbGqiXI6qdHZHwLbwoLOeON DtQg== 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=MDi/EIE35jIJussmLx01y84o376wj3rxWHdwk0vDvPo=; b=iuwvjQ1xhp9A0MHK3Es6y3UAkD2nn5MoT+HctkXv5Mbh/9LS11BWGRGgOpDp+Ks3e5 Wder7aRl1Wia2YH1gg9mfncLJlUdG7W13dZnscnHnmMIwOlZus6W73+x2sVpITUMreMG /ovu+PipUOpohM5DBlXu6RS4ePeCZ4dsFwoLN91j9Y7gayFX9dmA2ziXbU5/JJluMOye 96VLwyzdgDz0G8zp3tkfdSmV6yZnlek/d//XsFvaAWDRziDK2EovqTEBLCIZrg4UwpVA 3WUCPnP1BhPue7DHgNz73pjwkdIBG/HKPlmW5xhHErCUiUwb5RS037uPTNPeZtfuDCNz fBBw== X-Gm-Message-State: ABUngvfiW+Yv51tF2ThAYTcrhxG5k5etSL8JF2IW6xV8O6DlXpSkztTMqJdNOPOiqDidaCUKpxgBfY2YIGf4Uw== X-Received: by 10.31.158.81 with SMTP id h78mr4283847vke.34.1477947784785; Mon, 31 Oct 2016 14:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:02:44 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:02:44 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11427400b573d605402f8895 Archived-At: Subject: [Ice] draft-ietf-ice-trickle Section 3 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, 31 Oct 2016 21:03:08 -0000 --001a11427400b573d605402f8895 Content-Type: text/plain; charset=UTF-8 3 . Determining Support for Trickle ICE Application protocols that use Trickle ICE should do one of the following: [BA] Is the "should" intended to be a normative statement (e.g. SHOULD)? If so, I would change this to "To fully support Trickle ICE, applications SHOULD incorporate one of the following mechanisms to enable implementations to determine whether Trickle ICE is supported:" o Provide a way for agents to verify support of Trickle ICE prior to initiating a session (XMPP's Service Discovery [XEP-0030 ] is one such mechanism). o Make support for Trickle ICE mandatory so that user agents can assume support. Alternately, for cases where a protocol provides neither of the foregoing methods, agents may rely on provisioning/configuration [BA] I would delete this. Provisioning/configuration is not an interoperability strategy. Configuring Agents to assume Trickle ICE support fails if support is not mandatory and implementation of Trickle ICE does not help much if implementations are configured not to use it. or use the half trickle procedure described in Section 14 . [BA] Would change this to: "Where an application protocol cannot determine ahead of time whether Trickle ICE is supported, agents MAY utilize the half trickle procedure described in Section 14." Prior to sending an initial offer, agents using signaling protocols that support capabilities discovery can attempt to verify whether or not the remote party supports Trickle ICE. If an agent determines that the remote party does not support Trickle ICE, it MUST fall back to using Vanilla ICE or abandon the entire session. [BA] Don't think the term "Vanilla ICE" adds much. Why not just reference [RFC5245bis]? In application protocols that use SDP, a user agent supporting Trickle ICE MUST include a token of "trickle" in the ice-options attribute every time it generates an offer or an answer. This enables an agent that receives offers or answers to verify support by checking for inclusion of the token. [BA] This paragraph seems like it belongs in the SIP Trickle ICE draft. Dedicated discovery semantics and half trickle are needed only prior to session initiation (e.g., when sending the initial offer). After a session is established and Trickle ICE support is confirmed for both parties, either agent can use full trickle for subsequent offers. --001a11427400b573d605402f8895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
                                3<= span style=3D"font-size:1em;font-weight:bold;color:rgb(0,0,0)">. Determini= ng Support for Trickle ICE
                                   Application protocols that use Trickle ICE should do one of the
   following:

                                [BA] Is the "should" intended to be a nor=
mative statement (e.g. SHOULD)?
                                If s=
o, I would change this to "To fully support Trickle ICE, applications<=
/pre>
                                SHOULD incorporate one of the follow=
ing mechanisms to enable implementations
                                to determine whether Trickle ICE is supported:"
                                   o  Provide a way for agents to verify support of=
 Trickle ICE prior to
      initiating a session (XMPP's Service Discovery [XEP-0030]=
 is one
      such mechanism).
                                   o  Make su=
pport for Trickle ICE mandatory so that user agents can
      assume support.

   Alternately, for cases where a protocol provides neither of the
   foregoing methods, agents may rely on provisioning/configuration 
                                <=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">
                                [BA] I would delete this. Provisioning/configuration is not an
                                interoperability strategy.  Configuring Agents=
 to assume Trickle
                                ICE support fails=
 if support is not mandatory and implementation
                                of Trickle ICE does not help much if implementations are config=
ured
                                not to use it.  

                                   or =
use the half trickle procedure described in Section 14.

                                [BA] =
Would change this to: "Where an application protocol cannot determine<=
/pre>
                                ahead of time whether Trickle ICE is=
 supported, agents MAY utilize the half trickle procedure 
                                described in Section 14." 
                                   Prior to sending an initial offer, agents using sign=
aling protocols
   that support capabilities discovery can attempt to verify whether or
   not the remote party supports Trickle ICE.  If an agent determines
   that the remote party does not support Trickle ICE, it MUST fall back
   to using Vanilla ICE or abandon the entire session.

                                [BA] Don'=
;t think the term "Vanilla ICE" adds much.  Why not just referenc=
e
                                [RFC5245bis]?

   In application protocols that use SDP, a user agent supporting
   Trickle ICE MUST include a token of "trickle" in the ice-optio=
ns
   attribute every time it generates an offer or an answer.  This
   enables an agent that receives offers or answers to verify support by
   checking for inclusion of the token.

                                [BA] This paragraph seems l=
ike it belongs in the SIP Trickle ICE draft.

   Dedicated discovery semantics and half trickle are needed only prior
   to session initiation (e.g., when sending the initial offer).  After
   a session is established and Trickle ICE support is confirmed for

                                   both parties, either agent can u=
se full trickle for subsequent
   offers.
                                --001a11427400b573d605402f8895-- From nobody Mon Oct 31 14:09: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 36771129558 for ; Mon, 31 Oct 2016 14:09:26 -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 zOj7Hi1ng2WE for ; Mon, 31 Oct 2016 14:09:24 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BA012941A for ; Mon, 31 Oct 2016 14:09:23 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id d65so87444505vkg.0 for ; Mon, 31 Oct 2016 14:09:23 -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=qBdHV/UaCd4qbzu45Ax80VQA8Z6AWT6vk/C1Xtqrpz8=; b=CGH0a+Tkf5bnfbR6RprB5PSf0JVoK8Vol5TMAM9XwjL8TAxqkf/PHofjqwnlFPsRwV nyplbtYxiV509ufH/no648GF1z2/uZzANcnaQNEQnrkygCjYUC7rzDm3Py29ATyBwlSb IXK1RWQEQ86huyGNBmfzsw+hhGArP5zLqdHBk9MnwpMItOr5zxyU9WpKWUQFU4QPvQFl WhesUs6/XSFiY+1SO0UclnJZnp2ImW1vyq5WyinbpQqsnO/QJ4QHbH1oK1ehMjhuuPCj INJKKJEiYzFhGfarN/PUaPpdQldgRJ9lXpRyL9mnAxJvnk28f2ePsuHgrKzYBdSOX/1m FcoQ== 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=qBdHV/UaCd4qbzu45Ax80VQA8Z6AWT6vk/C1Xtqrpz8=; b=ja3vVFZRaOSBgEf888/iKgMtQme2wItzRSSCIue7L25+JUjWOORYNU7Rsg1tv8wKT+ XI5tozpVqMc5T0IkeheDlPs1TGqNe7RPTb1MOMxAU3oDbYAXfCEjxe/p++ajg9ivuMuc eabAllpHYuAjgW/v2eDTCQrIh/dyob8KJMAUuM6zV5X16SCpgbmsB6Goi9BUFG50aCx8 x4ltV2X3qmaXgA/ZPjoD1jIU0tIlVfbNSrhiu++ufOgN3b981NISLi4vDgf8D8vRKFM8 eInfEtpyZfMTNplB5xBJNA9muWo2SawFOc1JpqAoLJNHerW7pTe2dHIfXHG1QYgE0/S1 ebag== X-Gm-Message-State: ABUngvdmUXUmjW4lxDAXoIIx1uoPCPTeHgxxsZ9YA9XAXHqumAISLLFaXxIeFlfcgNm8FG1doZchIHLalq3U5w== X-Received: by 10.31.134.3 with SMTP id i3mr25793231vkd.57.1477948162555; Mon, 31 Oct 2016 14:09:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:09:02 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:09:02 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11441afc39c9ec05402f9ff4 Archived-At: Subject: [Ice] Trickle ICE Section 4 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, 31 Oct 2016 21:09:26 -0000 --001a11441afc39c9ec05402f9ff4 Content-Type: text/plain; charset=UTF-8 Trickle ICE agents MAY include any set of candidates in an offer. This includes the possibility of sending an offer that contains all the candidates that the agent plans to use (as in half trickle mode), sending an offer that contains only a publically-reachable IP address (e.g., a host candidate at a media relay that is known to not be behind a firewall), or sending an offer with no candidates at all (in which case the offerer can receive the answerer's initial candidate list sooner and the answerer can begin candidate gathering more quickly). For optimal performance, it is RECOMMENDED that the candidates in an initial offer (if any) be host candidates only. [BA] The first paragraph says that agents MAY send any set of candidates, then this paragraph says it is RECOMMENDED that host candidates only be sent in an initial offer. This seems like a contradiction, and the use of RECOMMENDED does not conform to RFC 2026 usage. Moreover, is it really true that sending host candidates is optimal? I don't believe that this is what the data shows (e.g. relay candidates are more likely to yield successful tests, enabling connectivity more quickly, on average). This would allow both agents to start gathering server reflexive, relayed, and other non-host candidates simultaneously, and it would also enable them to begin connectivity checks. --001a11441afc39c9ec05402f9ff4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
                                   Trickle ICE agents MA=
Y include any set of candidates in an offer.
   This includes the possibility of sending an offer that contains all
   the candidates that the agent plans to use (as in half trickle mode),
   sending an offer that contains only a publically-reachable IP address
   (e.g., a host candidate at a media relay that is known to not be
   behind a firewall), or sending an offer with no candidates at all (in
   which case the offerer can receive the answerer's initial candidate
   list sooner and the answerer can begin candidate gathering more
   quickly).

   For optimal performance, it is RECOMMENDED that the candidates in an
   initial offer (if any) be host candidates only.  

                                [BA] The first=
 paragraph says that agents MAY send any set of candidates,
                                then this paragraph says it is RECOMMENDED that hos=
t candidates only be
                                sent in an init=
ial offer.  This seems like a contradiction, and the
                                use of RECOMMENDED does not conform to RFC 2026 usage.  Mo=
reover, 
                                is it really true that send=
ing host candidates is optimal?  I don't believe
                                that this is what the data shows (e.g. relay candidates ar=
e more likely to
                                yield successful te=
sts, enabling connectivity more quickly, on average). 

                                   This woul=
d allow
   both agents to start gathering server reflexive, relayed, and other
   non-host candidates simultaneously, and it would also enable them to
   begin connectivity checks.
                                --001a11441afc39c9ec05402f9ff4-- From nobody Mon Oct 31 14:11: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 E9093129B32 for ; Mon, 31 Oct 2016 14:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6HuMkP5l91w for ; Mon, 31 Oct 2016 14:11:47 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994A1129B22 for ; Mon, 31 Oct 2016 14:11:47 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 51so96747636uai.1 for ; Mon, 31 Oct 2016 14:11:47 -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=LpjbJwMudErUsFcBPk8wvFQnxu6ieff+RIv0J5auCFw=; b=xHobvTh8Du6ugpmOq46zPHap7BqdJeRA6+cZgOVpQi2YxJqNLsC263JC/AepMxrhC6 n2P6uB6b4rwTT0Vy8p5feBEVnkW3C8R026LJMqhRlnMJfRPQ1FT1r+WXv8WEdvuOSYZB EYYbFdp62BtNKQOTp9N3oXO2VdE9FGj/82t9ZTJSGpJN3chQTtaaZlO13Ccb/GRFLLLG kPh+t/xbcc5ZfzdeHXtFN3BlVUmE8RsykziHnUCqyGKXDvtK/NV9U+lSvYhm/jvo4XC8 NI9cRZsGzo5aVweLErOizXg6MSILw6akgrtXP/rAaIUlsprIHaiTP9biRrAC1sRwFw7S WtOA== 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=LpjbJwMudErUsFcBPk8wvFQnxu6ieff+RIv0J5auCFw=; b=IidBAsD8tnkKp1GAkaGcJmd64q1LqwCRdo/BByVDu7kCnQsNKa5We9WMRelKdit0aG yIHszcygQvAskNyZuUwmXEqBDJUkRsUfVVbA/Hyem1XfjFR23F3WXsoGLxSJxskSRFHG hf4UpRCtgCEJyTZ0QJFbwSAC5Zpym/JfpizLH28zZRxqYsXO6ZPCn4bw6YK+r1J38xKE Rnd0uqhp8mX8doEm7i+tt2tdPh3m/8MXqFUCGc1T5kOYWLCU1Xte8wpbjsSnXx234j6y J0RTi5aLB05Gz9b8rvQOIHIgo/Wsm2Odux7T7gDFxnudmmKifz1EU/sOAfhVZLzYWJsG lmVA== X-Gm-Message-State: ABUngvcHdqMd9ULT7weYBvvx1ooO/6n/EEYguPbPfQMcyp/Kwpn01KDdYCRue/TMKwl4JteH4zqWDlUTzrhcFQ== X-Received: by 10.176.82.118 with SMTP id j51mr13632374uaa.161.1477948306386; Mon, 31 Oct 2016 14:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:11:26 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:11:26 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c190cb0cc752a05402fa74a Archived-At: Subject: [Ice] Trickle ICE Section 5 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, 31 Oct 2016 21:11:51 -0000 --94eb2c190cb0cc752a05402fa74a Content-Type: text/plain; charset=UTF-8 Receiving the Initial Offer When an agent receives an initial offer, it will first check if the offer or offerer indicates support for Trickle ICE as explained in Section 3 . If this is not the case, the agent MUST process the offer according to Vanilla ICE procedures [rfc5245bis ] or offer/answer processing rules [RFC3264 ] if no ICE support is detected at all. If support for Trickle ICE is confirmed, an agent will automatically assume support for Vanilla ICE as well even if the support verification procedure in [rfc5245bis ] indicates otherwise. Specifically, the rules from [rfc5245bis ] would imply that ICE itself is not supported if the initial offer includes no candidates in the offer; however, such a conclusion is not warranted if the answerer can confirm that the offerer supports Trickle ICE and thus fallback to [RFC3264 ] is not necessary. If the offer does indicate support for Trickle ICE, the agent will determine its role, start gathering and prioritizing candidates; while doing so, it will also respond by sending its own answer, so that both agents can start forming check lists and begin connectivity checks. [BA] Most of this text seems more appropriate to the SIP draft than this one, since it references RFC 3264. --94eb2c190cb0cc752a05402fa74a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
                                Receiving the Init=
ial Offer

   When an agent receives an initial offer, it will first check if the
   offer or offerer indicates support for Trickle ICE as explained in
   Section 3.  If this is not the case, the agent MUST process the off=
er
   according to Vanilla ICE procedures [rfc5245bis] or offer/answ=
er
   processing rules [RFC3264] if no ICE support is detected at all.
                                   If support for Trickle ICE is confirmed, an agent wil=
l automatically
   assume support for Vanilla ICE as well even if the support

                                   verification procedure in [rfc5245bis] indicates otherwise.
   Specifically, the rules from [rfc5245bis] would imply that ICE=
 itself
   is not supported if the initial offer includes no candidates in the
   offer; however, such a conclusion is not warranted if the answerer
   can confirm that the offerer supports Trickle ICE and thus fallback
   to [RFC3264=
] is not necessary.

   If the offer does indicate support for Trickle ICE, the agent will
   determine its role, start gathering and prioritizing candidates;
   while doing so, it will also respond by sending its own answer, so
   that both agents can start forming check lists and begin connectivity
   checks.

                                [BA] Most of this text seems more appropriate to the SIP=
 draft than this one, 
                                since it =
references RFC 3264.
                                --94eb2c190cb0cc752a05402fa74a-- From nobody Mon Oct 31 14:15: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 9BF931299A2 for ; Mon, 31 Oct 2016 14:15:14 -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 D0BjycMuSeZ2 for ; Mon, 31 Oct 2016 14:15:12 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2671299A5 for ; Mon, 31 Oct 2016 14:15:12 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d65so87557437vkg.0 for ; Mon, 31 Oct 2016 14:15:12 -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=0dVv3DLNgYQNzoL0Ob1+6VTt0VZ4wRD5DirPBs68iCs=; b=OnqugAZ8lQgUFWpkj1p5dKD81QDupRhrOxVQCv25dCi1R1vYzWI4k2VTkpuBWnzPED lev0rDwK8Mff7a+Gj29tF+cQtsIO5es1LU5P6tkRHwthuCzdIUAJiCOkuAGz4S9oHsuG y+HBRSVt9SScPFLUVH6Iln3nQ2bSlZlAVXN1LAErEtthZxk9+7VCnFU93pS0ZD1TVbIC WJaLC3KC0XQcUUvYDHt8O5US9lm0cyiYas94/ha4q+XfWW+d0+cS7b+VakRTAc/rMyI0 iXS/LI0NpL+rVdt0hidUeVZZVulokHG5Spaguog+1NokiWFNmdyscQ9W8OhFlgpiBrUa ka5g== 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=0dVv3DLNgYQNzoL0Ob1+6VTt0VZ4wRD5DirPBs68iCs=; b=byp+eDmBSw9RpKXMtWS8c2jF9ApPuxpLyAHL4NMoDEYX4gsSxtDjWnOo+eOL7u9WUb vYCDVRRBq2AB1tYPgNsIxRvhUZLU4mrhIQoMgrz+/vdi7RIyLeWmoo3HTGU42dPGBc4c xXEbCuY1FoIlSp8n7VxR4L1+gtzy1zvvr92tEMpKZ/dOrOwVChu+IluIuA+nyBHMDCTc AbDugfkEJ+3FMLfH/HndMDYOWF80uAZJlFgGkUROWSa+TqKGxrSNaTgp2TiUG1478rpZ 5RWiULHtxO3xwwFCfqy9k+tRV7o/dldFAJeb9TWQtgnuz1tNrjLthrO3nhhQpF9V/4pR kzmA== X-Gm-Message-State: ABUngvdGTlk8V2m/wsLiPaG77gCsTIAes6lS8KyA2f6ahWtUV/ItgcvGbg2RG4egJepapWUTUmZuo6LiPhIqcA== X-Received: by 10.31.224.71 with SMTP id x68mr22399328vkg.63.1477948511064; Mon, 31 Oct 2016 14:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:14:50 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:14:50 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07bb88ff9c6805402fb3ef Archived-At: Subject: [Ice] Trickle ICE Section 5.1 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, 31 Oct 2016 21:15:14 -0000 --94eb2c07bb88ff9c6805402fb3ef Content-Type: text/plain; charset=UTF-8 5.1 . Sending the Initial Answer An agent can respond to an initial offer at any point while gathering candidates. The answer can again contain any set of candidates, including all candidates or no candidates. (The benefit of including no candidates is to send the answer as quickly as possible, so that both parties can consider the overall session to be under active negotiation as soon as possible.) Unless the answering agent is protecting host addresses for privacy reasons, it would typically construct this initial answer including only host addresses, thus enabling the remote party to also start forming check lists and performing connectivity checks. [BA] The lack of normative language is inconsistent with Section 4. Also, don't understand why including only host addresses enables forming of check lists whereas other candidates would not permit this. In application protocols that use SDP, the answer MUST indicate support for Trickle ICE as described in Section 3 . [BA] Doesn't SDP guidance make more sense in the SIP draft? --94eb2c07bb88ff9c6805402fb3ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
                                5=
.1.  Sending the Initial Answer

   An agent can respond to an initial offer at any point while gathering
   candidates.  The answer can again contain any set of candidates,
   including all candidates or no candidates.  (The benefit of including
   no candidates is to send the answer as quickly as possible, so that
   both parties can consider the overall session to be under active
   negotiation as soon as possible.)  Unless the answering agent is
   protecting host addresses for privacy reasons, it would typically
   construct this initial answer including only host addresses, thus
   enabling the remote party to also start forming check lists and
   performing connectivity checks.
                                =

                                [BA] The lack of normative lang=
uage is inconsistent with Section 4.
                                Also, don't understand why including only host addresses enables formi=
ng
                                of check lists whereas other cand=
idates would not permit this. 
                                   In=
 application protocols that use SDP, the answer MUST indicate
   support for Trickle ICE as described in Section 3.

                                [BA] Do=
esn't SDP guidance make more sense in the SIP draft?
                                --94eb2c07bb88ff9c6805402fb3ef-- From nobody Mon Oct 31 14:23:50 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 9439F129B07 for ; Mon, 31 Oct 2016 14:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGNxsG8AA3oc for ; Mon, 31 Oct 2016 14:23:48 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 2179B129AFB for ; Mon, 31 Oct 2016 14:23:48 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 12so114788863uas.2 for ; Mon, 31 Oct 2016 14:23:48 -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=NCKqVi2lA7XbUDGaqFaEBRsAsyurU6x6M6ELX+bFlnc=; b=R8JrOdLj3I/lRCS6Krv7eQymMYMXuZxx8VgbZUkVWsHSiTQZ0YOJO/kZ1ieceh6XyR ZVVruu07Q1sFVVMHcw6l1fp37FH+jIlOjcvCHeEAQyJBppy6WkeWqSYdPXsq3Mq51tKi zFqwfXMg3FOvhoFngI+MsWOOjq2J1LxYCnh/p3OkpSN5PZ1fCXKWZeASJj8csUOkmtEA dDqlMiPd0zGBjfZrFOZ2nHzFlVi5vIdr8tc2ZUyucCrSayw0mZNS4xz/yN6wFTPct9Me S98X45X0fPCMG7THOeD3j+1YvJlZPep1of2a3Nm8mWcyzdTDLX1Z0eSohSIIViWOw8c8 OP/A== 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=NCKqVi2lA7XbUDGaqFaEBRsAsyurU6x6M6ELX+bFlnc=; b=ECdIPTZjtzdK5ZZMpE8lqqVpvqodKjW8L4kO8Td2AIL3xsLWX/NK/uDZ220V/RN/8u mXDShCvQAoEQYyozscnK580/YJPjigDvvdeEdEBp8dL3fky2W2N8R7HJKfDgsVX0akEF g8Km8A5Y6LK2/M0eH1w46g0NXTpqEg06Ml2iY6N3wZGstX13wtssmqd0aGhnbWpD8x5X dTiWGX09wf0oChxPj9u2My+JHU9qloKgGcLY3Tvm/77bV1Svz3mND/yvH3oNFz4soosE q5xgVNi4QiwdD84K5v5jGyAjVrAUssSyfBBYnbUnFMmZvbtnRFfXs+GgyV4HNo7WD95b DBHw== X-Gm-Message-State: ABUngvdSuk9XXqTtS1e+TrkMARdpTbNfckVd5vXK84IcHJ+kKdtRNYSw02KLM3Mf8oeyGDJE7n1AgLJPmxoLpg== X-Received: by 10.176.83.92 with SMTP id y28mr24306639uay.128.1477949026985; Mon, 31 Oct 2016 14:23:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:23:26 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:23:26 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1929febfeb5505402fd204 Archived-At: Subject: [Ice] Trickle ICE Section 8 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, 31 Oct 2016 21:23:49 -0000 --94eb2c1929febfeb5505402fd204 Content-Type: text/plain; charset=UTF-8 Next the agent sends (i.e., trickles) the newly discovered candidate(s) to the remote agent. The actual delivery of the new candidates is handled by signaling protocols such as SIP or XMPP. Trickle ICE imposes no restrictions on the way this is done or whether it is done at all. [BA] Surely Trickle ICE cannot function with no signaling, right? I think you mean to say that the specification does not require that all candidates be trickled and that the implementation can filter candidates. For example, some applications may choose not to send trickle updates for server reflexive candidates and rely on the discovery of peer reflexive ones instead. --94eb2c1929febfeb5505402fd204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
                                   Next the agent sends =
(i.e., trickles) the newly discovered
   candidate(s) to the remote agent.  The actual delivery of the new
   candidates is handled by signaling protocols such as SIP or XMPP.
   Trickle ICE imposes no restrictions on the way this is done or
   whether it is done at all. 

                                <=
/pre>
                                [BA] Surely Trickle ICE cannot funct=
ion with no signaling, right?
                                I thin=
k you mean to say that the specification does not require that all
                                candidates be trickled and that the implemen=
tation can filter candidates.

                                   For example, some applications may=
 choose
   not to send trickle updates for server reflexive candidates and rely
   on the discovery of peer reflexive ones instead.
                                --94eb2c1929febfeb5505402fd204-- From nobody Mon Oct 31 14:46: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 EAA8F129B3F for ; Mon, 31 Oct 2016 14:46: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 w_ghk8OAwm4N for ; Mon, 31 Oct 2016 14:46:35 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04C0129B36 for ; Mon, 31 Oct 2016 14:46:34 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id p9so14005357vkd.3 for ; Mon, 31 Oct 2016 14:46:34 -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=Pnb2pQ7c+sEQ1NX8PPajB3kjZI4dHfBLZNxpFAoYScM=; b=xtYU+be1T2PwmWRakZ8gI7Bp5H81LjPQbT4Zymz4EAumFUnPjqaEQq3p0wWeEWEgCG WdJDuE+DjwBNBH9C1KqAU6nO5N/UyYhSnI289P8E2iEs5vgOSwnK4p5xGOMVOO+M0ENT KiSwJjQDG3z+Qv0Etk0oiMy9NKp/1TnIogeAS6CxTMLXl67GRQKNeN6yXKzrvRteSMmC nT0+HiTmojRdTF8f1tp0xGn7vKiLibs3/wCOQ9HGFSk3Yvs47uoK3EljFX7BbuHC5Ajf 3SR4sci7bka8Zi+ddJHjy6/f7b8jKx58/6M0bGI/hmR5o9JejmOEEIiNUE02oc+UPU+a d5tQ== 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=Pnb2pQ7c+sEQ1NX8PPajB3kjZI4dHfBLZNxpFAoYScM=; b=mlG+kq26JwB1kOfaQlMukLkD9mV1Q7r4lMpdRoSumrkIcPQqr7Q1bZKiQQr5GwLUhK 96ssB6K7g4xfjjZ0SftACmmyMUtxkwZFZy7+KzOOTLWXBJmnSeaK5z/A0NCHCiCdv5DQ 4xlii9svdGaru00qe547MHUfn+B2aVbXe1cI+bFFkkDg511ms7xe1JQ2ZlziFg0aDp/L AJsP40AsJi9XJEZ4UESJsfbkM09SUvRMs3MGz8YNg0JSjs+Z709vcOutajod8XWf06iI 2KtQSrhs7DmUCM3vmCM5ZMExFkViyR3v3F5AA/0UCWbk+JILD6Mt1FIQMdgQbLftebHI 3MPA== X-Gm-Message-State: ABUngvd7tRwQZf63IcX0pPx49VAUndJnFnzC+hhbMgyaGgKyIW3hLoTkB+BcvxyQF0Wop9li+fTRbWVdemzUVQ== X-Received: by 10.31.92.215 with SMTP id q206mr8279233vkb.104.1477950393770; Mon, 31 Oct 2016 14:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:46:13 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:46:13 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114e5266376840054030242d Archived-At: Subject: [Ice] Trickle ICE Section 8 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, 31 Oct 2016 21:46:37 -0000 --001a114e5266376840054030242d Content-Type: text/plain; charset=UTF-8 In order to preserve this feature in Trickle ICE, when trickling candidates agents MUST respect the order of the components as they appear (implicitly or explicitly) in the offer/answer descriptions. Therefore a candidate for a specific component MUST NOT be sent prior to candidates for other components within the same foundation. [BA] The above sentence would seem to require candidates with the same foundation to be sent simultaneously. Is this what you mean?? For example, the following SDP description contains two components (RTP and RTCP) and two foundations (host and server reflexive): v=0 o=jdoe 2890844526 2890842807 IN IP6 2001:db8:a0b:12f0::1 s= c=IN IP4 2001:db8:a0b:12f0::1 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 5000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx raddr 2001:db8:a0b:12f0::1 rport 8998 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx raddr 2001:db8:a0b:12f0::1 rport 8998 For this description the RTCP host candidate MUST NOT be sent prior to the RTP host candidate. Similarly the RTP server reflexive candidate MUST be sent together with or prior to the RTCP server reflexive candidate. Note: The order restriction only applies among candidates that belong to the same foundation. [BA] This sentence would appear redundant. It is also equally important to preserve this order across media streams, which is covered by the requirement to always start unfreezing candidates starting from the first media stream as described under Section 5.2 . [BA] Would change this to: "It is also important to preserve order across media streams" --001a114e5266376840054030242d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
                                   In order to preserve =
this feature in Trickle ICE, when trickling
   candidates agents MUST respect the order of the components as they
   appear (implicitly or explicitly) in the offer/answer descriptions.
                                   Therefore a candidate for a specific =
component MUST NOT be sent prior
   to candidates for other components within the same foundation.

                                =
[BA] The above sentence would seem to require candidates with
                                the same foundation to be sent simultaneously.  I=
s this what you 
                                mean?? 

                                   =
For example, the following SDP description contains two components
   (RTP and RTCP) and two foundations (host and server reflexive):


     v=3D0
     o=3Djdoe 2890844526 2890842807 IN IP6 2001:db8:a0b:12f0::1
     s=3D
     c=3DIN IP4 2001:db8:a0b:12f0::1
     t=3D0 0
     a=3Dice-pwd:asd88fgpdd777uzjYhagZg
     a=3Dice-ufrag:8hhY
     m=3Daudio 5000 RTP/AVP 0
     a=3Drtpmap:0 PCMU/8000
     a=3Dcandidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host
     a=3Dcandidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host
     a=3Dcandidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
         raddr 2001:db8:a0b:12f0::1 rport 8998
     a=3Dcandidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
         raddr 2001:db8:a0b:12f0::1 rport 8998


   For this description the RTCP host candidate MUST NOT be sent prior
   to the RTP host candidate.  Similarly the RTP server reflexive
   candidate MUST be sent together with or prior to the RTCP server
   reflexive candidate.

   Note: The order restriction only applies among candidates that belong
   to the same foundation.

                                [BA] This sentence would appear redundan=
t.
                                   It is also equally important t=
o preserve this order across media
   streams, which is covered by the requirement to always start
   unfreezing candidates starting from the first media stream as
   described under Section 5.2.


                                [BA] Would change this to:
                                =

                                "It is also important to p=
reserve order across media streams"

                                --001a114e5266376840054030242d-- From nobody Mon Oct 31 14:55: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 78C15129B5D for ; Mon, 31 Oct 2016 14:55:12 -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 DcMZc7c8CEl9 for ; Mon, 31 Oct 2016 14:55:11 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508C31299BE for ; Mon, 31 Oct 2016 14:55:10 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id p9so14153903vkd.3 for ; Mon, 31 Oct 2016 14:55:10 -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=iUehu+hsssH9aB1WYimQmeWN2+lxDKjJJhbqcMWzBkY=; b=MD83jhyEbCNh7YClpLyCNapMMy3BMTwOvwCODYqh+wxb4PBmGkG5uC2+ttKe6Ol5nX aLsWlXchwEKNFvTYAMbCgAtN+LwlJ1nHeDNIlb/c1q31o6whdwBcOXgFS75gKZyB6HNw I8HQo0n5712gq1yTh5KkT0M2CuhaK6iYaVFMQ0SgnfGrJu0EfbJtWma7AOUmxImY+yTs jMV63l6ajTzFQKHKCL9H4QFr46Qpb8ofKToCQTlWIVo+f5fVbJB4c7Gln68fSlb45Rdi l80Y2ab1HUr21QKGi7NlriWYAKVQgd5uKHDf8sEWdLhH8E7k58MdNXzmIRatMLJfdsA6 0cMA== 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=iUehu+hsssH9aB1WYimQmeWN2+lxDKjJJhbqcMWzBkY=; b=NHy7RDI9maxNv7RQsFjRjTcChra1Trt4v72rbG4AN5gmvlnqZZZoSrcEqu58Jq7xPN Pr4527OOxqhbSWJF12B9/9o4aDT9k2paAuBEz6LGGFMCstv4Zs32/U0fnPFtw5h1HjHB O4xPRWfyUiRmXdAOevE24UP+4VXPN71GereiYmx9wIxfZPzsGBSjz9ODybl+xsR+PFzE A4O3AsQgjyjJcla2efE4b/+opO+iL4A87/cB3GLOpCsYSyrrWAnWZ0+3nj7eS1UpbI5K jcLCc/AyfBoZTbfb4CKOJXY+gUMy3fR/iRsfh1zvZ707F4WrXPy1hmmPcxBBtgE0gkoG mPuA== X-Gm-Message-State: ABUngvcpBAFR7pWAjsj1keY64PQPWhnNavCgFU44TewWe7urATdyldrFbCq3NXOrGe++dS59RuKv5i/KWUfXeQ== X-Received: by 10.31.74.4 with SMTP id x4mr22263205vka.58.1477950909193; Mon, 31 Oct 2016 14:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 14:54:48 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 14:54:48 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114daaacf027c705403042f9 Archived-At: Subject: [Ice] Trickle ICE Section 8.1 (Aggressive nomination) 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, 31 Oct 2016 21:55:12 -0000 --001a114daaacf027c705403042f9 Content-Type: text/plain; charset=UTF-8 Note: Replacing pre-existing pairs with seemingly equivalent higher-priority ones helps guarantee that both agents will have the same view of candidate priorities. This is particularly important during aggressive nomination, when priority is sometimes the only way a controlled agent can determine the selected pair. It is for that same reason that peer-reflexive candidates need to always be updated if equivalent alternatives are received through signaling... This would typically be the case with aggressive nomination. However, it is RECOMMENDED that controlling agents do send such indications whenever possible for the sake of consistency and to keep middle boxes and controlled agents up-to-date on the state of ICE processing.... [BA] Two mentions of aggressive nomination. Given that this is deprecated in RFC 5245bis, it would help to make it clear what the status is in Trickle ICE and what the support requirements are. --001a114daaacf027c705403042f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 

                                      Note: Rep=
lacing pre-existing pairs with seemingly equivalent
      higher-priority ones helps guarantee that both agents will have
      the same view of candidate priorities.  This is particularly
      important during aggressive nomination, when priority is sometimes
      the only way a controlled agent can determine the selected pair.
      It is for that same reason that peer-reflexive candidates need to
      always be updated if equivalent alternatives are received through
      signaling...


                                   This would typically be
   the case with aggressive nomination.  However, it is RECOMMENDED that
   controlling agents do send such indications whenever possible for the
   sake of consistency and to keep middle boxes and controlled agents
   up-to-date on the state of ICE processing....

                                =

                                [BA] Two mentions of aggressive nomination.  Given t=
hat this is deprecated
                                in RFC 5245bis, it would help =
to make it clear what the status is in
                                Trickle ICE an=
d what the support requirements are.

                                --001a114daaacf027c705403042f9-- From nobody Mon Oct 31 15:00: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 4F71B129B5D for ; Mon, 31 Oct 2016 15:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMX9syqmEvY2 for ; Mon, 31 Oct 2016 15:00:35 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 F04261299BE for ; Mon, 31 Oct 2016 15:00:34 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 51so97616308uai.1 for ; Mon, 31 Oct 2016 15:00:34 -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=h9NYYgpRT+uUl0WWNUSU1eS++Q5N1+t8YgrX2IY278I=; b=wJDmVnwGyRHRy7ekTZEzOOrH9ZHrPfkFKQqYeP7knm1XZhoiqhpO7s4SroLs3Sy3Ow 7bKquboe2iwBDc96JGP+H9qA04IClkUu8CNmwyhv7Pb/RARqvLVNZBdWhzykBevNnUy4 5Evn1IfM0QJwVxt3mpcvOcd6mPNtRQanVTrdGucODO8IxbutS//Vw/wnw03e49Owi6GN ijM8nUfOJiIApg8KdclLpBUzbvCemYH4dhg3U13/V5v5iQCvGjjXNyvWVvpQ6PD+zdxp HeICeQ4QGWWnAQKdHO64mW+TRE7Szgu9A5YormzPnS7n5DFqyzSf5AazKoL64xewDlXa HCrA== 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=h9NYYgpRT+uUl0WWNUSU1eS++Q5N1+t8YgrX2IY278I=; b=edfpg0WacSvKmq4SH8NdkATka9GyODu7kBzaXVlxwPn87a6ZQXK6VHTyt/d9HorMM9 M1tN3mddiIM9uOpgy2w+xnpgBlsUshKPzaVqgXPaJd1ax0n8pdzPH+yfbLKxll1xFgmb n3SjeCLW3UFP5VKk0X9PuKoJ/dcFoZQNsgAheQ1jTYu2Lur+dPFKC9fC/ysujgtBOJkF 0rGCYigyb/Zx0zEXOFeQydE6OC3+1sDWugBMgfiWOK/YzglADQ+92b9/jAmL41t8Ui85 hn7Oth/A9LzbgLa3DnpLG9ZdYkyNMHgpn7x++DTv6vmL5AWqppacWIpiDJSfUyPP86An +h2w== X-Gm-Message-State: ABUngvfUHvuqu6vcGTw+F2wbVGv2NZNX0NjCjQTvrw5Y/D89Y74sOcPB1DfYlYK8NZnjepdjGqne6B5YktjE+A== X-Received: by 10.176.67.1 with SMTP id k1mr21941632uak.177.1477951233799; Mon, 31 Oct 2016 15:00:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 31 Oct 2016 15:00:13 -0700 (PDT) From: Bernard Aboba Date: Mon, 31 Oct 2016 15:00:13 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114b5b48493b6b05403056d9 Archived-At: Subject: [Ice] Trickle ICE Section 8.2 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, 31 Oct 2016 22:00:36 -0000 --001a114b5b48493b6b05403056d9 Content-Type: text/plain; charset=UTF-8 Once all candidate gathering is completed or expires for a specific media stream, the agent will generate an "end-of-candidates" indication for that stream and send it to the remote agent via the signaling channel.... When an end-of-candidates indication is sent as part of an offer or an answer, it can be considered to apply to the session as a whole, which is equivalent to having it apply to all media streams. [BA] These two paragraphs would seem to contradict each other. One talks about "end of candidates" for a media stream and the other talks about it applying to all media streams. Should the latter material be moved to the SIP draft? --001a114b5b48493b6b05403056d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
                                   Once all candidate ga=
thering is completed or expires for a specific
   media stream, the agent will generate an "end-of-candidates"
   indication for that stream and send it to the remote agent via the
   signaling channel....
                                   When an =
end-of-candidates indication is sent as part of an offer or
   an answer, it can be considered to apply to the session as a whole,
   which is equivalent to having it apply to all media streams.

                                [BA=
] These two paragraphs would seem to contradict each other.  One talks abou=
t 
                                "end of candidates" for=
 a media stream and the other talks about it applying
                                to all media streams.  Should the latter material be move=
d to the SIP draft?
                                --001a114b5b48493b6b05403056d9--