From nobody Sun Apr 9 14:42:17 2017 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 EC9A7129408 for ; Sun, 9 Apr 2017 14:42:16 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=KgphxzTJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K3o2AdVF 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 9QqRNAPP6vJM for ; Sun, 9 Apr 2017 14:42:15 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86464128DE5 for ; Sun, 9 Apr 2017 14:42:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AC5B0206B7; Sun, 9 Apr 2017 17:42:12 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 09 Apr 2017 17:42:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=VCdhExQeDUHbpDZM3G /IIdQSahEwPrWUext0dm+M8CY=; b=KgphxzTJv4TQ0QHjctIN8MZeYtX4+RGft+ 86h0joCKHt+H0+O+6l0D2h6TuuXvIvFhGpmRdn1ZugdCF5Yu7FiBvZHOD/BkcbQd Y5fXh7S81WOATbH+IS8peL/N+gTnRmTsZeynUprOS3qSY97eIJ7ojf044z6I8KcX 05dPoRI6uEOjy8Vht3opKVFmV+1xwS9aBaKsDlxrnRUSG+vMxux6w3x1h2qw54XC tMYDCoH2QOkAEHzvyR5NABzD+HkJ5aeeCbWmMRuaJL2RJDCLPdJqFDT56ftR6nd7 uts1IQCtJxWlRB01VE8Z5YA6+uOcGzghH3bVBAWKTcF2YAUH9Sjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=VCdhExQeDUHbpDZM3G/IIdQSahEwPrWUext0dm+M8CY=; b=K3o2AdVF PBQoD5zw0pDQIsieGVWYHqYLKUU/yO2uha3Fy0MNd7t/4udaU4e4nZMkeWCQjABX AuXvbXOWzkwvAEPPaqEuaLhICVH0h2Dnn00UqZbS5yz3LjtX5wq+cYrAXuJeQ0By qDN4OYePHwpXu5M8HgPnN85otr9fD7LgoUPJ2UDrt9tDO9kGdIAPfAEU3z2WoWxU J/zn9qlsL1+CxfyzsoDRBxEe4+t9SpJlb04TNtJMmj/AjcoIU8cvsHJ5wsEAhI+m twlxbeEfGq/iO8WeIpFS+cyGN/4Q1CjnbuZCfTvCkowdnQhdSw5cCY9uGOZGyQ5Z Lnf5/7fTd4A1CQ== X-ME-Sender: X-Sasl-enc: 4yF4K0ns/F6Pzrqafgv8a21Owdz7JC8tv+nTZN8D4Ims 1491774132 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id E1ECC7E31E; Sun, 9 Apr 2017 17:42:11 -0400 (EDT) To: Peter Thatcher , Taylor Brandstetter , Christer Holmberg References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se> Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "ice@ietf.org" From: Peter Saint-Andre Message-ID: <19c7c1c6-fc7a-b10f-ffc0-1a3c9cf31dbe@stpeter.im> Date: Sun, 9 Apr 2017 15:42:11 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 21:42:17 -0000 Agreed. The authors will submit a new version soon that addresses Taylor's feedback. On 3/31/17 4:03 PM, Peter Thatcher wrote: > Ah, thanks for explaining this. I like your idea of making the real > intention explicit (pair and trickle in the same order). I think that's > much more clear and precise. > > > > > > On Thu, Mar 30, 2017 at 8:45 PM Taylor Brandstetter > wrote: > > In the phrase " A Trickle ICE agent MUST NOT pair a local > candidate until it has been trickled to the remote agent.", what > does "has been trickled" mean? > > > Sorry I'm late at responding to this, but I assumed the main > intention here was that candidates are paired in the same order that > they're trickled, because that was necessary for the unfreezing > logic to work. For example: suppose an endpoint already has remote > candidates, and then gathers RTP and RTCP candidates. It pairs them > in the order "RTCP, RTP" (maybe the STUN response for the RTCP > candidate came back first), resulting in an RTCP pair being unfrozen > first, but they're trickled in the order "RTP, RTCP" (as a result of > the restrictions of section 16), resulting in the remote endpoint > unfreezing the RTP pair first. > > Before, this would have resulted in things failing (as I recall). > But this isn't as much of a problem now; I'm looking at the current > section 8.1.1, and it would result in the local endpoint just > unfreezing /both/ pairs, so things would be able to proceed. > > But it still could result in extra pairs being unfrozen; is that > acceptable? If not, I'd suggest moving this note to section 16, and > making it more clear what the intention is. For example: "Candidates > MUST be paired, following the procedures in section 8.1.1, in the > same order that they're trickled." > > An important related question: There used to be a line that said > "When trickle updates are sent, each candidate MUST be delivered to > the receiving Trickle ICE implementation ... in the same order that > they were sent." But the "in the same order that they were sent" > part has been removed. Do we no longer require that the signaling > mechanism preserves ordering? If so, Section 16 doesn't make sense > any more; it requires a specific order of candidate trickling, but > that can't be guaranteed if the signaling mechanism doesn't preserve > ordering. All my ramblings above would be moot as well. > > On Thu, Mar 30, 2017 at 10:53 AM, Christer Holmberg > > wrote: > > Hi, > > Perhaps we could say something like "re-start or once all > candidates have been released", or something like that... We > seem to agree, so it's just about wording :) > > Regards, > > Christer > > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im > ] > Sent: 30 March 2017 20:42 > To: Peter Thatcher >; Christer Holmberg > >; Ari Keränen > > > Cc: ice@ietf.org > Subject: Re: [Ice] Trickle ICE review > > On 3/30/17 9:45 AM, Peter Thatcher wrote: > > Ah, I see what you mean now. > > > > In that case, could we just define "ICE session" as the > something like > > "stuff until the next ICE restart or the termination of all ICE > > activity by this agent"? > > Right, there's no "ICE session termination" message, so that'll > have to do. > > Peter > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Sun Apr 9 15:05:12 2017 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 0E73C128CDB for ; Sun, 9 Apr 2017 15:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=juygyzmd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QhXAOBDD 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 L24wxpuakw2S for ; Sun, 9 Apr 2017 15:05:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA1B126C7B for ; Sun, 9 Apr 2017 15:05:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E7AC520AAB; Sun, 9 Apr 2017 18:05:08 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 09 Apr 2017 18:05:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=WkuTWsZKmWNIDX7AOa UT5BQKtjukcUsjA2ebvQfsEEs=; b=juygyzmdWy8NS9mYszPJRLj9HjQC1i1Vdl haLWAy/WXlm5W7sfsAGlqG3QadMS7tqv6akSvAdk8Ow0WZTBfu2RnQXSrc4UOih1 EMbh8w4J5t8Uzub6CpouOA5SBysI1GLe41g4xO/B6RIhRiP6KFAqxiaoY0MA3xaw Ery+sbanqTr35o62Oi6aTMvPjnINxoE80Zq/1MF27vQYrBYY1UNhiovd6J8UzdFC ofSUClX01VngmQP1yhzjWgnbBPuyH/IWgZ8yXM9zSmRr9oImhHdv5uuwLByr1fAI 0MDClHxu9mp0eNzshIAmEqm1E7chw+7+FR53P911ur9DTBjQAN/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=WkuTWsZKmWNIDX7AOaUT5BQKtjukcUsjA2ebvQfsEEs=; b=QhXAOBDD Zh0xbn8IlkdoUa0PUtL7SfCQ94g3Qc27XEuACTzgaa/m2ZYNAbJGyritzTwSnMqL mpLsc5tEVKZ4h+a0GSYJ+qFrnnMSWVfjo1bYgobpHNICetibLgmFI2riXDgvv37R TpPnJQwjGm2C0CYqdCHEXqItS/RofkdzvtsiRQCg7DFxJto0fu+natnVvtMXR1t4 YymVFrFrmkz2TzNNTW90lR1xMU7av+27USvUvyyNlDPk1BuiQGil7KvY5jKXBdzh RMgniRd8x5b7ZLjICqPxv8h7tsdjeDhTdYMC/SHCP74Sgn0G5rnsVz+cReU0sidA Dv11HaD2to7Dhg== X-ME-Sender: X-Sasl-enc: wCP8J8U/cUjzzC087sQ1DUCav8oRa3jaax4CTy/pCUK6 1491775508 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 68DDF7E2B1; Sun, 9 Apr 2017 18:05:08 -0400 (EDT) To: Taylor Brandstetter References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: Date: Sun, 9 Apr 2017 16:05:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 22:05:11 -0000 On 3/30/17 9:45 PM, Taylor Brandstetter wrote: > In the phrase " A Trickle ICE agent MUST NOT pair a local candidate > until it has been trickled to the remote agent.", what does "has > been trickled" mean? > > > Sorry I'm late at responding to this, but I assumed the main intention > here was that candidates are paired in the same order that they're > trickled, because that was necessary for the unfreezing logic to work. > For example: suppose an endpoint already has remote candidates, and then > gathers RTP and RTCP candidates. It pairs them in the order "RTCP, RTP" > (maybe the STUN response for the RTCP candidate came back first), > resulting in an RTCP pair being unfrozen first, but they're trickled in > the order "RTP, RTCP" (as a result of the restrictions of section 16), > resulting in the remote endpoint unfreezing the RTP pair first. > > Before, this would have resulted in things failing (as I recall). But > this isn't as much of a problem now; I'm looking at the current section > 8.1.1, and it would result in the local endpoint just unfreezing > /both/ pairs, so things would be able to proceed. > > But it still could result in extra pairs being unfrozen; is that > acceptable? If not, I'd suggest moving this note to section 16, and > making it more clear what the intention is. For example: "Candidates > MUST be paired, following the procedures in section 8.1.1, in the same > order that they're trickled." WFM. > An important related question: There used to be a line that said "When > trickle updates are sent, each candidate MUST be delivered to the > receiving Trickle ICE implementation ... in the same order that they > were sent." But the "in the same order that they were sent" part has > been removed. Do we no longer require that the signaling mechanism > preserves ordering? If so, Section 16 doesn't make sense any more; it > requires a specific order of candidate trickling, but that can't be > guaranteed if the signaling mechanism doesn't preserve ordering. All my > ramblings above would be moot as well. This was changed between -04 (September 206) and -05 (January 2017). We received quite a bit of feedback in that time period (e.g., Bernard Aboba did a thorough review) and I would need to look at the specifics more carefully to determine why we removed the clause "and in the same order that they were sent". However, I think it's a reasonable requirement to place on a signaling protocol, so I'd be fine with re-adding in Section 8 ("Discovering and Sending Additional Local Candidates") and mentioning it in Section 15 ("Requirements for Signaling Protocols"). Peter From nobody Sun Apr 9 15:52:53 2017 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 4D2EF124C27 for ; Sun, 9 Apr 2017 15:52:52 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Ovq3jSfJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DOSIZhed 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 94SMpE6vk5pk for ; Sun, 9 Apr 2017 15:52:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239EA1242F5 for ; Sun, 9 Apr 2017 15:52:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 524752092C; Sun, 9 Apr 2017 18:52:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 09 Apr 2017 18:52:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=MfwMBdXM6KqUrhF7mj BDUNjxOtGCq+FiD195qNBaGJE=; b=Ovq3jSfJwhmH5ZNOUidtf7E24jEvZZCAJj 4s1gJYsbjS6VvF7Sys/tFVWXvYEbDN6V+A5G4miOjKPGaTWwjDvHB7Up4VzikxZb meVx5+IlLiOyig73mUVCkDsv+CZiS2WRhRehVVkqbY101cd7wEZnxzICsK559RbO 6AyNGDrwdXN8gDAnSz0xpykrQsS4gQupE6lU8Ot+WiG1F2vVwhcKo7f/INjziQih Sb/T9vLPHwvWBzEEywvAAmYohugkiHa6j3gPfUFfM0hCUrppfkE5/87TSFWi/AkN 38wi/StCbV9XrMfpVsPmVwOcxr0X9ELbGZtdYAXD9GQ2dMBhTZ0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=MfwMBdXM6KqUrhF7mjBDUNjxOtGCq+FiD195qNBaGJE=; b=DOSIZhed AWl0JXh0QuUt6ll9qkl22yAEkJkd/7m9cjXHn2QkpZ7abS6mDzqwcxb9suKw6j6U ycRr4Vr8VdKuueO2p3ezeTAEFdzXHZj7Iyl+8f1yR71i07h5vyNuJZuD4pmfMRZd RK/w/tLJis+8gLqZaDrsUETWFw5+cWPtbLMg02arFh9H/9IFfxRqkHS9ALEgBbx+ Qkww2hrE2lmrBMNaW+6uGmsfDq1EcosyIfKERNd0ImJYkU7E659nGa3KjBdRDpSx qZStkH+u5/2/k3ZjuylbYQCvEPeM4NQrHuhpac3qp89OOpnDO8qRoHoJwotGfAfU CJsPFUly24ionw== X-ME-Sender: X-Sasl-enc: WM05Ta9BTTm3RmxLS2rEk0kommXmjsHu4NDrhRAquD7p 1491778368 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id B27AA7E2B1; Sun, 9 Apr 2017 18:52:48 -0400 (EDT) To: Taylor Brandstetter , ice@ietf.org References: From: Peter Saint-Andre Message-ID: Date: Sun, 9 Apr 2017 16:52:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 22:52:52 -0000 On 3/30/17 11:28 PM, Taylor Brandstetter wrote: > I reviewed Trickle ICE, and overall I think it's in pretty good shape. > The main remaining areas I believe could be improved are: > > 1. Using terminology that's too SDP-specific. This has been improved a > lot since I last reviewed, but in my opinion it could still be made > a bit better. If it used the same sort of terminology as ICEbis > ("convey the ICE parameters" as opposed to "send an ICE > description"), I'd be happy. But I may be nitpicking too much. Consistency with rfc5245bis seems like a good idea. > 2. The unfreezing logic still doesn't seem perfect. If there are people > who still feel it's important, I'd be glad to explain the issues as > I see them further and work on fixing them. Though, I'm fine with > saying "what we have is good enough." The current unfreezing logic > at least now clearly ensures that one candidate per foundation is > always unfrozen. I feel we're at the "good enough" stage, but if you have significant concerns then let's hear you out. > Here are the individual issues I found: > > * In the terminology section: > o The definition of "ICE description" refers to SDP attributes > like "ice-ufrag" by name. This should be changed to just say > "username fragment" (for instance) and not rely on SDP terminology. Agreed. > o Also, in my opinion, using the terms "description," "session" > and even "attribute" ties this too much to SDP. ICEbis uses the > phrase "candidate information" to refer to the collection of > information that's signaled; can Trickle ICE refer to this, and > use similar terminology? ICEbis also says "parameter" rather > than "attribute". Fine with me, except for "session" (which is used in 5245bis and per list discussion will be defined in the next version of 5245bis). > o Related to the above: the concept of "sending an ICE > description," used in many places, sounds too much like "sending > an SDP offer" to me. ICEbis uses terminology like "the following > parameters and their data types need to be conveyed as a part of > the candidate exchange process," which is much less prescriptive > of an offer/answer or message-based signaling protocol. Again; > could Trickle ICE use similar terminology? I'll change it everywhere to "convey candidate information". > * In section 5.2: "With regard to pruning of duplicate candidate > pairs, a Trickle ICE agent SHOULD follow a policy of pruning the > lower priority candidate unless it is peer reflexive." This makes it > sound like peer reflexive candidates are /never/ pruned, but it's > the opposite; they're /always/ pruned, as described in Section 8.1. > Also, in ICEbis, candidates themselves aren't pruned, only candidate > pairs are. Peter Thatcher suggested changing this to "a policy of keeping the higher priority candidate unless it is peer reflexive". Does that meet your needs? > * In section 7.2: "Therefore a Trickle ICE agent MUST monitor whether > a check list is active or frozen independently of the state of the > candidate pairs in the check list (since there might not be any > pairs yet), and MUST consider a check list to be active whenever it > adds the first candidate pair with a state of Waiting to the check > list (see Section 8.1.1)." The first MUST seems redundant with the > second. I don't see a harmful redundancy here. > In earlier drafts, the purpose of monitoring the > "active/frozen" state independently was so that if a check list is > empty and frozen, the first pair added starts as "Frozen", while if > it's empty and active, the first pair added starts as "Waiting." If > the first pair /always/ starts as "Waiting," then tracking the > active/frozen state of a check list independently is no longer > necessary. The foregoing text does not say that the first pair always starts as Waiting. Do you think it should? > Though I don't see anything in Section 8.1.1 that relates > specifically to this, so I'm not sure what "see Section 8.1.1" is > referring to. Perhaps we'll remove that pointer. > * In section 8.1.1: In general I like the improvements that have been > made. However: > o The rules for how a new pair gets either a "Waiting" or "Frozen" > state don't completely match standard ICE; at least the part > where when one "media stream" completes, pairs from other media > streams with matching foundations are unfrozen. With the current > rules in section 8.1.1, only the topmost remaining pair in each > foundation is guaranteed to be unfrozen. Is this difference > acceptable? If it is, we should at least acknowledge it, and not > give the wrong impression by saying "Trickle ICE preserves all > of [the standard ICE] rules." > o The rule that a pair changes to "Waiting" if a pair in a lower > row is "Succeeded" means that if a pair in the lowermost row is > unfrozen first (which is possible, if the signaling mechanism > doesn't preserve ordering of candidates), all of the other pairs > with its foundation would be unfrozen as soon as it's unfrozen. > This seems odd. I'll talk with Emil about this. > * As mentioned in a different email thread, Section 16 doesn't make > sense any more if the signaling protocol isn't required to preserve > candidate ordering. See other thread. > I also found a couple of really trivial things, which I made a PR > for: https://github.com/ice-wg/trickle/pull/10 Merged. Peter From nobody Sun Apr 9 22:09:59 2017 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 432821286CA for ; Sun, 9 Apr 2017 22:09:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ud2G8fr1Xg0p for ; Sun, 9 Apr 2017 22:09:55 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613DA12940F for ; Sun, 9 Apr 2017 22:09:55 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p22so99682160qka.3 for ; Sun, 09 Apr 2017 22:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WOs3s47JyyFDkZFMKOWlVU5Uiraeo9YqhcLGuZ2IwcI=; b=olH3VJmzM2C2uG7t62uaSM0xfd31iC+Zz+EcWwfKRnNgaL0oML16eK2w9vykHXC3/p UrUNNoLxhl3N2OQAJdDnMY4CGrWACotjQhcUUPy7hT4k51JhiPKd2Z9ETDyxr5G+BRhB Id3P5I2hD5r19BbyC3J35SBjt8C0G2W+UP+Ua+aKW7/INVIjTD1uWLp+zHCiyZbqy6Zh EoUVxlyEP3GSkiSaCAlphwki3CZ5eGo1PVgQhzx3VFcnPMjTDXTnMSf3R8oibXyeDtzL NkGcO6r9XhEMohB0y0KHW9VnImazd0pn1l68jhbEWNoeUSBHLek7nyCm2gfoyq0azVfp yE1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WOs3s47JyyFDkZFMKOWlVU5Uiraeo9YqhcLGuZ2IwcI=; b=n2caXsBBKdGtC30dXyjhIEmTN5pWQHg0vG/UfUMrjzN1unksLLemOIEo+Hs6bqnRT5 fICXTCGBE7GRj6x45k/stJGDVNdOzsMy8OlLJJ105qKSvrvG/nf12dLOSdLaybysFWWq GHc22wNISHeo4YE5ajzXZhh5YcDO5d5IW+t720Gn0uNxKzrfar/VqBWZxpfuHXPI1oNb /nxcNduo9Lw3Q36fX7CbMAeO6r0UUkx9v4XO+60xPP19kNBl3y1qgtkVq3go0X20s+Eg 5Q78ZRpRgWtzzuLGFNVQiU1508ikWfWBZDf7VCA/iDj+3RJpTb/N2e1VMMsD7nvSys+u YCkA== X-Gm-Message-State: AFeK/H1bsmoR1LwMNUyzCn1Jbc/AA25EXWDc6mf4rtuZofZP+NMPwQsiocKQmdOWhIc2fsvw0ow9DpUzF25e9QiF X-Received: by 10.55.141.5 with SMTP id p5mr47089127qkd.322.1491800994382; Sun, 09 Apr 2017 22:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Sun, 9 Apr 2017 22:09:53 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Sun, 9 Apr 2017 22:09:53 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c085872592295054cc8fc6f Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 05:09:58 -0000 --94eb2c085872592295054cc8fc6f Content-Type: text/plain; charset=UTF-8 > > Peter Thatcher suggested changing this to "a policy of keeping the > higher priority candidate unless it is peer reflexive". Does that meet > your needs? That sounds good. > In earlier drafts, the purpose of monitoring the > > "active/frozen" state independently was so that if a check list is > > empty and frozen, the first pair added starts as "Frozen", while if > > it's empty and active, the first pair added starts as "Waiting." If > > the first pair /always/ starts as "Waiting," then tracking the > > active/frozen state of a check list independently is no longer > > necessary. > > The foregoing text does not say that the first pair always starts as > Waiting. Do you think it should? The foregoing text doesn't say the first pair starts as Waiting, but section 8.1.1 does. My overall point is that monitoring the active/frozen state independently isn't necessary with the new algorithm in 8.1.1, so this whole paragraph seems like it's outdated and can be removed. On Sun, Apr 9, 2017 at 3:52 PM, Peter Saint-Andre wrote: > On 3/30/17 11:28 PM, Taylor Brandstetter wrote: > > I reviewed Trickle ICE, and overall I think it's in pretty good shape. > > The main remaining areas I believe could be improved are: > > > > 1. Using terminology that's too SDP-specific. This has been improved a > > lot since I last reviewed, but in my opinion it could still be made > > a bit better. If it used the same sort of terminology as ICEbis > > ("convey the ICE parameters" as opposed to "send an ICE > > description"), I'd be happy. But I may be nitpicking too much. > > Consistency with rfc5245bis seems like a good idea. > > > 2. The unfreezing logic still doesn't seem perfect. If there are people > > who still feel it's important, I'd be glad to explain the issues as > > I see them further and work on fixing them. Though, I'm fine with > > saying "what we have is good enough." The current unfreezing logic > > at least now clearly ensures that one candidate per foundation is > > always unfrozen. > > I feel we're at the "good enough" stage, but if you have significant > concerns then let's hear you out. > > > Here are the individual issues I found: > > > > * In the terminology section: > > o The definition of "ICE description" refers to SDP attributes > > like "ice-ufrag" by name. This should be changed to just say > > "username fragment" (for instance) and not rely on SDP > terminology. > > Agreed. > > > o Also, in my opinion, using the terms "description," "session" > > and even "attribute" ties this too much to SDP. ICEbis uses the > > phrase "candidate information" to refer to the collection of > > information that's signaled; can Trickle ICE refer to this, and > > use similar terminology? ICEbis also says "parameter" rather > > than "attribute". > > Fine with me, except for "session" (which is used in 5245bis and per > list discussion will be defined in the next version of 5245bis). > > > o Related to the above: the concept of "sending an ICE > > description," used in many places, sounds too much like "sending > > an SDP offer" to me. ICEbis uses terminology like "the following > > parameters and their data types need to be conveyed as a part of > > the candidate exchange process," which is much less prescriptive > > of an offer/answer or message-based signaling protocol. Again; > > could Trickle ICE use similar terminology? > > I'll change it everywhere to "convey candidate information". > > > * In section 5.2: "With regard to pruning of duplicate candidate > > pairs, a Trickle ICE agent SHOULD follow a policy of pruning the > > lower priority candidate unless it is peer reflexive." This makes it > > sound like peer reflexive candidates are /never/ pruned, but it's > > the opposite; they're /always/ pruned, as described in Section 8.1. > > Also, in ICEbis, candidates themselves aren't pruned, only candidate > > pairs are. > > Peter Thatcher suggested changing this to "a policy of keeping the > higher priority candidate unless it is peer reflexive". Does that meet > your needs? > > > * In section 7.2: "Therefore a Trickle ICE agent MUST monitor whether > > a check list is active or frozen independently of the state of the > > candidate pairs in the check list (since there might not be any > > pairs yet), and MUST consider a check list to be active whenever it > > adds the first candidate pair with a state of Waiting to the check > > list (see Section 8.1.1)." The first MUST seems redundant with the > > second. > > I don't see a harmful redundancy here. > > > In earlier drafts, the purpose of monitoring the > > "active/frozen" state independently was so that if a check list is > > empty and frozen, the first pair added starts as "Frozen", while if > > it's empty and active, the first pair added starts as "Waiting." If > > the first pair /always/ starts as "Waiting," then tracking the > > active/frozen state of a check list independently is no longer > > necessary. > > The foregoing text does not say that the first pair always starts as > Waiting. Do you think it should? > > > Though I don't see anything in Section 8.1.1 that relates > > specifically to this, so I'm not sure what "see Section 8.1.1" is > > referring to. > > Perhaps we'll remove that pointer. > > > * In section 8.1.1: In general I like the improvements that have been > > made. However: > > o The rules for how a new pair gets either a "Waiting" or "Frozen" > > state don't completely match standard ICE; at least the part > > where when one "media stream" completes, pairs from other media > > streams with matching foundations are unfrozen. With the current > > rules in section 8.1.1, only the topmost remaining pair in each > > foundation is guaranteed to be unfrozen. Is this difference > > acceptable? If it is, we should at least acknowledge it, and not > > give the wrong impression by saying "Trickle ICE preserves all > > of [the standard ICE] rules." > > o The rule that a pair changes to "Waiting" if a pair in a lower > > row is "Succeeded" means that if a pair in the lowermost row is > > unfrozen first (which is possible, if the signaling mechanism > > doesn't preserve ordering of candidates), all of the other pairs > > with its foundation would be unfrozen as soon as it's unfrozen. > > This seems odd. > > I'll talk with Emil about this. > > > * As mentioned in a different email thread, Section 16 doesn't make > > sense any more if the signaling protocol isn't required to preserve > > candidate ordering. > > See other thread. > > > I also found a couple of really trivial things, which I made a PR > > for: https://github.com/ice-wg/trickle/pull/10 > > Merged. > > Peter > > > --94eb2c085872592295054cc8fc6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter Thatcher suggested changing this to "a = policy of keeping the
higher priority candidate unless it is peer reflexive"= ;. Does that meet
your needs?

That sounds= good.=C2=A0

> In earlier= drafts, the purpose of monitoring the
>=C2=A0 =C2=A0 =C2=A0"act= ive/frozen" state independently was so that if a check list is
>= =C2=A0 =C2=A0 =C2=A0empty and frozen, the first pair added starts as "= Frozen", while if
>=C2=A0 =C2=A0 =C2=A0it's empty and active= , the first pair added starts as "Waiting." If
>=C2=A0 =C2=A0 =C2=A0the first pair /always/ st= arts as "Waiting," then tracking the
>=C2=A0 =C2= =A0 =C2=A0active/frozen state of a check list independently is no longer>=C2=A0 =C2=A0 =C2=A0necessary.

The foregoing text does not say that the first pair always starts a= s
Wai= ting. Do you think it should?

The fo= regoing text doesn't say the first pair starts as Waiting, but section = 8.1.1 does. My overall point is that monitoring the active/frozen state ind= ependently isn't necessary with the new algorithm in 8.1.1, so this who= le paragraph seems like it's outdated and can be removed.
=C2=A0

On Sun, Apr 9, 2017 at 3:52 PM, Peter Saint-Andre <stpeter@s= tpeter.im> wrote:
On 3/30/17 11:28 PM, Taylor Brandstetter wrote:
> I reviewed Trickle ICE, and overall I think it's in pretty good sh= ape.
> The main remaining areas I believe could be improved are:
>
>=C2=A0 1. Using terminology that's too SDP-specific. This ha= s been improved a
>=C2=A0 =C2=A0 =C2=A0lot since I last reviewed, but in = my opinion it could still be made
>=C2=A0 =C2=A0 =C2=A0a bit better. If it used the same sort of terminolo= gy as ICEbis
>=C2=A0 =C2=A0 =C2=A0("convey the ICE parameters" as opposed t= o "send an ICE
>=C2=A0 =C2=A0 =C2=A0description"), I'd be happy. But I may be = nitpicking too much.

Consistency with rfc5245bis seems like a good idea.

>=C2=A0 2. The unfreezing logic still doesn't seem perfect. If there= are people
>=C2=A0 =C2=A0 =C2=A0who still feel it's important,= I'd be glad to explain the issues as
>=C2=A0 =C2=A0 =C2=A0I see them further and work on fixing them. Though,= I'm fine with
>=C2=A0 =C2=A0 =C2=A0saying "what we have is good enough." The= current unfreezing logic
>=C2=A0 =C2=A0 =C2=A0at least now clearly ensures that one candidate per= foundation is
>=C2=A0 =C2=A0 =C2=A0always unfrozen.

I feel we're at the "good enough" stage, but if you ha= ve significant
concerns then let's hear you out.

> Here are the individual issues I found:
>
>=C2=A0 =C2=A0* In the terminology section:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o The definition of "ICE description&qu= ot; refers to SDP attributes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like "ice-ufrag= " by name. This should be changed to just say
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"username fragment" (for in= stance) and not rely on SDP terminology.

Agreed.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0o Also, in my opinion, using the terms "= ;description," "session"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and even "attri= bute" ties this too much to SDP. ICEbis uses the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0phrase "candidate information&qu= ot; to refer to the collection of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information that's signaled; can = Trickle ICE refer to this, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use similar terminology? ICEbis also = says "parameter" rather
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than "attribute".

Fine with me, except for "session" (which is used in 5245b= is and per
list discussion will be defined in the next version of 5245bis).

>=C2=A0 =C2=A0 =C2=A0 =C2=A0o Related to the above: the concept of "= ;sending an ICE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description," u= sed in many places, sounds too much like "sending
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an SDP offer" to me. ICEbis uses= terminology like "the following
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parameters and their data types need = to be conveyed as a part of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the candidate exchange process,"= which is much less prescriptive
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of an offer/answer or message-based s= ignaling protocol. Again;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could Trickle ICE use similar termino= logy?

I'll change it everywhere to "convey candidate information&= quot;.

>=C2=A0 =C2=A0* In section 5.2: "With regard to pruning of duplicat= e candidate
>=C2=A0 =C2=A0 =C2=A0pairs, a Trickle ICE agent SHOULD = follow a policy of pruning the
>=C2=A0 =C2=A0 =C2=A0lower priority candidate unless it is peer reflexiv= e." This makes it
>=C2=A0 =C2=A0 =C2=A0sound like peer reflexive candidates are /ne= ver/ pruned, but it's
>=C2=A0 =C2=A0 =C2=A0the opposite; they're /always/ pruned, as descr= ibed in Section 8.1.
>=C2=A0 =C2=A0 =C2=A0Also, in ICEbis, candidates themse= lves aren't pruned, only candidate
>=C2=A0 =C2=A0 =C2=A0pairs are.

Peter Thatcher suggested changing this to "a policy of keeping = the
higher priority candidate unless it is peer reflexive". Does that meet=
your needs?

>=C2=A0 =C2=A0* In section 7.2: "Therefore a Trickle ICE agent MUST= monitor whether
>=C2=A0 =C2=A0 =C2=A0a check list is active or frozen i= ndependently of the state of the
>=C2=A0 =C2=A0 =C2=A0candidate pairs in the check list (since there migh= t not be any
>=C2=A0 =C2=A0 =C2=A0pairs yet), and MUST consider a check list to be ac= tive whenever it
>=C2=A0 =C2=A0 =C2=A0adds the first candidate pair with a state of Waiti= ng to the check
>=C2=A0 =C2=A0 =C2=A0list (see Section 8.1.1)." The first MUST seem= s redundant with the
>=C2=A0 =C2=A0 =C2=A0second.

I don't see a harmful redundancy here.

> In earlier drafts, the purpose of monitoring the
>=C2=A0 =C2=A0 =C2=A0"active/frozen" state independently was s= o that if a check list is
>=C2=A0 =C2=A0 =C2=A0empty and frozen, the first pair added starts as &q= uot;Frozen", while if
>=C2=A0 =C2=A0 =C2=A0it's empty and active, the first pair added sta= rts as "Waiting." If
>=C2=A0 =C2=A0 =C2=A0the first pair /always/ starts as "Wait= ing," then tracking the
>=C2=A0 =C2=A0 =C2=A0active/frozen state of a check lis= t independently is no longer
>=C2=A0 =C2=A0 =C2=A0necessary.

The foregoing text does not say that the first pair always starts as=
Waiting. Do you think it should?

> Though I don't see anything in Section 8.1.1 that relates
>=C2=A0 =C2=A0 =C2=A0specifically to this, so I'm not sure what &quo= t;see Section 8.1.1" is
>=C2=A0 =C2=A0 =C2=A0referring to.

Perhaps we'll remove that pointer.

>=C2=A0 =C2=A0* In section 8.1.1: In general I like the improvements tha= t have been
>=C2=A0 =C2=A0 =C2=A0made. However:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o The rules for how a new pair gets either a= "Waiting" or "Frozen"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't comp= letely match standard ICE; at least the part
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "media stream&quo= t; completes, pairs from other media
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching foundations are= unfrozen. With the current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1, only the topm= ost remaining pair in each
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guaranteed to be unfroz= en. Is this difference
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, we should at le= ast acknowledge it, and not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impression by saying &= quot;Trickle ICE preserves all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] rules." >=C2=A0 =C2=A0 =C2=A0 =C2=A0o The rule that a pair changes to &qu= ot;Waiting" if a pair in a lower
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0row is "Succeed= ed" means that if a pair in the lowermost row is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unfrozen first (which is possible, if= the signaling mechanism
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't preserve ordering of cand= idates), all of the other pairs
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with its foundation would be unfrozen= as soon as it's unfrozen.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This seems odd.

I'll talk with Emil about this.

>=C2=A0 =C2=A0* As mentioned in a different email thread, Section 16 doe= sn't make
>=C2=A0 =C2=A0 =C2=A0sense any more if the signaling pr= otocol isn't required to preserve
>=C2=A0 =C2=A0 =C2=A0candidate ordering.

See other thread.

> I also found a couple of really trivial things, which I made a PR
> for: https://github.com/ice-wg/trickle/pull/10

Merged.

Peter



--94eb2c085872592295054cc8fc6f-- From nobody Mon Apr 10 12:44:30 2017 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 87795129AD0 for ; Mon, 10 Apr 2017 12:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=G6DJtr4e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GCsgACqb 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 waX2QkETJrOS for ; Mon, 10 Apr 2017 12:44:26 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620BE1274D2 for ; Mon, 10 Apr 2017 12:44:26 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id ABDDE20BCF; Mon, 10 Apr 2017 15:44:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 10 Apr 2017 15:44:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=iKwzWsa0jHsgodS8oO Hz/a9Vnj9iabybQQI/SRpcCgY=; b=G6DJtr4e/+JP4EnQ4huhV+4uAT8tB3vtaT u5is/TMWqckiCCy51Sau0K9wCyEOtU2Fl6gk7ihRDQDB7+662rh4lnjBf2yfqxb7 EAliOV0UVxi9/n6Gl/PuKtf8X8EcMrOcSIgiR4IrELiYalBb+PZAU70cV8pxPTBt fcSg7h93A2kilBKGQpYghRhmP2RvItXFp8EjaEpUfM44QuFPQBFYP3JvS9tXVNv7 aEjR3Qj5tXQhd3XoNPEk7xQaNP+cik60EuWC2CirlDxeNThz+XaE1h6MBq+a3GRS +LLzywEQ8FdTqSuLj8yANYKC5T1PMF9zFNvwFbeBW5FVNwo4uARg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=iKwzWsa0jHsgodS8oOHz/a9Vnj9iabybQQI/SRpcCgY=; b=GCsgACqb VrBqk3yWp8/VTfctZ7bQJLNE5DVdogVUhGGfhkvJ3f7dnh8voJLlEjRn4T3kspXe yWMlVKr2DUtbeNHJN/gGTpYA1qDNmOv/D8nru0L0Hg4henqkjxvGo9BYmXJaVwO0 nitYBczs/lA0LtG8UTNH6E+lYWNhsPoAsAq0d/Ev1i7/u6XVZWU1CXDs2COkZ+GF qlYnqYh8Z8eA0rr3AzYAsnh7szWqQmmVgTPUEzMTMTiycPenc3tLgXQHVE68+N1R h4jDgUJeL07RtoOjL9ZMjrMawCo2/ho9VkhTjd42qTFnG5sacy0hKAJEjAp5Y1Rt 7AwyaotqB43XFg== X-ME-Sender: X-Sasl-enc: TgQIXbuy6buw4jnnMnF+CDCCHdHdRhrCXgQlxAEG+Gn6 1491853465 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 358267E2B0; Mon, 10 Apr 2017 15:44:25 -0400 (EDT) To: Taylor Brandstetter References: Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: Date: Mon, 10 Apr 2017 13:44:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:44:29 -0000 On 4/9/17 11:09 PM, Taylor Brandstetter wrote: > > > In earlier drafts, the purpose of monitoring the > > "active/frozen" state independently was so that if a check list is > > empty and frozen, the first pair added starts as "Frozen", while if > > it's empty and active, the first pair added starts as "Waiting." If > > the first pair /always/ starts as "Waiting," then tracking the > > active/frozen state of a check list independently is no longer > > necessary. > > The foregoing text does not say that the first pair always starts as > Waiting. Do you think it should? > > > The foregoing text doesn't say the first pair starts as Waiting, but > section 8.1.1 does. My overall point is that monitoring the > active/frozen state independently isn't necessary with the new algorithm > in 8.1.1, so this whole paragraph seems like it's outdated and can be > removed. Good catch. So although it's true that the agent needs to monitor the "state" of the check list (note: no such check list state is actually defined in 5245bis) independent of the state of the candidate pairs in the list, to your point the second clause ("MUST consider a check list to be active whenever it adds the first candidate pair with a state of Waiting to the check list") is unnecessary here because 8.1.1 now says how to handle things (i.e., when inserting a new candidate pair into an empty check list, set it to a state of Waiting). Does that sound right? Peter From nobody Mon Apr 10 12:53:59 2017 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 226E9129AB6 for ; Mon, 10 Apr 2017 12:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=n1aj6R83; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gBh0w7XF 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 p1W4rX60vNA5 for ; Mon, 10 Apr 2017 12:53:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8947127876 for ; Mon, 10 Apr 2017 12:53:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1C07B20A73; Mon, 10 Apr 2017 15:53:56 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 10 Apr 2017 15:53:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=eYvV9kJZbo6+ndKHN+ V8EAsBNNK+mDIbZxKv/gG6/QY=; b=n1aj6R83Daw64FXdlHcnY+PWWBeBWBEgpy k5qkrHyjGgQueqDLYRT1wubgcAI1xxFSGcHzL5RJCsECpbfNfBoCMWttctCZKV3A cEmLFgVNn3GbJO8ebdNeggIu0U8jRpETL3u1kZZo2ClUUvfrroblOg0h9fSiAePv V0ZA2cFsWRByaGVSbEurew5GiHfhJVUlZ57oCA08/2BSGzQEyqjU9Ln+3n1gxvC1 li7DV+3pGNexIQm/6s0ghHPbTNtHAyt98jY7j+OoNXWmoGIGfT2/NmdJ/AGuzM/K MyUx2ZS6a0B5vmN94ugNDfQFLA2SAn1/wjOdAWVOY0/Ek+tQtzOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=eYvV9kJZbo6+ndKHN+V8EAsBNNK+mDIbZxKv/gG6/QY=; b=gBh0w7XF MNL9VvCzDqmp/zxlvEOGUpZxeh3NaCC9t8cggGJrsAPQv/cQWHDTr1qYpSa/u69z SBmSaAbns0xp+KhJ7cdon8kBYH3Avzxezabc5ZeEH6Gi06ijcdUSSWZ+/r0u+IoN 9MbzDszfPvEhs1Hbui02R44vCO00NKS/HZHyCbIaA1jFAXY5VjvF5otFYEntwS0L wAGgontd9rdaQLmdHDriU229CskUbrKwManHedi3jfkuybpSlBlKocOICBy0Hqls ckjtgZjoPN6RYcVrSgq/JEybmjImjI5/NZzAepfJqOtVSOGXOI+GgJU8VGF4653O 7dBBQsfYjgC4uw== X-ME-Sender: X-Sasl-enc: hMR/jG4Q142GTzBJXuqfnPyMYJ8C0vBgDT7kz+77idsU 1491854035 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id A6E897E334; Mon, 10 Apr 2017 15:53:55 -0400 (EDT) To: Taylor Brandstetter References: Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: Date: Mon, 10 Apr 2017 13:53:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:53:58 -0000 On 4/10/17 1:44 PM, Peter Saint-Andre wrote: > On 4/9/17 11:09 PM, Taylor Brandstetter wrote: > >> >> > In earlier drafts, the purpose of monitoring the >> > "active/frozen" state independently was so that if a check list is >> > empty and frozen, the first pair added starts as "Frozen", while if >> > it's empty and active, the first pair added starts as "Waiting." If >> > the first pair /always/ starts as "Waiting," then tracking the >> > active/frozen state of a check list independently is no longer >> > necessary. >> >> The foregoing text does not say that the first pair always starts as >> Waiting. Do you think it should? >> >> >> The foregoing text doesn't say the first pair starts as Waiting, but >> section 8.1.1 does. My overall point is that monitoring the >> active/frozen state independently isn't necessary with the new algorithm >> in 8.1.1, so this whole paragraph seems like it's outdated and can be >> removed. > > Good catch. So although it's true that the agent needs to monitor the > "state" of the check list (note: no such check list state is actually > defined in 5245bis) independent of the state of the candidate pairs in > the list, to your point the second clause ("MUST consider a check list > to be active whenever it adds the first candidate pair with a state of > Waiting to the check list") is unnecessary here because 8.1.1 now says > how to handle things (i.e., when inserting a new candidate pair into an > empty check list, set it to a state of Waiting). > > Does that sound right? Hmm, not exactly. I'll need to think about this when I'm not at the office. :-) From nobody Mon Apr 10 12:57:00 2017 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 3497E129AD5 for ; Mon, 10 Apr 2017 12:56:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qez2X0RSMDMJ for ; Mon, 10 Apr 2017 12:56:56 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2CC127876 for ; Mon, 10 Apr 2017 12:56:54 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p68so97820440qke.1 for ; Mon, 10 Apr 2017 12:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ncGHhFabAtE/YxrSfEBIaUsKFmT4ofDZ25Mol4/5uXE=; b=EUP4G5AOMNKQ/zMza9NO7GiOD6SFSpn3+FiycXVfHvXS0XJblK1eQTgfyLDCsHLfn1 l91oATXvd88mhECwFHWXX5o/+wI8I8WwSOWlm/KdkZbhkOjXblOUD5lqfd6fSklwbWJC zLxquIS58F8VmQilPgiP6nBmqCp7sSbkUl1g4OZa+keosddNgoewzQDI8/n6ASAb4O4F cgk35ijOxPp4RB9t0T5qFKTPlvjOoaxlE3jtfn0e8YoFOmTdjB/3hO3BLCiL+SG9b72w kCGjqWkfOEh72jtkBeBGG6f41haPTANLKHunCasNOkmHYzlu9TcBjYuhNXthvNyCo+U+ qAyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ncGHhFabAtE/YxrSfEBIaUsKFmT4ofDZ25Mol4/5uXE=; b=dGSjT0NoF2W+XPy9o3BzJNGMUX947MzrjYdqY4rJ0qrSq636KApnQg8xtk+iU3lXG6 ZbcuJ1jS68rDqEZ9Z9ugLAJTrdGsn89um2yB7QkE0q4wooQqKPO0YfQ51Ko6rirx/9m+ uk8ZnoDsLcRToygCQHek0+VcCd0r8vSFOI1L+gUok0JqNJem8AfbszL0Dnls8QF4G6xd frcbyrVc2RNUSl4H88C7wtIatbQxbmh3OaJ2CkaDvbVHqEb5rUB8PdvhRcRxJJif3RWZ v1BXKuXqfSh3wQ6Yfg9PIuOe0j9c2cA7Hl+OXXYp2DS1TuLy8cPsgMKOh02h1CJdd5is cF/g== X-Gm-Message-State: AFeK/H3ka0GsbrBDhohh+k3rbQePM9Fiov6n7XddHyRga1/Lf0itMhCniBx48WcN7OTh1z/y52MnF0LbIBWj2p+w X-Received: by 10.55.43.219 with SMTP id r88mr52168795qkr.143.1491854213462; Mon, 10 Apr 2017 12:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Mon, 10 Apr 2017 12:56:51 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Mon, 10 Apr 2017 12:56:51 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11493ed8737e13054cd560c5 Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:56:58 -0000 --001a11493ed8737e13054cd560c5 Content-Type: text/plain; charset=UTF-8 > > it's true that the agent needs to monitor the > "state" of the check list (note: no such check list state is actually > defined in 5245bis) independent of the state of the candidate pairs in > the list I don't see how this is true any more. If this additional "frozen/active" flag is necessary, where is it used? Previously, I assumed it was used to set the state of the first candidate pair in a checklist to either "Waiting" or "Frozen". But the state of the first pair will now *always* be set to "Waiting" (due to the "topmost in column" rule). Maybe section 8.1.1 was intended to reference this "frozen/active" check list state? But it doesn't currently. Also, the latest draft of RFC5245bis *does* still define a check list state. See section 5.1.3.1 , "Check List State". On Mon, Apr 10, 2017 at 12:53 PM, Peter Saint-Andre wrote: > On 4/10/17 1:44 PM, Peter Saint-Andre wrote: > > On 4/9/17 11:09 PM, Taylor Brandstetter wrote: > > > >> > >> > In earlier drafts, the purpose of monitoring the > >> > "active/frozen" state independently was so that if a check > list is > >> > empty and frozen, the first pair added starts as "Frozen", > while if > >> > it's empty and active, the first pair added starts as > "Waiting." If > >> > the first pair /always/ starts as "Waiting," then tracking the > >> > active/frozen state of a check list independently is no longer > >> > necessary. > >> > >> The foregoing text does not say that the first pair always starts as > >> Waiting. Do you think it should? > >> > >> > >> The foregoing text doesn't say the first pair starts as Waiting, but > >> section 8.1.1 does. My overall point is that monitoring the > >> active/frozen state independently isn't necessary with the new algorithm > >> in 8.1.1, so this whole paragraph seems like it's outdated and can be > >> removed. > > > > Good catch. So although it's true that the agent needs to monitor the > > "state" of the check list (note: no such check list state is actually > > defined in 5245bis) independent of the state of the candidate pairs in > > the list, to your point the second clause ("MUST consider a check list > > to be active whenever it adds the first candidate pair with a state of > > Waiting to the check list") is unnecessary here because 8.1.1 now says > > how to handle things (i.e., when inserting a new candidate pair into an > > empty check list, set it to a state of Waiting). > > > > Does that sound right? > > Hmm, not exactly. I'll need to think about this when I'm not at the > office. :-) > > > --001a11493ed8737e13054cd560c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
it's= true that the agent needs to monitor the
"state" of the check= list (note: no such check list state is actually
defined in 5245bis) in= dependent of the state of the candidate pairs in
the list

I don't see how this is true any more. If this additi= onal "frozen/active" flag is necessary, where is it used? Previou= sly, I assumed it was used to set the state of the first candidate pair in = a checklist to either "Waiting" or "Frozen". But the st= ate of the first pair will now always be set to "Waiting" = (due to the "topmost in column" rule). Maybe section 8.1.1 was in= tended to reference this "frozen/active" check list state? But it= doesn't currently.


On Mon, Apr 10, 2017 at 1= 2:53 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On 4/= 10/17 1:44 PM, Peter Saint-Andre wrote:
> On 4/9/17 11:09 PM, Taylor Brandstetter wrote:
>
>>
>>=C2=A0 =C2=A0 =C2=A0> In earlier drafts, the purpose of monitori= ng the
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0"active/frozen&quo= t; state independently was so that if a check list is
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0empty and frozen, the f= irst pair added starts as "Frozen", while if
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0it's empty and acti= ve, the first pair added starts as "Waiting." If
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0the first pair /always/= starts as "Waiting," then tracking the
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0active/frozen state of = a check list independently is no longer
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0necessary.
>>
>>=C2=A0 =C2=A0 =C2=A0The foregoing text does not say that the first = pair always starts as
>>=C2=A0 =C2=A0 =C2=A0Waiting. Do you think it should?
>>
>>
>> The foregoing text doesn't say the first pair starts as Waitin= g, but
>> section 8.1.1 does. My overall point is that monitoring the
>> active/frozen state independently isn't necessary with the new= algorithm
>> in 8.1.1, so this whole paragraph seems like it's outdated and= can be
>> removed.
>
> Good catch. So although it's true that the agent needs to monitor = the
> "state" of the check list (note: no such check list state is= actually
> defined in 5245bis) independent of the state of the candidate pairs in=
> the list, to your point the second clause ("MUST consider a check= list
> to be active whenever it adds the first candidate pair with a state of=
> Waiting to the check list") is unnecessary here because 8.1.1 now= says
> how to handle things (i.e., when inserting a new candidate pair into a= n
> empty check list, set it to a state of Waiting).
>
> Does that sound right?

Hmm, not exactly. I'll need to think about this when I'= m not at the
office. :-)



--001a11493ed8737e13054cd560c5-- From nobody Mon Apr 10 13:05:57 2017 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 091E6129AD4 for ; Mon, 10 Apr 2017 13:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=F7+mv84Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dY4AI9t/ 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 d1ZTBp8r27dc for ; Mon, 10 Apr 2017 13:05:54 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA2B129A96 for ; Mon, 10 Apr 2017 13:05:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D5C2F20C03; Mon, 10 Apr 2017 16:05:53 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 10 Apr 2017 16:05:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=LXO141qXflorw3gplH n2vTVJLjsyeunCDrtsjENxK9Q=; b=F7+mv84Y8gH/qT1f9zh2dxCcCRbCbJCOWo R5HjGPeLWm1l5NK/WnEwppTDvN+065+FBGOM4awggfR2jT8WJ6utILvlfIdxVced aRYloWJbQcFJBxmJO/t43Ok4YrDcj/EjKALgVI90gPCEHEVKK0JWvG9HN5q2g10C RgKBBQowlQRnbF9+ZjfqVtzLVkRM+GTDqRxzzRMqxuIzi7bcysoZLVksTrkx0O7G FtGhhzV8TbFDN0kcZ2In8UUqBHDB9FO/Az4U3b65jIQKMXy2xShZCT6mKHCDOIZI 5krNhgNi1KQlc5UMvwQEdfm/Cf6GvucU36JYKvvBXaTo4TYYvRhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=LXO141qXflorw3gplHn2vTVJLjsyeunCDrtsjENxK9Q=; b=dY4AI9t/ PiDL61tC6IwkL9eC78apmcH8FiCD8tavUkrm297h1iiuG6Ygjzgd/zBajEKhU85V nGOI2CWryRiV+Qn5p1cV+G0qplHrSRAPnBWYcGvcRRSxoIFJwckY7q8K9uQkIKi7 7xgImx08+iUVKvZe51UvgezLrsuya415ezjdhBveGxDJWS+fZ3fMf/VvHpZcQBec arqeG5h1c8UHbxG4YI8SBgF3XnIBbxdouWBtsqdFQOYS+bP3cMB+qbro7xIBY8Ti 4/QqCmeN0k42w+NyAYyI4CSBYpj0GkIKe4SmnGt6FXbn9REAwt+3dfZRn9r0Wfot jegFjpkGQeFVlA== X-ME-Sender: X-Sasl-enc: T2K/dE6FPpg8f8mmdTK0VHmaExh+QgxMCo/G2DtEjtpm 1491854753 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 5BC697E352; Mon, 10 Apr 2017 16:05:53 -0400 (EDT) To: Taylor Brandstetter References: Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> Date: Mon, 10 Apr 2017 14:05:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:05:56 -0000 On 4/10/17 1:56 PM, Taylor Brandstetter wrote: > it's true that the agent needs to monitor the > "state" of the check list (note: no such check list state is actually > defined in 5245bis) independent of the state of the candidate pairs in > the list > > > I don't see how this is true any more. If this additional > "frozen/active" flag is necessary, where is it used? Previously, I > assumed it was used to set the state of the first candidate pair in a > checklist to either "Waiting" or "Frozen". But the state of the first > pair will now /always/ be set to "Waiting" (due to the "topmost in > column" rule). Maybe section 8.1.1 was intended to reference this > "frozen/active" check list state? But it doesn't currently. Agreed. We'll need to clean up the text across these sections. I'll try to formulate proposed text this evening. > Also, the latest draft of RFC5245bis /does/ still define a check list > state. See section 5.1.3.1 > , > "Check List State". Right, but not check list states of Active or Frozen (only Running, Completed, and Failed). Peter From nobody Mon Apr 10 15:07:50 2017 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 29370127333 for ; Mon, 10 Apr 2017 15:07:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AS-lhusaCaPL for ; Mon, 10 Apr 2017 15:07:46 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF6F1293D6 for ; Mon, 10 Apr 2017 15:07:44 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id d131so12581118qkc.3 for ; Mon, 10 Apr 2017 15:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WKwAfBqYzOvSmkVPVpQxH9BdEFKYH1vMuPxfxuXUC9I=; b=RbKJfazwhRRkN8M1jaBc7yPln9pDEkabzOLR6tKREbrxxUOl8u4WsTAsgBrqZZkhqP 2K8CUodTyI54i84mMnxO3FtBwPHZAjbvOUT481ssPNjnQK9XRuFzNE+o3jyB+cAtd4wH HVgHJ+uqAHojkdcUkomCvQJKVJg0yp0NWpL1Y9/rmooJpil3hPdkbq15VgkUlr0HkFqv bjmLe7JYe8yFSyPPPytCSEAZAO/bcSAQMN8iQQIEz6giAOT6xadXOdho98BFNqsjtIeg 9hagJ3opIamiMg+VUf3lvw9uEuoSJDVfkEy1XFnW0+5gLUo/mfF2zMTtTLgoAjk4sLze wXDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WKwAfBqYzOvSmkVPVpQxH9BdEFKYH1vMuPxfxuXUC9I=; b=GmjmFKw15YN/Mke9JwrRe1Oe4iTedJOeLVXzUHYOQNQ7iga4hnYhDf/a/M2RTodQgr 9cVRwpMabcmh0qpzsKpdKnJXJvHnCHh3vFrmUsBz/Cf5O3dy4SpXwFUGOv8teoPsukFV gG4kjMTCfw7JfZANfgX1dkmlntfaunpLbjNQ0UE31cAWR5Xz1N3nrgkv3NbnSeBR/6yc KxGjrBHZXUGE1BU2aHjBrfiifOhTLJnVZlylaIDl+pj4t7I+XRTfQ3HwJS4HpqVfEzfv 1plb/2nQjT86ZY5iavI5OMLrzMqWDW4GwFS3Wrxw0gPIsF9/Ijvv1PlHtXaO36xbeoNh iGcA== X-Gm-Message-State: AFeK/H33Q6pk/XLt0v2Y4E/tVGg6N53M/itcDAKOdiokZLX5C0XmeYxoODXrgT93rS/Yjvvo5JWipFv5WZn5kb2e X-Received: by 10.55.43.219 with SMTP id r88mr52660871qkr.143.1491862063187; Mon, 10 Apr 2017 15:07:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Mon, 10 Apr 2017 15:07:41 -0700 (PDT) In-Reply-To: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> References: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> From: Taylor Brandstetter Date: Mon, 10 Apr 2017 15:07:41 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11493ed854daa5054cd73452 Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 22:07:48 -0000 --001a11493ed854daa5054cd73452 Content-Type: text/plain; charset=UTF-8 It still mentions "active" and "frozen" at the end: "A check list with at least one pair that is Waiting is called an active check list, and a check list with all pairs Frozen is called a frozen check list." On Mon, Apr 10, 2017 at 1:05 PM, Peter Saint-Andre wrote: > On 4/10/17 1:56 PM, Taylor Brandstetter wrote: > > it's true that the agent needs to monitor the > > "state" of the check list (note: no such check list state is actually > > defined in 5245bis) independent of the state of the candidate pairs > in > > the list > > > > > > I don't see how this is true any more. If this additional > > "frozen/active" flag is necessary, where is it used? Previously, I > > assumed it was used to set the state of the first candidate pair in a > > checklist to either "Waiting" or "Frozen". But the state of the first > > pair will now /always/ be set to "Waiting" (due to the "topmost in > > column" rule). Maybe section 8.1.1 was intended to reference this > > "frozen/active" check list state? But it doesn't currently. > > Agreed. We'll need to clean up the text across these sections. I'll try > to formulate proposed text this evening. > > > Also, the latest draft of RFC5245bis /does/ still define a check list > > state. See section 5.1.3.1 > > section-5.1.3.1>, > > "Check List State". > > Right, but not check list states of Active or Frozen (only Running, > Completed, and Failed). > > Peter > > --001a11493ed854daa5054cd73452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It still mentions "active" and "frozen"= ; at the end:

"A check list with at least one pair = that is Waiting is called an active check list, and a check list with all p= airs Frozen is called a frozen check list."

On Mon, Apr 10, 2017 at 1:05 PM,= Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 4/10/17 1:56 PM, Taylor Brandstet= ter wrote:
>=C2=A0 =C2=A0 =C2=A0it's true that the agent needs to monitor the >=C2=A0 =C2=A0 =C2=A0"state" of the check list (note: no such = check list state is actually
>=C2=A0 =C2=A0 =C2=A0defined in 5245bis) independent of the state of the= candidate pairs in
>=C2=A0 =C2=A0 =C2=A0the list
>
>
> I don't see how this is true any more. If this additional
> "frozen/active" flag is necessary, where is it used? Previou= sly, I
> assumed it was used to set the state of the first candidate pair in a<= br> > checklist to either "Waiting" or "Frozen". But the= state of the first
> pair will now /always/ be set to "Waiting" (due to th= e "topmost in
> column" rule). Maybe section 8.1.1 was intended = to reference this
> "frozen/active" check list state? But it doesn't current= ly.

Agreed. We'll need to clean up the text across these sections. I= 'll try
to formulate proposed text this evening.

> Also, the latest draft of RFC5245bis /does/ still define a check list<= br> > state. See section 5.1.3.1
> <https://tools.ietf.= org/html/draft-ietf-ice-rfc5245bis-08#section-5.1.3.1>, > "Check List State".

Right, but not check list states of Active or Frozen (only Running,
Completed, and Failed).

Peter


--001a11493ed854daa5054cd73452-- From nobody Mon Apr 10 15:23:44 2017 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 751811293D6 for ; Mon, 10 Apr 2017 15:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Dl0xIN8D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QSklG8yg 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 C9qIlm_BDq3S for ; Mon, 10 Apr 2017 15:23:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4F61293E4 for ; Mon, 10 Apr 2017 15:23:41 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8C7F820B1E; Mon, 10 Apr 2017 18:23:40 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 10 Apr 2017 18:23:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=d9XrUCXdH/F55k2pF4 Egv9Eg8npUpv3zS74ujdoVup0=; b=Dl0xIN8DdoydGwDc4ujmajYMwuogegWilL sKMuVjhn4qhE76Rj2X6lA/lYHjoAusLHVXQNIg4JUssKKENSgWKaLnL5IL0GoeWu bGHUEu5vqhdPOfeE3ivx+LgfwjQVsfO5GjIQYORzBiHX8KmugURoRT51OSkAaNjT s2xiKS9Dwstom3vltM6n43d0TkFzcQjxAngJZFtQwBli7FLRYSVPet44G5NNECiT gC6a1Moehzt1LwJ/Z8BHdombT3UWngeOBFKn/SWy69/HxJVfEmfXT//UVQk0TI8s 37VjH5xuMEqXzetIDOa/NLPc1BSj8DTsZM1Fjuv0Cx+5ASNClwZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=d9XrUCXdH/F55k2pF4Egv9Eg8npUpv3zS74ujdoVup0=; b=QSklG8yg b7Ur8HHfgGvVrHNwCUPI0SKt2aGcW0KhhAFzkrtEpnPoPQhqIfprFIeD3OpLoXny gCW2EQS/z2UbFkZygiqW7f0eNkbM8WWLnMzkS/88wAdNBL/hDO2Vvj0ihmgJoQNL 29zEphE6qnmL769gAHqdW6C5z175F+T3kcsS0MnhLsTEbEXGFpPZKhAWlPfybtf8 gXZn13IQbLuwc3rzw4jorIoeuIeEKRzGHQpnAWIkYRdbos+YUADOu1OIBLUHtQnt WMzIXf4d96+Mv8ZghkYUNUYZ248qxkAE2Lt5qrW/jC8R7qI0h3rDwuJ5XDzymtus VuWlJiQgYx9ORg== X-ME-Sender: X-Sasl-enc: Ek2CfOvXmbrvi7KCxLhqEPEbknHxd7lTdKw/kD+ahQ14 1491863020 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AFE2242B7; Mon, 10 Apr 2017 18:23:40 -0400 (EDT) To: Taylor Brandstetter References: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <9e650ac1-73a1-9c26-5cd3-812522b1f6ff@stpeter.im> Date: Mon, 10 Apr 2017 16:23:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 22:23:42 -0000 On 4/10/17 4:07 PM, Taylor Brandstetter wrote: > It still mentions "active" and "frozen" at the end: > > "A check list with at least one pair that is Waiting is called an active > check list, and a check list with all pairs Frozen is called a frozen > check list." Yes. I was being pedantic: they're not actually *states*. Peter From nobody Mon Apr 10 23:40:29 2017 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 516671292C5 for ; Mon, 10 Apr 2017 23:40:28 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 vC4OwNTD24bQ for ; Mon, 10 Apr 2017 23:40:26 -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 1F386128B8D for ; Mon, 10 Apr 2017 23:40:24 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-59-58ec7a57ad3d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 45.2D.27378.75A7CE85; Tue, 11 Apr 2017 08:40:23 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Tue, 11 Apr 2017 08:40:20 +0200 From: Christer Holmberg To: Peter Saint-Andre , Taylor Brandstetter CC: "ice@ietf.org" Thread-Topic: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt Thread-Index: AQHSqd+v5pTH7eT1WEqm0CcDG080LaG9kr2AgABpXICAAPRVgIAAAqeAgAAA1YCAAAKDgIAA5LWA Date: Tue, 11 Apr 2017 06:40:55 +0000 Message-ID: References: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> In-Reply-To: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <03188DAFBAE88C4989928EDF4B1534C8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7om541ZsIg7cNihaXVzxktfh2odbi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsErow3U7cwFjTwV9xduZylgbGN p4uRk0NCwETiwJf57F2MXBxCAusZJV5uPsoI4SxhlJh0bAKQw8HBJmAh0f1PG6RBRCBc4vPx JrAws4CixMu9aiBhYQFniePTbzBBlLhIrO/9zQJhR0lMuvuDEcRmEVCVuNj+hxmklVfAWmLm dlmITeuYJa5PPwfWyylgJ9Gx7B4ziM0oICbx/dQasDizgLjErSfzmSBuFpBYsuc8M4QtKvHy 8T9WEFtUQE9i37+vbBBxRYmr05dD9epJ3Jg6hQ3CtpaY2PQbytaWWLbwNdgcXgFBiZMzn7BM YBSfhWTdLCTts5C0z0LSPgtJ+wJG1lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgdF3cMtv 1R2Ml984HmIU4GBU4uF90P86Qog1say4MvcQowQHs5II79UOoBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFex30XIoQE0hNLUrNTUwtSi2CyTBycUg2MBsnymue2O19+0Kt/dX/h8h0ufcK2bBvZ c7ptPOtVpX3Xb93x8t+1qOqdKxf+uLv3oltD3yre3e8Us2xqriSGZ2kr/TcXZjZ/JHN6o6BV 0dqTa04tODPFXDV3n5+7m4Ezd6lp/xMbFh6jW/ePh5/iP6zMW8X/Nv1E00mHTzqHTnIraRxN 3JeqxFKckWioxVxUnAgANYPiCboCAAA= Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 06:40:28 -0000 Hi, A comment regarding states etc in 5245bis. 5245bis contains lots of different states, and non-state properties, and as part of the =B3clean up=B2 process I have tried to simplify (and perhaps even remove) much of that. As I have had to spend my time on a bunch of MMUSIC drafts, the work on 5245bis has been on hold for a while, but my intention is to continue the work very shortly. Regards, Christer On 10/04/17 23:05, "Ice on behalf of Peter Saint-Andre" wrote: >On 4/10/17 1:56 PM, Taylor Brandstetter wrote: >> it's true that the agent needs to monitor the >> "state" of the check list (note: no such check list state is >>actually >> defined in 5245bis) independent of the state of the candidate pairs >>in >> the list >>=20 >>=20 >> I don't see how this is true any more. If this additional >> "frozen/active" flag is necessary, where is it used? Previously, I >> assumed it was used to set the state of the first candidate pair in a >> checklist to either "Waiting" or "Frozen". But the state of the first >> pair will now /always/ be set to "Waiting" (due to the "topmost in >> column" rule). Maybe section 8.1.1 was intended to reference this >> "frozen/active" check list state? But it doesn't currently. > >Agreed. We'll need to clean up the text across these sections. I'll try >to formulate proposed text this evening. > >> Also, the latest draft of RFC5245bis /does/ still define a check list >> state. See section 5.1.3.1 >>=20 >>>>, >> "Check List State". > >Right, but not check list states of Active or Frozen (only Running, >Completed, and Failed). > >Peter > >_______________________________________________ >Ice mailing list >Ice@ietf.org >https://www.ietf.org/mailman/listinfo/ice From nobody Fri Apr 14 19:01:30 2017 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 55A23129B43 for ; Fri, 14 Apr 2017 19:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=TTTym/MO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lp+dZjlZ 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 XRN9B-JU0u8A for ; Fri, 14 Apr 2017 19:01:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3B1127369 for ; Fri, 14 Apr 2017 19:01:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7E5EC2092F; Fri, 14 Apr 2017 22:01:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 14 Apr 2017 22:01:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=gPOv9MgLPRzrLcxRzG JE6HEAg1C+v3FFz/mh/PxYjrA=; b=TTTym/MOQFHxtzSHWKCOODhMctu4qbcPx7 rizZp+jze+a8ZFbktPocjnT9ouOJ4nTPAcBOdgEMdQnsa9s0Qp6adIbtXvXBVDxB PmaDtU/l2jGObBedQG+jXrvI4CiYjOxEjLWE2RjKN0wMicyRh4SjF1uauCGPHVbf cvCN1SMgU7BHS4ktpYE4rbuZMdHuQia9x90GacPSLO50lskk3q4a8Qy3vJfOu8Q3 G+mNntawwZv+fF7ze4IC77iuJ8zNyLY/BbIb4wN4IJUtAIJp10Ewf3yTOC2vZejR XO5CU9uLnjuWovVu+Gsa9FovxoFytgGH9zYUvh0wDeg0T+1zVrBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=gPOv9MgLPRzrLcxRzGJE6HEAg1C+v3FFz/mh/PxYjrA=; b=lp+dZjlZ uIpzlylxPMzzK0VtSrO+jYpNPakJpatDqJzh2EK7hN9CAoaUCl9kgHFxCscDhUA8 nXMrLUdSjM8TYgyHK67zODEqImcqJPcdnxBc4D/kMmc+hV3zs8oCE2vs246qd4h3 EIlgy5ZZglTEptFml5/ajKhFx2hbvh41r7L1717Av109C3wpQLyhK/BbqDJmye6R ZzVOrFlSAdo0sQSDmarl80/zKpOvEqTfVILap8pka3AQGhGKd0fVpKlhfPu1+x6X dtCmdpFSioPGaU3y3d6pN4jH6tj6XwfPmJag0jgYYcJbLDPmfUeS1Z9BuFzWGKuo ckdKPqy2oSobbw== X-ME-Sender: X-Sasl-enc: B6lSA/+9vHpNyxuk0YvgChIMzZLxiNR9TSYTqEBFMLjY 1492221687 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 118452469B; Fri, 14 Apr 2017 22:01:26 -0400 (EDT) From: Peter Saint-Andre To: Taylor Brandstetter , ice@ietf.org References: Message-ID: <89d02e3c-03db-98a3-fe2d-5971e54628fe@stpeter.im> Date: Fri, 14 Apr 2017 20:01:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 02:01:29 -0000 On 4/9/17 4:52 PM, Peter Saint-Andre wrote: > On 3/30/17 11:28 PM, Taylor Brandstetter wrote: >> * In section 8.1.1: In general I like the improvements that have been >> made. However: I've looked at this again and have a few questions. >> o The rules for how a new pair gets either a "Waiting" or "Frozen" >> state don't completely match standard ICE; Well, regular ICE doesn't have a concept of "new pair" in the sense that Trickle ICE does, but I see what you mean. It seems to me that the best way to explain things here is by showing snapshots of the tabular representation over time as new pairs are added, somewhat as is done in Section 5.1.3.6 of 5245bis. This will increase the length of Section 8.1.1 significantly. >> at least the part >> where when one "media stream" completes, pairs from other media >> streams with matching foundations are unfrozen. With the current >> rules in section 8.1.1, only the topmost remaining pair in each >> foundation is guaranteed to be unfrozen. Is this difference >> acceptable? If it is, we should at least acknowledge it, and not >> give the wrong impression by saying "Trickle ICE preserves all >> of [the standard ICE] rules." That sentence was meant to reinforce that the rules for regular ICE processing of "static" check lists still apply to Trickle ICE agents. The question is how to handle new pairs. However, as you note, right now the new-pair rules at the end of Section 8.1.1 aren't entirely consistent with 5245bis. This weekend I will look into the discrepancies in more detail, in part by sketching out the snapshots as mentioned above. >> o The rule that a pair changes to "Waiting" if a pair in a lower >> row is "Succeeded" means that if a pair in the lowermost row is >> unfrozen first (which is possible, if the signaling mechanism >> doesn't preserve ordering of candidates), We've agreed to add that rule back in (unless there are objections during WGLC). >> all of the other pairs >> with its foundation would be unfrozen as soon as it's unfrozen. >> This seems odd. This might not be a worry anymore given the just-mentioned text reinstatement. Peter From nobody Mon Apr 17 20:16:12 2017 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 7D19512941C for ; Mon, 17 Apr 2017 20:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=kJTj7ky/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Bv4l9cKd 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 c1qrjwaAQGAL for ; Mon, 17 Apr 2017 20:16:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F8E126579 for ; Mon, 17 Apr 2017 20:16:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AFF1B20BA7; Mon, 17 Apr 2017 23:16:08 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 17 Apr 2017 23:16:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Q5O21oymtmyJej6HXB hEB1efxcqXdqHd2Y+pnizr5Zk=; b=kJTj7ky/rqZ/63oY1bOFQtFHW4VyXJfZVB /I/sBacZn4TMB4A3HnyetZbeec+DzecIrBWqGMr2GnT+DkXLsnelY7XSLJ/cod1S TsQElBTM4Sfd7hfgtEIK8fYUGHWu7gU2TumX6W2vRJ9RnWow0Xcwlzmp96yeT8r5 YvTjGJBSKzc7HEAVB5GjDdYeW8931GoGDUz5EWiv6JgqIycCwsqvyKGdjCikf2kq EDfR8GYgBaEiCtKpSKu0/PK9IyB3cJLhB8KviuO51vZMF93py40TzB/lkwzuq5Qe aEETHkdbvTbnAk4Q61Jv1pNQghapo/Bh1dDNTZ0iwUBeQo6yogXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=Q5O21oymtmyJej6HXBhEB1efxcqXdqHd2Y+pnizr5Zk=; b=Bv4l9cKd vTQApQKv00L0Su//nBdUHTECXPUpenD1eSMldFM7e+zGtj0Sknzlu+nBlDIayF1b EWZLVCN+Jon6FsMGUrwu6SqP1oTtL5HthOB9GAT464pMFmGt1HJYzPWkxTSPGp2n J/goIOhWjr+7AJF7YyxO00oolPRACMW9yv5hRB5uXdH4IYrg+rdtqaIxP56GbVnL P7tljz3nAXS+7iPB52YJH1KVHexVqVrchntC4AAcCFw7gAyF7wiGdfprxJhhgBfl ThmLLsFYEKjZZKAZE3pgDFUw1wP8ZV/x/3JtrshlKikBcDNKSwIFHM5+3uj6IKeL B4ErcwOADK/P1w== X-ME-Sender: X-Sasl-enc: yDrrXqyAzPRDRlouAzcSfYkUoJ6RKLswOp0iSvyP0yv4 1492485368 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B97C24373; Mon, 17 Apr 2017 23:16:07 -0400 (EDT) To: Taylor Brandstetter , ice@ietf.org References: From: Peter Saint-Andre Message-ID: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> Date: Mon, 17 Apr 2017 21:16:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 03:16:11 -0000 On 3/30/17 11:28 PM, Taylor Brandstetter wrote: [areas of seeming agreement elided] > * In section 8.1.1: In general I like the improvements that have been > made. However: > o The rules for how a new pair gets either a "Waiting" or "Frozen" > state don't completely match standard ICE; at least the part > where when one "media stream" completes, pairs from other media > streams with matching foundations are unfrozen. With the current > rules in section 8.1.1, only the topmost remaining pair in each > foundation is guaranteed to be unfrozen. Is this difference > acceptable? If it is, we should at least acknowledge it, and not > give the wrong impression by saying "Trickle ICE preserves all > of [the standard ICE] rules." Taylor, would you mind spelling this out a bit more fully and point to discrepancies between the text of 5245bis and the text of the Trickle spec? I'm sure I'm missing something, but I don't yet see the truth of your statement that "only the topmost remaining pair in each foundation is guaranteed to be unfrozen". In particular, your statement doesn't seem to match the rules defined in the Trickle spec. I've tried to spell them out in greater detail (with examples) in the following proposed text. ### 8.1.1. Inserting a New Pair in a Check List Consider the following tabular representation of all checklists in an agent: +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | cp | cp | cp | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | cp | cp | cp | cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | cp | | | | cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 1: Example of Check List State Each row in the table represents a component for a given media stream (e.g., m1 and m2 might be the RTP and RTCP components for audio). Each column represents one foundation. Each cell represents one candidate pair. When an agent commences ICE processing, in accordance with Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in the Waiting state) the topmost candidate pair in every column (i.e., the pair with the lowest component ID). This state is shown in the following table, with candidate pairs in the Waiting state marked by "w-cp". +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | w-cp | w-cp | w-cp | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | cp | cp | cp | w-cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | cp | | | | w-cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 2: Initial Check List State Then, as the checks proceed (see Section 6.1.2.4.2.3 of [rfc5245bis]), for each pair that enters the Succeeded state (denoted here by "s-cp"), the agent will unfreeze all pairs for the same media stream and foundation (e.g., if the pair in column 1, row 1 succeeds then the agent will unfreeze the pair in column 1, row 2). +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | cp | | | | w-cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 3: Check List State after Succeeded Check ICE also specifies that, if all the pairs in a media stream for one foundation are unfrozen (e.g., column 1, rows 1 and 2 representing both components for the audio stream), then all of the candidate pairs in the entire column are unfrozen (e.g., column 1, rows 3 and 4). +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | w-cp | | | | w-cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | w-cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 4: Check List State with Unfrozen Media Stream Trickle ICE preserves all of these rules as they apply to what we might call "static" check list sets. This implies that if, for some reason, a Trickle agent were to begin connectivity checks with all of its pairs already present, the way that pair states change is indistinguishable from that of a regular ICE agent. Of course, the major difference with Trickle ICE is that check list sets can be dynamically updated because candidates can arrive after connectivity checks have started. When this happens, an agent sets the state of the newly formed pair as described below. Case 1: If the newly formed pair is the topmost pair in this column, set the state to Waiting (e.g., this would be the case if the newly formed pair were placed in column 4, row 1). +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | w-cp | | | | w-cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | w-cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 5: Check List State with Newly Formed Pair, Case 1 Case 2: If the pair immediately above the newly formed pair in this column is in the Succeeded state, set the state to Waiting (e.g., this would be the case if the pair in column 4, row 2 succeeded and the newly formed pair were placed in column 4, row 3); +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | w-cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 6: Check List State with Newly Formed Pair, Case 2 Case 3: If there is at least one pair in this column below the row of the newly formed pair whose state is either Succeeded or Failed (e.g., this would be the case if the pair in column 4, row 2 succeeded and the newly formed pair were placed in column 4, row 1). +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | w-cp | | | | cp | +-----------------+------+------+------+------+------+ Figure 7: Check List State with Newly Formed Pair, Case 3 Case 4: In all other cases, set the state to Frozen. ### Peter From nobody Tue Apr 18 18:44:21 2017 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 076BF126C2F for ; Tue, 18 Apr 2017 18:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rVd6SATZoxlU for ; Tue, 18 Apr 2017 18:44:17 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DEC1205F1 for ; Tue, 18 Apr 2017 18:44:16 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id c45so8588160qtb.1 for ; Tue, 18 Apr 2017 18:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XAODfdcktHRJrOQVVVEfLyceGCONMpnbhbtQOs2bXzU=; b=pVecIUXUTrT3D16M06tAzQHmGTuUhA4ZZsPKFVOBF44UUTgOrhzPEVTlDjNg7U+Lzc LUXOsjeOqUj7nnDuHm8ODokJ4bZHyup5AE0Jd57Pmsp/htHAm1QkJGHxiEBIKaukGUvJ SPilIkuCPpaJ20RKI0iDw6Y6a1XvBEQiSrHteLN6YNH7hyD1kShRwboCZcmDZnWvuylM KNpcjarg2kH0sOZ7+gYOl/tvf04SqC4I1ZjDc5PvMuXlvKqpeG8YSkbCEfdxpUJyiUeq RGgKJ18SPFuVRsfARLqGNDQ8EQYilDSyGLKRzuZ2JK0aNevDJHVBzF1FLmY/BRKGHq6S 4LAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XAODfdcktHRJrOQVVVEfLyceGCONMpnbhbtQOs2bXzU=; b=aASEgPTNblWL3iu2yEOAK/AwTKMaXgXEEW09CD6XrFQIfCK68g9jDg+x326j28txYv bzi9hbLZNRj7/Uwig38NuAESC5ID2t30ap+Hj/G7pJT6XYZPRb/Y0QcC3ivZnGnW05Fh LouKuxIDltXGNbBfsSr1/owojGEx7oQqhHlpkQ1tL/nqTnTqV0P0Svea8Pqd1AjdxPGQ eQJRl8QGG+NUJvcSMFc7jsUMTEU2BGAJhwwb2V63j4KYGnZmc5UhENoaigYiw5n1QSiE 7dO9qmnTSwcMFGgYYpxc//zw42qpYN78uBYHaEQFYsgP69cefSrXXajn3Z1Kz+aQblDT MtCQ== X-Gm-Message-State: AN3rC/6kilyJhg9PQEOAny19sHzIk7YM4W70Zp5O63unnYRjJ29YL//F XysHuLPjJhCfr6n8T466dCAiL6Kq4PbFL29Gng== X-Received: by 10.200.52.180 with SMTP id w49mr306036qtb.75.1492566255547; Tue, 18 Apr 2017 18:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Tue, 18 Apr 2017 18:44:15 -0700 (PDT) In-Reply-To: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> From: Taylor Brandstetter Date: Tue, 18 Apr 2017 18:44:15 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary=001a113777ec77e429054d7b291f Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 01:44:19 -0000 --001a113777ec77e429054d7b291f Content-Type: text/plain; charset=UTF-8 > > Taylor, would you mind spelling this out a bit more fully and point to > discrepancies between the text of 5245bis and the text of the Trickle > spec? I'm sure I'm missing something, but I don't yet see the truth of > your statement that "only the topmost remaining pair in each foundation > is guaranteed to be unfrozen". > Sure; let me try to give an example. Suppose I have three media streams, and one foundation (let's keep it simple). I'll represent the states like this for brevity: "SWFFFF", where "S" is "succeeded", "W" is "waiting", and "F" is "frozen". And they're ordered in the same way as the rows in your table above. With non-trickle ICE, here's what would typically happen: 1. Only the RTP candidate pair for the first media stream is unfrozen initially. State: WFFFFF 2. Check succeeds for RTP candidate pair. RTCP pair unfrozen. State: SWFFFF 3. Check succeeds for RTCP pair. *All* the other pairs with the same foundation are now unfrozen. State: SSWWWW With trickle ICE, here's what could happen: 1. Candidates for the first media stream are trickled in. Starts out just like normal ICE. State: WF 2. Checks for both pairs succeed. Still waiting for candidates for other media streams. State: SS 3. Candidates for the other media streams arrive, and pairs are formed. The topmost pair is set to waiting, but not the others. State: SSWFFF So, where normal ICE ensures that once a foundation is proven to work (for both components of a media stream), all other pairs with that foundation are unfrozen, trickle ICE only guarantees that one of them is. On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre wrote: > On 3/30/17 11:28 PM, Taylor Brandstetter wrote: > > [areas of seeming agreement elided] > > > * In section 8.1.1: In general I like the improvements that have been > > made. However: > > o The rules for how a new pair gets either a "Waiting" or "Frozen" > > state don't completely match standard ICE; at least the part > > where when one "media stream" completes, pairs from other media > > streams with matching foundations are unfrozen. With the current > > rules in section 8.1.1, only the topmost remaining pair in each > > foundation is guaranteed to be unfrozen. Is this difference > > acceptable? If it is, we should at least acknowledge it, and not > > give the wrong impression by saying "Trickle ICE preserves all > > of [the standard ICE] rules." > > Taylor, would you mind spelling this out a bit more fully and point to > discrepancies between the text of 5245bis and the text of the Trickle > spec? I'm sure I'm missing something, but I don't yet see the truth of > your statement that "only the topmost remaining pair in each foundation > is guaranteed to be unfrozen". > > In particular, your statement doesn't seem to match the rules defined in > the Trickle spec. I've tried to spell them out in greater detail (with > examples) in the following proposed text. > > ### > > > 8.1.1. Inserting a New Pair in a Check List > > Consider the following tabular representation of all checklists in an > agent: > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | cp | cp | cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | cp | cp | cp | cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 1: Example of Check List State > > Each row in the table represents a component for a given media stream > (e.g., m1 and m2 might be the RTP and RTCP components for audio). > Each column represents one foundation. Each cell represents one > candidate pair. > > When an agent commences ICE processing, in accordance with > Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in the > Waiting state) the topmost candidate pair in every column (i.e., the > pair with the lowest component ID). This state is shown in the > following table, with candidate pairs in the Waiting state marked by > "w-cp". > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | w-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 2: Initial Check List State > > Then, as the checks proceed (see Section 6.1.2.4.2.3 of > [rfc5245bis]), for each pair that enters the Succeeded state (denoted > here by "s-cp"), the agent will unfreeze all pairs for the same media > stream and foundation (e.g., if the pair in column 1, row 1 succeeds > then the agent will unfreeze the pair in column 1, row 2). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 3: Check List State after Succeeded Check > > ICE also specifies that, if all the pairs in a media stream for one > foundation are unfrozen (e.g., column 1, rows 1 and 2 representing > both components for the audio stream), then all of the candidate > pairs in the entire column are unfrozen (e.g., column 1, rows 3 and > 4). > > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 4: Check List State with Unfrozen Media Stream > > Trickle ICE preserves all of these rules as they apply to what we > might call "static" check list sets. This implies that if, for some > reason, a Trickle agent were to begin connectivity checks with all of > its pairs already present, the way that pair states change is > indistinguishable from that of a regular ICE agent. > > Of course, the major difference with Trickle ICE is that check list > sets can be dynamically updated because candidates can arrive after > connectivity checks have started. When this happens, an agent sets > the state of the newly formed pair as described below. > > Case 1: If the newly formed pair is the topmost pair in this column, > set the state to Waiting (e.g., this would be the case if the newly > formed pair were placed in column 4, row 1). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 5: Check List State with Newly Formed Pair, Case 1 > > Case 2: If the pair immediately above the newly formed pair in this > column is in the Succeeded state, set the state to Waiting (e.g., > this would be the case if the pair in column 4, row 2 succeeded and > the newly formed pair were placed in column 4, row 3); > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 6: Check List State with Newly Formed Pair, Case 2 > > Case 3: If there is at least one pair in this column below the row of > the newly formed pair whose state is either Succeeded or Failed > (e.g., this would be the case if the pair in column 4, row 2 > succeeded and the newly formed pair were placed in column 4, row 1). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 7: Check List State with Newly Formed Pair, Case 3 > > Case 4: In all other cases, set the state to Frozen. > > ### > > Peter > > --001a113777ec77e429054d7b291f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Taylor, would you mind spelling this out a bit mor= e fully and point to
discrepancies between the text of 5245bis and the text of t= he Trickle
spec? I'm sure I'm missing something, but I don't yet see= the truth of
your statement that "only the topmost remaining pair in each = foundation
is guaranteed to be unfrozen".

Sure; let me try to give an example.

=
Suppose I have three media streams, and one foundation (let's keep= it simple). I'll represent the states like this for brevity: "SWF= FFF", where "S" is "succeeded", "W" is &= quot;waiting", and "F" is "frozen". And they'r= e ordered in the same way as the rows in your table above.

With non-trickle ICE, here's what would typically happen:
  1. Only the RTP candidate pair for the first media stream is unf= rozen initially.
    State: WFFFFF
  2. Check succeeds for RTP candidate = pair. RTCP pair unfrozen.
    State: SWFFFF
  3. Check succeeds for RTCP = pair. All=C2=A0the other pairs with the same foundation are now unfr= ozen.
    State: SSWWWW
With trickle ICE, here's what coul= d happen:
  1. Candidates for the first media stream are= trickled in. Starts out just like normal ICE.
    State: WF
  2. Checks = for both pairs succeed. Still waiting for candidates for other media stream= s.
    State: SS
  3. Candidates for the other media streams arrive, and = pairs are formed. The topmost pair is set to waiting, but not the others.State: SSWFFF
So, where normal ICE ensures that once a foun= dation is proven to work (for both components of a media stream), all other= pairs with that foundation are unfrozen, trickle ICE only guarantees that = one of them is.

On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpe= ter@stpeter.im> wrote:
On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

[areas of seeming agreement elided]

>=C2=A0 =C2=A0* In section 8.1.1: In general I like the improvements tha= t have been
>=C2=A0 =C2=A0 =C2=A0made. However:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o The rules for how a new pair gets either a= "Waiting" or "Frozen"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't comp= letely match standard ICE; at least the part
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "media stream&quo= t; completes, pairs from other media
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching foundations are= unfrozen. With the current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1, only the topm= ost remaining pair in each
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guaranteed to be unfroz= en. Is this difference
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, we should at le= ast acknowledge it, and not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impression by saying &= quot;Trickle ICE preserves all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] rules."
Taylor, would you mind spelling this out a bit more fully and point = to
discrepancies between the text of 5245bis and the text of the Trickle
spec? I'm sure I'm missing something, but I don't yet see the t= ruth of
your statement that "only the topmost remaining pair in each foundatio= n
is guaranteed to be unfrozen".

In particular, your statement doesn't seem to match the rules de= fined in
the Trickle spec. I've tried to spell them out in greater detail (with<= br> examples) in the following proposed text.

###


8.1.1.=C2=A0 Inserting a New Pair in a Check List

=C2=A0 =C2=A0Consider the following tabular representation of all checklist= s in an
=C2=A0 =C2=A0agent:


=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 |=C2= =A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 cp= =C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure= 1: Example of Check List State

=C2=A0 =C2=A0Each row in the table represents a component for a given media= stream
=C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP components for audi= o).
=C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Each cell represe= nts one
=C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0When an agent commences ICE processing, in accordance with
=C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place = in the
=C2=A0 =C2=A0Waiting state) the topmost candidate pair in every column (i.e= ., the
=C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This state is shown = in the
=C2=A0 =C2=A0following table, with candidate pairs in the Waiting state mar= ked by
=C2=A0 =C2=A0"w-cp".


=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 | w-cp | w-cp | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 cp= =C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figur= e 2: Initial Check List State

=C2=A0 =C2=A0Then, as the checks proceed (see Section 6.1.2.4.2.3 of
=C2=A0 =C2=A0[rfc5245bis]), for each pair that enters the Succeeded state (= denoted
=C2=A0 =C2=A0here by "s-cp"), the agent will unfreeze all pairs f= or the same media
=C2=A0 =C2=A0stream and foundation (e.g., if the pair in column 1, row 1 su= cceeds
=C2=A0 =C2=A0then the agent will unfreeze the pair in column 1, row 2).


=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 | w= -cp |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 3: Check List State = after Succeeded Check

=C2=A0 =C2=A0ICE also specifies that, if all the pairs in a media stream fo= r one
=C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 and 2 represen= ting
=C2=A0 =C2=A0both components for the audio stream), then all of the candida= te
=C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., column 1, rows = 3 and
=C2=A0 =C2=A04).



=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 | w= -cp |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 4: Check List State with Un= frozen Media Stream

=C2=A0 =C2=A0Trickle ICE preserves all of these rules as they apply to what= we
=C2=A0 =C2=A0might call "static" check list sets.=C2=A0 This impl= ies that if, for some
=C2=A0 =C2=A0reason, a Trickle agent were to begin connectivity checks with= all of
=C2=A0 =C2=A0its pairs already present, the way that pair states change is<= br> =C2=A0 =C2=A0indistinguishable from that of a regular ICE agent.

=C2=A0 =C2=A0Of course, the major difference with Trickle ICE is that check= list
=C2=A0 =C2=A0sets can be dynamically updated because candidates can arrive = after
=C2=A0 =C2=A0connectivity checks have started.=C2=A0 When this happens, an = agent sets
=C2=A0 =C2=A0the state of the newly formed pair as described below.

=C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost pair in this c= olumn,
=C2=A0 =C2=A0set the state to Waiting (e.g., this would be the case if the = newly
=C2=A0 =C2=A0formed pair were placed in column 4, row 1).


=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp | w-cp |=C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 | w= -cp |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 5: Check List State with Newly For= med Pair, Case 1

=C2=A0 =C2=A0Case 2: If the pair immediately above the newly formed pair in= this
=C2=A0 =C2=A0column is in the Succeeded state, set the state to Waiting (e.= g.,
=C2=A0 =C2=A0this would be the case if the pair in column 4, row 2 succeede= d and
=C2=A0 =C2=A0the newly formed pair were placed in column 4, row 3);


=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 | s= -cp |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 | w-cp | w-cp |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 6: Check List State with Newly For= med Pair, Case 2

=C2=A0 =C2=A0Case 3: If there is at least one pair in this column below the= row of
=C2=A0 =C2=A0the newly formed pair whose state is either Succeeded or Faile= d
=C2=A0 =C2=A0(e.g., this would be the case if the pair in column 4, row 2 =C2=A0 =C2=A0succeeded and the newly formed pair were placed in column 4, r= ow 1).


=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2= =A0 f5=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp | w-cp |=C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 | s= -cp |=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 | w-cp | w-cp |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+ =C2=A0 =C2=A0| m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
=C2=A0 =C2=A0+-----------------+------+------+------+------+------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: Check List State with Newly For= med Pair, Case 3

=C2=A0 =C2=A0Case 4: In all other cases, set the state to Frozen.

###

Peter


--001a113777ec77e429054d7b291f-- From nobody Thu Apr 20 00:43:24 2017 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 A87E612EB04; Thu, 20 Apr 2017 00:43:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149267419664.22314.17980945059487974234@ietfa.amsl.com> Date: Thu, 20 Apr 2017 00:43:16 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-09.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 07:43:17 -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-09.txt Pages : 96 Date : 2017-04-20 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 20 00:48:17 2017 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 2E6D412EB31 for ; Thu, 20 Apr 2017 00:48:16 -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 bTKqKhoVta_S for ; Thu, 20 Apr 2017 00:48:15 -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 C3BF012EB35 for ; Thu, 20 Apr 2017 00:48:14 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-fe-58f867bad14b Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id FF.52.27378.AB768F85; Thu, 20 Apr 2017 09:48:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0339.000; Thu, 20 Apr 2017 09:48:10 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Draft new version: draft-ice-5245bis-09 Thread-Index: AQHSuap0nUp6L4BLNUSPAnYCDB/Ivg== Date: Thu, 20 Apr 2017 07:48:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D51E43741B514christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7je6e9B8RBldvWFp8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6Me8/fMRfMFqhYsmYOYwPjPd4uRk4OCQETiZ0/t7F2MXJxCAms Z5T48foFO4SzhFFi7qeDjF2MHBxsAhYS3f+0QRpEBBQlZrY8YwaxhQUMJF6e/ccOETeV2DFl FRuErSfxvGk3E4jNIqAqsXVeG1g9r4C1xKutk8HqGQXEJL6fWgNWwywgLnHryXwmiIMEJJbs Oc8MYYtKvHz8jxXEFgWaue/fVzaQcyQElCSmbU2DaE2QeNl4mwVivKDEyZlPWCYwCs1CMnUW krJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhHCtpbY13uLBVnNAkaOVYyixanFSbnpRsZ6 qUWZycXF+Xl6eaklmxiBcXJwy2/VHYyX3zgeYhTgYFTi4U3I/R4hxJpYVlyZe4hRgoNZSYTX LRMoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dUA6PS5+oU G5V6rw3ZZ9i1zfKjC9YIO/Uf9Wvg/PXpcNanX7e1soLZmC+cD97bJhRjVRThn7GmZWbFmd8n bTOO6XNdMvtfcuH8Q8GAZVPaAs4ITPXaK3p8Yqlmx6qVl97PYFl9+W/re2V9zz4dVpdJa80T J8yUXKReevPn973/ZJnnffj39/LWH4ZKLMUZiYZazEXFiQAGvTq9jwIAAA== Archived-At: Subject: [Ice] Draft new version: draft-ice-5245bis-09 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 07:48:16 -0000 --_000_D51E43741B514christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have submitted a new version (-09) of draft-ice-5245bis. The new version contains mostly editorial cleanups of the connectivity chec= k procedures (mostly the STUN Client procedures). However, I have received virtually no feedback on the previous implementati= on of =93Emil=92s table=94, that we agreed upon in Berlin. Is it correct? D= id I misunderstand something? I think there are still lots of clean-ups that can be done, but I think thi= s is as far as I=92ll go. We should focus on potential bugs, and start movi= ng towards WGLC. Regards, Christer --_000_D51E43741B514christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I have submitted a new version (-09) of draft-ice-5245bis.

The new version contains mostly editorial cleanups of the connectivity= check procedures (mostly the STUN Client procedures).

However, I have received virtually no feedback on the previous impleme= ntation of =93Emil=92s table=94, that we agreed upon in Berlin. Is it corre= ct? Did I misunderstand something?

I think there are still lots of clean-ups that can be done, but I thin= k this is as far as I=92ll go. We should focus on potential bugs, and start= moving towards WGLC.

Regards,

Christer
--_000_D51E43741B514christerholmbergericssoncom_-- From nobody Thu Apr 20 07:59:27 2017 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 C7E65129AA6 for ; Thu, 20 Apr 2017 07:59:26 -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 9C8gx7hmC75R for ; Thu, 20 Apr 2017 07:59:25 -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 E1D45129AA2 for ; Thu, 20 Apr 2017 07:59:24 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-49-58f8ccca595d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id D3.1F.21650.ACCC8F85; Thu, 20 Apr 2017 16:59:23 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0339.000; Thu, 20 Apr 2017 16:59:18 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: nomination questions Thread-Index: AdK55q8/y1rN8gUVSsyD5BIe+76Vvg== Date: Thu, 20 Apr 2017 14:59:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB7BF40@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB7BF40ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7lu7pMz8iDK4cEbD4dqHWgdFjyZKf TAGMUVw2Kak5mWWpRfp2CVwZa5fcYy6Y4FKx5M4NtgbGPVZdjJwcEgImEh3L/zF2MXJxCAms Z5R4uW8GM4SzhFFi2twT7F2MHBxsAhYS3f+0QRpEBBQlZrY8YwaxhQXUJFrWP2KCiGtLvDvV ywxh60nMa57IAmKzCKhKPHp5jxXE5hXwlWi5sYYNxGYUEJP4fmoNWC+zgLjErSfzmSAOEpBY suc8M4QtKvHy8T9WCFtJonHJE1aI+nyJT0/PMUHMFJQ4OfMJywRGwVlIRs1CUjYLSRlEXEdi we5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREY+Ae3 /LbawXjwueMhRgEORiUe3gf7fkQIsSaWFVfmHmKU4GBWEuHt3Q4U4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgVF/0XTW85sSJ7B8XtCQqcfnlXx9MQuj xHlGKUGdgAmpPze+ls+bnCooJPLt7RzxhspTUVLrDyy4lK1UdbVu59PJ79/K/L0YufNJAceP BYlBSmsr3l038KnfYe31QM7kcUCWwhbxExa75O6LTd10pK83bhmbUFeTvlbV/i0s63cHzDn8 /TnzyuVKLMUZiYZazEXFiQC2ZDrpeAIAAA== Archived-At: Subject: [Ice] 5245bis: nomination questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:59:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB7BF40ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A couple of question on nomination: Q1: STUN client Section 6.2.5.3.4. (Updating the Nominated Flag) of draft-5245bis-09 says: "If the ICE agent was a controlling agent, and the agent had included a USE-CANDIDATE attribute in the Binding request, the valid pair generated from that check has its nominated flag value set to true. This flag indicates that this valid pair SHOULD be used for media, unless the sending agent detects that the candidate pair does not work." First, I don't think this text should be here to begin with. It belongs to = section 7 (where similar text exists). Second, is there a reason for not using MUST (instead of SHOULD)? Third, what is meant by "sending agent"? Is it the controlling agent, or an= y agent trying to use the pair for sending media? Q2: STUN server Section 6.3.1.5. (Updating the Nominated Flag) says: "If the Binding request received by the agent had the USE-CANDIDATE attribute set, and the agent is in the controlled role, the agent looks at the state of the pair computed in Section 6.3.1.4: o If the state of this pair is Succeeded, it means that the check generated by this pair produced a successful response. This would have caused the agent to construct a valid pair when that success response was received (see Section 6.2.5.3.2). The agent now sets the nominated flag value of the valid pair to true. This may end ICE processing for this media stream; see Section 7. o If the state of this pair is In-Progress, and if its check produces a successful result, the resulting valid pair has its nominated flag set when the response arrives. This may end ICE processing for this media stream when it arrives; see Section 7." What if the state is Failed? The peer (controlling agent) does not know wha= t the state is when nominating the pair, does it? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB7BF40ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A couple of question on nomination:

 

Q1:        STUN c= lient

 

Section 6.2.5.3.4.  (Updating the Nominated Fla= g) of draft-5245bis-09 says:        = ;     

 

   “If the ICE agent was a controlli= ng agent, and the agent had included

   a USE-CANDIDATE attribute in the Bindin= g request, the valid pair

   generated from that check has its nomin= ated flag value set to true.

   This flag indicates that this valid pai= r SHOULD be used for media,

   unless the sending agent detects that t= he candidate pair does not

   work.”

 

First, I don’t think this text should be here = to begin with. It belongs to section 7 (where similar text exists).

 

Second, is there a reason for not using MUST (instea= d of SHOULD)?

 

Third, what is meant by “sending agent”?= Is it the controlling agent, or any agent trying to use the pair for sendi= ng media?

 

 

Q2:        STUN s= erver

 

Section 6.3.1.5.  (Updating the Nominated Flag)= says:

 

   “If the Binding request received = by the agent had the USE-CANDIDATE

   attribute set, and the agent is in the = controlled role, the agent

   looks at the state of the pair computed= in Section 6.3.1.4:

 

   o  If the state of this pair is Su= cceeded, it means that the check

      generated by this pai= r produced a successful response.  This would

      have caused the agent= to construct a valid pair when that success

      response was received= (see Section 6.2.5.3.2).  The agent now sets

      the nominated flag va= lue of the valid pair to true.  This may end

      ICE processing for th= is media stream; see Section 7.

 

   o  If the state of this pair is In= -Progress, and if its check

      produces a successful= result, the resulting valid pair has its

      nominated flag set wh= en the response arrives.  This may end ICE

      processing for this m= edia stream when it arrives; see Section 7.”

 

What if the state is Failed? The peer (controlling a= gent) does not know what the state is when nominating the pair, does it?

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4CB7BF40ESESSMB109erics_-- From nobody Fri Apr 21 00:43:43 2017 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 EEBC1129494 for ; Fri, 21 Apr 2017 00:43:41 -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 clUNLncFLadA for ; Fri, 21 Apr 2017 00:43:40 -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 12E1912947C for ; Fri, 21 Apr 2017 00:43:39 -0700 (PDT) X-AuditID: c1b4fb2d-89fff70000004c5d-a7-58f9b8292ef7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id B6.81.19549.928B9F85; Fri, 21 Apr 2017 09:43:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Fri, 21 Apr 2017 09:43:36 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: ICE states Thread-Index: AQHSunL8v/klU6kAc0aisHu8cCoq6Q== Date: Fri, 21 Apr 2017 07:43:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D51F93E51B67Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7rq7Wjp8RBpP+Slh8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6M/xt+MhY8M63YOqOHuYHxpm4XIyeHhICJxOsjB9m7GLk4hATW M0qsOXCFGcJZwijxZFUHSxcjBwebgIVE9z9tkAYRAUWJmS3PmEFsYQEZieZ3m5lh4pvf7GWF sPUkzj65zw5iswioSrzpvc8EYvMKWEtsvfIAzGYUEJP4fmoNmM0sIC5x68l8JoiDBCSW7DnP DGGLSrx8/A9spijQzH3/vrJBxJUkfmy4xALRmyBx5mIXI8R8QYmTM5+wTGAUmoVk7CwkZbOQ lEHEDSTen5vPDGFrSyxb+BrK1pfY+OUsI4RtLfFhSisbspoFjByrGEWLU4uLc9ONjPVSizKT i4vz8/TyUks2MQIj5eCW37o7GFe/djzEKMDBqMTD+3Dfjwgh1sSy4srcQ4wSHMxKIry924FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0tSC2CyTJxcEo1MPJuP/+kju/k iYndtXHffrz/pOXP8vz7K+0K/ZysLVy7dnXsnXlw5c5smW3TK8vKwrTFPx0ya5c8fv76qovH bm2oKOsT5Im/snvvkU2M0XxRM2z5k2puPpg93UI/TNpim1lqf2jdmaKkaZH3Oq43v2layLvu gUT/w5aln/YW+UTc/2948rjy3clKLMUZiYZazEXFiQCvWPnqkAIAAA== Archived-At: Subject: [Ice] 5245bis: ICE states X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 07:43:42 -0000 --_000_D51F93E51B67Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Below is a list of the different states/status/flags in ICE, and some quest= ions related to it. Note that my questions are not (at least not at this point) change suggesti= ons, but more questions for clarifications. ------------- ICE LEVEL: =3D=3D=3D=3D=3D=3D=3D=3D=3D ICE State: * Running, Completed, Failed QUESTION: Is this really needed? I realise ICE can complete, fail etc, but = do we really need to have a state machine for it? MEDIA STREAM LEVEL: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHECK LISTS: Check list state: * Running, Completed, Failed Check list status: * Frozen, Active QUESTION: Do we need the check list status? Could we somehow incorporate it= into the check list state machine? PAIRS: Candidate pair state: * Waiting, In-Progress, Succeeded, Failed, Frozen Candidate pair Nomination flag: * false, true QUESTION: Do we need the nomination flag? Could =93Nominated=94 be a state? Regards, Christer --_000_D51F93E51B67Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7D86058A7FA4CF46BCA81732AD3CE654@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Below is a list of the different states/status/flags in ICE, and some quest= ions related to it.

Note that my questions are not (at least not at this point) change suggesti= ons, but more questions for clarifications.

-------------

ICE LEVEL:
=3D=3D=3D=3D=3D=3D=3D=3D=3D

ICE State:
  • Running, Completed, Failed
QUESTION: Is this really needed? = I realise ICE can complete, fail etc, but do we really need to have a = state machine for it?


MEDIA STREAM LEVEL:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHECK LISTS:

Check list state:
  • Running, Completed, Failed
Check list status:
  • Frozen, Active

QUESTION: Do we need the check list status? Could we somehow=  incorporate it into the chec= k list state machine?

PAIRS:

Candidate pair state:
  • Waiting, In-Progress, Succeeded, Failed, Frozen
Candidate pair Nomination flag:
  • false, true

QUESTION: Do we need the nom= ination flag? Could =93Nominated=94 be a state?


Regards,

Christer
--_000_D51F93E51B67Echristerholmbergericssoncom_-- From nobody Sun Apr 23 13:30:42 2017 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 F358C128854 for ; Sun, 23 Apr 2017 13:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=K3clxa8Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZU+5ayUr 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 22DmV4t8Ojmk for ; Sun, 23 Apr 2017 13:30:39 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AD11287A7 for ; Sun, 23 Apr 2017 13:30:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AEF2820B36; Sun, 23 Apr 2017 16:30:35 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 23 Apr 2017 16:30:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=eWasPAvLZ8L3RGCO/1u7M9bG5fBF4wFZKGKoTkRnI r4=; b=K3clxa8YrDZ7fDMMYDrSECFiRQFkKkx/wprtGZTwV7FZKg3t5kT0CKhZx mnSCDp8GO+dUo+rTrIYUHkbTuL0wRV70LbhiP7GLublvEMcGkymL5QEqgK0V7ls8 gCL0mtrnTGN40Zt+CEcCypjxBx1iX7fgNCjmdrmqEUAm922hnr1UCMQSV0PKNzvs mTqRV5HNLIaY8CXW+O9YO96Qug6a1VSSuqJoQEECgLGLUO9FRVpaMEVUhpH2vHNI r2Yf1DfPwo2TJO6qFnRc+yifU0HmQa3o9GJRukm0/UzdcwDcwAxcJSou2UAXe6A+ 99PLaRDpWxHl2rYnuXhp6WPg6dFkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=eWasPAvLZ8L3RGCO/1 u7M9bG5fBF4wFZKGKoTkRnIr4=; b=ZU+5ayUrS161Zu1YTaigYms5JE6rTotGi+ tmzIYzUb2rSufz5WM3chwJfWsgP5rrwuKqLQ4WbpOhYHstcWC/22/1+wPVBZ8aLu A7ldo+U31juMWI1vA1KFjUfil1qkYKxWjaFqm5TKF/2evtg+xegsNAJnF6IGu2Cl 38icev6zDwaqix5seHDbWQS0Kxynvz5w/9u6L6iytjmlpAmvEQyuDvnB20rV+FAk gYlitg5yOJ4nKFcsCZazEmNny2VKhlLBuQfMezOnqMWh/WvsL7a3dwCiO5OWZKFE o+P/oIbTuyJ/mmrDRlH6rPyn/L5AoCbgOM9AT4Ulr2htTnonNKrA== X-ME-Sender: X-Sasl-enc: OQn/vA7nm5uNlUFhtIoM6uzfvti8jZbZyorI5HKBvu1d 1492979435 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 4C2917E430; Sun, 23 Apr 2017 16:30:35 -0400 (EDT) To: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> Date: Sun, 23 Apr 2017 14:30:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 20:30:41 -0000 Over at GitHub, Taylor posted a note about a comment that Philipp Hancke made regarding the fact that (in SDP) "a=ice-option:trickle" is allowed to exist at the media level as opposed to the session level... https://github.com/ice-wg/trickle/issues/11 Taylor suggested that we probably don't want to negotiate trickle for some media streams and not others, and proposed the following text: An ICE agent compliant to this specification MUST inform the peer about the compliance using the 'trickle' ICE option, either at the session level or for every media stream at the media stream level. The best place I can find for the relevant text is in Section 3... OLD Even if a signaling protocol does not include a capabilities discovery method, a user agent can provide an indication within the ICE description that it supports Trickle ICE (e.g., in SDP this would be a token of "trickle" in the ice-options attribute). NEW Even if a signaling protocol does not include a capabilities discovery method, a user agent can provide an indication within the candidate information that it supports Trickle ICE, either at the session level or for every media stream at the media stream level (e.g., in SDP this would be a token of "trickle" in the ice-options attribute). Note that Taylor adapted his proposed text from the latest version 5245bis, which says: An ICE agent compliant to this specification MUST inform the peer about the compliance using the 'ice2' ICE option. The fact that 5245bis defines an ICE option for registration by IANA at https://www.iana.org/assignments/ice/ice.xhtml#options makes me think that we need to register an ICE option for trickle, too. Somehow we've overlooked this so far, but I can add the registration template to the next version of draft-ietf-ice-trickle. Peter From nobody Sun Apr 23 13:42:15 2017 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 BBCBA126C25 for ; Sun, 23 Apr 2017 13:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 v8DPQTwFK2lG for ; Sun, 23 Apr 2017 13:42:11 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 D13DE12426E for ; Sun, 23 Apr 2017 13:42:11 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id 70so35827668ita.0 for ; Sun, 23 Apr 2017 13:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=R3sHOeOnMK9C9ZtGr079r5m6HOaiVNCrt08V5kEKWsI=; b=K91gYrlDcR43NOGWFkiYM3TQhfFYKDnYpaPUHckTX7IhflbzOXS/0Y7B9xrmy1YrSv EJ8e/o7JOdKipFKKLzkARR/4fQVCdhbbBh9vFbQkQTJ0Ul2UfjI4MZfLi/DsPxZokLKK 92ZZrPQocITTVx74mCcPSYE45NMbPphE68Iyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=R3sHOeOnMK9C9ZtGr079r5m6HOaiVNCrt08V5kEKWsI=; b=btCrnvPR80appEiBISfTiJaiOSxnn18j1YaCKnkv2cIzOTlpPE0TziCNqfwHuJgs2x 54L1PBJ2sXohhpE5yKCVI6BYoARKE8SURO6jmBYb08p8QmMu4kbDTzRuEQI4GbUZLgXd 8T4+b0aKhWHowda/4dou0alh+eUef2pyPgGuwNkDc4R5G/5xfqdTCXke/fPJHtOGb5Yj LGeU2ocg9ZLdRuUw+lPt3RQ8/AbpDXpWwARUaNiDiy8OxsRjQ9ua51ArlCOS3N/uoRWb Ir9E2DxLvnZGRMkITt/esUPsLy2pAbPaftE7aKogsYzt1rn52UlxMBfKdinnX64/egKO 3SqA== X-Gm-Message-State: AN3rC/7RQ9T/r+mMLFf3ruHTNCL4/alwbWyhpgq0rG5UJ/atE/b18hOz qgFmA2VfQZXZIXa8 X-Received: by 10.99.126.23 with SMTP id z23mr16839868pgc.63.1492980130613; Sun, 23 Apr 2017 13:42:10 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:184:9680:ee9a:5280? ([2601:647:4601:ec84:184:9680:ee9a:5280]) by smtp.gmail.com with ESMTPSA id m4sm26799343pgm.25.2017.04.23.13.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Apr 2017 13:42:09 -0700 (PDT) From: Nils Ohlmeier Message-Id: <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F10EB516-816A-4897-9B25-0F7CA8EF9C6A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 23 Apr 2017 13:42:07 -0700 In-Reply-To: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> Cc: "ice@ietf.org" To: Peter Saint-Andre References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 20:42:14 -0000 --Apple-Mail=_F10EB516-816A-4897-9B25-0F7CA8EF9C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 23, 2017, at 13:30, Peter Saint-Andre = wrote: > NEW >=20 > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > candidate information that it supports Trickle ICE, either at the > session level or for every media stream at the media stream level > (e.g., in SDP this would be a token of "trickle" in the ice-options > attribute). Sounds good to me. Although this makes me wonder how to handle the situation where all = m-sections have the ice-options, but one indicates support for trickle = and another does not. While technically I could maybe handle this by = trickling only for the sections for which the support is announced. I = guess webrtc needs to define how to translate this into the "can = trickle=E2=80=9D flag. > Note that Taylor adapted his proposed text from the latest version > 5245bis, which says: >=20 > An ICE agent compliant to this specification MUST inform the peer > about the compliance using the 'ice2' ICE option. >=20 > The fact that 5245bis defines an ICE option for registration by IANA = at > https://www.iana.org/assignments/ice/ice.xhtml#options makes me think > that we need to register an ICE option for trickle, too. Somehow we've > overlooked this so far, but I can add the registration template to the > next version of draft-ietf-ice-trickle. Yes please. --Apple-Mail=_F10EB516-816A-4897-9B25-0F7CA8EF9C6A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/RGgAAoJEJ3NnGfOORkkyS4P/idW0grrXZOEDAP5YqimZZWu OjlLstj3kepV5Jqj7PCNjeJI82cuHHuno+wM2Kr9OVSjKW/yDHqTtRXDeSIRgQ/Q aS6UqFlEEK3CQITZ5UWoiEz2hTB2N/iZDuLHWUJ5LnJu9c1IpbCjWDiJtierXGuA TtqmgIxv3bQdvDzIi+buMjT+96eOkmR627KIvWTAB5nwKTAcTDYnmEJtMbkx7wZP fgWZlOunkTzNAPNiWq/7alW5pNQhsl2GbtrlYtkcSkA0UXoQpj/2GrdVm9VycmHx 3ymOTubMmT+jpcy+KDYEWzXLFs5B6GZuUAn0VPUtwxR9Jv+cS/kJsAra0R+mBFIp MO/lyN3Rtcm2kRMgAAMoA7O9TPpS7c6kc4/3GOd0ALH3k7f5PivMja12Ci1ThnJf fmxVnqNF48xvgvcCpA2Whhz7pKSX3IA8fs4BukxfdfYY97/JAtlZRsXYDwsRJJL9 d/24KgRQc+zmBVRm3TGy1Y/fTTvW5l7jlMOMFY5eKbDpFdP4AHfOLGb3/DleEWEN GOfl2hVvFKRsrrvALvWc0FJZNeFIaEMJ69weWNNxD/nD9gnX18mJ7PjlU6glr71M Ul/pM8e6R2GEFyKPnILawjgrOEyU6fkFdJYS4gL4Tr2AgwtjRUsIm9jMnfGJuiTI de8pqqUQAEsv18DzCfpc =IrE3 -----END PGP SIGNATURE----- --Apple-Mail=_F10EB516-816A-4897-9B25-0F7CA8EF9C6A-- From nobody Sun Apr 23 13:56:26 2017 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 558431294E2 for ; Sun, 23 Apr 2017 13:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=fuC6JR8t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=paLYFk6E 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 PeSd78oOgfwW for ; Sun, 23 Apr 2017 13:56:23 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D73A127076 for ; Sun, 23 Apr 2017 13:56:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6D93F20A34; Sun, 23 Apr 2017 16:56:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Apr 2017 16:56:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=0Vf5UKHxPXyIQXdP5J7zHIsgdc0kpU6RHrt5ZpodY KY=; b=fuC6JR8tPrni2vIvXI5Y+rdmXpcqh8L9vcnA8ThpUNiuKajkZMZQ3MSNd +b3xrTidNwV28/xLMjB5nwqZKixZqmecXlLzbWA8RIgqa+FE7AWMozliMzgV7ypx X/41SOImb2MGmZMcUS0/w0Qxm3N1OowwN0Zgkd6Zl9QZmfyNlmxokd9YQkrquZ/j YfhCVdi3aPrhPwIp9eljSkIfl110oyOl5PaA0UPppKzi5tOH71XB9vZs+JN3YCZn MxzdibooT+1xLW4k99T4PU+Nkpl7sYKwa3Yh3NT5H2N3E2kS+b39moTwHA2Xm1fa uOWBLTMdsvUMi78VOwXYwGw5IzBcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=0Vf5UKHxPXyIQXdP5J 7zHIsgdc0kpU6RHrt5ZpodYKY=; b=paLYFk6EmYIR3MB40X/0riCjEy7oWFJ6hb 7Uqy2weSLGg1rPDr2uZmjvOG6OFFU9ORBsoF47m+jKbswqDbllT0C6AFF8TmGHMW 4PSswILb0Jr9j6bQBCP/HhQdnwpmkUEWALlE4IxEVxQGL0pGoKW6zIX9yhTuQPjD 8SEGd1k2pSOhz7I/89ERePSdRrbNUpSYG9m/t7VpW9LDAZzJtYSgj98piOrHMkv4 0CgxWdyZvLQ59aur82IU7rTQ36Gn+ipfJ+LJk1denztI6mFzddCU8E/4uPVIyGmU PDgBIHxynK20cVhA1t2WTCyK5LbhwSEjIuO3FlBZAyHFoma/GAvQ== X-ME-Sender: X-Sasl-enc: ic83vwPwtPHahP8i4PpPB1/mcMh67uZP36tjVA3Ihyv4 1492980982 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id CC0C3241ED; Sun, 23 Apr 2017 16:56:21 -0400 (EDT) To: Nils Ohlmeier References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> Date: Sun, 23 Apr 2017 14:56:20 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NXDCTVrUImJ46xcGLEHWKmNvsBpW5FUkt" Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 20:56:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NXDCTVrUImJ46xcGLEHWKmNvsBpW5FUkt Content-Type: multipart/mixed; boundary="FFk0cQVS9dE1wWKQqC8ApVjcJSnVXcjx5"; protected-headers="v1" From: Peter Saint-Andre To: Nils Ohlmeier Cc: "ice@ietf.org" Message-ID: <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> Subject: Re: [Ice] negotiating trickle: always session-level? References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> In-Reply-To: <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> --FFk0cQVS9dE1wWKQqC8ApVjcJSnVXcjx5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/23/17 2:42 PM, Nils Ohlmeier wrote: >=20 >> On Apr 23, 2017, at 13:30, Peter Saint-Andre >> wrote: NEW >>=20 >> Even if a signaling protocol does not include a capabilities=20 >> discovery method, a user agent can provide an indication within >> the candidate information that it supports Trickle ICE, either at >> the session level or for every media stream at the media stream >> level (e.g., in SDP this would be a token of "trickle" in the >> ice-options attribute). >=20 > Sounds good to me. >=20 > Although this makes me wonder how to handle the situation where all > m-sections have the ice-options, but one indicates support for > trickle and another does not.=20 If I understand Taylor and Philipp correctly, they're saying "don't do that"; perhaps we need to say MUST NOT? > While technically I could maybe handle > this by trickling only for the sections for which the support is > announced. I guess webrtc needs to define how to translate this into > the "can trickle=E2=80=9D flag. >=20 Good point. Peter --FFk0cQVS9dE1wWKQqC8ApVjcJSnVXcjx5-- --NXDCTVrUImJ46xcGLEHWKmNvsBpW5FUkt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJY/RT1AAoJEOoGpJErxa2p5OoP/2b/tN0bWjKduunCiCjM/fh0 Xke60sKZDMVY0cls+1uaJCWbxp6yzTTtIZejgCgfbJ79r8rcQv+HtvUZ8Dbou571 BTfQwpgGw6yJadhfOosiA5cQ1A/TO+Xi1V5tdhojWbacUI70G8+xyKP1yb0ZAZA9 yqGAF/vQL8vKopqvAu6HmUXC+fBRk0OMq5Prcxf9abHR200gJ1MhxsgsY0UsxzBl qlsLnUG+4uvomVEfrRGi9WZnuaWYwxc/8cNRWZKZ/l5yGN5DNssauGWOhYxqnxLB aFkQ0YruinunPsHyRGbkdXc/P7c/WrhQX8CXaRto46AjgdIm/WLQY36eHWDSQ0/E /CArcATmN66I/jCgvxEbRhyqsyjLcNLvKN6eOYhN5L96+kezfFQm9mbgPHtfVAEZ /V6gxsdpKeM9rkE+qGehzmceLQfG10iGASjtQfmB0tprAGeCIdroM477bXrF/r6W WIHC3eYFYu454DcKa6tipmzKIS3t3koQJEbRAMWIO6bXdZd+Q1rrBeBvBkTKVpSh J3gp3jImhsAHp+4isqFbizt4NGAYvZlOo38xavfF3iyIYeQf0UpiMKCEr3UqiYlG 2rHx3xYQPR64BNs1PTL2oyom7LGJNU/ws/S6YX+wiJR0rzVC17H0DyFfSOLlnKbf aeSszf2dIk8FebM0Dbcr =ko90 -----END PGP SIGNATURE----- --NXDCTVrUImJ46xcGLEHWKmNvsBpW5FUkt-- From nobody Sun Apr 23 14:05:19 2017 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 DF1501294EF for ; Sun, 23 Apr 2017 14:05:18 -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 (2048-bit key) header.d=stpeter.im header.b=XuKj4DRD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jdIeES20 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 DtqF4l-rJa8f for ; Sun, 23 Apr 2017 14:05:18 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C3B1294E9 for ; Sun, 23 Apr 2017 14:05:17 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4C6D720929; Sun, 23 Apr 2017 17:05:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Apr 2017 17:05:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FEGjBQNNjjyv4I7gnk kUvdC49NOabsfiKHv2O/YCQX8=; b=XuKj4DRDPblcHzsKT9FlCJfjcHhQtObbDb Oyo5khNjVlgU8jGHkkFtLoDWO88L6IfLfi51LPjyTzVO3WcxXG0zPRSovrlW2xNo Jlal40Xk966HF3X+NX5L5EJzFasA2suCtiKn8XKN6v6YJ7d+x7FUxqlDInJr9Zkc MuNbLTaGBpW8FzcH83iMwMGJYq5FNHtIvETJ21dmely+YliEsZ7xT5WFIAF3SQsn 6DEGmRybF6RHkuY8lOt0dpcj6VdXHLSDWs99jq70O65mSuiJjCzS9l+Czc1qaVzh Vf4m6B9KYh7qYAvXSfOQ/FSyVZtNmx3cbxZlS62JmZOSD4R1HsiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=FEGjBQNNjjyv4I7gnkkUvdC49NOabsfiKHv2O/YCQX8=; b=jdIeES20 /Dxy4n8cuqMsY8Aax4NNP9g5CToEeiHuz2NL/Xb8vdn/8QJtLHCa2XISdZWPcoao +RT0Gqutc4qe3bCSmol3f7s50vTUmK662BmpqYhXVU/sGra74K0UazSRm8AQF1mL EjmeaOMl9JukgKVmp/caOnXCkx/dd1xlOg8sijRja13RDKNuqsk/z4ttYVFME3Ku cark0qCZUyNrt3QqzFCy7yVClu+H/bxRUf6k/EDnPtI09JKMqPSOv14nszaQFMtz Vq58hyQeQant4aqtqSp8zybUXKVgGVOSvlCxOIZqPCYQN+GwtrM9UMpfH7GYnwgx IsaaUI7zLDui0g== X-ME-Sender: X-Sasl-enc: 5nVghKHPEAtxp3OO7SD6byqB8ILhfm5JNV6voHaZ/VqT 1492981516 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id ACD3A240A5; Sun, 23 Apr 2017 17:05:16 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: Date: Sun, 23 Apr 2017 15:05:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] 5245bis: ICE states X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 21:05:19 -0000 On 4/21/17 1:43 AM, Christer Holmberg wrote: > Hi, > > Below is a list of the different states/status/flags in ICE, and some > questions related to it. > > Note that my questions are not (at least not at this point) change > suggestions, but more questions for clarifications. > > ------------- > > /ICE LEVEL:/ > ========= > > *ICE State:* > > * Running, Completed, Failed > > *QUESTION: Is this really needed? I realise ICE can complete, fail etc, > but do we really need to have a state machine for it?* I tend to think we don't need this. > /MEDIA STREAM LEVEL:/ > =================== > > *CHECK LISTS:* > > Check list state: > > * Running, Completed, Failed > > Check list status: > > * Frozen, Active > > * > * > *QUESTION: Do we need the check list status? Could we > somehow **incorporate it into the check list state machine?* I find state vs. status confusing. Integrating them sounds like a good idea. > * > * > *PAIRS:* > > Candidate pair state: > > * Waiting, In-Progress, Succeeded, Failed, Frozen > > Candidate pair Nomination flag: > > * false, true > > > *QUESTION: Do we need the nomination flag? Could “Nominated” be a state?* Seems feasible. Peter From nobody Sun Apr 23 14:09:26 2017 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 B1926126E01 for ; Sun, 23 Apr 2017 14:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=BOQwkSaQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=duezRG1o 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 lZVvhov3d4ZQ for ; Sun, 23 Apr 2017 14:09:23 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CED126C25 for ; Sun, 23 Apr 2017 14:09:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3762F20A44; Sun, 23 Apr 2017 17:09:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Apr 2017 17:09:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ucvO2RO55j1yGcWvsi qN+qKlOPRSWbqTJrXQK/iHW2k=; b=BOQwkSaQ5bjz9NPQj80lnfiiBFe62Zgk28 llhN7sur+nLxRfl7RMrokuLnkEHaHnOXJBj1olEvgeRpgUCBAHGVfIryi/gRPt0w heG9nQ5TFBUHK+PZJF8CRPpRlOcCYWqqpa/H8PM0X3OQBjoPFTkPfW6qvEX0/Xnr PlSHjJIkYKXCcXj4RIP3cKbaLYnePMa5zkwLqlSLL/bClSxXRee5LcHJHy2ujJ4Z FJbuXE3QJBMof/9tTfjM9Nw6kld/WH61twsF66+64cwRvRFNHpGfDCtaAhNwadqJ T6Rprn3gGzeySP9Mjv0fU/+0qrR3bcDpl2KHtRFTWk2U+/K2xmzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ucvO2RO55j1yGcWvsiqN+qKlOPRSWbqTJrXQK/iHW2k=; b=duezRG1o bwGSizaVJkiylwiyv8BnO6+5wIGidCEh/hKjQf0IfHcBUGnqjxIYfFl7p4ktkDXN tcaddnZCJ456TuXFZ2i04JCJX2D2wjLRli9A2IcfgM/J9hgJ9KDoZw0HKJQE8mK3 oLatr4Z2e+Yguzlsk9Pn3QWAo0NmlNF78d3iMc75U0i+J6kxagHgDBxFpr7XhcF4 sYja66WwWwBKg6HLWiJcHTVqAn20eZtUN4qTAIkIjOyvKhs5wIFYou1Wx943l9vw CfdPtL1qB9EbCxbqMn9f4vNQOIHHQrmr4MAsFdgbZwH6DzgghZjafYX9iwGsUWQs mxqecgR7Ucwd/g== X-ME-Sender: X-Sasl-enc: k7DIWUws1Rir4WYBvhO3d5R+ZIBpPsSOOBgTlYzflSPA 1492981762 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 874C72445F; Sun, 23 Apr 2017 17:09:22 -0400 (EDT) To: Christer Holmberg References: Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <4a16b597-1984-8708-4e6e-6e464c5dc255@stpeter.im> Date: Sun, 23 Apr 2017 15:09:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Draft new version: draft-ice-5245bis-09 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 21:09:25 -0000 On 4/20/17 1:48 AM, Christer Holmberg wrote: > Hi, > > I have submitted a new version (-09) of draft-ice-5245bis. Thanks for your work on -09. My impression from list discussion was that we agreed to add a definition for "ICE Session" - will that be added in a future version? Peter From nobody Sun Apr 23 14:57:53 2017 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 B6017126FDC for ; Sun, 23 Apr 2017 14:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=hyl40Gqk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=obnQu8VM 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 QwHZvqUVeh-A for ; Sun, 23 Apr 2017 14:57:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1CC1243F6 for ; Sun, 23 Apr 2017 14:57:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D0F1A20A18; Sun, 23 Apr 2017 17:57:47 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Apr 2017 17:57:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=mOe+yZekTusOQY+GMu VlOxWsE/Iglo09w4ugWpwxncc=; b=hyl40Gqkcl5K1Ll8K2/LTivI0UlN8Zqfqm fTlVejjI1M+r2jFT0/NvUX+r+xYbG4r+Vy0c7hp10k3jJ220PsnAik0dnDnOkVei Eh1ReJ2GkIufQM19gyRC6Ix+yQF/CpDneasbYdQahAmv3Bn28liFy5Sa8cVlxJIL UcdnfHmrE2x7lGWsLT/Huj2GOVi4OS60jsN3bgqadn+AFy+n56uoy8H6FxtXVGOd a3SR2o1jQffhTPnCCl8525mTYlre4E8SzwP02np1BUAq0H8hYM/RYYdyoARMKSBc muhsNQ4V7NT6c7GHYqGKqY+BgcCnY19v4IwXFgIywtX2+HCYtfSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=mOe+yZekTusOQY+GMuVlOxWsE/Iglo09w4ugWpwxncc=; b=obnQu8VM ZuoFFTihJPBXIzuMpcDfN9pYed80g5fXmdZB1Ju7lrKUKnlNruaWQAXI92PQOWSp DTBbk0RCF6zVXzTMnJen2d8K/++eaPHZqrb8dnyUWteVKEJGEUNg4Zl6aMhqPP9U N/6mTNAoXyKc++oyCKQodcvFkWeFLoFKXI0cYjIwnBSjTF2WszcI5ENIuZzYzPlf sHyrNgnwHkl/f7RGPDcwJwhFZOelVTK2r/ZoxpbHFmFe20xaHPImFDv0xE2taZhD zG1xCJE7wJd8+tPFOwi5OLjp60tAKuiHr/HhrVFuzJG4m+jljV0h1M0bWbYdHHF9 DHBPSSW4aBtQEw== X-ME-Sender: X-Sasl-enc: 1EWpxRzUs/RZlkADjod203qMxzWHJOAj8bGFSMsNnG3H 1492984667 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id E533E240A5; Sun, 23 Apr 2017 17:57:46 -0400 (EDT) To: Taylor Brandstetter References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> Date: Sun, 23 Apr 2017 15:57:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 21:57:51 -0000 On 4/18/17 7:44 PM, Taylor Brandstetter wrote: > Taylor, would you mind spelling this out a bit more fully and point to > discrepancies between the text of 5245bis and the text of the Trickle > spec? I'm sure I'm missing something, but I don't yet see the truth of > your statement that "only the topmost remaining pair in each foundation > is guaranteed to be unfrozen". > > > Sure; let me try to give an example. > > Suppose I have three media streams, and one foundation (let's keep it > simple). I'll represent the states like this for brevity: "SWFFFF", > where "S" is "succeeded", "W" is "waiting", and "F" is "frozen". And > they're ordered in the same way as the rows in your table above. > > With non-trickle ICE, here's what would typically happen: > > 1. Only the RTP candidate pair for the first media stream is unfrozen > initially. > State: WFFFFF > 2. Check succeeds for RTP candidate pair. RTCP pair unfrozen. > State: SWFFFF Section 6.2.5.3.3 of 5245bis states: The success of the connectivity check might also cause the state of other candidate pairs to change. The ICE agent MUST set the states for all other Frozen candidate pairs (in each CHECK LIST in the CHECK LIST SET) with the same foundation to Waiting. Does that mean we'd go directly from WFFFFF to SWWWWW? > 3. Check succeeds for RTCP pair. /All/ the other pairs with the same > foundation are now unfrozen. > State: SSWWWW > > With trickle ICE, here's what could happen: > > 1. Candidates for the first media stream are trickled in. Starts out > just like normal ICE. > State: WF > 2. Checks for both pairs succeed. Still waiting for candidates for > other media streams. > State: SS > 3. Candidates for the other media streams arrive, and pairs are formed. > The topmost pair is set to waiting, but not the others. > State: SSWFFF Thanks for the example. My interpretation of Case 1 is that only the topmost pair for that foundation is set to waiting, however you seem to interpret it to mean the topmost pair for that media stream. I agree that the rules in draft-ietf-ice-trickle-08 aren't quite right. If we accept my interpretation of the "topmost pair" rule, then I think the fix we need to make is to Case 3 (change "below" to "above"). In the interest of time, I'm going to submit -09 right now so that we have a document and diff to review, not just these long email messages. Peter > So, where normal ICE ensures that once a foundation is proven to work > (for both components of a media stream), all other pairs with that > foundation are unfrozen, trickle ICE only guarantees that one of them is. > > On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre > wrote: > > On 3/30/17 11:28 PM, Taylor Brandstetter wrote: > > [areas of seeming agreement elided] > > > * In section 8.1.1: In general I like the improvements that have > been > > made. However: > > o The rules for how a new pair gets either a "Waiting" or > "Frozen" > > state don't completely match standard ICE; at least the part > > where when one "media stream" completes, pairs from other media > > streams with matching foundations are unfrozen. With the current > > rules in section 8.1.1, only the topmost remaining pair in each > > foundation is guaranteed to be unfrozen. Is this difference > > acceptable? If it is, we should at least acknowledge it, and not > > give the wrong impression by saying "Trickle ICE preserves all > > of [the standard ICE] rules." > > Taylor, would you mind spelling this out a bit more fully and point to > discrepancies between the text of 5245bis and the text of the Trickle > spec? I'm sure I'm missing something, but I don't yet see the truth of > your statement that "only the topmost remaining pair in each foundation > is guaranteed to be unfrozen". > > In particular, your statement doesn't seem to match the rules defined in > the Trickle spec. I've tried to spell them out in greater detail (with > examples) in the following proposed text. > > ### > > > 8.1.1. Inserting a New Pair in a Check List > > Consider the following tabular representation of all checklists in an > agent: > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | cp | cp | cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | cp | cp | cp | cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 1: Example of Check List State > > Each row in the table represents a component for a given media stream > (e.g., m1 and m2 might be the RTP and RTCP components for audio). > Each column represents one foundation. Each cell represents one > candidate pair. > > When an agent commences ICE processing, in accordance with > Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in the > Waiting state) the topmost candidate pair in every column (i.e., the > pair with the lowest component ID). This state is shown in the > following table, with candidate pairs in the Waiting state marked by > "w-cp". > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | w-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 2: Initial Check List State > > Then, as the checks proceed (see Section 6.1.2.4.2.3 of > [rfc5245bis]), for each pair that enters the Succeeded state (denoted > here by "s-cp"), the agent will unfreeze all pairs for the same media > stream and foundation (e.g., if the pair in column 1, row 1 succeeds > then the agent will unfreeze the pair in column 1, row 2). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 3: Check List State after Succeeded Check > > ICE also specifies that, if all the pairs in a media stream for one > foundation are unfrozen (e.g., column 1, rows 1 and 2 representing > both components for the audio stream), then all of the candidate > pairs in the entire column are unfrozen (e.g., column 1, rows 3 and > 4). > > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 4: Check List State with Unfrozen Media Stream > > Trickle ICE preserves all of these rules as they apply to what we > might call "static" check list sets. This implies that if, for some > reason, a Trickle agent were to begin connectivity checks with all of > its pairs already present, the way that pair states change is > indistinguishable from that of a regular ICE agent. > > Of course, the major difference with Trickle ICE is that check list > sets can be dynamically updated because candidates can arrive after > connectivity checks have started. When this happens, an agent sets > the state of the newly formed pair as described below. > > Case 1: If the newly formed pair is the topmost pair in this column, > set the state to Waiting (e.g., this would be the case if the newly > formed pair were placed in column 4, row 1). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 5: Check List State with Newly Formed Pair, Case 1 > > Case 2: If the pair immediately above the newly formed pair in this > column is in the Succeeded state, set the state to Waiting (e.g., > this would be the case if the pair in column 4, row 2 succeeded and > the newly formed pair were placed in column 4, row 3); > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 6: Check List State with Newly Formed Pair, Case 2 > > Case 3: If there is at least one pair in this column below the row of > the newly formed pair whose state is either Succeeded or Failed > (e.g., this would be the case if the pair in column 4, row 2 > succeeded and the newly formed pair were placed in column 4, row 1). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 7: Check List State with Newly Formed Pair, Case 3 > > Case 4: In all other cases, set the state to Frozen. > > ### > > Peter > > From nobody Sun Apr 23 14:59:40 2017 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 677D31243F6; Sun, 23 Apr 2017 14:59:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149298477838.25861.14494562182541527709@ietfa.amsl.com> Date: Sun, 23 Apr 2017 14:59:38 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-09.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 21:59:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-09.txt Pages : 32 Date : 2017-04-23 Abstract: This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-09 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-09 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 Sun Apr 23 21:33:01 2017 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 C9488126BF0 for ; Sun, 23 Apr 2017 21:32:58 -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 oeWQgksu3naS for ; Sun, 23 Apr 2017 21:32:57 -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 0BD04126B6D for ; Sun, 23 Apr 2017 21:32:56 -0700 (PDT) X-AuditID: c1b4fb3a-7cfff70000005492-37-58fd7ff6c8cf Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 4E.63.21650.6FF7DF85; Mon, 24 Apr 2017 06:32:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Mon, 24 Apr 2017 06:32:54 +0200 From: Christer Holmberg To: Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] Draft new version: draft-ice-5245bis-09 Thread-Index: AQHSuap0nUp6L4BLNUSPAnYCDB/IvqHTVuSAgACvgQA= Date: Mon, 24 Apr 2017 04:32:53 +0000 Message-ID: References: <4a16b597-1984-8708-4e6e-6e464c5dc255@stpeter.im> In-Reply-To: <4a16b597-1984-8708-4e6e-6e464c5dc255@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BA0C09A3E38D84B82711559A025F203@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7tO73+r8RBk+2clp8u1BrcWxPP7MD k8eSJT+ZPObuecEcwBTFZZOSmpNZllqkb5fAlXHh1mrWglbmirOHp7A1MC5l6mLk5JAQMJGY 2P+HrYuRi0NIYD2jxLqPC5kgnCWMEn+ubQbKcHCwCVhIdP/TBmkQEdCSuHStjx0kzCygKPFy rxpIWFjASmJzyxsmiBJriXd7OtggbCuJFbP2s4LYLAKqEr+PTQGr4QWqef9jCjOILSSQL/Go 6TYLiM0pYCfx7fgkMJtRQEzi+6k1YPXMAuISt57Mh7pZQGLJnvPMELaoxMvH/8DmiwroSez7 95UNIq4osfNsOzNEr47Egt2f2CBsa4nDlyaxQtjaEssWvmaGuEdQ4uTMJywTGMVnIVk3C0n7 LCTts5C0z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYKwd3PLbagfjweeOhxgF OBiVeHgfKP+NEGJNLCuuzD3EKMHBrCTC+4cHKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+F CCGB9MSS1OzU1ILUIpgsEwenVAOj8FvjX+sCXjw4aRN97M+VsPmdQddnTU9IeCySv8k2RdWm QvJR27eNhmn72Y38Yre/mFPt4nbw63dpQ5uZ0ndCby77c9Bo4kVR9zXWXm0NeWuTShcvuXzl 2BpjlSYTw9C+ifX+t/l8ORyzZoYy2ZXYcdufFvp8uG4d33R/xvmVRT3/n+3w3cSoxFKckWio xVxUnAgA8EJrdbECAAA= Archived-At: Subject: Re: [Ice] Draft new version: draft-ice-5245bis-09 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 04:32:59 -0000 Hi Peter, >>Hi, >>=20 >> I have submitted a new version (-09) of draft-ice-5245bis. > >Thanks for your work on -09. > >My impression from list discussion was that we agreed to add a >definition for "ICE Session" - will that be added in a future version? It will :) I was supposed to add it to -09, but for some reason I forgot. Sorry for that. Regards, Christer From nobody Mon Apr 24 11:01:58 2017 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 DAE6E126CE8 for ; Mon, 24 Apr 2017 11:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001, 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 0XWso3nM0VRE for ; Mon, 24 Apr 2017 11:01:54 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 CA25C127444 for ; Mon, 24 Apr 2017 11:01:53 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id g60so120892343qtd.3 for ; Mon, 24 Apr 2017 11:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cSAuQho0TMM+YsvlsrV1aAdyOkBuX7M7r6H8NYQUwTs=; b=LcDSTeJRCcSBL0em00DuHS+A9ledQTIK5yfUG3D91QlbfD9ZjdoMHZOrB1XnBZFzGo cFNrdW8Nrs0Kv/5WFo+uAH+M/rE4zjqbkQZmRNblM2NKesx/SVvpWggoI4QNuNiHC5EA /3ERRJompWW6aL/pBDzzWlQOvdXBSUjB3RNY6tv8UV//tB3/VzRWrLbVw9uAUEk92KGL JH964/QwOi+LSA4iG7fL8zX6XNquTG0n8iC5q2JH/UQh7S2HxhyssIoGO8TRpaAUGyht rIOvbyQJb9/0QCmKd8pr6GFV4sVK/8+YGzMZAQxbIvW40+niIVfXUcIRJsTwUjX9GCcM Rwdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cSAuQho0TMM+YsvlsrV1aAdyOkBuX7M7r6H8NYQUwTs=; b=DqCPicTzza9NgGr6D+skSODXplImD+iusHZ9l58m5PY95aevp4kDI+lIKScC9aio6I giEdF1wS1wjZZzBjWWXDVNynSd7HXuROedadDfGAX8s3pL6xsjw2icbTSU6MdT3JNW7E 9DSls1mRitrem3XEuQDT7L8O4W8Z923G2iHq/puV8LMO4msYwMlOIcCg7IA3dGhNT3CM M1EK2EuML2i4bIZGr+6/kxDRKhTjEoVqL4zxc6olk+dsFLg659J2BLgjv+3O1kLKSc9F Y9TLSiRr+aUbgr//nJrJ4AtGJfl56TT4tN6K0f5kY2nX936C3XNZF5sKRh+slLiXqWmY ISgA== X-Gm-Message-State: AN3rC/4grNVltJaRLQfV/6B79HIeR/kZdCGp8ws8EiXcVxNDSyCC8v6z kAoNMJo/HEaUL4afQzEAi+nHD107BuqdwyfIJA== X-Received: by 10.237.44.162 with SMTP id g31mr25415170qtd.43.1493056912339; Mon, 24 Apr 2017 11:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Mon, 24 Apr 2017 11:01:51 -0700 (PDT) In-Reply-To: <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> From: Taylor Brandstetter Date: Mon, 24 Apr 2017 11:01:51 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1249c6e424fb054ded6654 Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:01:57 -0000 --94eb2c1249c6e424fb054ded6654 Content-Type: text/plain; charset=UTF-8 > > Does that mean we'd go directly from WFFFFF to SWWWWW? Yes; when I was typing up the example I hadn't noticed that the "each component of the media stream" part had been removed from 5245bis. My interpretation of Case 1 is that only the topmost pair for that > foundation is set to waiting, however you seem to interpret it to mean > the topmost pair for that media stream. No, I also interpret it as "topmost for foundation". I think the fix we need to make is to Case 3 (change "below" to "above"). I think you could merge cases 2 and 3 and make it "another pair in the same column is in the Succeeded state." On Sun, Apr 23, 2017 at 2:57 PM, Peter Saint-Andre wrote: > On 4/18/17 7:44 PM, Taylor Brandstetter wrote: > > Taylor, would you mind spelling this out a bit more fully and point > to > > discrepancies between the text of 5245bis and the text of the Trickle > > spec? I'm sure I'm missing something, but I don't yet see the truth > of > > your statement that "only the topmost remaining pair in each > foundation > > is guaranteed to be unfrozen". > > > > > > Sure; let me try to give an example. > > > > Suppose I have three media streams, and one foundation (let's keep it > > simple). I'll represent the states like this for brevity: "SWFFFF", > > where "S" is "succeeded", "W" is "waiting", and "F" is "frozen". And > > they're ordered in the same way as the rows in your table above. > > > > With non-trickle ICE, here's what would typically happen: > > > > 1. Only the RTP candidate pair for the first media stream is unfrozen > > initially. > > State: WFFFFF > > 2. Check succeeds for RTP candidate pair. RTCP pair unfrozen. > > State: SWFFFF > > Section 6.2.5.3.3 of 5245bis states: > > The success of the connectivity check might also cause the state of > other candidate pairs to change. The ICE agent MUST set the states > for all other Frozen candidate pairs (in each CHECK LIST in the CHECK > LIST SET) with the same foundation to Waiting. > > Does that mean we'd go directly from WFFFFF to SWWWWW? > > > 3. Check succeeds for RTCP pair. /All/ the other pairs with the same > > foundation are now unfrozen. > > State: SSWWWW > > > > With trickle ICE, here's what could happen: > > > > 1. Candidates for the first media stream are trickled in. Starts out > > just like normal ICE. > > State: WF > > 2. Checks for both pairs succeed. Still waiting for candidates for > > other media streams. > > State: SS > > 3. Candidates for the other media streams arrive, and pairs are formed. > > The topmost pair is set to waiting, but not the others. > > State: SSWFFF > > Thanks for the example. > > My interpretation of Case 1 is that only the topmost pair for that > foundation is set to waiting, however you seem to interpret it to mean > the topmost pair for that media stream. > > I agree that the rules in draft-ietf-ice-trickle-08 aren't quite right. > If we accept my interpretation of the "topmost pair" rule, then I think > the fix we need to make is to Case 3 (change "below" to "above"). > > In the interest of time, I'm going to submit -09 right now so that we > have a document and diff to review, not just these long email messages. > > Peter > > > > So, where normal ICE ensures that once a foundation is proven to work > > (for both components of a media stream), all other pairs with that > > foundation are unfrozen, trickle ICE only guarantees that one of them is. > > > > On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre > > wrote: > > > > On 3/30/17 11:28 PM, Taylor Brandstetter wrote: > > > > [areas of seeming agreement elided] > > > > > * In section 8.1.1: In general I like the improvements that have > > been > > > made. However: > > > o The rules for how a new pair gets either a "Waiting" or > > "Frozen" > > > state don't completely match standard ICE; at least the > part > > > where when one "media stream" completes, pairs from other > media > > > streams with matching foundations are unfrozen. With the > current > > > rules in section 8.1.1, only the topmost remaining pair in > each > > > foundation is guaranteed to be unfrozen. Is this difference > > > acceptable? If it is, we should at least acknowledge it, > and not > > > give the wrong impression by saying "Trickle ICE preserves > all > > > of [the standard ICE] rules." > > > > Taylor, would you mind spelling this out a bit more fully and point > to > > discrepancies between the text of 5245bis and the text of the Trickle > > spec? I'm sure I'm missing something, but I don't yet see the truth > of > > your statement that "only the topmost remaining pair in each > foundation > > is guaranteed to be unfrozen". > > > > In particular, your statement doesn't seem to match the rules > defined in > > the Trickle spec. I've tried to spell them out in greater detail > (with > > examples) in the following proposed text. > > > > ### > > > > > > 8.1.1. Inserting a New Pair in a Check List > > > > Consider the following tabular representation of all checklists > in an > > agent: > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | cp | cp | cp | | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | cp | cp | cp | cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 1: Example of Check List State > > > > Each row in the table represents a component for a given media > stream > > (e.g., m1 and m2 might be the RTP and RTCP components for audio). > > Each column represents one foundation. Each cell represents one > > candidate pair. > > > > When an agent commences ICE processing, in accordance with > > Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in > the > > Waiting state) the topmost candidate pair in every column (i.e., > the > > pair with the lowest component ID). This state is shown in the > > following table, with candidate pairs in the Waiting state marked > by > > "w-cp". > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | w-cp | w-cp | w-cp | | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | cp | cp | cp | w-cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | cp | | | | w-cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 2: Initial Check List State > > > > Then, as the checks proceed (see Section 6.1.2.4.2.3 of > > [rfc5245bis]), for each pair that enters the Succeeded state > (denoted > > here by "s-cp"), the agent will unfreeze all pairs for the same > media > > stream and foundation (e.g., if the pair in column 1, row 1 > succeeds > > then the agent will unfreeze the pair in column 1, row 2). > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | cp | | | | w-cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 3: Check List State after Succeeded Check > > > > ICE also specifies that, if all the pairs in a media stream for > one > > foundation are unfrozen (e.g., column 1, rows 1 and 2 representing > > both components for the audio stream), then all of the candidate > > pairs in the entire column are unfrozen (e.g., column 1, rows 3 > and > > 4). > > > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | w-cp | | | | w-cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | w-cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 4: Check List State with Unfrozen Media Stream > > > > Trickle ICE preserves all of these rules as they apply to what we > > might call "static" check list sets. This implies that if, for > some > > reason, a Trickle agent were to begin connectivity checks with > all of > > its pairs already present, the way that pair states change is > > indistinguishable from that of a regular ICE agent. > > > > Of course, the major difference with Trickle ICE is that check > list > > sets can be dynamically updated because candidates can arrive > after > > connectivity checks have started. When this happens, an agent > sets > > the state of the newly formed pair as described below. > > > > Case 1: If the newly formed pair is the topmost pair in this > column, > > set the state to Waiting (e.g., this would be the case if the > newly > > formed pair were placed in column 4, row 1). > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | w-cp | | | | w-cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | w-cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 5: Check List State with Newly Formed Pair, Case 1 > > > > Case 2: If the pair immediately above the newly formed pair in > this > > column is in the Succeeded state, set the state to Waiting (e.g., > > this would be the case if the pair in column 4, row 2 succeeded > and > > the newly formed pair were placed in column 4, row 3); > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | w-cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 6: Check List State with Newly Formed Pair, Case 2 > > > > Case 3: If there is at least one pair in this column below the > row of > > the newly formed pair whose state is either Succeeded or Failed > > (e.g., this would be the case if the pair in column 4, row 2 > > succeeded and the newly formed pair were placed in column 4, row > 1). > > > > > > +-----------------+------+------+------+------+------+ > > | | f1 | f2 | f3 | f4 | f5 | > > +-----------------+------+------+------+------+------+ > > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > > +-----------------+------+------+------+------+------+ > > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > > +-----------------+------+------+------+------+------+ > > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > > +-----------------+------+------+------+------+------+ > > | m4 (Video.RTCP) | w-cp | | | | cp | > > +-----------------+------+------+------+------+------+ > > > > > > Figure 7: Check List State with Newly Formed Pair, Case 3 > > > > Case 4: In all other cases, set the state to Frozen. > > > > ### > > > > Peter > > > > > > --94eb2c1249c6e424fb054ded6654 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does that mean we'd go directly from WFFFFF to= SWWWWW?

Yes; when I was typing up t= he example I hadn't noticed that the "each component of the media = stream" part had been removed from 5245bis.

My interpretation of Case 1 is that only the topmost pair for that=
foundation = is set to waiting, however you seem to interpret it to mean
the topmost pair for= that media stream.

No, I also inter= pret it as "topmost for foundation".

=C2=A0I think=C2=A0the fix we need = to make is to Case 3 (change "below" to "above").

I think you could merge cases 2 and 3 and= make it "another pair in the same column is in the Succeeded state.&q= uot;=C2=A0

On Sun, Apr 23, 2017 at 2:57 PM, Peter Saint-Andre &= lt;stpeter@stpeter.= im> wrote:
On 4/18/17 7:44 PM, Taylor Brandstetter wrote:
>=C2=A0 =C2=A0 =C2=A0Taylor, would you mind spelling this out a bit more= fully and point to
>=C2=A0 =C2=A0 =C2=A0discrepancies between the text of 5245bis and the t= ext of the Trickle
>=C2=A0 =C2=A0 =C2=A0spec? I'm sure I'm missing something, but I= don't yet see the truth of
>=C2=A0 =C2=A0 =C2=A0your statement that "only the topmost remainin= g pair in each foundation
>=C2=A0 =C2=A0 =C2=A0is guaranteed to be unfrozen".
>
>
> Sure; let me try to give an example.
>
> Suppose I have three media streams, and one foundation (let's keep= it
> simple). I'll represent the states like this for brevity: "SW= FFFF",
> where "S" is "succeeded", "W" is "w= aiting", and "F" is "frozen". And
> they're ordered in the same way as the rows in your table above. >
> With non-trickle ICE, here's what would typically happen:
>
>=C2=A0 1. Only the RTP candidate pair for the first media stream= is unfrozen
>=C2=A0 =C2=A0 =C2=A0initially.
>=C2=A0 =C2=A0 =C2=A0State: WFFFFF
>=C2=A0 2. Check succeeds for RTP candidate pair. RTCP pair unfrozen. >=C2=A0 =C2=A0 =C2=A0State: SWFFFF

Section 6.2.5.3.3 of 5245bis states:

=C2=A0 =C2=A0The success of the connectivity check might also cause the sta= te of
=C2=A0 =C2=A0other candidate pairs to change.=C2=A0 The ICE agent MUST set = the states
=C2=A0 =C2=A0for all other Frozen candidate pairs (in each CHECK LIST in th= e CHECK
=C2=A0 =C2=A0LIST SET) with the same foundation to Waiting.

Does that mean we'd go directly from WFFFFF to SWWWWW?

>=C2=A0 3. Check succeeds for RTCP pair. /All/ the other pairs with the = same
>=C2=A0 =C2=A0 =C2=A0foundation are now unfrozen.
>=C2=A0 =C2=A0 =C2=A0State: SSWWWW
>
> With trickle ICE, here's what could happen:
>
>=C2=A0 1. Candidates for the first media stream are trickled in.= Starts out
>=C2=A0 =C2=A0 =C2=A0just like normal ICE.
>=C2=A0 =C2=A0 =C2=A0State: WF
>=C2=A0 2. Checks for both pairs succeed. Still waiting for candi= dates for
>=C2=A0 =C2=A0 =C2=A0other media streams.
>=C2=A0 =C2=A0 =C2=A0State: SS
>=C2=A0 3. Candidates for the other media streams arrive, and pai= rs are formed.
>=C2=A0 =C2=A0 =C2=A0The topmost pair is set to waiting= , but not the others.
>=C2=A0 =C2=A0 =C2=A0State: SSWFFF

Thanks for the example.

My interpretation of Case 1 is that only the topmost pair for that
foundation is set to waiting, however you seem to interpret it to mean
the topmost pair for that media stream.

I agree that the rules in draft-ietf-ice-trickle-08 aren't quite right.=
If we accept my interpretation of the "topmost pair" rule, then I= think
the fix we need to make is to Case 3 (change "below" to "abo= ve").

In the interest of time, I'm going to submit -09 right now so that we have a document and diff to review, not just these long email messages.

Peter


> So, where normal ICE ensures that once a foundation is proven to work<= br> > (for both components of a media stream), all other pairs with that
> foundation are unfrozen, trickle ICE only guarantees that one of them = is.
>
> On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 3/30/17 11:28 PM, Taylor Brandstetter wrote:
>
>=C2=A0 =C2=A0 =C2=A0[areas of seeming agreement elided]
>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0* In section 8.1.1: In general I l= ike the improvements that have
>=C2=A0 =C2=A0 =C2=A0been
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0made. However:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0o The rules for how = a new pair gets either a "Waiting" or
>=C2=A0 =C2=A0 =C2=A0"Frozen"
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don'= ;t completely match standard ICE; at least the part
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when on= e "media stream" completes, pairs from other media
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with = matching foundations are unfrozen. With the current
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in sect= ion 8.1.1, only the topmost remaining pair in each
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is= guaranteed to be unfrozen. Is this difference
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? I= f it is, we should at least acknowledge it, and not
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wron= g impression by saying "Trickle ICE preserves all
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the stand= ard ICE] rules."
>
>=C2=A0 =C2=A0 =C2=A0Taylor, would you mind spelling this out a bit more= fully and point to
>=C2=A0 =C2=A0 =C2=A0discrepancies between the text of 5245bis and the t= ext of the Trickle
>=C2=A0 =C2=A0 =C2=A0spec? I'm sure I'm missing something, but I= don't yet see the truth of
>=C2=A0 =C2=A0 =C2=A0your statement that "only the topmost remainin= g pair in each foundation
>=C2=A0 =C2=A0 =C2=A0is guaranteed to be unfrozen".
>
>=C2=A0 =C2=A0 =C2=A0In particular, your statement doesn't seem to m= atch the rules defined in
>=C2=A0 =C2=A0 =C2=A0the Trickle spec. I've tried to spell them out = in greater detail (with
>=C2=A0 =C2=A0 =C2=A0examples) in the following proposed text.
>
>=C2=A0 =C2=A0 =C2=A0###
>
>
>=C2=A0 =C2=A0 =C2=A08.1.1.=C2=A0 Inserting a New Pair in a Check List >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Consider the following tabular representati= on of all checklists in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 agent:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |= =C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 = cp=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 cp=C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp= =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 = |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Figure 1: Example of Check List State
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Each row in the table represents a componen= t for a given media stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g., m1 and m2 might be the RTP and RTCP = components for audio).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Each column represents one foundation.=C2= =A0 Each cell represents one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate pair.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 When an agent commences ICE processing, in = accordance with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 5.1.3.6 of [rfc5245bis] it will unf= reeze (i.e., place in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Waiting state) the topmost candidate pair i= n every column (i.e., the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pair with the lowest component ID).=C2=A0 T= his state is shown in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 following table, with candidate pairs in th= e Waiting state marked by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "w-cp".
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 | w-cp | w-cp | w-cp= |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 = cp=C2=A0 |=C2=A0 cp=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp | >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 = |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Figure 2: Initial Check List State
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Then, as the checks proceed (see Section 6.= 1.2.4.2.3 of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [rfc5245bis]), for each pair that enters th= e Succeeded state (denoted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 here by "s-cp"), the agent will u= nfreeze all pairs for the same media
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 stream and foundation (e.g., if the pair in= column 1, row 1 succeeds
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 then the agent will unfreeze the pair in co= lumn 1, row 2).
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp= |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |= =C2=A0 cp=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 |=C2=A0 cp=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp | >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) |=C2=A0 cp=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 = |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3= : Check List State after Succeeded Check
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ICE also specifies that, if all the pairs i= n a media stream for one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 foundation are unfrozen (e.g., column 1, ro= ws 1 and 2 representing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 both components for the audio stream), then= all of the candidate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pairs in the entire column are unfrozen (e.= g., column 1, rows 3 and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4).
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp= |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |= =C2=A0 cp=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 4: Check= List State with Unfrozen Media Stream
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Trickle ICE preserves all of these rules as= they apply to what we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 might call "static" check list se= ts.=C2=A0 This implies that if, for some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 reason, a Trickle agent were to begin conne= ctivity checks with all of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 its pairs already present, the way that pai= r states change is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 indistinguishable from that of a regular IC= E agent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Of course, the major difference with Trickl= e ICE is that check list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sets can be dynamically updated because can= didates can arrive after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 connectivity checks have started.=C2=A0 Whe= n this happens, an agent sets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the state of the newly formed pair as descr= ibed below.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Case 1: If the newly formed pair is the top= most pair in this column,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 set the state to Waiting (e.g., this would = be the case if the newly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 formed pair were placed in column 4, row 1)= .
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp= | w-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |= =C2=A0 cp=C2=A0 | w-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 5: Check List S= tate with Newly Formed Pair, Case 1
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Case 2: If the pair immediately above the n= ewly formed pair in this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 column is in the Succeeded state, set the s= tate to Waiting (e.g.,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 this would be the case if the pair in colum= n 4, row 2 succeeded and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the newly formed pair were placed in column= 4, row 3);
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp= |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |= =C2=A0 cp=C2=A0 | s-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp | w-cp |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 6: Check List S= tate with Newly Formed Pair, Case 2
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Case 3: If there is at least one pair in th= is column below the row of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the newly formed pair whose state is either= Succeeded or Failed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g., this would be the case if the pair i= n column 4, row 2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 succeeded and the newly formed pair were pl= aced in column 4, row 1).
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |=C2= =A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m1 (Audio.RTP)=C2=A0 | s-cp | w-cp | w-cp= | w-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m2 (Audio.RTCP) | w-cp |=C2=A0 cp=C2=A0 |= =C2=A0 cp=C2=A0 | s-cp |=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m3 (Video.RTP)=C2=A0 | w-cp |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | w-cp | w-cp |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | m4 (Video.RTCP) | w-cp |=C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 cp=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+------+------+-----= -+------+------+
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 7: Check List S= tate with Newly Formed Pair, Case 3
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Case 4: In all other cases, set the state t= o Frozen.
>
>=C2=A0 =C2=A0 =C2=A0###
>
>=C2=A0 =C2=A0 =C2=A0Peter
>
>


--94eb2c1249c6e424fb054ded6654-- From nobody Mon Apr 24 11:06:39 2017 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 6F8EB131907 for ; Mon, 24 Apr 2017 11:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001, 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 kHB-KL2vp5sc for ; Mon, 24 Apr 2017 11:06:36 -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 CCFFE129418 for ; Mon, 24 Apr 2017 11:06:35 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id g60so121016057qtd.3 for ; Mon, 24 Apr 2017 11:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ul6zCtpdcD/aTU7NvkTENYrUyXkHJqIX/RagLDZh10s=; b=OxldkJFXYxpVMmSvQlLtwmlg0YbhftBsB76EuZSJjYF/nD8U2pBXLCTjxPt7+NBSMx MtKhoXjMwUZCQyWMDNXAz7wnWZLv1zXmq062Pyr3Guf7cBVR0tXevYMScmU2V5W4C08/ 6dQ4vyxPLCvKunUJ3VZyST+OsZQFO+G0QUxN9ncgU6KrsI8jDBb2/9j4kajk4DWGXBXS lu8FavybxB3vFXS1j5VAlu1h9nnCcNFHYoTRilBYW9ysCIQX1j7cRu/9sdgRy1s+AxTC W1H5GylTt/rpYmGoc0AYhDuPVIKEmRGUWsCh8dcn4y027+wYFE8d+ip7w6X1V+i2MelN TThA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ul6zCtpdcD/aTU7NvkTENYrUyXkHJqIX/RagLDZh10s=; b=lXvPOFJmw0cdTxhPgkEu/VNrFA4Cm/KKkfhouyGiBOLyD75XIWVL9rqdfVJMquNxbB JqEaQa96DfXWEAiHYWfaYSQLST5GHUGs7X94KDjYatQMRh7h70jKZJJi7eQx6L9+txth qQu0bBEMyAd4JM4y/BVx8pdTqVx1AL30n7PgdhlTsJd+p823ZS+Gzv1cLk38RAvOrkyt SScjdakjY7NwVEQbfFbw6P9fDyP8EWabZ2y4ic4teZso7lAClGKcJU/bKV1bFsKWM4ej saMKejbiYWCIQvVaVZ7qQg9Zjj73IZI9cgcyz060rekRVV5jTOprJhAS3s6+ySM/wyNH Nquw== X-Gm-Message-State: AN3rC/4NkreiMJgnCmBgEHpOJbPGDHovdW6qMiC9axDAn83j35h2SrmN S9WuEVSdHIsbh9ZJ/FRdRr3Cf2bC4qfw X-Received: by 10.237.44.162 with SMTP id g31mr25439792qtd.43.1493057194723; Mon, 24 Apr 2017 11:06:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Mon, 24 Apr 2017 11:06:34 -0700 (PDT) In-Reply-To: <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> From: Taylor Brandstetter Date: Mon, 24 Apr 2017 11:06:34 -0700 Message-ID: To: Peter Saint-Andre Cc: Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1249c6b8e1ff054ded7796 Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:06:37 -0000 --94eb2c1249c6b8e1ff054ded7796 Content-Type: text/plain; charset=UTF-8 > > Although this makes me wonder how to handle the situation where all > m-sections have the ice-options, but one indicates support for trickle and > another does not. I believe this is exactly what brought up the issue. My suggestion is to just make this illegal and interpret it as invalid SDP. --94eb2c1249c6b8e1ff054ded7796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although this makes me wonder how to handle the si= tuation where all m-sections have the ice-options, but one indicates suppor= t for trickle and another does not.

= I believe this is exactly what brought up the issue. My suggestion is to ju= st make this illegal and interpret it as invalid SDP.
--94eb2c1249c6b8e1ff054ded7796-- From nobody Mon Apr 24 11:20:14 2017 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 E15D2131909 for ; Mon, 24 Apr 2017 11:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 2dmPS3oW5toX for ; Mon, 24 Apr 2017 11:20:11 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A09131901 for ; Mon, 24 Apr 2017 11:20:11 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id 194so16051928pfv.3 for ; Mon, 24 Apr 2017 11:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EN5NJbW44MdfPW0LLkEf/I/Ynxvw+iTmEqAmmQoUxQI=; b=MoR1wzi73s4G1uP6Q7y3My6ig5kwo8vjxACT08YBXkEO625/kSVsuvRT3UrRaU7DKn v5nkVYImNtpvgtGcJ6dQ9gFmfzKotxgc+UMHsNo4+sg7eLxCbTSLxi0Y97HjifOLC7Je 1pPSnGl8FLTDMK+8DeoiJv+oHwb+r6Ds+y6gE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EN5NJbW44MdfPW0LLkEf/I/Ynxvw+iTmEqAmmQoUxQI=; b=E0OJb63DTIL+5FxyLGO/adUiPiL9yGZSjUmV28VQgwYGtCXmozPgIYnfTAd3+3uFlB V/C2sR1GPXqyWuN+2EzGAp6vNv7wxXP589QsQdhLy3c3yqVnOh1c4GgbkBkjsbDtai+C kY4fwckqKZ3sPT4soo9PneLxGYoKIhk6JwK+hyrRVjlmbBVq5cs8yqDYN74Oj1+X/Sen sBHaYjwBGJlCfUF8ZOwuERvMoFdXMD7AltCVvGtzlHrWS/4j7HAVN6SiBdkWwN/AXBl7 FIwDJgBeYavCQo69aI8lWLCf2+VeDEOuBT4osiu0Xie1mnFZaSE+B/WWr8UyeI9S6nc3 /MsQ== X-Gm-Message-State: AN3rC/7t1EElGNXRK6DE/2nGkFois3lO47N3I0KtSAiar++8Wi2zfUru PhlzEaokxf3tuY5R X-Received: by 10.99.123.7 with SMTP id w7mr12315452pgc.82.1493058010620; Mon, 24 Apr 2017 11:20:10 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:3122:e88f:1459:8313? ([2620:101:80fc:224:3122:e88f:1459:8313]) by smtp.gmail.com with ESMTPSA id p28sm32203462pfd.53.2017.04.24.11.20.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 11:20:09 -0700 (PDT) From: Nils Ohlmeier Message-Id: <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D9998704-F3C8-4CB8-9E99-886E3056608F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 11:20:06 -0700 In-Reply-To: Cc: Peter Saint-Andre , "ice@ietf.org" To: Taylor Brandstetter References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:20:13 -0000 --Apple-Mail=_D9998704-F3C8-4CB8-9E99-886E3056608F Content-Type: multipart/alternative; boundary="Apple-Mail=_C9AA7896-1F9D-4D26-925B-1F13DA3AD5C8" --Apple-Mail=_C9AA7896-1F9D-4D26-925B-1F13DA3AD5C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 24, 2017, at 11:06, Taylor Brandstetter = wrote: >=20 > Although this makes me wonder how to handle the situation where all = m-sections have the ice-options, but one indicates support for trickle = and another does not. >=20 > I believe this is exactly what brought up the issue. My suggestion is = to just make this illegal and interpret it as invalid SDP. I=E2=80=99m fine with that. But then I would think it should say MUST = NOT like Peter suggested to make it explicit. Probably I=E2=80=99m missing a point here, but if the trickle = ice-options need to be identical across all m-sections what is the = difference to a session level attribute then (except that a receiver = would need to check for consistency of all attributes and reject)? Is the reason only that ice-options in general are allowed in m-sections = and we can=E2=80=99t mandate the trickle option only to be used at the = session level ice-options? Best Nils Ohlmeier --Apple-Mail=_C9AA7896-1F9D-4D26-925B-1F13DA3AD5C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 24, 2017, at 11:06, Taylor Brandstetter <deadbeef@google.com>= wrote:

Although this makes me wonder how to handle the situation = where all m-sections have the ice-options, but one indicates support for = trickle and another does not.

I believe this is exactly what brought = up the issue. My suggestion is to just make this illegal and interpret = it as invalid SDP.

I=E2=80=99m fine = with that. But then I would think it should say MUST NOT like Peter = suggested to make it explicit.

Probably I=E2=80=99m missing a point = here, but if the trickle ice-options need to be identical across all = m-sections what is the difference to a session level attribute then = (except that a receiver would need to check for consistency of all = attributes and reject)?
Is the reason only that = ice-options in general are allowed in m-sections and we can=E2=80=99t = mandate the trickle option only to be used at the session level = ice-options?

Best
  Nils = Ohlmeier
= --Apple-Mail=_C9AA7896-1F9D-4D26-925B-1F13DA3AD5C8-- --Apple-Mail=_D9998704-F3C8-4CB8-9E99-886E3056608F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/kHWAAoJEJ3NnGfOORkkK6kP/1gXQ9hUvAgPLk8MPdVaPUVM JqESVctKiPEt3/C3L7JOlCYtMCE4K14RAUrK5X8ItlspB+D/EvOpTYC9ehMYme4y 0kHjwCAyV3qppbG06VFc1bhSGoyBMYyrjq5QAOHw8UTTmsGbib3mU6u1MJhchp8S zwgW6o89HlfYpQXycj6loD1ZrqKKbRgPHOTTngg9VTbDTOamhjvAnMkVPieGXvFW f2xUympw935XaYBV/AqUm4emCAITpCK/XEQPsxAFOB0vGZjS/FtyYqE917jwNcTt 7GIQ7Ufeg98QccagPMuL8dA2UAJA/Ksb018aoY0iWSw9a7G5a5x5rzTAeL16C9CW T/TosAjFyFyYlff2UxkZktDyPCNHxZz9Fm2o6tY/gdxTkGHXJllpHttTDByQPppU 4tvM0rlqio7ZdacCaRT1dFB2Ik7BqyC4L7kkYDfGnL3n/Sln6s19f2tMI6Nbr0Fd Z5o+5WDKSC8mol/cyGaFCCFt2hhw07msAWw+xaRI/M1U9taujq5tIrXU34Uf8gSy MYdgY3EToE7exY7wR9X2o8s32ayTm/vwVGrsx72wK9jwJPNtj8DwgbU9ooJm1y58 Runw4FtKstYL1CN3GlZo/29FcLG7J/Zw0MWZoizcZXubqfZ6Vrhp2Xv8DSmu+1cc WAjLV3TYRd1W5ZqUCtYl =btjz -----END PGP SIGNATURE----- --Apple-Mail=_D9998704-F3C8-4CB8-9E99-886E3056608F-- From nobody Mon Apr 24 11:30:21 2017 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 7A44613192B for ; Mon, 24 Apr 2017 11:30:19 -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 XRnpGcoC9iJB for ; Mon, 24 Apr 2017 11:30:16 -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 49D3C131927 for ; Mon, 24 Apr 2017 11:30:15 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-5d-58fe443523ee Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id D7.88.20220.5344EF85; Mon, 24 Apr 2017 20:30:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Mon, 24 Apr 2017 20:29:57 +0200 From: Christer Holmberg To: Taylor Brandstetter , Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt Thread-Index: AQHSqd+v5pTH7eT1WEqm0CcDG080LaHKbvUAgAF4q4CAB5xggIABUGyAgAApAUA= Date: Mon, 24 Apr 2017 18:29:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB82DFE@ESESSMB109.ericsson.se> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB82DFEESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7uq6py78Ig0sPxC0ur3jIavHtQq3F sT39zA7MHgs2lXosWfKTyWPunhfMAcxRXDYpqTmZZalF+nYJXBlthx+zF/w6xVxx/vUbtgbG lv3MXYycHBICJhKvz/QC2VwcQgLrGSXWf/3CBOEsYZQ4dvUJaxcjBwebgIVE9z9tEFNEIFzi /NocEJNZQFHi5V41kDHCAs4Sf298ZQexRQRcJNb3/maBsP0kji06xgRiswioSryftAkszivg K3F1xzowW0jgGJNEf28uiM0pEChxrOMWG4jNKCAm8f3UGrBeZgFxiVtP5jNBnCwgsWTPeajz RSVePv7HCmErSazYfokRoj5f4nbvAWaIXYISJ2c+YZnAKDILyahZSMpmISmbBfaZpsT6XfoQ JYoSU7ofskPYGhKtc+ayI4svYGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYZQe3/Fbd wXj5jeMhRgEORiUe3gcs/yKEWBPLiitzDzFKcDArifBeAgnxpiRWVqUW5ccXleakFh9ilOZg URLnddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAqH3/q9L8m5ofLpxb1e58/MAO4/1Bj5afE3qw +kaxh+z8LBFup6k5nyNj+KTv6GR7X50V5hEQPOXwE6V8O1GGqZa3tgoadujd21jyab6Et9up 2+rStx01JN2OPsltvxDRlyt7adsXe+dJoaUK5k03D8ybrLtrolmKYdCU8rqaRWVzpXY86J3M pMRSnJFoqMVcVJwIABAyukOuAgAA Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:30:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB82DFEESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluaXRpYWxseSwgYmVmb3JlIHRoZSBjaGVja3MgYmVnaW4sIG9ubHkgdGhlIHRvcG1v c3QgcGFpciBmb3IgZWFjaCBmb3VuZGF0aW9uIGlzIHNldCB0byB3YWl0aW5nLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBJY2UgW21haWx0bzppY2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFRheWxvciBCcmFuZHN0ZXR0ZXINClNlbnQ6IDI0IEFwcmlsIDIwMTcgMjA6 MDINClRvOiBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPg0KQ2M6IGljZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJY2VdIFRheWxvcidzIHJldmlldyBvZiBkcmFmdC1pZXRm LWljZS10cmlja2xlLTA4LnR4dA0KDQpEb2VzIHRoYXQgbWVhbiB3ZSdkIGdvIGRpcmVjdGx5IGZy b20gV0ZGRkZGIHRvIFNXV1dXVz8NCg0KWWVzOyB3aGVuIEkgd2FzIHR5cGluZyB1cCB0aGUgZXhh bXBsZSBJIGhhZG4ndCBub3RpY2VkIHRoYXQgdGhlICJlYWNoIGNvbXBvbmVudCBvZiB0aGUgbWVk aWEgc3RyZWFtIiBwYXJ0IGhhZCBiZWVuIHJlbW92ZWQgZnJvbSA1MjQ1YmlzLg0KDQpNeSBpbnRl cnByZXRhdGlvbiBvZiBDYXNlIDEgaXMgdGhhdCBvbmx5IHRoZSB0b3Btb3N0IHBhaXIgZm9yIHRo YXQNCmZvdW5kYXRpb24gaXMgc2V0IHRvIHdhaXRpbmcsIGhvd2V2ZXIgeW91IHNlZW0gdG8gaW50 ZXJwcmV0IGl0IHRvIG1lYW4NCnRoZSB0b3Btb3N0IHBhaXIgZm9yIHRoYXQgbWVkaWEgc3RyZWFt Lg0KDQpObywgSSBhbHNvIGludGVycHJldCBpdCBhcyAidG9wbW9zdCBmb3IgZm91bmRhdGlvbiIu DQoNCiBJIHRoaW5rIHRoZSBmaXggd2UgbmVlZCB0byBtYWtlIGlzIHRvIENhc2UgMyAoY2hhbmdl ICJiZWxvdyIgdG8gImFib3ZlIikuDQoNCkkgdGhpbmsgeW91IGNvdWxkIG1lcmdlIGNhc2VzIDIg YW5kIDMgYW5kIG1ha2UgaXQgImFub3RoZXIgcGFpciBpbiB0aGUgc2FtZSBjb2x1bW4gaXMgaW4g dGhlIFN1Y2NlZWRlZCBzdGF0ZS4iDQoNCk9uIFN1biwgQXByIDIzLCAyMDE3IGF0IDI6NTcgUE0s IFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW08bWFpbHRvOnN0cGV0ZXJAc3Rw ZXRlci5pbT4+IHdyb3RlOg0KT24gNC8xOC8xNyA3OjQ0IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVy IHdyb3RlOg0KPiAgICAgVGF5bG9yLCB3b3VsZCB5b3UgbWluZCBzcGVsbGluZyB0aGlzIG91dCBh IGJpdCBtb3JlIGZ1bGx5IGFuZCBwb2ludCB0bw0KPiAgICAgZGlzY3JlcGFuY2llcyBiZXR3ZWVu IHRoZSB0ZXh0IG9mIDUyNDViaXMgYW5kIHRoZSB0ZXh0IG9mIHRoZSBUcmlja2xlDQo+ICAgICBz cGVjPyBJJ20gc3VyZSBJJ20gbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBJIGRvbid0IHlldCBzZWUg dGhlIHRydXRoIG9mDQo+ICAgICB5b3VyIHN0YXRlbWVudCB0aGF0ICJvbmx5IHRoZSB0b3Btb3N0 IHJlbWFpbmluZyBwYWlyIGluIGVhY2ggZm91bmRhdGlvbg0KPiAgICAgaXMgZ3VhcmFudGVlZCB0 byBiZSB1bmZyb3plbiIuDQo+DQo+DQo+IFN1cmU7IGxldCBtZSB0cnkgdG8gZ2l2ZSBhbiBleGFt cGxlLg0KPg0KPiBTdXBwb3NlIEkgaGF2ZSB0aHJlZSBtZWRpYSBzdHJlYW1zLCBhbmQgb25lIGZv dW5kYXRpb24gKGxldCdzIGtlZXAgaXQNCj4gc2ltcGxlKS4gSSdsbCByZXByZXNlbnQgdGhlIHN0 YXRlcyBsaWtlIHRoaXMgZm9yIGJyZXZpdHk6ICJTV0ZGRkYiLA0KPiB3aGVyZSAiUyIgaXMgInN1 Y2NlZWRlZCIsICJXIiBpcyAid2FpdGluZyIsIGFuZCAiRiIgaXMgImZyb3plbiIuIEFuZA0KPiB0 aGV5J3JlIG9yZGVyZWQgaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSByb3dzIGluIHlvdXIgdGFibGUg YWJvdmUuDQo+DQo+IFdpdGggbm9uLXRyaWNrbGUgSUNFLCBoZXJlJ3Mgd2hhdCB3b3VsZCB0eXBp Y2FsbHkgaGFwcGVuOg0KPg0KPiAgMS4gT25seSB0aGUgUlRQIGNhbmRpZGF0ZSBwYWlyIGZvciB0 aGUgZmlyc3QgbWVkaWEgc3RyZWFtIGlzIHVuZnJvemVuDQo+ICAgICBpbml0aWFsbHkuDQo+ICAg ICBTdGF0ZTogV0ZGRkZGDQo+ICAyLiBDaGVjayBzdWNjZWVkcyBmb3IgUlRQIGNhbmRpZGF0ZSBw YWlyLiBSVENQIHBhaXIgdW5mcm96ZW4uDQo+ICAgICBTdGF0ZTogU1dGRkZGDQoNClNlY3Rpb24g Ni4yLjUuMy4zIG9mIDUyNDViaXMgc3RhdGVzOg0KDQogICBUaGUgc3VjY2VzcyBvZiB0aGUgY29u bmVjdGl2aXR5IGNoZWNrIG1pZ2h0IGFsc28gY2F1c2UgdGhlIHN0YXRlIG9mDQogICBvdGhlciBj YW5kaWRhdGUgcGFpcnMgdG8gY2hhbmdlLiAgVGhlIElDRSBhZ2VudCBNVVNUIHNldCB0aGUgc3Rh dGVzDQogICBmb3IgYWxsIG90aGVyIEZyb3plbiBjYW5kaWRhdGUgcGFpcnMgKGluIGVhY2ggQ0hF Q0sgTElTVCBpbiB0aGUgQ0hFQ0sNCiAgIExJU1QgU0VUKSB3aXRoIHRoZSBzYW1lIGZvdW5kYXRp b24gdG8gV2FpdGluZy4NCg0KRG9lcyB0aGF0IG1lYW4gd2UnZCBnbyBkaXJlY3RseSBmcm9tIFdG RkZGRiB0byBTV1dXV1c/DQoNCj4gIDMuIENoZWNrIHN1Y2NlZWRzIGZvciBSVENQIHBhaXIuIC9B bGwvIHRoZSBvdGhlciBwYWlycyB3aXRoIHRoZSBzYW1lDQo+ICAgICBmb3VuZGF0aW9uIGFyZSBu b3cgdW5mcm96ZW4uDQo+ICAgICBTdGF0ZTogU1NXV1dXDQo+DQo+IFdpdGggdHJpY2tsZSBJQ0Us IGhlcmUncyB3aGF0IGNvdWxkIGhhcHBlbjoNCj4NCj4gIDEuIENhbmRpZGF0ZXMgZm9yIHRoZSBm aXJzdCBtZWRpYSBzdHJlYW0gYXJlIHRyaWNrbGVkIGluLiBTdGFydHMgb3V0DQo+ICAgICBqdXN0 IGxpa2Ugbm9ybWFsIElDRS4NCj4gICAgIFN0YXRlOiBXRg0KPiAgMi4gQ2hlY2tzIGZvciBib3Ro IHBhaXJzIHN1Y2NlZWQuIFN0aWxsIHdhaXRpbmcgZm9yIGNhbmRpZGF0ZXMgZm9yDQo+ICAgICBv dGhlciBtZWRpYSBzdHJlYW1zLg0KPiAgICAgU3RhdGU6IFNTDQo+ICAzLiBDYW5kaWRhdGVzIGZv ciB0aGUgb3RoZXIgbWVkaWEgc3RyZWFtcyBhcnJpdmUsIGFuZCBwYWlycyBhcmUgZm9ybWVkLg0K PiAgICAgVGhlIHRvcG1vc3QgcGFpciBpcyBzZXQgdG8gd2FpdGluZywgYnV0IG5vdCB0aGUgb3Ro ZXJzLg0KPiAgICAgU3RhdGU6IFNTV0ZGRg0KDQpUaGFua3MgZm9yIHRoZSBleGFtcGxlLg0KDQpN eSBpbnRlcnByZXRhdGlvbiBvZiBDYXNlIDEgaXMgdGhhdCBvbmx5IHRoZSB0b3Btb3N0IHBhaXIg Zm9yIHRoYXQNCmZvdW5kYXRpb24gaXMgc2V0IHRvIHdhaXRpbmcsIGhvd2V2ZXIgeW91IHNlZW0g dG8gaW50ZXJwcmV0IGl0IHRvIG1lYW4NCnRoZSB0b3Btb3N0IHBhaXIgZm9yIHRoYXQgbWVkaWEg c3RyZWFtLg0KDQpJIGFncmVlIHRoYXQgdGhlIHJ1bGVzIGluIGRyYWZ0LWlldGYtaWNlLXRyaWNr bGUtMDggYXJlbid0IHF1aXRlIHJpZ2h0Lg0KSWYgd2UgYWNjZXB0IG15IGludGVycHJldGF0aW9u IG9mIHRoZSAidG9wbW9zdCBwYWlyIiBydWxlLCB0aGVuIEkgdGhpbmsNCnRoZSBmaXggd2UgbmVl ZCB0byBtYWtlIGlzIHRvIENhc2UgMyAoY2hhbmdlICJiZWxvdyIgdG8gImFib3ZlIikuDQoNCklu IHRoZSBpbnRlcmVzdCBvZiB0aW1lLCBJJ20gZ29pbmcgdG8gc3VibWl0IC0wOSByaWdodCBub3cg c28gdGhhdCB3ZQ0KaGF2ZSBhIGRvY3VtZW50IGFuZCBkaWZmIHRvIHJldmlldywgbm90IGp1c3Qg dGhlc2UgbG9uZyBlbWFpbCBtZXNzYWdlcy4NCg0KUGV0ZXINCg0KDQo+IFNvLCB3aGVyZSBub3Jt YWwgSUNFIGVuc3VyZXMgdGhhdCBvbmNlIGEgZm91bmRhdGlvbiBpcyBwcm92ZW4gdG8gd29yaw0K PiAoZm9yIGJvdGggY29tcG9uZW50cyBvZiBhIG1lZGlhIHN0cmVhbSksIGFsbCBvdGhlciBwYWly cyB3aXRoIHRoYXQNCj4gZm91bmRhdGlvbiBhcmUgdW5mcm96ZW4sIHRyaWNrbGUgSUNFIG9ubHkg Z3VhcmFudGVlcyB0aGF0IG9uZSBvZiB0aGVtIGlzLg0KPg0KPiBPbiBNb24sIEFwciAxNywgMjAx NyBhdCA4OjE2IFBNLCBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPG1haWx0 bzpzdHBldGVyQHN0cGV0ZXIuaW0+DQo+IDxtYWlsdG86c3RwZXRlckBzdHBldGVyLmltPG1haWx0 bzpzdHBldGVyQHN0cGV0ZXIuaW0+Pj4gd3JvdGU6DQo+DQo+ICAgICBPbiAzLzMwLzE3IDExOjI4 IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIHdyb3RlOg0KPg0KPiAgICAgW2FyZWFzIG9mIHNlZW1p bmcgYWdyZWVtZW50IGVsaWRlZF0NCj4NCj4gICAgID4gICAqIEluIHNlY3Rpb24gOC4xLjE6IElu IGdlbmVyYWwgSSBsaWtlIHRoZSBpbXByb3ZlbWVudHMgdGhhdCBoYXZlDQo+ICAgICBiZWVuDQo+ ICAgICA+ICAgICBtYWRlLiBIb3dldmVyOg0KPiAgICAgPiAgICAgICBvIFRoZSBydWxlcyBmb3Ig aG93IGEgbmV3IHBhaXIgZ2V0cyBlaXRoZXIgYSAiV2FpdGluZyIgb3INCj4gICAgICJGcm96ZW4i DQo+ICAgICA+ICAgICAgICAgc3RhdGUgZG9uJ3QgY29tcGxldGVseSBtYXRjaCBzdGFuZGFyZCBJ Q0U7IGF0IGxlYXN0IHRoZSBwYXJ0DQo+ICAgICA+ICAgICAgICAgd2hlcmUgd2hlbiBvbmUgIm1l ZGlhIHN0cmVhbSIgY29tcGxldGVzLCBwYWlycyBmcm9tIG90aGVyIG1lZGlhDQo+ICAgICA+ICAg ICAgICAgc3RyZWFtcyB3aXRoIG1hdGNoaW5nIGZvdW5kYXRpb25zIGFyZSB1bmZyb3plbi4gV2l0 aCB0aGUgY3VycmVudA0KPiAgICAgPiAgICAgICAgIHJ1bGVzIGluIHNlY3Rpb24gOC4xLjEsIG9u bHkgdGhlIHRvcG1vc3QgcmVtYWluaW5nIHBhaXIgaW4gZWFjaA0KPiAgICAgPiAgICAgICAgIGZv dW5kYXRpb24gaXMgZ3VhcmFudGVlZCB0byBiZSB1bmZyb3plbi4gSXMgdGhpcyBkaWZmZXJlbmNl DQo+ICAgICA+ICAgICAgICAgYWNjZXB0YWJsZT8gSWYgaXQgaXMsIHdlIHNob3VsZCBhdCBsZWFz dCBhY2tub3dsZWRnZSBpdCwgYW5kIG5vdA0KPiAgICAgPiAgICAgICAgIGdpdmUgdGhlIHdyb25n IGltcHJlc3Npb24gYnkgc2F5aW5nICJUcmlja2xlIElDRSBwcmVzZXJ2ZXMgYWxsDQo+ICAgICA+ ICAgICAgICAgb2YgW3RoZSBzdGFuZGFyZCBJQ0VdIHJ1bGVzLiINCj4NCj4gICAgIFRheWxvciwg d291bGQgeW91IG1pbmQgc3BlbGxpbmcgdGhpcyBvdXQgYSBiaXQgbW9yZSBmdWxseSBhbmQgcG9p bnQgdG8NCj4gICAgIGRpc2NyZXBhbmNpZXMgYmV0d2VlbiB0aGUgdGV4dCBvZiA1MjQ1YmlzIGFu ZCB0aGUgdGV4dCBvZiB0aGUgVHJpY2tsZQ0KPiAgICAgc3BlYz8gSSdtIHN1cmUgSSdtIG1pc3Np bmcgc29tZXRoaW5nLCBidXQgSSBkb24ndCB5ZXQgc2VlIHRoZSB0cnV0aCBvZg0KPiAgICAgeW91 ciBzdGF0ZW1lbnQgdGhhdCAib25seSB0aGUgdG9wbW9zdCByZW1haW5pbmcgcGFpciBpbiBlYWNo IGZvdW5kYXRpb24NCj4gICAgIGlzIGd1YXJhbnRlZWQgdG8gYmUgdW5mcm96ZW4iLg0KPg0KPiAg ICAgSW4gcGFydGljdWxhciwgeW91ciBzdGF0ZW1lbnQgZG9lc24ndCBzZWVtIHRvIG1hdGNoIHRo ZSBydWxlcyBkZWZpbmVkIGluDQo+ICAgICB0aGUgVHJpY2tsZSBzcGVjLiBJJ3ZlIHRyaWVkIHRv IHNwZWxsIHRoZW0gb3V0IGluIGdyZWF0ZXIgZGV0YWlsICh3aXRoDQo+ICAgICBleGFtcGxlcykg aW4gdGhlIGZvbGxvd2luZyBwcm9wb3NlZCB0ZXh0Lg0KPg0KPiAgICAgIyMjDQo+DQo+DQo+ICAg ICA4LjEuMS4gIEluc2VydGluZyBhIE5ldyBQYWlyIGluIGEgQ2hlY2sgTGlzdA0KPg0KPiAgICAg ICAgQ29uc2lkZXIgdGhlIGZvbGxvd2luZyB0YWJ1bGFyIHJlcHJlc2VudGF0aW9uIG9mIGFsbCBj aGVja2xpc3RzIGluIGFuDQo+ICAgICAgICBhZ2VudDoNCj4NCj4NCj4gICAgICAgICstLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPiAgICAgICAg fCAgICAgICAgICAgICAgICAgfCAgZjEgIHwgIGYyICB8ICBmMyAgfCAgZjQgIHwgIGY1ICB8DQo+ ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0t LS0tLSsNCj4gICAgICAgIHwgbTEgKEF1ZGlvLlJUUCkgIHwgIGNwICB8ICBjcCAgfCAgY3AgIHwg ICAgICB8ICAgICAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0r LS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAgICB8IG0yIChBdWRpby5SVENQKSB8ICBjcCAg fCAgY3AgIHwgIGNwICB8ICBjcCAgfCAgICAgIHwNCj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPiAgICAgICAgfCBtMyAoVmlk ZW8uUlRQKSAgfCAgY3AgIHwgICAgICB8ICAgICAgfCAgICAgIHwgIGNwICB8DQo+ICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4g ICAgICAgIHwgbTQgKFZpZGVvLlJUQ1ApIHwgIGNwICB8ICAgICAgfCAgICAgIHwgICAgICB8ICBj cCAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0t LS0tLSstLS0tLS0rDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IEV4 YW1wbGUgb2YgQ2hlY2sgTGlzdCBTdGF0ZQ0KPg0KPiAgICAgICAgRWFjaCByb3cgaW4gdGhlIHRh YmxlIHJlcHJlc2VudHMgYSBjb21wb25lbnQgZm9yIGEgZ2l2ZW4gbWVkaWEgc3RyZWFtDQo+ICAg ICAgICAoZS5nLiwgbTEgYW5kIG0yIG1pZ2h0IGJlIHRoZSBSVFAgYW5kIFJUQ1AgY29tcG9uZW50 cyBmb3IgYXVkaW8pLg0KPiAgICAgICAgRWFjaCBjb2x1bW4gcmVwcmVzZW50cyBvbmUgZm91bmRh dGlvbi4gIEVhY2ggY2VsbCByZXByZXNlbnRzIG9uZQ0KPiAgICAgICAgY2FuZGlkYXRlIHBhaXIu DQo+DQo+ICAgICAgICBXaGVuIGFuIGFnZW50IGNvbW1lbmNlcyBJQ0UgcHJvY2Vzc2luZywgaW4g YWNjb3JkYW5jZSB3aXRoDQo+ICAgICAgICBTZWN0aW9uIDUuMS4zLjYgb2YgW3JmYzUyNDViaXNd IGl0IHdpbGwgdW5mcmVlemUgKGkuZS4sIHBsYWNlIGluIHRoZQ0KPiAgICAgICAgV2FpdGluZyBz dGF0ZSkgdGhlIHRvcG1vc3QgY2FuZGlkYXRlIHBhaXIgaW4gZXZlcnkgY29sdW1uIChpLmUuLCB0 aGUNCj4gICAgICAgIHBhaXIgd2l0aCB0aGUgbG93ZXN0IGNvbXBvbmVudCBJRCkuICBUaGlzIHN0 YXRlIGlzIHNob3duIGluIHRoZQ0KPiAgICAgICAgZm9sbG93aW5nIHRhYmxlLCB3aXRoIGNhbmRp ZGF0ZSBwYWlycyBpbiB0aGUgV2FpdGluZyBzdGF0ZSBtYXJrZWQgYnkNCj4gICAgICAgICJ3LWNw Ii4NCj4NCj4NCj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0t LSstLS0tLS0rLS0tLS0tKw0KPiAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgZjEgIHwgIGYy ICB8ICBmMyAgfCAgZjQgIHwgIGY1ICB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTEgKEF1ZGlvLlJU UCkgIHwgdy1jcCB8IHctY3AgfCB3LWNwIHwgICAgICB8ICAgICAgfA0KPiAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAg ICB8IG0yIChBdWRpby5SVENQKSB8ICBjcCAgfCAgY3AgIHwgIGNwICB8IHctY3AgfCAgICAgIHwN Cj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0r LS0tLS0tKw0KPiAgICAgICAgfCBtMyAoVmlkZW8uUlRQKSAgfCAgY3AgIHwgICAgICB8ICAgICAg fCAgICAgIHwgdy1jcCB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0t LSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTQgKFZpZGVvLlJUQ1ApIHwgIGNw ICB8ICAgICAgfCAgICAgIHwgICAgICB8ICBjcCAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+DQo+DQo+ICAgICAgICAg ICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBJbml0aWFsIENoZWNrIExpc3QgU3RhdGUNCj4NCj4g ICAgICAgIFRoZW4sIGFzIHRoZSBjaGVja3MgcHJvY2VlZCAoc2VlIFNlY3Rpb24gNi4xLjIuNC4y LjMgb2YNCj4gICAgICAgIFtyZmM1MjQ1YmlzXSksIGZvciBlYWNoIHBhaXIgdGhhdCBlbnRlcnMg dGhlIFN1Y2NlZWRlZCBzdGF0ZSAoZGVub3RlZA0KPiAgICAgICAgaGVyZSBieSAicy1jcCIpLCB0 aGUgYWdlbnQgd2lsbCB1bmZyZWV6ZSBhbGwgcGFpcnMgZm9yIHRoZSBzYW1lIG1lZGlhDQo+ICAg ICAgICBzdHJlYW0gYW5kIGZvdW5kYXRpb24gKGUuZy4sIGlmIHRoZSBwYWlyIGluIGNvbHVtbiAx LCByb3cgMSBzdWNjZWVkcw0KPiAgICAgICAgdGhlbiB0aGUgYWdlbnQgd2lsbCB1bmZyZWV6ZSB0 aGUgcGFpciBpbiBjb2x1bW4gMSwgcm93IDIpLg0KPg0KPg0KPiAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAgICB8ICAg ICAgICAgICAgICAgICB8ICBmMSAgfCAgZjIgIHwgIGYzICB8ICBmNCAgfCAgZjUgIHwNCj4gICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Kw0KPiAgICAgICAgfCBtMSAoQXVkaW8uUlRQKSAgfCBzLWNwIHwgdy1jcCB8IHctY3AgfCAgICAg IHwgICAgICB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTIgKEF1ZGlvLlJUQ1ApIHwgdy1jcCB8ICBj cCAgfCAgY3AgIHwgdy1jcCB8ICAgICAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAgICB8IG0zIChWaWRlby5S VFApICB8ICBjcCAgfCAgICAgIHwgICAgICB8ICAgICAgfCB3LWNwIHwNCj4gICAgICAgICstLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPiAgICAg ICAgfCBtNCAoVmlkZW8uUlRDUCkgfCAgY3AgIHwgICAgICB8ICAgICAgfCAgICAgIHwgIGNwICB8 DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Ky0tLS0tLSsNCj4NCj4NCj4gICAgICAgICAgICAgICAgICBGaWd1cmUgMzogQ2hlY2sgTGlzdCBT dGF0ZSBhZnRlciBTdWNjZWVkZWQgQ2hlY2sNCj4NCj4gICAgICAgIElDRSBhbHNvIHNwZWNpZmll cyB0aGF0LCBpZiBhbGwgdGhlIHBhaXJzIGluIGEgbWVkaWEgc3RyZWFtIGZvciBvbmUNCj4gICAg ICAgIGZvdW5kYXRpb24gYXJlIHVuZnJvemVuIChlLmcuLCBjb2x1bW4gMSwgcm93cyAxIGFuZCAy IHJlcHJlc2VudGluZw0KPiAgICAgICAgYm90aCBjb21wb25lbnRzIGZvciB0aGUgYXVkaW8gc3Ry ZWFtKSwgdGhlbiBhbGwgb2YgdGhlIGNhbmRpZGF0ZQ0KPiAgICAgICAgcGFpcnMgaW4gdGhlIGVu dGlyZSBjb2x1bW4gYXJlIHVuZnJvemVuIChlLmcuLCBjb2x1bW4gMSwgcm93cyAzIGFuZA0KPiAg ICAgICAgNCkuDQo+DQo+DQo+DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0t LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgICAgICAgICAgICAgICAgIHwg IGYxICB8ICBmMiAgfCAgZjMgIHwgIGY0ICB8ICBmNSAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAgICB8IG0x IChBdWRpby5SVFApICB8IHMtY3AgfCB3LWNwIHwgdy1jcCB8ICAgICAgfCAgICAgIHwNCj4gICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Kw0KPiAgICAgICAgfCBtMiAoQXVkaW8uUlRDUCkgfCB3LWNwIHwgIGNwICB8ICBjcCAgfCB3LWNw IHwgICAgICB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTMgKFZpZGVvLlJUUCkgIHwgdy1jcCB8ICAg ICAgfCAgICAgIHwgICAgICB8IHctY3AgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAgICB8IG00IChWaWRlby5S VENQKSB8IHctY3AgfCAgICAgIHwgICAgICB8ICAgICAgfCAgY3AgIHwNCj4gICAgICAgICstLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPg0KPg0K PiAgICAgICAgICAgICAgICBGaWd1cmUgNDogQ2hlY2sgTGlzdCBTdGF0ZSB3aXRoIFVuZnJvemVu IE1lZGlhIFN0cmVhbQ0KPg0KPiAgICAgICAgVHJpY2tsZSBJQ0UgcHJlc2VydmVzIGFsbCBvZiB0 aGVzZSBydWxlcyBhcyB0aGV5IGFwcGx5IHRvIHdoYXQgd2UNCj4gICAgICAgIG1pZ2h0IGNhbGwg InN0YXRpYyIgY2hlY2sgbGlzdCBzZXRzLiAgVGhpcyBpbXBsaWVzIHRoYXQgaWYsIGZvciBzb21l DQo+ICAgICAgICByZWFzb24sIGEgVHJpY2tsZSBhZ2VudCB3ZXJlIHRvIGJlZ2luIGNvbm5lY3Rp dml0eSBjaGVja3Mgd2l0aCBhbGwgb2YNCj4gICAgICAgIGl0cyBwYWlycyBhbHJlYWR5IHByZXNl bnQsIHRoZSB3YXkgdGhhdCBwYWlyIHN0YXRlcyBjaGFuZ2UgaXMNCj4gICAgICAgIGluZGlzdGlu Z3Vpc2hhYmxlIGZyb20gdGhhdCBvZiBhIHJlZ3VsYXIgSUNFIGFnZW50Lg0KPg0KPiAgICAgICAg T2YgY291cnNlLCB0aGUgbWFqb3IgZGlmZmVyZW5jZSB3aXRoIFRyaWNrbGUgSUNFIGlzIHRoYXQg Y2hlY2sgbGlzdA0KPiAgICAgICAgc2V0cyBjYW4gYmUgZHluYW1pY2FsbHkgdXBkYXRlZCBiZWNh dXNlIGNhbmRpZGF0ZXMgY2FuIGFycml2ZSBhZnRlcg0KPiAgICAgICAgY29ubmVjdGl2aXR5IGNo ZWNrcyBoYXZlIHN0YXJ0ZWQuICBXaGVuIHRoaXMgaGFwcGVucywgYW4gYWdlbnQgc2V0cw0KPiAg ICAgICAgdGhlIHN0YXRlIG9mIHRoZSBuZXdseSBmb3JtZWQgcGFpciBhcyBkZXNjcmliZWQgYmVs b3cuDQo+DQo+ICAgICAgICBDYXNlIDE6IElmIHRoZSBuZXdseSBmb3JtZWQgcGFpciBpcyB0aGUg dG9wbW9zdCBwYWlyIGluIHRoaXMgY29sdW1uLA0KPiAgICAgICAgc2V0IHRoZSBzdGF0ZSB0byBX YWl0aW5nIChlLmcuLCB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlIGlmIHRoZSBuZXdseQ0KPiAgICAg ICAgZm9ybWVkIHBhaXIgd2VyZSBwbGFjZWQgaW4gY29sdW1uIDQsIHJvdyAxKS4NCj4NCj4NCj4g ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKw0KPiAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgZjEgIHwgIGYyICB8ICBmMyAgfCAg ZjQgIHwgIGY1ICB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTEgKEF1ZGlvLlJUUCkgIHwgcy1jcCB8 IHctY3AgfCB3LWNwIHwgdy1jcCB8ICAgICAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ICAgICAgICB8IG0yIChBdWRp by5SVENQKSB8IHctY3AgfCAgY3AgIHwgIGNwICB8IHctY3AgfCAgICAgIHwNCj4gICAgICAgICst LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPiAg ICAgICAgfCBtMyAoVmlkZW8uUlRQKSAgfCB3LWNwIHwgICAgICB8ICAgICAgfCAgICAgIHwgdy1j cCB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTQgKFZpZGVvLlJUQ1ApIHwgdy1jcCB8ICAgICAgfCAg ICAgIHwgICAgICB8ICBjcCAgfA0KPiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+DQo+DQo+ICAgICAgICAgICAgICBGaWd1cmUg NTogQ2hlY2sgTGlzdCBTdGF0ZSB3aXRoIE5ld2x5IEZvcm1lZCBQYWlyLCBDYXNlIDENCj4NCj4g ICAgICAgIENhc2UgMjogSWYgdGhlIHBhaXIgaW1tZWRpYXRlbHkgYWJvdmUgdGhlIG5ld2x5IGZv cm1lZCBwYWlyIGluIHRoaXMNCj4gICAgICAgIGNvbHVtbiBpcyBpbiB0aGUgU3VjY2VlZGVkIHN0 YXRlLCBzZXQgdGhlIHN0YXRlIHRvIFdhaXRpbmcgKGUuZy4sDQo+ICAgICAgICB0aGlzIHdvdWxk IGJlIHRoZSBjYXNlIGlmIHRoZSBwYWlyIGluIGNvbHVtbiA0LCByb3cgMiBzdWNjZWVkZWQgYW5k DQo+ICAgICAgICB0aGUgbmV3bHkgZm9ybWVkIHBhaXIgd2VyZSBwbGFjZWQgaW4gY29sdW1uIDQs IHJvdyAzKTsNCj4NCj4NCj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPiAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgZjEg IHwgIGYyICB8ICBmMyAgfCAgZjQgIHwgIGY1ICB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTEgKEF1 ZGlvLlJUUCkgIHwgcy1jcCB8IHctY3AgfCB3LWNwIHwgICAgICB8ICAgICAgfA0KPiAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ ICAgICAgICB8IG0yIChBdWRpby5SVENQKSB8IHctY3AgfCAgY3AgIHwgIGNwICB8IHMtY3AgfCAg ICAgIHwNCj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSst LS0tLS0rLS0tLS0tKw0KPiAgICAgICAgfCBtMyAoVmlkZW8uUlRQKSAgfCB3LWNwIHwgICAgICB8 ICAgICAgfCB3LWNwIHwgdy1jcCB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTQgKFZpZGVvLlJUQ1Ap IHwgdy1jcCB8ICAgICAgfCAgICAgIHwgICAgICB8ICBjcCAgfA0KPiAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+DQo+DQo+ICAg ICAgICAgICAgICBGaWd1cmUgNjogQ2hlY2sgTGlzdCBTdGF0ZSB3aXRoIE5ld2x5IEZvcm1lZCBQ YWlyLCBDYXNlIDINCj4NCj4gICAgICAgIENhc2UgMzogSWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25l IHBhaXIgaW4gdGhpcyBjb2x1bW4gYmVsb3cgdGhlIHJvdyBvZg0KPiAgICAgICAgdGhlIG5ld2x5 IGZvcm1lZCBwYWlyIHdob3NlIHN0YXRlIGlzIGVpdGhlciBTdWNjZWVkZWQgb3IgRmFpbGVkDQo+ ICAgICAgICAoZS5nLiwgdGhpcyB3b3VsZCBiZSB0aGUgY2FzZSBpZiB0aGUgcGFpciBpbiBjb2x1 bW4gNCwgcm93IDINCj4gICAgICAgIHN1Y2NlZWRlZCBhbmQgdGhlIG5ld2x5IGZvcm1lZCBwYWly IHdlcmUgcGxhY2VkIGluIGNvbHVtbiA0LCByb3cgMSkuDQo+DQo+DQo+ICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAg IHwgICAgICAgICAgICAgICAgIHwgIGYxICB8ICBmMiAgfCAgZjMgIHwgIGY0ICB8ICBmNSAgfA0K PiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSst LS0tLS0rDQo+ICAgICAgICB8IG0xIChBdWRpby5SVFApICB8IHMtY3AgfCB3LWNwIHwgdy1jcCB8 IHctY3AgfCAgICAgIHwNCj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPiAgICAgICAgfCBtMiAoQXVkaW8uUlRDUCkgfCB3LWNw IHwgIGNwICB8ICBjcCAgfCBzLWNwIHwgICAgICB8DQo+ICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4gICAgICAgIHwgbTMgKFZp ZGVvLlJUUCkgIHwgdy1jcCB8ICAgICAgfCAgICAgIHwgdy1jcCB8IHctY3AgfA0KPiAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ ICAgICAgICB8IG00IChWaWRlby5SVENQKSB8IHctY3AgfCAgICAgIHwgICAgICB8ICAgICAgfCAg Y3AgIHwNCj4gICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSst LS0tLS0rLS0tLS0tKw0KPg0KPg0KPiAgICAgICAgICAgICAgRmlndXJlIDc6IENoZWNrIExpc3Qg U3RhdGUgd2l0aCBOZXdseSBGb3JtZWQgUGFpciwgQ2FzZSAzDQo+DQo+ICAgICAgICBDYXNlIDQ6 IEluIGFsbCBvdGhlciBjYXNlcywgc2V0IHRoZSBzdGF0ZSB0byBGcm96ZW4uDQo+DQo+ICAgICAj IyMNCj4NCj4gICAgIFBldGVyDQo+DQo+DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB82DFEESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Jbml0aWFsbHksIGJlZm9yZSB0aGUgY2hl Y2tzIGJlZ2luLCBvbmx5IHRoZSB0b3Btb3N0IHBhaXIgZm9yIGVhY2ggZm91bmRhdGlvbiBpcyBz ZXQgdG8gd2FpdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEljZSBbbWFpbHRvOmljZS1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UYXlsb3IgQnJhbmRzdGV0dGVyPGJyPg0K PGI+U2VudDo8L2I+IDI0IEFwcmlsIDIwMTcgMjA6MDI8YnI+DQo8Yj5Ubzo8L2I+IFBldGVyIFNh aW50LUFuZHJlICZsdDtzdHBldGVyQHN0cGV0ZXIuaW0mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpY2VA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJY2VdIFRheWxvcidzIHJldmlldyBv ZiBkcmFmdC1pZXRmLWljZS10cmlja2xlLTA4LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5E b2VzIHRoYXQgbWVhbiB3ZSdkIGdvIGRpcmVjdGx5IGZyb20gV0ZGRkZGIHRvIFNXV1dXVz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ZZXM7IHdoZW4gSSB3YXMgdHlwaW5nIHVwIHRoZSBleGFtcGxlIEkgaGFkbid0IG5v dGljZWQgdGhhdCB0aGUgJnF1b3Q7ZWFjaCBjb21wb25lbnQgb2YgdGhlIG1lZGlhIHN0cmVhbSZx dW90OyBwYXJ0IGhhZCBiZWVuIHJlbW92ZWQgZnJvbSA1MjQ1YmlzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij5NeSBpbnRlcnByZXRhdGlvbiBvZiBDYXNlIDEgaXMgdGhhdCBvbmx5 IHRoZSB0b3Btb3N0IHBhaXIgZm9yIHRoYXQ8YnI+DQpmb3VuZGF0aW9uIGlzIHNldCB0byB3YWl0 aW5nLCBob3dldmVyIHlvdSBzZWVtIHRvIGludGVycHJldCBpdCB0byBtZWFuPGJyPg0KdGhlIHRv cG1vc3QgcGFpciBmb3IgdGhhdCBtZWRpYSBzdHJlYW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIEkgYWxzbyBp bnRlcnByZXQgaXQgYXMgJnF1b3Q7dG9wbW9zdCBmb3IgZm91bmRhdGlvbiZxdW90Oy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+SSB0aGluayZuYnNwO3RoZSBmaXggd2Ug bmVlZCB0byBtYWtlIGlzIHRvIENhc2UgMyAoY2hhbmdlICZxdW90O2JlbG93JnF1b3Q7IHRvICZx dW90O2Fib3ZlJnF1b3Q7KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBjb3VsZCBtZXJnZSBjYXNl cyAyIGFuZCAzIGFuZCBtYWtlIGl0ICZxdW90O2Fub3RoZXIgcGFpciBpbiB0aGUgc2FtZSBjb2x1 bW4gaXMgaW4gdGhlIFN1Y2NlZWRlZCBzdGF0ZS4mcXVvdDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBBcHIgMjMsIDIw MTcgYXQgMjo1NyBQTSwgUGV0ZXIgU2FpbnQtQW5kcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpzdHBl dGVyQHN0cGV0ZXIuaW0iIHRhcmdldD0iX2JsYW5rIj5zdHBldGVyQHN0cGV0ZXIuaW08L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiA0LzE4LzE3IDc6NDQgUE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgd3JvdGU6PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7VGF5bG9yLCB3b3VsZCB5b3UgbWluZCBzcGVsbGluZyB0aGlz IG91dCBhIGJpdCBtb3JlIGZ1bGx5IGFuZCBwb2ludCB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO2Rpc2NyZXBhbmNpZXMgYmV0d2VlbiB0aGUgdGV4dCBvZiA1MjQ1YmlzIGFuZCB0aGUg dGV4dCBvZiB0aGUgVHJpY2tsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3NwZWM/IEkn bSBzdXJlIEknbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkgZG9uJ3QgeWV0IHNlZSB0aGUgdHJ1 dGggb2Y8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt5b3VyIHN0YXRlbWVudCB0aGF0ICZx dW90O29ubHkgdGhlIHRvcG1vc3QgcmVtYWluaW5nIHBhaXIgaW4gZWFjaCBmb3VuZGF0aW9uPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aXMgZ3VhcmFudGVlZCB0byBiZSB1bmZyb3plbiZx dW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgU3VyZTsgbGV0IG1lIHRyeSB0byBn aXZlIGFuIGV4YW1wbGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgU3VwcG9zZSBJIGhhdmUgdGhyZWUg bWVkaWEgc3RyZWFtcywgYW5kIG9uZSBmb3VuZGF0aW9uIChsZXQncyBrZWVwIGl0PGJyPg0KJmd0 OyBzaW1wbGUpLiBJJ2xsIHJlcHJlc2VudCB0aGUgc3RhdGVzIGxpa2UgdGhpcyBmb3IgYnJldml0 eTogJnF1b3Q7U1dGRkZGJnF1b3Q7LDxicj4NCiZndDsgd2hlcmUgJnF1b3Q7UyZxdW90OyBpcyAm cXVvdDtzdWNjZWVkZWQmcXVvdDssICZxdW90O1cmcXVvdDsgaXMgJnF1b3Q7d2FpdGluZyZxdW90 OywgYW5kICZxdW90O0YmcXVvdDsgaXMgJnF1b3Q7ZnJvemVuJnF1b3Q7LiBBbmQ8YnI+DQomZ3Q7 IHRoZXkncmUgb3JkZXJlZCBpbiB0aGUgc2FtZSB3YXkgYXMgdGhlIHJvd3MgaW4geW91ciB0YWJs ZSBhYm92ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaXRoIG5vbi10cmlja2xlIElDRSwgaGVyZSdz IHdoYXQgd291bGQgdHlwaWNhbGx5IGhhcHBlbjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAx LiBPbmx5IHRoZSBSVFAgY2FuZGlkYXRlIHBhaXIgZm9yIHRoZSBmaXJzdCBtZWRpYSBzdHJlYW0g aXMgdW5mcm96ZW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbml0aWFsbHkuPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7U3RhdGU6IFdGRkZGRjxicj4NCiZndDsmbmJzcDsgMi4g Q2hlY2sgc3VjY2VlZHMgZm9yIFJUUCBjYW5kaWRhdGUgcGFpci4gUlRDUCBwYWlyIHVuZnJvemVu Ljxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1N0YXRlOiBTV0ZGRkY8YnI+DQo8YnI+DQpT ZWN0aW9uIDYuMi41LjMuMyBvZiA1MjQ1YmlzIHN0YXRlczo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7VGhlIHN1Y2Nlc3Mgb2YgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayBtaWdodCBhbHNvIGNhdXNl IHRoZSBzdGF0ZSBvZjxicj4NCiZuYnNwOyAmbmJzcDtvdGhlciBjYW5kaWRhdGUgcGFpcnMgdG8g Y2hhbmdlLiZuYnNwOyBUaGUgSUNFIGFnZW50IE1VU1Qgc2V0IHRoZSBzdGF0ZXM8YnI+DQombmJz cDsgJm5ic3A7Zm9yIGFsbCBvdGhlciBGcm96ZW4gY2FuZGlkYXRlIHBhaXJzIChpbiBlYWNoIENI RUNLIExJU1QgaW4gdGhlIENIRUNLPGJyPg0KJm5ic3A7ICZuYnNwO0xJU1QgU0VUKSB3aXRoIHRo ZSBzYW1lIGZvdW5kYXRpb24gdG8gV2FpdGluZy48YnI+DQo8YnI+DQpEb2VzIHRoYXQgbWVhbiB3 ZSdkIGdvIGRpcmVjdGx5IGZyb20gV0ZGRkZGIHRvIFNXV1dXVz88YnI+DQo8YnI+DQomZ3Q7Jm5i c3A7IDMuIENoZWNrIHN1Y2NlZWRzIGZvciBSVENQIHBhaXIuIC9BbGwvIHRoZSBvdGhlciBwYWly cyB3aXRoIHRoZSBzYW1lPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Zm91bmRhdGlvbiBh cmUgbm93IHVuZnJvemVuLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1N0YXRlOiBTU1dX V1c8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaXRoIHRyaWNrbGUgSUNFLCBoZXJlJ3Mgd2hhdCBjb3Vs ZCBoYXBwZW46PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgMS4gQ2FuZGlkYXRlcyBmb3IgdGhl IGZpcnN0IG1lZGlhIHN0cmVhbSBhcmUgdHJpY2tsZWQgaW4uIFN0YXJ0cyBvdXQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtqdXN0IGxpa2Ugbm9ybWFsIElDRS48YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtTdGF0ZTogV0Y8YnI+DQomZ3Q7Jm5ic3A7IDIuIENoZWNrcyBmb3IgYm90 aCBwYWlycyBzdWNjZWVkLiBTdGlsbCB3YWl0aW5nIGZvciBjYW5kaWRhdGVzIGZvcjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO290aGVyIG1lZGlhIHN0cmVhbXMuPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7U3RhdGU6IFNTPGJyPg0KJmd0OyZuYnNwOyAzLiBDYW5kaWRhdGVzIGZv ciB0aGUgb3RoZXIgbWVkaWEgc3RyZWFtcyBhcnJpdmUsIGFuZCBwYWlycyBhcmUgZm9ybWVkLjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSB0b3Btb3N0IHBhaXIgaXMgc2V0IHRvIHdh aXRpbmcsIGJ1dCBub3QgdGhlIG90aGVycy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtT dGF0ZTogU1NXRkZGPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgZXhhbXBsZS48YnI+DQo8YnI+ DQpNeSBpbnRlcnByZXRhdGlvbiBvZiBDYXNlIDEgaXMgdGhhdCBvbmx5IHRoZSB0b3Btb3N0IHBh aXIgZm9yIHRoYXQ8YnI+DQpmb3VuZGF0aW9uIGlzIHNldCB0byB3YWl0aW5nLCBob3dldmVyIHlv dSBzZWVtIHRvIGludGVycHJldCBpdCB0byBtZWFuPGJyPg0KdGhlIHRvcG1vc3QgcGFpciBmb3Ig dGhhdCBtZWRpYSBzdHJlYW0uPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IHRoZSBydWxlcyBpbiBk cmFmdC1pZXRmLWljZS10cmlja2xlLTA4IGFyZW4ndCBxdWl0ZSByaWdodC48YnI+DQpJZiB3ZSBh Y2NlcHQgbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlICZxdW90O3RvcG1vc3QgcGFpciZxdW90OyBy dWxlLCB0aGVuIEkgdGhpbms8YnI+DQp0aGUgZml4IHdlIG5lZWQgdG8gbWFrZSBpcyB0byBDYXNl IDMgKGNoYW5nZSAmcXVvdDtiZWxvdyZxdW90OyB0byAmcXVvdDthYm92ZSZxdW90OykuPGJyPg0K PGJyPg0KSW4gdGhlIGludGVyZXN0IG9mIHRpbWUsIEknbSBnb2luZyB0byBzdWJtaXQgLTA5IHJp Z2h0IG5vdyBzbyB0aGF0IHdlPGJyPg0KaGF2ZSBhIGRvY3VtZW50IGFuZCBkaWZmIHRvIHJldmll dywgbm90IGp1c3QgdGhlc2UgbG9uZyBlbWFpbCBtZXNzYWdlcy48YnI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+UGV0ZXI8L3NwYW4+PGJy Pg0KPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBTbywgd2hlcmUgbm9y bWFsIElDRSBlbnN1cmVzIHRoYXQgb25jZSBhIGZvdW5kYXRpb24gaXMgcHJvdmVuIHRvIHdvcms8 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IChmb3IgYm90aCBjb21wb25lbnRzIG9m IGEgbWVkaWEgc3RyZWFtKSwgYWxsIG90aGVyIHBhaXJzIHdpdGggdGhhdDwvc3Bhbj48YnI+DQo8 c3BhbiBjbGFzcz0iaW0iPiZndDsgZm91bmRhdGlvbiBhcmUgdW5mcm96ZW4sIHRyaWNrbGUgSUNF IG9ubHkgZ3VhcmFudGVlcyB0aGF0IG9uZSBvZiB0aGVtIGlzLjwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0iaW0iPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IE9uIE1vbiwg QXByIDE3LCAyMDE3IGF0IDg6MTYgUE0sIFBldGVyIFNhaW50LUFuZHJlICZsdDs8YSBocmVmPSJt YWlsdG86c3RwZXRlckBzdHBldGVyLmltIj5zdHBldGVyQHN0cGV0ZXIuaW08L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3Rw ZXRlckBzdHBldGVyLmltIj5zdHBldGVyQHN0cGV0ZXIuaW08L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO09uIDMvMzAvMTcgMTE6MjggUE0s IFRheWxvciBCcmFuZHN0ZXR0ZXIgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO1thcmVhcyBvZiBzZWVtaW5nIGFncmVlbWVudCBlbGlkZWRdPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7KiBJbiBzZWN0aW9u IDguMS4xOiBJbiBnZW5lcmFsIEkgbGlrZSB0aGUgaW1wcm92ZW1lbnRzIHRoYXQgaGF2ZTxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2JlZW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDttYWRlLiBIb3dldmVyOjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvIFRoZSBydWxlcyBm b3IgaG93IGEgbmV3IHBhaXIgZ2V0cyBlaXRoZXIgYSAmcXVvdDtXYWl0aW5nJnF1b3Q7IG9yPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7RnJvemVuJnF1b3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtz dGF0ZSBkb24ndCBjb21wbGV0ZWx5IG1hdGNoIHN0YW5kYXJkIElDRTsgYXQgbGVhc3QgdGhlIHBh cnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3doZXJlIHdoZW4gb25lICZxdW90O21lZGlhIHN0cmVhbSZxdW90OyBjb21w bGV0ZXMsIHBhaXJzIGZyb20gb3RoZXIgbWVkaWE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0cmVhbXMgd2l0aCBtYXRj aGluZyBmb3VuZGF0aW9ucyBhcmUgdW5mcm96ZW4uIFdpdGggdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3J1bGVzIGluIHNlY3Rpb24gOC4xLjEsIG9ubHkgdGhlIHRvcG1vc3QgcmVtYWluaW5nIHBhaXIg aW4gZWFjaDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Zm91bmRhdGlvbiBpcyBndWFyYW50ZWVkIHRvIGJlIHVuZnJvemVu LiBJcyB0aGlzIGRpZmZlcmVuY2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FjY2VwdGFibGU/IElmIGl0IGlzLCB3ZSBz aG91bGQgYXQgbGVhc3QgYWNrbm93bGVkZ2UgaXQsIGFuZCBub3Q8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2dpdmUgdGhl IHdyb25nIGltcHJlc3Npb24gYnkgc2F5aW5nICZxdW90O1RyaWNrbGUgSUNFIHByZXNlcnZlcyBh bGw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO29mIFt0aGUgc3RhbmRhcmQgSUNFXSBydWxlcy4mcXVvdDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7VGF5bG9yLCB3b3VsZCB5b3UgbWluZCBzcGVs bGluZyB0aGlzIG91dCBhIGJpdCBtb3JlIGZ1bGx5IGFuZCBwb2ludCB0bzxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO2Rpc2NyZXBhbmNpZXMgYmV0d2VlbiB0aGUgdGV4dCBvZiA1MjQ1Ymlz IGFuZCB0aGUgdGV4dCBvZiB0aGUgVHJpY2tsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O3NwZWM/IEknbSBzdXJlIEknbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkgZG9uJ3QgeWV0IHNl ZSB0aGUgdHJ1dGggb2Y8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt5b3VyIHN0YXRlbWVu dCB0aGF0ICZxdW90O29ubHkgdGhlIHRvcG1vc3QgcmVtYWluaW5nIHBhaXIgaW4gZWFjaCBmb3Vu ZGF0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aXMgZ3VhcmFudGVlZCB0byBiZSB1 bmZyb3plbiZxdW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SW4g cGFydGljdWxhciwgeW91ciBzdGF0ZW1lbnQgZG9lc24ndCBzZWVtIHRvIG1hdGNoIHRoZSBydWxl cyBkZWZpbmVkIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIFRyaWNrbGUgc3Bl Yy4gSSd2ZSB0cmllZCB0byBzcGVsbCB0aGVtIG91dCBpbiBncmVhdGVyIGRldGFpbCAod2l0aDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2V4YW1wbGVzKSBpbiB0aGUgZm9sbG93aW5nIHBy b3Bvc2VkIHRleHQuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyMjIzxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7OC4xLjEuJm5i c3A7IEluc2VydGluZyBhIE5ldyBQYWlyIGluIGEgQ2hlY2sgTGlzdDxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgdGFi dWxhciByZXByZXNlbnRhdGlvbiBvZiBhbGwgY2hlY2tsaXN0cyBpbiBhbjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWdlbnQ6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgZjEmbmJz cDsgfCZuYnNwOyBmMiZuYnNwOyB8Jm5ic3A7IGYzJm5ic3A7IHwmbmJzcDsgZjQmbmJzcDsgfCZu YnNwOyBmNSZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8IG0xIChBdWRpby5SVFApJm5ic3A7IHwmbmJzcDsgY3AmbmJzcDsgfCZuYnNwOyBjcCZuYnNw OyB8Jm5ic3A7IGNwJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0t LS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0 MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtMiAo QXVkaW8uUlRDUCkgfCZuYnNwOyBjcCZuYnNwOyB8Jm5ic3A7IGNwJm5ic3A7IHwmbmJzcDsgY3Am bmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtMyAoVmlkZW8uUlRQKSZuYnNwOyB8 Jm5ic3A7IGNwJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgY3AmbmJzcDsgfDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0t JiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtNCAoVmlkZW8uUlRDUCkgfCZuYnNwOyBj cCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJz cDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IGNwJm5ic3A7IHw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0t LS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWd1cmUgMTogRXhhbXBs ZSBvZiBDaGVjayBMaXN0IFN0YXRlPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgRWFjaCByb3cgaW4gdGhlIHRhYmxlIHJlcHJlc2VudHMgYSBjb21wb25lbnQg Zm9yIGEgZ2l2ZW4gbWVkaWEgc3RyZWFtPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAoZS5nLiwgbTEgYW5kIG0yIG1pZ2h0IGJlIHRoZSBSVFAgYW5kIFJUQ1AgY29tcG9uZW50 cyBmb3IgYXVkaW8pLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRWFjaCBj b2x1bW4gcmVwcmVzZW50cyBvbmUgZm91bmRhdGlvbi4mbmJzcDsgRWFjaCBjZWxsIHJlcHJlc2Vu dHMgb25lPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjYW5kaWRhdGUgcGFp ci48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGVuIGFu IGFnZW50IGNvbW1lbmNlcyBJQ0UgcHJvY2Vzc2luZywgaW4gYWNjb3JkYW5jZSB3aXRoPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTZWN0aW9uIDUuMS4zLjYgb2YgW3JmYzUy NDViaXNdIGl0IHdpbGwgdW5mcmVlemUgKGkuZS4sIHBsYWNlIGluIHRoZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2FpdGluZyBzdGF0ZSkgdGhlIHRvcG1vc3QgY2FuZGlk YXRlIHBhaXIgaW4gZXZlcnkgY29sdW1uIChpLmUuLCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHBhaXIgd2l0aCB0aGUgbG93ZXN0IGNvbXBvbmVudCBJRCkuJm5ic3A7 IFRoaXMgc3RhdGUgaXMgc2hvd24gaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBmb2xsb3dpbmcgdGFibGUsIHdpdGggY2FuZGlkYXRlIHBhaXJzIGluIHRoZSBXYWl0 aW5nIHN0YXRlIG1hcmtlZCBieTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JnF1b3Q7dy1jcCZxdW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyBmMSZuYnNwOyB8Jm5ic3A7IGYy Jm5ic3A7IHwmbmJzcDsgZjMmbmJzcDsgfCZuYnNwOyBmNCZuYnNwOyB8Jm5ic3A7IGY1Jm5ic3A7 IHw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0t LS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0t LS0tJiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbTEgKEF1ZGlv LlJUUCkmbmJzcDsgfCB3LWNwIHwgdy1jcCB8IHctY3AgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwm bmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0t JiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8IG0yIChBdWRpby5SVENQKSB8Jm5ic3A7IGNwJm5ic3A7IHwmbmJzcDsgY3AmbmJz cDsgfCZuYnNwOyBjcCZuYnNwOyB8IHctY3AgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbTMgKFZpZGVvLlJUUCkmbmJz cDsgfCZuYnNwOyBjcCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IHctY3AgfDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtNCAoVmlkZW8uUlRDUCkgfCZuYnNwOyBjcCZuYnNw OyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5i c3A7ICZuYnNwOyB8Jm5ic3A7IGNwJm5ic3A7IHw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0 MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWd1cmUgMjogSW5pdGlh bCBDaGVjayBMaXN0IFN0YXRlPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgVGhlbiwgYXMgdGhlIGNoZWNrcyBwcm9jZWVkIChzZWUgU2VjdGlvbiA2LjEuMi40 LjIuMyBvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW3JmYzUyNDViaXNd KSwgZm9yIGVhY2ggcGFpciB0aGF0IGVudGVycyB0aGUgU3VjY2VlZGVkIHN0YXRlIChkZW5vdGVk PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoZXJlIGJ5ICZxdW90O3MtY3Am cXVvdDspLCB0aGUgYWdlbnQgd2lsbCB1bmZyZWV6ZSBhbGwgcGFpcnMgZm9yIHRoZSBzYW1lIG1l ZGlhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdHJlYW0gYW5kIGZvdW5k YXRpb24gKGUuZy4sIGlmIHRoZSBwYWlyIGluIGNvbHVtbiAxLCByb3cgMSBzdWNjZWVkczxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlbiB0aGUgYWdlbnQgd2lsbCB1bmZy ZWV6ZSB0aGUgcGFpciBpbiBjb2x1bW4gMSwgcm93IDIpLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0t JiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYj NDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7IGYx Jm5ic3A7IHwmbmJzcDsgZjImbmJzcDsgfCZuYnNwOyBmMyZuYnNwOyB8Jm5ic3A7IGY0Jm5ic3A7 IHwmbmJzcDsgZjUmbmJzcDsgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYj NDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCBtMSAoQXVkaW8uUlRQKSZuYnNwOyB8IHMtY3AgfCB3LWNwIHwgdy1jcCB8Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7 LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbTIgKEF1ZGlvLlJUQ1ApIHwgdy1jcCB8Jm5ic3A7 IGNwJm5ic3A7IHwmbmJzcDsgY3AmbmJzcDsgfCB3LWNwIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0t LS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0t LSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG0zIChWaWRlby5S VFApJm5ic3A7IHwmbmJzcDsgY3AmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB3LWNwIHw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0t LSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbTQgKFZpZGVvLlJUQ1ApIHwmbmJzcDsg Y3AmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5i c3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0t LS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlndXJlIDM6IENoZWNrIExpc3QgU3RhdGUgYWZ0ZXIgU3Vj Y2VlZGVkIENoZWNrPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgSUNFIGFsc28gc3BlY2lmaWVzIHRoYXQsIGlmIGFsbCB0aGUgcGFpcnMgaW4gYSBtZWRpYSBz dHJlYW0gZm9yIG9uZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm91bmRh dGlvbiBhcmUgdW5mcm96ZW4gKGUuZy4sIGNvbHVtbiAxLCByb3dzIDEgYW5kIDIgcmVwcmVzZW50 aW5nPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBib3RoIGNvbXBvbmVudHMg Zm9yIHRoZSBhdWRpbyBzdHJlYW0pLCB0aGVuIGFsbCBvZiB0aGUgY2FuZGlkYXRlPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYWlycyBpbiB0aGUgZW50aXJlIGNvbHVtbiBh cmUgdW5mcm96ZW4gKGUuZy4sIGNvbHVtbiAxLCByb3dzIDMgYW5kPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA0KS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0m IzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0 Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgZjEm bmJzcDsgfCZuYnNwOyBmMiZuYnNwOyB8Jm5ic3A7IGYzJm5ic3A7IHwmbmJzcDsgZjQmbmJzcDsg fCZuYnNwOyBmNSZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0 MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8IG0xIChBdWRpby5SVFApJm5ic3A7IHwgcy1jcCB8IHctY3AgfCB3LWNwIHwmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtMiAoQXVkaW8uUlRDUCkgfCB3LWNwIHwmbmJzcDsg Y3AmbmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8IHctY3AgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0t LS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0t JiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbTMgKFZpZGVvLlJU UCkmbmJzcDsgfCB3LWNwIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgdy1jcCB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0t LSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8IG00IChWaWRlby5SVENQKSB8IHctY3AgfCZuYnNwOyAmbmJz cDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZu YnNwOyBjcCZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWd1cmUg NDogQ2hlY2sgTGlzdCBTdGF0ZSB3aXRoIFVuZnJvemVuIE1lZGlhIFN0cmVhbTxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRyaWNrbGUgSUNFIHByZXNlcnZl cyBhbGwgb2YgdGhlc2UgcnVsZXMgYXMgdGhleSBhcHBseSB0byB3aGF0IHdlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtaWdodCBjYWxsICZxdW90O3N0YXRpYyZxdW90OyBj aGVjayBsaXN0IHNldHMuJm5ic3A7IFRoaXMgaW1wbGllcyB0aGF0IGlmLCBmb3Igc29tZTxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVhc29uLCBhIFRyaWNrbGUgYWdlbnQg d2VyZSB0byBiZWdpbiBjb25uZWN0aXZpdHkgY2hlY2tzIHdpdGggYWxsIG9mPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpdHMgcGFpcnMgYWxyZWFkeSBwcmVzZW50LCB0aGUg d2F5IHRoYXQgcGFpciBzdGF0ZXMgY2hhbmdlIGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHRoYXQgb2YgYSByZWd1bGFyIElDRSBh Z2VudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPZiBj b3Vyc2UsIHRoZSBtYWpvciBkaWZmZXJlbmNlIHdpdGggVHJpY2tsZSBJQ0UgaXMgdGhhdCBjaGVj ayBsaXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZXRzIGNhbiBiZSBk eW5hbWljYWxseSB1cGRhdGVkIGJlY2F1c2UgY2FuZGlkYXRlcyBjYW4gYXJyaXZlIGFmdGVyPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25uZWN0aXZpdHkgY2hlY2tzIGhh dmUgc3RhcnRlZC4mbmJzcDsgV2hlbiB0aGlzIGhhcHBlbnMsIGFuIGFnZW50IHNldHM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBzdGF0ZSBvZiB0aGUgbmV3bHkgZm9y bWVkIHBhaXIgYXMgZGVzY3JpYmVkIGJlbG93Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IENhc2UgMTogSWYgdGhlIG5ld2x5IGZvcm1lZCBwYWlyIGlzIHRo ZSB0b3Btb3N0IHBhaXIgaW4gdGhpcyBjb2x1bW4sPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBzZXQgdGhlIHN0YXRlIHRvIFdhaXRpbmcgKGUuZy4sIHRoaXMgd291bGQgYmUg dGhlIGNhc2UgaWYgdGhlIG5ld2x5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBmb3JtZWQgcGFpciB3ZXJlIHBsYWNlZCBpbiBjb2x1bW4gNCwgcm93IDEpLjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0t LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8Jm5ic3A7IGYxJm5ic3A7IHwmbmJzcDsgZjImbmJzcDsgfCZuYnNwOyBmMyZuYnNwOyB8Jm5i c3A7IGY0Jm5ic3A7IHwmbmJzcDsgZjUmbmJzcDsgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCBtMSAoQXVkaW8uUlRQKSZuYnNwOyB8IHMtY3AgfCB3LWNwIHwg dy1jcCB8IHctY3AgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0t LS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbTIgKEF1ZGlvLlJUQ1ApIHwgdy1jcCB8Jm5ic3A7IGNw Jm5ic3A7IHwmbmJzcDsgY3AmbmJzcDsgfCB3LWNwIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0t JiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYj NDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG0zIChWaWRlby5SVFAp Jm5ic3A7IHwgdy1jcCB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IHctY3AgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCBtNCAoVmlkZW8uUlRDUCkgfCB3LWNwIHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJz cDsgY3AmbmJzcDsgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0Mzst LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0t LS0tJiM0MzstLS0tLS0mIzQzOzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWd1cmUgNTogQ2hlY2sg TGlzdCBTdGF0ZSB3aXRoIE5ld2x5IEZvcm1lZCBQYWlyLCBDYXNlIDE8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYXNlIDI6IElmIHRoZSBwYWlyIGltbWVk aWF0ZWx5IGFib3ZlIHRoZSBuZXdseSBmb3JtZWQgcGFpciBpbiB0aGlzPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb2x1bW4gaXMgaW4gdGhlIFN1Y2NlZWRlZCBzdGF0ZSwg c2V0IHRoZSBzdGF0ZSB0byBXYWl0aW5nIChlLmcuLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdGhpcyB3b3VsZCBiZSB0aGUgY2FzZSBpZiB0aGUgcGFpciBpbiBjb2x1bW4g NCwgcm93IDIgc3VjY2VlZGVkIGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgdGhlIG5ld2x5IGZvcm1lZCBwYWlyIHdlcmUgcGxhY2VkIGluIGNvbHVtbiA0LCByb3cgMyk7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wmbmJzcDsgZjEmbmJzcDsgfCZuYnNwOyBmMiZuYnNwOyB8Jm5ic3A7IGYz Jm5ic3A7IHwmbmJzcDsgZjQmbmJzcDsgfCZuYnNwOyBmNSZuYnNwOyB8PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG0xIChBdWRpby5SVFApJm5ic3A7IHwgcy1j cCB8IHctY3AgfCB3LWNwIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtMiAoQXVk aW8uUlRDUCkgfCB3LWNwIHwmbmJzcDsgY3AmbmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8IHMtY3Ag fCZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0t LS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgbTMgKFZpZGVvLlJUUCkmbmJzcDsgfCB3LWNwIHwmbmJzcDsgJm5ic3A7ICZu YnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB3LWNwIHwgdy1jcCB8PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG00IChWaWRlby5SVENQKSB8IHctY3AgfCZu YnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0t LS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpZ3Vy ZSA2OiBDaGVjayBMaXN0IFN0YXRlIHdpdGggTmV3bHkgRm9ybWVkIFBhaXIsIENhc2UgMjxicj4N CiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhc2UgMzogSWYgdGhl cmUgaXMgYXQgbGVhc3Qgb25lIHBhaXIgaW4gdGhpcyBjb2x1bW4gYmVsb3cgdGhlIHJvdyBvZjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIG5ld2x5IGZvcm1lZCBwYWly IHdob3NlIHN0YXRlIGlzIGVpdGhlciBTdWNjZWVkZWQgb3IgRmFpbGVkPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAoZS5nLiwgdGhpcyB3b3VsZCBiZSB0aGUgY2FzZSBpZiB0 aGUgcGFpciBpbiBjb2x1bW4gNCwgcm93IDI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHN1Y2NlZWRlZCBhbmQgdGhlIG5ld2x5IGZvcm1lZCBwYWlyIHdlcmUgcGxhY2VkIGlu IGNvbHVtbiA0LCByb3cgMSkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7 LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgZjEmbmJzcDsgfCZuYnNwOyBm MiZuYnNwOyB8Jm5ic3A7IGYzJm5ic3A7IHwmbmJzcDsgZjQmbmJzcDsgfCZuYnNwOyBmNSZuYnNw OyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0t LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0t LS0tLSYjNDM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG0xIChBdWRp by5SVFApJm5ic3A7IHwgcy1jcCB8IHctY3AgfCB3LWNwIHwgdy1jcCB8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgfDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0t LS0tLS0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0 MzstLS0tLS0mIzQzOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBtMiAo QXVkaW8uUlRDUCkgfCB3LWNwIHwmbmJzcDsgY3AmbmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8IHMt Y3AgfCZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzst LS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgbTMgKFZpZGVvLlJUUCkmbmJzcDsgfCB3LWNwIHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB3LWNwIHwgdy1jcCB8PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0t LS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG00IChWaWRlby5SVENQKSB8IHctY3Ag fCZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNw OyAmbmJzcDsgfCZuYnNwOyBjcCZuYnNwOyB8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7 LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZp Z3VyZSA3OiBDaGVjayBMaXN0IFN0YXRlIHdpdGggTmV3bHkgRm9ybWVkIFBhaXIsIENhc2UgMzxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhc2UgNDogSW4g YWxsIG90aGVyIGNhc2VzLCBzZXQgdGhlIHN0YXRlIHRvIEZyb3plbi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IyMjPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO1BldGVyPGJyPg0KJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB82DFEESESSMB109erics_-- From nobody Mon Apr 24 11:39:58 2017 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 D01F4127241 for ; Mon, 24 Apr 2017 11:39:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9sEoB3oMonOo for ; Mon, 24 Apr 2017 11:39:55 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE7E1270FC for ; Mon, 24 Apr 2017 11:39:55 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3OIdoW9029676; Mon, 24 Apr 2017 14:39:50 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2a01x6srpx-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Apr 2017 14:39:50 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 24 Apr 2017 13:39:49 -0500 From: Jonathan Lennox To: Nils Ohlmeier CC: Taylor Brandstetter , Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] negotiating trickle: always session-level? Thread-Index: AQHSvSmy+JgpgMCu60Ca6vZ7bFeToKHVLcsA Date: Mon, 24 Apr 2017 18:39:48 +0000 Message-ID: References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> In-Reply-To: <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.243.43.122] Content-Type: multipart/alternative; boundary="_000_EA9684B39A544024B5F84BA91C7116EAvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240314 Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:39:57 -0000 --_000_EA9684B39A544024B5F84BA91C7116EAvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBcHIgMjQsIDIwMTcsIGF0IDI6MjAgUE0sIE5pbHMgT2hsbWVpZXIgPG5vaGxtZWllckBt b3ppbGxhLmNvbTxtYWlsdG86bm9obG1laWVyQG1vemlsbGEuY29tPj4gd3JvdGU6DQoNCg0KT24g QXByIDI0LCAyMDE3LCBhdCAxMTowNiwgVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29v Z2xlLmNvbTxtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpBbHRob3VnaCB0 aGlzIG1ha2VzIG1lIHdvbmRlciBob3cgdG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hlcmUgYWxs IG0tc2VjdGlvbnMgaGF2ZSB0aGUgaWNlLW9wdGlvbnMsIGJ1dCBvbmUgaW5kaWNhdGVzIHN1cHBv cnQgZm9yIHRyaWNrbGUgYW5kIGFub3RoZXIgZG9lcyBub3QuDQoNCkkgYmVsaWV2ZSB0aGlzIGlz IGV4YWN0bHkgd2hhdCBicm91Z2h0IHVwIHRoZSBpc3N1ZS4gTXkgc3VnZ2VzdGlvbiBpcyB0byBq dXN0IG1ha2UgdGhpcyBpbGxlZ2FsIGFuZCBpbnRlcnByZXQgaXQgYXMgaW52YWxpZCBTRFAuDQoN CknigJltIGZpbmUgd2l0aCB0aGF0LiBCdXQgdGhlbiBJIHdvdWxkIHRoaW5rIGl0IHNob3VsZCBz YXkgTVVTVCBOT1QgbGlrZSBQZXRlciBzdWdnZXN0ZWQgdG8gbWFrZSBpdCBleHBsaWNpdC4NCg0K UHJvYmFibHkgSeKAmW0gbWlzc2luZyBhIHBvaW50IGhlcmUsIGJ1dCBpZiB0aGUgdHJpY2tsZSBp Y2Utb3B0aW9ucyBuZWVkIHRvIGJlIGlkZW50aWNhbCBhY3Jvc3MgYWxsIG0tc2VjdGlvbnMgd2hh dCBpcyB0aGUgZGlmZmVyZW5jZSB0byBhIHNlc3Npb24gbGV2ZWwgYXR0cmlidXRlIHRoZW4gKGV4 Y2VwdCB0aGF0IGEgcmVjZWl2ZXIgd291bGQgbmVlZCB0byBjaGVjayBmb3IgY29uc2lzdGVuY3kg b2YgYWxsIGF0dHJpYnV0ZXMgYW5kIHJlamVjdCk/DQpJcyB0aGUgcmVhc29uIG9ubHkgdGhhdCBp Y2Utb3B0aW9ucyBpbiBnZW5lcmFsIGFyZSBhbGxvd2VkIGluIG0tc2VjdGlvbnMgYW5kIHdlIGNh buKAmXQgbWFuZGF0ZSB0aGUgdHJpY2tsZSBvcHRpb24gb25seSB0byBiZSB1c2VkIGF0IHRoZSBz ZXNzaW9uIGxldmVsIGljZS1vcHRpb25zPw0KDQpUaGUgZ2VuZXJhbCByZWFzb24gaWNlLW9wdGlv bnMgYXJlIGFsbG93ZWQgYXQgdGhlIG1lZGlhIGxldmVsIGlzIHRvIGhhbmRsZSBkaXN0cmlidXRl ZCBtZWRpYSBjYXNlcyDigJQgc29tZSB2YXJpZXR5IG9mIDNQQ0MgbWlnaHQgYmUgYWdncmVnYXRp bmcgc2V2ZXJhbCBkaWZmZXJlbnQgZW5kIHN5c3RlbXPigJkgSUNFIHNlc3Npb25zLg0KDQpJdCBz ZWVtcyBwb3NzaWJsZSB0aGlzIHVzZSBjYXNlIGNhbuKAmXQgYmUgbWFkZSB0byB3b3JrIGZvciB0 cmlja2xlLCBpbiB3aGljaCBjYXNlIHdlIG5lZWQgdG8gaGF2ZSB0aGUgb3B0aW9uIGFsaWduZWQg YWNyb3NzIGFsbCBtZWRpYSBzZXNzaW9ucy4gIChTbyBhIDNQQ0Mgd291bGQgaGF2ZSB0byBmb3Jj ZSBhbGwgaXRzIGNvbnRyb2xsZWQgc3lzdGVtcyBiYWNrIHRvIG5vbi10cmlja2xlIGlmIHRoZXkg ZG9u4oCZdCBhbGwgc3VwcG9ydCB0cmlja2xlLCBidXQgdGhhdOKAmWQgYmUgcmVhc29uYWJseSBz dHJhaWdodGZvcndhcmQgdG8gZG8uKQ0KDQo= --_000_EA9684B39A544024B5F84BA91C7116EAvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIg MjQsIDIwMTcsIGF0IDI6MjAgUE0sIE5pbHMgT2hsbWVpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpu b2hsbWVpZXJAbW96aWxsYS5jb20iIGNsYXNzPSIiPm5vaGxtZWllckBtb3ppbGxhLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMjQsIDIwMTcsIGF0 IDExOjA2LCBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGVhZGJlZWZA Z29vZ2xlLmNvbSIgY2xhc3M9IiI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29s aWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuOHB4IiBjbGFzcz0iIj5BbHRob3VnaCB0aGlzIG1ha2VzIG1lIHdvbmRlciBob3cg dG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hlcmUgYWxsIG0tc2VjdGlvbnMgaGF2ZSB0aGUgaWNl LW9wdGlvbnMsIGJ1dCBvbmUgaW5kaWNhdGVzIHN1cHBvcnQgZm9yIHRyaWNrbGUgYW5kIGFub3Ro ZXIgZG9lcyBub3QuPC9zcGFuPjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYmVsaWV2ZSB0aGlzIGlzIGV4YWN0bHkgd2hh dCBicm91Z2h0IHVwIHRoZSBpc3N1ZS4gTXkgc3VnZ2VzdGlvbiBpcyB0byBqdXN0IG1ha2UgdGhp cyBpbGxlZ2FsIGFuZCBpbnRlcnByZXQgaXQgYXMgaW52YWxpZCBTRFAuPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPknigJltIGZpbmUgd2l0aCB0aGF0LiBCdXQgdGhlbiBJIHdvdWxkIHRoaW5rIGl0IHNob3Vs ZCBzYXkgTVVTVCBOT1QgbGlrZSBQZXRlciBzdWdnZXN0ZWQgdG8gbWFrZSBpdCBleHBsaWNpdC48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlByb2JhYmx5IEnigJltIG1pc3NpbmcgYSBwb2ludCBoZXJlLCBidXQgaWYgdGhlIHRyaWNrbGUg aWNlLW9wdGlvbnMgbmVlZCB0byBiZSBpZGVudGljYWwgYWNyb3NzIGFsbCBtLXNlY3Rpb25zIHdo YXQgaXMgdGhlIGRpZmZlcmVuY2UgdG8gYSBzZXNzaW9uIGxldmVsIGF0dHJpYnV0ZSB0aGVuIChl eGNlcHQgdGhhdCBhIHJlY2VpdmVyIHdvdWxkIG5lZWQgdG8gY2hlY2sgZm9yIGNvbnNpc3RlbmN5 IG9mIGFsbCBhdHRyaWJ1dGVzDQogYW5kIHJlamVjdCk/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklz IHRoZSByZWFzb24gb25seSB0aGF0IGljZS1vcHRpb25zIGluIGdlbmVyYWwgYXJlIGFsbG93ZWQg aW4gbS1zZWN0aW9ucyBhbmQgd2UgY2Fu4oCZdCBtYW5kYXRlIHRoZSB0cmlja2xlIG9wdGlvbiBv bmx5IHRvIGJlIHVzZWQgYXQgdGhlIHNlc3Npb24gbGV2ZWwgaWNlLW9wdGlvbnM/PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 PlRoZSBnZW5lcmFsIHJlYXNvbiBpY2Utb3B0aW9ucyBhcmUgYWxsb3dlZCBhdCB0aGUgbWVkaWEg bGV2ZWwgaXMgdG8gaGFuZGxlIGRpc3RyaWJ1dGVkIG1lZGlhIGNhc2VzIOKAlCBzb21lIHZhcmll dHkgb2YgM1BDQyBtaWdodCBiZSBhZ2dyZWdhdGluZyBzZXZlcmFsIGRpZmZlcmVudCBlbmQgc3lz dGVtc+KAmSBJQ0Ugc2Vzc2lvbnMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj5JdCBzZWVtcyBwb3NzaWJsZSB0aGlzIHVzZSBjYXNlIGNhbuKAmXQgYmUgbWFkZSB0byB3 b3JrIGZvciB0cmlja2xlLCBpbiB3aGljaCBjYXNlIHdlIG5lZWQgdG8gaGF2ZSB0aGUgb3B0aW9u IGFsaWduZWQgYWNyb3NzIGFsbCBtZWRpYSBzZXNzaW9ucy4gJm5ic3A7KFNvIGEgM1BDQyB3b3Vs ZCBoYXZlIHRvIGZvcmNlIGFsbCBpdHMgY29udHJvbGxlZCBzeXN0ZW1zIGJhY2sgdG8gbm9uLXRy aWNrbGUgaWYgdGhleSBkb27igJl0IGFsbCBzdXBwb3J0IHRyaWNrbGUsDQogYnV0IHRoYXTigJlk IGJlIHJlYXNvbmFibHkgc3RyYWlnaHRmb3J3YXJkIHRvIGRvLik8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EA9684B39A544024B5F84BA91C7116EAvidyocom_-- From nobody Mon Apr 24 11:47:36 2017 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 34F7213193A for ; Mon, 24 Apr 2017 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 c606nhXHmN-8 for ; Mon, 24 Apr 2017 11:47:33 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 6EED7131935 for ; Mon, 24 Apr 2017 11:47:33 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id c198so16361701pfc.1 for ; Mon, 24 Apr 2017 11:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3jlQAuacwcnu2oOH/nBcFtFktUuAe30aoFBIZx09DeM=; b=YeRX1rSLtKacuJ6UoufG16PzHMZhneHv4a6qUginwskqm+U6bV7ktFZeXhOKfCDvat d5AV7mLptH+gMR+Ozk9S9Ad6qFVzeB59i6OikWuJE+Q2d3MeE5veiRWWUIndwNwD46am vGpd2nis8zVrxOjjOivsXgjk7rT9raJFQeiaA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3jlQAuacwcnu2oOH/nBcFtFktUuAe30aoFBIZx09DeM=; b=HuUJaU7ZxJGGljULkMYjEUSe2XjCTNPTVWdeSDgS0TwYxkYO5nI7OqT/zpiL8ouOQm JMGkyT9ezUxzxr84hG+3F5DWVcyaQIVcxo1OJBP/0Oqjj7NV8dJeEcCTXodzm6aaKrrt /T6yhQYEIbFua5+4pw7WOxaVfs2RJ7avlPYfs9ub5504/LlBLG6r4C2Q65G8W66cBR4C s3cwKXPjcIkARpfpRECt44fxpF6XVlp4C41vit+rwnik1y7KpxdUUEukVE9OFgAs0Fd9 IaI1xEwsBP//qQU+JWWWOXJh4545ifyfMw9Qc9WVJioaU1XR8IM9THjsFMbZaoeJLyJ2 UcOw== X-Gm-Message-State: AN3rC/7ZKZvrPDeSn20gCij9ebLHeS3Sv1HAgX4PjFl30zgNnCJS1Hor aJd0hcqK2jfE0QRb X-Received: by 10.99.101.135 with SMTP id z129mr26285690pgb.164.1493059652945; Mon, 24 Apr 2017 11:47:32 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:3122:e88f:1459:8313? ([2620:101:80fc:224:3122:e88f:1459:8313]) by smtp.gmail.com with ESMTPSA id s7sm15551380pgs.52.2017.04.24.11.47.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 11:47:31 -0700 (PDT) From: Nils Ohlmeier Message-Id: <3CB56B6C-20AB-4353-A2B4-C09A2F4E2F36@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C7346C4E-589B-46A0-B0E8-3095DE38D7AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 11:47:29 -0700 In-Reply-To: Cc: Taylor Brandstetter , Peter Saint-Andre , "ice@ietf.org" To: Jonathan Lennox References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:47:35 -0000 --Apple-Mail=_C7346C4E-589B-46A0-B0E8-3095DE38D7AA Content-Type: multipart/alternative; boundary="Apple-Mail=_4ACAB02D-F4DC-454B-99F2-2923468EE8ED" --Apple-Mail=_4ACAB02D-F4DC-454B-99F2-2923468EE8ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 24, 2017, at 11:39, Jonathan Lennox wrote: >=20 >>=20 >> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier > wrote: >>=20 >> I=E2=80=99m fine with that. But then I would think it should say MUST = NOT like Peter suggested to make it explicit. >>=20 >> Probably I=E2=80=99m missing a point here, but if the trickle = ice-options need to be identical across all m-sections what is the = difference to a session level attribute then (except that a receiver = would need to check for consistency of all attributes and reject)? >> Is the reason only that ice-options in general are allowed in = m-sections and we can=E2=80=99t mandate the trickle option only to be = used at the session level ice-options? >=20 > The general reason ice-options are allowed at the media level is to = handle distributed media cases =E2=80=94 some variety of 3PCC might be = aggregating several different end systems=E2=80=99 ICE sessions. >=20 > It seems possible this use case can=E2=80=99t be made to work for = trickle, in which case we need to have the option aligned across all = media sessions. (So a 3PCC would have to force all its controlled = systems back to non-trickle if they don=E2=80=99t all support trickle, = but that=E2=80=99d be reasonably straightforward to do.) Okay. I guess the other option would be to allow different values in the = trickle RFC itself. And then WebRTC for example would have to forbid it = to avoid confusion with the PeerConnection canTrickle property. Best Nils --Apple-Mail=_4ACAB02D-F4DC-454B-99F2-2923468EE8ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 24, 2017, at 11:39, Jonathan Lennox <jonathan@vidyo.com> = wrote:


On Apr 24, 2017, at 2:20 PM, Nils = Ohlmeier <nohlmeier@mozilla.com> wrote:

I=E2=80=99m fine with that. But then I would think it should = say MUST NOT like Peter suggested to make it explicit.

Probably I=E2=80=99m = missing a point here, but if the trickle ice-options need to be = identical across all m-sections what is the difference to a session = level attribute then (except that a receiver would need to check for = consistency of all attributes and reject)?
Is the = reason only that ice-options in general are allowed in m-sections and we = can=E2=80=99t mandate the trickle option only to be used at the session = level ice-options?

The= general reason ice-options are allowed at the media level is to handle = distributed media cases =E2=80=94 some variety of 3PCC might be = aggregating several different end systems=E2=80=99 ICE = sessions.

It = seems possible this use case can=E2=80=99t be made to work for trickle, = in which case we need to have the option aligned across all media = sessions.  (So a 3PCC would have to force all its controlled = systems back to non-trickle if they don=E2=80=99t all support trickle, = but that=E2=80=99d be reasonably straightforward to = do.)

Okay. = I guess the other option would be to allow different values in the = trickle RFC itself. And then WebRTC for example would have to forbid it = to avoid confusion with the PeerConnection canTrickle = property.

Best
  Nils

= --Apple-Mail=_4ACAB02D-F4DC-454B-99F2-2923468EE8ED-- --Apple-Mail=_C7346C4E-589B-46A0-B0E8-3095DE38D7AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/khBAAoJEJ3NnGfOORkk2E0P/jAXwqnm1d6K8NXbMS49/yg+ lBiJ4ZmJuvqatS5RzgxmSdJn6W0gUyxAlSaqgaZIvPEzjtuCFpgd+sV9Apdkx3v2 jD15teVuS9WO7ggzkAlR393i046REg319SgYFVUEj0zLwK/2PHw409aZiE6WLveH 62oDt/TT7amGDW15cvBgpsM3WcMYOPgXe69zbD9OcZmm98hHhYsi9br1vvemMP11 D6oTkjNl9bvB+KX5c3vhnylZriShXeHEl8PASs3epHqRo2mc8pWohWjw1/v4I7mC zIcXuhsLnknStqProF/lesVhtsYo8V7WNy2W8PFYohNNJeJaBLG29RWW9rnmjT2c 6y6VzWU37LT8s0U4tuS0dHQ5RDByGGt2NGZAQDssF+svUSaVXZwHDC961MTkvLzR gFrB0YcU2Wx7QWHfsarKtevOhEFnpYbRkYCwAa441qtz3t99Lp/bejm+YH0Jns40 HhNMglKSQZpOuaJBBLignX3rrC6Fv2mJT8O1oDAiJDippiV8DLc5xKbZXCISnKxC hUyQRAVXQDdfpz3lw5eONZhcTxzsUU5paePWdpw/HcD1zMZyoeoRPo8MzaLEgEnq 8SBrytKJYtA6nC1KfB9B0GsFB8j+mecwOvDb1QzQXLcnDgsywWOcv9kcBwBIB/Q2 ad1vRdO2NdOW+n6Elby2 =YRlF -----END PGP SIGNATURE----- --Apple-Mail=_C7346C4E-589B-46A0-B0E8-3095DE38D7AA-- From nobody Mon Apr 24 20:03:53 2017 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 E04E31319AF for ; Mon, 24 Apr 2017 20:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Dg765/jJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DYsg3z78 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 s8kWdSaZVko2 for ; Mon, 24 Apr 2017 20:03:49 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B639131846 for ; Mon, 24 Apr 2017 20:03:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C562520B37; Mon, 24 Apr 2017 23:03:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 24 Apr 2017 23:03:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=5ydZAwqffr7apEB/Tw VBzeOJyzQM1wYrzGg28cOORN4=; b=Dg765/jJ5Ra/7ynOBPbDqvL9HHYTXuCIiX /rjT59C9UG13xjhN+lVBEPob0vDHqAsaiu47H64GN3hhrUrRe7QvzchWNgDCigv0 1o5jwVaNGqNe2at8/N1spmnsxKYWyV+O5bK3zTowNo75GICcJxB1XD1lHAkfdV31 oq+AXht/wN6mjk0QjymniO5+A2dCVUKiiMxmStj/To4bOKW7Sf1+U3w/QkotWixb wD1KFbfIvJEOkydHU4DNqwDXLz0KcboiQaqqI58oUm3B3C16MJOXOyyQfk15egYn c+iZGuiTbWk3rS6Cjnya7RuCByzuYENhZjuk/Nv5U41yZO/HaVLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=5ydZAwqffr7apEB/TwVBzeOJyzQM1wYrzGg28cOORN4=; b=DYsg3z78 VLXYJkpN1lyMjouoVden4xfPXn4Nc4VIKQST+nDKOnkXQQM9xtYnPoBcmBdsAdgM IoSlruehsrrpfH0kGKd8zeGNTOZiht2602YJObJhpfT1CywLpeJ6NHefPscEaurg S8DdLojrPyp4EgvWfrLicKQcXihXg+iVIl1yRmMeRbYGkWZd4a+sSFEbr04RBPJZ y4eaFjkEu2UeJM3gM+ACdDbLJh8ceZsCumzHkS8wl6TY76ORWGC3PyucLcMHJAEU dZ3olsDHzH1wckfZZEcZ42t1+fjHi6TQ2w8OSjHsMG3eRn0BB6yGsOFIjSbst34S i9zOCFSgMtAZiQ== X-ME-Sender: X-Sasl-enc: vHBH0WN+/lOjPlQLjlV9I2LUbGC0FV2LCVEUrX8hEovd 1493089428 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 1C2A72466B; Mon, 24 Apr 2017 23:03:48 -0400 (EDT) To: Jonathan Lennox , Nils Ohlmeier References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> Cc: Taylor Brandstetter , "ice@ietf.org" From: Peter Saint-Andre Message-ID: <8b6c9412-2daf-7447-4292-ade4278a8be0@stpeter.im> Date: Mon, 24 Apr 2017 21:03:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 03:03:51 -0000 On 4/24/17 12:39 PM, Jonathan Lennox wrote: > >> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier > > wrote: >> >> >>> On Apr 24, 2017, at 11:06, Taylor Brandstetter >> > wrote: >>> >>> Although this makes me wonder how to handle the situation where >>> all m-sections have the ice-options, but one indicates support >>> for trickle and another does not. >>> >>> >>> I believe this is exactly what brought up the issue. My suggestion is >>> to just make this illegal and interpret it as invalid SDP. >> >> I’m fine with that. But then I would think it should say MUST NOT like >> Peter suggested to make it explicit. >> >> Probably I’m missing a point here, but if the trickle ice-options need >> to be identical across all m-sections what is the difference to a >> session level attribute then (except that a receiver would need to >> check for consistency of all attributes and reject)? >> Is the reason only that ice-options in general are allowed in >> m-sections and we can’t mandate the trickle option only to be used at >> the session level ice-options? > > The general reason ice-options are allowed at the media level is to > handle distributed media cases — some variety of 3PCC might be > aggregating several different end systems’ ICE sessions. > > It seems possible this use case can’t be made to work for trickle, in > which case we need to have the option aligned across all media sessions. > (So a 3PCC would have to force all its controlled systems back to > non-trickle if they don’t all support trickle, but that’d be reasonably > straightforward to do.) Yes, that seems like a possibility (although perhaps unattractive - we wouldn't get the benefits of Trickle until all the controlled systems support it). Peter From nobody Mon Apr 24 20:06:03 2017 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 37F751319B1 for ; Mon, 24 Apr 2017 20:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=hpN8HXC7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KAGSw/LC 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 sgXDDkKHCuqj for ; Mon, 24 Apr 2017 20:06:01 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EA0131968 for ; Mon, 24 Apr 2017 20:06:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BA57F20CB2; Mon, 24 Apr 2017 23:06:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 24 Apr 2017 23:06:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=QQJKfzEA8/A76VTkcQ sQN7X9V2slYt26hWh1DFJQuaU=; b=hpN8HXC7PKT8im34+QBzAgCBtDsrZRjmMG OYECVogZrfxbYnkOr38DB4jcPfHcJk+UK4tBOHD+H84ebTtHbQ1MUEoXk1wVOawJ OSTTr/nmkgWMDotGTCeG5XPB8RO5GTCO4LLZV9/kKRsmy2jPt1hmXwJMVdOZccjf Y00Mm/lSEdQpoenuInN4ZTD9rnDu1uGLdjffAFHp8acDbzGRPqrCQHKmJhHaSpiU IznF6CIVq3Vn+9RB9x8xavOLQcl0ZqnZU0CqHxrGzpCGGbyNTHtXvPUQBKVwAGZd yVwJbr/oT6Bug5VdwB4PR4RbCFh1iMRdzLimi9csy3PexRW6/zMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=QQJKfzEA8/A76VTkcQsQN7X9V2slYt26hWh1DFJQuaU=; b=KAGSw/LC dfR1ynujZWxUzIMmmDkRwi+R4PYehZyPX4thswexVml4dAE8Jd4euaqr8qw3PFE2 xdZ6rzfoGhX/pItpucAAVBor1g7B20CU7GHZh6av4smbVwVlX3Zlj5Ov1M8RK6Jy YyCHikPrGO0DX/Gdr0kBVX1pwlpBDFhh5r+wjNvj7HvXpgVDwQNZkqEJ2lHIi/zZ h6lfMcBMl036JFRS6esw483Sf/0F775+yootpmdTjeoa1qHm0EPmwvpJwMQ6v/+G rc73061lTzFtsPvukP9/D5Vf8rVf9lyOYTicTekq/yxmiHSNtJ/g4lq+O76VUl7D GDrQ4Z5NaMwRFQ== X-ME-Sender: X-Sasl-enc: v73/2ODeJmHxAjPtF2/A+JnhyofMSH/UPENE5dsoM75v 1493089560 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 45420246CA; Mon, 24 Apr 2017 23:06:00 -0400 (EDT) To: Taylor Brandstetter References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <6eec7121-f612-b95c-0d7d-6c7a29da07ff@stpeter.im> Date: Mon, 24 Apr 2017 21:05:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 03:06:02 -0000 On 4/24/17 12:01 PM, Taylor Brandstetter wrote: > Does that mean we'd go directly from WFFFFF to SWWWWW? > > > Yes; when I was typing up the example I hadn't noticed that the "each > component of the media stream" part had been removed from 5245bis. > > My interpretation of Case 1 is that only the topmost pair for that > foundation is set to waiting, however you seem to interpret it to mean > the topmost pair for that media stream. > > > No, I also interpret it as "topmost for foundation". > > I think the fix we need to make is to Case 3 (change "below" to > "above"). > > > I think you could merge cases 2 and 3 and make it "another pair in the > same column is in the Succeeded state." Maybe. I'll look at that more closely in the next day or two... Peter From nobody Tue Apr 25 04:24:43 2017 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 73A5712EC05 for ; Tue, 25 Apr 2017 04:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, URIBL_BLOCKED=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 Tw9PB9r0ec5z for ; Tue, 25 Apr 2017 04:24: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 AF98D12EBFD for ; Tue, 25 Apr 2017 04:24:35 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-8a-58ff31f13917 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id A7.DA.20220.1F13FF85; Tue, 25 Apr 2017 13:24:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Tue, 25 Apr 2017 13:20:13 +0200 From: Christer Holmberg To: Taylor Brandstetter , Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt Thread-Index: AQHSqd+v5pTH7eT1WEqm0CcDG080LaHKbvUAgAF4q4CAB5xggIABUGyAgAApAUCAASy1gA== Date: Tue, 25 Apr 2017 11:20:13 +0000 Message-ID: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB82DFE@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB82DFE@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D5250C8A1BA82christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7ru4nw/8RBq0dTBaXVzxktfh2odbi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsErozTp44xFvx9w1Rxb+kntgbG x6uYuhg5OSQETCSWz/3A2MXIxSEksJ5R4tKRPlYIZwmjxP+p89i6GDk42AQsJLr/aYOYIgLh EufX5oCYzAKKEi/3qoGMERZwljg+/QbYSBEBF4n1vb9ZIKrDJHaeMQAJswioSuzYdJgFxOYV sJZ43TkNalEXs8Skc0fBFnEK+Ek8mGoEUsMoICbx/dQasJHMAuISt57Mh7pYQGLJnvPMELao xMvH/1hBbFEBPYl9/76yQcQVJXaebWeG6E2QuH3jATPEXkGJkzOfsExgFJ2FZOwsJGWzkJRB xHUkFuz+xAZha0ssW/iaGcY+c+AxVK+1xJTDT1HULGDkWMUoWpxanJSbbmSsl1qUmVxcnJ+n l5dasokRGJUHt/xW3cF4+Y3jIUYBDkYlHt4HLP8ihFgTy4orcw8xSnAwK4nwXgIJ8aYkVlal FuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwBgic47xg6STYChPSM/E +6kPJZJ+c/02n8R2R0PR5cpd+Vo9S8+EmQUOj5Jyf+iXn17JV8yeZHqnQ87Tvavm8punFiyb oi55Pi34r7diwZNiyaqnZpFzL2hfzFnGL71hRYHlDDENzzDzrZyBh7qnXi2a9bQnhmVjrafZ 2yPyZ6wXnPxm90ktSYmlOCPRUIu5qDgRAIsLNWTGAgAA Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:24:41 -0000 --_000_D5250C8A1BA82christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In general, if something is unclear in 5245bis, please let the authors know= . One of the main reasons for doing 5245bis in the first place is to clarif= y the procedures. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Monday 24 April 2017 at 21:29 To: Taylor Brandstetter >, = "stpeter@stpeter.im" > Cc: "ice@ietf.org" > Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt Hi, Initially, before the checks begin, only the topmost pair for each foundati= on is set to waiting. Regards, Christer From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Taylor Brandstetter Sent: 24 April 2017 20:02 To: Peter Saint-Andre > Cc: ice@ietf.org Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt Does that mean we'd go directly from WFFFFF to SWWWWW? Yes; when I was typing up the example I hadn't noticed that the "each compo= nent of the media stream" part had been removed from 5245bis. My interpretation of Case 1 is that only the topmost pair for that foundation is set to waiting, however you seem to interpret it to mean the topmost pair for that media stream. No, I also interpret it as "topmost for foundation". I think the fix we need to make is to Case 3 (change "below" to "above"). I think you could merge cases 2 and 3 and make it "another pair in the same= column is in the Succeeded state." On Sun, Apr 23, 2017 at 2:57 PM, Peter Saint-Andre > wrote: On 4/18/17 7:44 PM, Taylor Brandstetter wrote: > Taylor, would you mind spelling this out a bit more fully and point t= o > discrepancies between the text of 5245bis and the text of the Trickle > spec? I'm sure I'm missing something, but I don't yet see the truth o= f > your statement that "only the topmost remaining pair in each foundati= on > is guaranteed to be unfrozen". > > > Sure; let me try to give an example. > > Suppose I have three media streams, and one foundation (let's keep it > simple). I'll represent the states like this for brevity: "SWFFFF", > where "S" is "succeeded", "W" is "waiting", and "F" is "frozen". And > they're ordered in the same way as the rows in your table above. > > With non-trickle ICE, here's what would typically happen: > > 1. Only the RTP candidate pair for the first media stream is unfrozen > initially. > State: WFFFFF > 2. Check succeeds for RTP candidate pair. RTCP pair unfrozen. > State: SWFFFF Section 6.2.5.3.3 of 5245bis states: The success of the connectivity check might also cause the state of other candidate pairs to change. The ICE agent MUST set the states for all other Frozen candidate pairs (in each CHECK LIST in the CHECK LIST SET) with the same foundation to Waiting. Does that mean we'd go directly from WFFFFF to SWWWWW? > 3. Check succeeds for RTCP pair. /All/ the other pairs with the same > foundation are now unfrozen. > State: SSWWWW > > With trickle ICE, here's what could happen: > > 1. Candidates for the first media stream are trickled in. Starts out > just like normal ICE. > State: WF > 2. Checks for both pairs succeed. Still waiting for candidates for > other media streams. > State: SS > 3. Candidates for the other media streams arrive, and pairs are formed. > The topmost pair is set to waiting, but not the others. > State: SSWFFF Thanks for the example. My interpretation of Case 1 is that only the topmost pair for that foundation is set to waiting, however you seem to interpret it to mean the topmost pair for that media stream. I agree that the rules in draft-ietf-ice-trickle-08 aren't quite right. If we accept my interpretation of the "topmost pair" rule, then I think the fix we need to make is to Case 3 (change "below" to "above"). In the interest of time, I'm going to submit -09 right now so that we have a document and diff to review, not just these long email messages. Peter > So, where normal ICE ensures that once a foundation is proven to work > (for both components of a media stream), all other pairs with that > foundation are unfrozen, trickle ICE only guarantees that one of them is. > > On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre > >> wrote: > > On 3/30/17 11:28 PM, Taylor Brandstetter wrote: > > [areas of seeming agreement elided] > > > * In section 8.1.1: In general I like the improvements that have > been > > made. However: > > o The rules for how a new pair gets either a "Waiting" or > "Frozen" > > state don't completely match standard ICE; at least the par= t > > where when one "media stream" completes, pairs from other m= edia > > streams with matching foundations are unfrozen. With the cu= rrent > > rules in section 8.1.1, only the topmost remaining pair in = each > > foundation is guaranteed to be unfrozen. Is this difference > > acceptable? If it is, we should at least acknowledge it, an= d not > > give the wrong impression by saying "Trickle ICE preserves = all > > of [the standard ICE] rules." > > Taylor, would you mind spelling this out a bit more fully and point t= o > discrepancies between the text of 5245bis and the text of the Trickle > spec? I'm sure I'm missing something, but I don't yet see the truth o= f > your statement that "only the topmost remaining pair in each foundati= on > is guaranteed to be unfrozen". > > In particular, your statement doesn't seem to match the rules defined= in > the Trickle spec. I've tried to spell them out in greater detail (wit= h > examples) in the following proposed text. > > ### > > > 8.1.1. Inserting a New Pair in a Check List > > Consider the following tabular representation of all checklists in= an > agent: > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | cp | cp | cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | cp | cp | cp | cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 1: Example of Check List State > > Each row in the table represents a component for a given media str= eam > (e.g., m1 and m2 might be the RTP and RTCP components for audio). > Each column represents one foundation. Each cell represents one > candidate pair. > > When an agent commences ICE processing, in accordance with > Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in t= he > Waiting state) the topmost candidate pair in every column (i.e., t= he > pair with the lowest component ID). This state is shown in the > following table, with candidate pairs in the Waiting state marked = by > "w-cp". > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | w-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 2: Initial Check List State > > Then, as the checks proceed (see Section 6.1.2.4.2.3 of > [rfc5245bis]), for each pair that enters the Succeeded state (deno= ted > here by "s-cp"), the agent will unfreeze all pairs for the same me= dia > stream and foundation (e.g., if the pair in column 1, row 1 succee= ds > then the agent will unfreeze the pair in column 1, row 2). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 3: Check List State after Succeeded Check > > ICE also specifies that, if all the pairs in a media stream for on= e > foundation are unfrozen (e.g., column 1, rows 1 and 2 representing > both components for the audio stream), then all of the candidate > pairs in the entire column are unfrozen (e.g., column 1, rows 3 an= d > 4). > > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 4: Check List State with Unfrozen Media Stream > > Trickle ICE preserves all of these rules as they apply to what we > might call "static" check list sets. This implies that if, for so= me > reason, a Trickle agent were to begin connectivity checks with all= of > its pairs already present, the way that pair states change is > indistinguishable from that of a regular ICE agent. > > Of course, the major difference with Trickle ICE is that check lis= t > sets can be dynamically updated because candidates can arrive afte= r > connectivity checks have started. When this happens, an agent set= s > the state of the newly formed pair as described below. > > Case 1: If the newly formed pair is the topmost pair in this colum= n, > set the state to Waiting (e.g., this would be the case if the newl= y > formed pair were placed in column 4, row 1). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 5: Check List State with Newly Formed Pair, Case 1 > > Case 2: If the pair immediately above the newly formed pair in thi= s > column is in the Succeeded state, set the state to Waiting (e.g., > this would be the case if the pair in column 4, row 2 succeeded an= d > the newly formed pair were placed in column 4, row 3); > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 6: Check List State with Newly Formed Pair, Case 2 > > Case 3: If there is at least one pair in this column below the row= of > the newly formed pair whose state is either Succeeded or Failed > (e.g., this would be the case if the pair in column 4, row 2 > succeeded and the newly formed pair were placed in column 4, row 1= ). > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | s-cp | w-cp | w-cp | w-cp | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | w-cp | cp | cp | s-cp | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | w-cp | | | w-cp | w-cp | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | w-cp | | | | cp | > +-----------------+------+------+------+------+------+ > > > Figure 7: Check List State with Newly Formed Pair, Case 3 > > Case 4: In all other cases, set the state to Frozen. > > ### > > Peter > > --_000_D5250C8A1BA82christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

In general, if something is unclear in 5245bis, please let the authors= know. One of the main reasons for doing 5245bis in the first place is to c= larify the procedures.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb= erg <christer.holmberg= @ericsson.com>
Date: Monday 24 April 2017 at 21:29=
To: Taylor Brandstetter <deadbeef@google.com>, "stpeter@stpeter.im" <stpeter@stpeter.im>
Cc: "ice@ietf.org" <ice@ietf.= org>
Subject: Re: [Ice] Taylor's review = of draft-ietf-ice-trickle-08.txt

Hi,

 = ;

Initially,= before the checks begin, only the topmost pair for each foundation is set = to waiting.

 = ;

Regards,

 = ;

Christer

 

From: = Ice [mailto:ice-bounces@ietf.org] On Behalf Of Taylor Brandstetter
Sent: 24 April 2017 20:02
To: Peter Saint-Andre <stpe= ter@stpeter.im>
Cc: ice@ietf.org
Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt<= o:p>

 

Does that mean we'd = go directly from WFFFFF to SWWWWW?

 

Yes; when I was typing up the example I hadn't notic= ed that the "each component of the media stream" part had been re= moved from 5245bis.

 

My interpretation of= Case 1 is that only the topmost pair for that
foundation is set to waiting, however you seem to interpret it to mean
the topmost pair for that media stream.

 

No, I also interpret it as "topmost for foundat= ion".

 

 I think t= he fix we need to make is to Case 3 (change "below" to "abov= e").

 

I think you could merge cases 2 and 3 and make it &q= uot;another pair in the same column is in the Succeeded state." <= o:p>

 

On Sun, Apr 23, 2017 at 2:57 PM, Peter Saint-Andre &= lt;stpeter@stpeter.= im> wrote:

On 4/18/17 7:44 PM, Taylor Brandstetter wrote:
>     Taylor, would you mind spelling this out a bit more= fully and point to
>     discrepancies between the text of 5245bis and the t= ext of the Trickle
>     spec? I'm sure I'm missing something, but I don't y= et see the truth of
>     your statement that "only the topmost remainin= g pair in each foundation
>     is guaranteed to be unfrozen".
>
>
> Sure; let me try to give an example.
>
> Suppose I have three media streams, and one foundation (let's keep it<= br> > simple). I'll represent the states like this for brevity: "SWFFFF= ",
> where "S" is "succeeded", "W" is "w= aiting", and "F" is "frozen". And
> they're ordered in the same way as the rows in your table above.
>
> With non-trickle ICE, here's what would typically happen:
>
>  1. Only the RTP candidate pair for the first media stream is unf= rozen
>     initially.
>     State: WFFFFF
>  2. Check succeeds for RTP candidate pair. RTCP pair unfrozen. >     State: SWFFFF

Section 6.2.5.3.3 of 5245bis states:

   The success of the connectivity check might also cause the sta= te of
   other candidate pairs to change.  The ICE agent MUST set = the states
   for all other Frozen candidate pairs (in each CHECK LIST in th= e CHECK
   LIST SET) with the same foundation to Waiting.

Does that mean we'd go directly from WFFFFF to SWWWWW?

>  3. Check succeeds for RTCP pair. /All/ the other pairs with the = same
>     foundation are now unfrozen.
>     State: SSWWWW
>
> With trickle ICE, here's what could happen:
>
>  1. Candidates for the first media stream are trickled in. Starts= out
>     just like normal ICE.
>     State: WF
>  2. Checks for both pairs succeed. Still waiting for candidates f= or
>     other media streams.
>     State: SS
>  3. Candidates for the other media streams arrive, and pairs are = formed.
>     The topmost pair is set to waiting, but not the oth= ers.
>     State: SSWFFF

Thanks for the example.

My interpretation of Case 1 is that only the topmost pair for that
foundation is set to waiting, however you seem to interpret it to mean
the topmost pair for that media stream.

I agree that the rules in draft-ietf-ice-trickle-08 aren't quite right.
If we accept my interpretation of the "topmost pair" rule, then I= think
the fix we need to make is to Case 3 (change "below" to "abo= ve").

In the interest of time, I'm going to submit -09 right now so that we
have a document and diff to review, not just these long email messages.

Peter


> So, where normal ICE ensures that once a foundation= is proven to work
> (for both components of a media stream), all other = pairs with that
> foundation are unfrozen, trickle ICE only guarantee= s that one of them is.
>
> On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre = <stpeter@stpeter.im

> <mailto:stpeter@stpeter.im>> wrote:
>
>     On 3/30/17 11:28 PM, Taylor Brandstetter wrote:
>
>     [areas of seeming agreement elided]
>
>     >   * In section 8.1.1: In general I l= ike the improvements that have
>     been
>     >     made. However:
>     >       o The rules for how = a new pair gets either a "Waiting" or
>     "Frozen"
>     >         state don't c= ompletely match standard ICE; at least the part
>     >         where when on= e "media stream" completes, pairs from other media
>     >         streams with = matching foundations are unfrozen. With the current
>     >         rules in sect= ion 8.1.1, only the topmost remaining pair in each
>     >         foundation is= guaranteed to be unfrozen. Is this difference
>     >         acceptable? I= f it is, we should at least acknowledge it, and not
>     >         give the wron= g impression by saying "Trickle ICE preserves all
>     >         of [the stand= ard ICE] rules."
>
>     Taylor, would you mind spelling this out a bit more= fully and point to
>     discrepancies between the text of 5245bis and the t= ext of the Trickle
>     spec? I'm sure I'm missing something, but I don't y= et see the truth of
>     your statement that "only the topmost remainin= g pair in each foundation
>     is guaranteed to be unfrozen".
>
>     In particular, your statement doesn't seem to match= the rules defined in
>     the Trickle spec. I've tried to spell them out in g= reater detail (with
>     examples) in the following proposed text.
>
>     ###
>
>
>     8.1.1.  Inserting a New Pair in a Check List >
>        Consider the following tabular representati= on of all checklists in an
>        agent:
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  |  cp  |&n= bsp; cp  |  cp  |      |      = |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) |  cp  |  = cp  |  cp  |  cp  |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  |  cp  |&n= bsp;     |      |      |  cp&n= bsp; |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) |  cp  |  =     |      |      |  cp  = |
>        +-----------------+------+-----= -+------+------+------+
>
>
>                    &= nbsp;   Figure 1: Example of Check List State
>
>        Each row in the table represents a componen= t for a given media stream
>        (e.g., m1 and m2 might be the RTP and RTCP = components for audio).
>        Each column represents one foundation. = ; Each cell represents one
>        candidate pair.
>
>        When an agent commences ICE processing, in = accordance with
>        Section 5.1.3.6 of [rfc5245bis] it will unf= reeze (i.e., place in the
>        Waiting state) the topmost candidate pair i= n every column (i.e., the
>        pair with the lowest component ID).  T= his state is shown in the
>        following table, with candidate pairs in th= e Waiting state marked by
>        "w-cp".
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  | w-cp | w-cp | w-cp= |      |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) |  cp  |  = cp  |  cp  | w-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  |  cp  |&n= bsp;     |      |      | w-cp |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) |  cp  |  =     |      |      |  cp  = |
>        +-----------------+------+-----= -+------+------+------+
>
>
>                    &= nbsp;    Figure 2: Initial Check List State
>
>        Then, as the checks proceed (see Section 6.= 1.2.4.2.3 of
>        [rfc5245bis]), for each pair that enters th= e Succeeded state (denoted
>        here by "s-cp"), the agent will u= nfreeze all pairs for the same media
>        stream and foundation (e.g., if the pair in= column 1, row 1 succeeds
>        then the agent will unfreeze the pair in co= lumn 1, row 2).
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp= |      |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |=   cp  | w-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  |  cp  |&n= bsp;     |      |      | w-cp |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) |  cp  |  =     |      |      |  cp  = |
>        +-----------------+------+-----= -+------+------+------+
>
>
>                  Figure 3= : Check List State after Succeeded Check
>
>        ICE also specifies that, if all the pairs i= n a media stream for one
>        foundation are unfrozen (e.g., column 1, ro= ws 1 and 2 representing
>        both components for the audio stream), then= all of the candidate
>        pairs in the entire column are unfrozen (e.= g., column 1, rows 3 and
>        4).
>
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp= |      |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |=   cp  | w-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  | w-cp |   = ;   |      |      | w-cp |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) | w-cp |    &nb= sp; |      |      |  cp  |
>        +-----------------+------+-----= -+------+------+------+
>
>
>                Figure 4: Check= List State with Unfrozen Media Stream
>
>        Trickle ICE preserves all of these rules as= they apply to what we
>        might call "static" check list se= ts.  This implies that if, for some
>        reason, a Trickle agent were to begin conne= ctivity checks with all of
>        its pairs already present, the way that pai= r states change is
>        indistinguishable from that of a regular IC= E agent.
>
>        Of course, the major difference with Trickl= e ICE is that check list
>        sets can be dynamically updated because can= didates can arrive after
>        connectivity checks have started.  Whe= n this happens, an agent sets
>        the state of the newly formed pair as descr= ibed below.
>
>        Case 1: If the newly formed pair is the top= most pair in this column,
>        set the state to Waiting (e.g., this would = be the case if the newly
>        formed pair were placed in column 4, row 1)= .
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp= | w-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |=   cp  | w-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  | w-cp |   = ;   |      |      | w-cp |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) | w-cp |    &nb= sp; |      |      |  cp  |
>        +-----------------+------+-----= -+------+------+------+
>
>
>              Figure 5: Check List S= tate with Newly Formed Pair, Case 1
>
>        Case 2: If the pair immediately above the n= ewly formed pair in this
>        column is in the Succeeded state, set the s= tate to Waiting (e.g.,
>        this would be the case if the pair in colum= n 4, row 2 succeeded and
>        the newly formed pair were placed in column= 4, row 3);
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp= |      |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |=   cp  | s-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  | w-cp |   = ;   |      | w-cp | w-cp |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) | w-cp |    &nb= sp; |      |      |  cp  |
>        +-----------------+------+-----= -+------+------+------+
>
>
>              Figure 6: Check List S= tate with Newly Formed Pair, Case 2
>
>        Case 3: If there is at least one pair in th= is column below the row of
>        the newly formed pair whose state is either= Succeeded or Failed
>        (e.g., this would be the case if the pair i= n column 4, row 2
>        succeeded and the newly formed pair were pl= aced in column 4, row 1).
>
>
>        +-----------------+------+-----= -+------+------+------+
>        |            =      |  f1  |  f2  |  f3  |&nb= sp; f4  |  f5  |
>        +-----------------+------+-----= -+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp= | w-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |=   cp  | s-cp |      |
>        +-----------------+------+-----= -+------+------+------+
>        | m3 (Video.RTP)  | w-cp |   = ;   |      | w-cp | w-cp |
>        +-----------------+------+-----= -+------+------+------+
>        | m4 (Video.RTCP) | w-cp |    &nb= sp; |      |      |  cp  |
>        +-----------------+------+-----= -+------+------+------+
>
>
>              Figure 7: Check List S= tate with Newly Formed Pair, Case 3
>
>        Case 4: In all other cases, set the state t= o Frozen.
>
>     ###
>
>     Peter
>
>

 

 --_000_D5250C8A1BA82christerholmbergericssoncom_-- From nobody Tue Apr 25 10:16:46 2017 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 0C45B1316FE for ; Tue, 25 Apr 2017 10:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=F636/3j1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hgzmNg3q 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 yFNpwbQypSxD for ; Tue, 25 Apr 2017 10:16:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386881316E6 for ; Tue, 25 Apr 2017 10:13:50 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 779AA20A14; Tue, 25 Apr 2017 13:13:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 25 Apr 2017 13:13:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=PEVPZQPIKAVTgrBpg/ OArLCoeXQw+/U34VFtelg7m10=; b=F636/3j1D2UNbkz68lRWHzhetkQZUnXpf/ M8b8IejgRnaTJw2QJm8lGucgF5QBCB9y7o4hAJc7kpYhTe2x76vhaF8zG6Sp+QSS pyAj1rlB2RsWnHsvaJw68WekFmRpaVp9BiSAjmKwiSVBW2BGniIpwDp0ieRLLMO7 irCJnGmw4/ZjZJQ2dXGU0ZaQDL8WOscMsUZ9+4Rc3eSLe8pTmwzbN5310h2ZjXb+ kyQphNglFXP24okZEc/6w+mhicVoKlkzl9gTWi8G067NDFx61wTQfEUysxV/nsIw Z33Qk77H8Q4REvI/cQeuATy8fdi5nMiN52vmSDf6skj3jINIEThg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=PEVPZQPIKAVTgrBpg/OArLCoeXQw+/U34VFtelg7m10=; b=hgzmNg3q O9URcv0fBN+fTr+Wur6LzFeDYZIVLg2ujRUlDDorIIZiOKMXcLFkAuHtAeJTPSpR VI9qcyU9HGEWj2ZKdBJrx6ikMMbNIa9OLgvod686w7xxWB2eCYtJMxvks5FSYq2R 80KQmve6E/j/Nzm5rXRrxsePVSQg0tA5iIeuXrMBcCE6NLWnna0xcqKpgzlwDUHS coZU07ZmJHkLA6hpx8Hb9WCtKOljAP/ZXS1Z73j95btVuPtcdBNeh2Mxo5vN+vYT NATKXGIhbY2d4km80lP2QRRQ5zzOWaPLP3C3Vu5dcGWP55WtQVoPhMDsDsQ1Tgj+ WLn1WYGblJwVxw== X-ME-Sender: X-Sasl-enc: 9xD1ZXJDQpbrumULvSmefEtjrMUqiai+WKcYLj7MnZrt 1493140429 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 03A622473E; Tue, 25 Apr 2017 13:13:48 -0400 (EDT) To: Taylor Brandstetter References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> <6eec7121-f612-b95c-0d7d-6c7a29da07ff@stpeter.im> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <23d521f7-35e6-79c2-af48-66c834f0a8aa@stpeter.im> Date: Tue, 25 Apr 2017 11:13:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6eec7121-f612-b95c-0d7d-6c7a29da07ff@stpeter.im> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:16:44 -0000 On 4/24/17 9:05 PM, Peter Saint-Andre wrote: > On 4/24/17 12:01 PM, Taylor Brandstetter wrote: >> Does that mean we'd go directly from WFFFFF to SWWWWW? >> >> >> Yes; when I was typing up the example I hadn't noticed that the "each >> component of the media stream" part had been removed from 5245bis. >> >> My interpretation of Case 1 is that only the topmost pair for that >> foundation is set to waiting, however you seem to interpret it to mean >> the topmost pair for that media stream. >> >> >> No, I also interpret it as "topmost for foundation". >> >> I think the fix we need to make is to Case 3 (change "below" to >> "above"). >> >> >> I think you could merge cases 2 and 3 and make it "another pair in the >> same column is in the Succeeded state." > > Maybe. I'll look at that more closely in the next day or two... If we only mention Succeeded, we would lose the part of Case 3 that covers the Failed state... Peter From nobody Tue Apr 25 10:35:40 2017 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 7089C131708 for ; Tue, 25 Apr 2017 10:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=ROoJ9HL1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h953Dcjh 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 anCJP8dH082j for ; Tue, 25 Apr 2017 10:35:37 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4392C1316D4 for ; Tue, 25 Apr 2017 10:35:37 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A180621732; Tue, 25 Apr 2017 13:35:36 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 25 Apr 2017 13:35:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=U0T5dgZPqMMCSq2bib qoLW5fDfpwr3xrszn726L63zY=; b=ROoJ9HL1LEZK1r7vjXTf2XI+8L9y8sLwAc +2JWZaAOhXp+EzO1PdOJNnEVpRg7UPFkZk3WaD01KMdeICVEApAP2R8+7954zRm0 ANci/9zu2E/T+zixivskbnWOMCs/dznkOIHdO/+26J1IWFVQYbTeQatclhO/JUn9 9W4F5mO0iKaNpkxUGn6ZfkEDYZO24LhV4njaCpDOpYfOcunivhOZ6Usn7kPeM4ne g9ImU+qqy07EVe5aY2NfWrKco4Swn7TNhUezNxW3co78KUBIafBsoCzOXAjC7Rrq GiOGhGh6UsfdmnovHMx47rhd3F/kW9kiYCZHzn0uko8n2TduN/Xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=U0T5dgZPqMMCSq2bibqoLW5fDfpwr3xrszn726L63zY=; b=h953Dcjh ntom1GNli2EruiSwUWuwk4WHC4fctKZFbxSP/QNMitoIeMsqgjD2U5p/QtdTsQh7 g87HpASXfElbmQ11HkXcUrixFP3WFHOdqLXrseL4JA8aJpQt6DOop+uvy3kLPpN+ jJJ9BWNCUpXgrPtESa+ec2jyqKdpupShXguuIuKJ4lunQTmSpxMF6/yiDvVVOct2 aBsIo31ej6KdAeNIKU4fQYiCjhWkdRjnlx8pqXaEAcp5BiPJQeiJBlY5tYaSmpLJ YrHAicapb7NrNMdJOJ9a+KPj0sH/a7wuOSOxKZfWPmLtJxUL/Gqh8fbVhnD6RBMZ iezqJeoIkVgpgQ== X-ME-Sender: X-Sasl-enc: biePZ1kjBpg3p2kb0ZRKKWeHeQlepHNDaAyCVzvl6PaE 1493141736 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id D1F86241E1; Tue, 25 Apr 2017 13:35:35 -0400 (EDT) To: Jonathan Lennox , Nils Ohlmeier References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> <8b6c9412-2daf-7447-4292-ade4278a8be0@stpeter.im> Cc: Taylor Brandstetter , "ice@ietf.org" From: Peter Saint-Andre Message-ID: <7a8a6142-7e3d-353d-872a-1811ecee0337@stpeter.im> Date: Tue, 25 Apr 2017 11:35:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8b6c9412-2daf-7447-4292-ade4278a8be0@stpeter.im> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:35:38 -0000 On 4/24/17 9:03 PM, Peter Saint-Andre wrote: > On 4/24/17 12:39 PM, Jonathan Lennox wrote: >> >>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier >> > wrote: >>> >>> >>>> On Apr 24, 2017, at 11:06, Taylor Brandstetter >>> > wrote: >>>> >>>> Although this makes me wonder how to handle the situation where >>>> all m-sections have the ice-options, but one indicates support >>>> for trickle and another does not. >>>> >>>> >>>> I believe this is exactly what brought up the issue. My suggestion is >>>> to just make this illegal and interpret it as invalid SDP. >>> >>> I’m fine with that. But then I would think it should say MUST NOT like >>> Peter suggested to make it explicit. >>> >>> Probably I’m missing a point here, but if the trickle ice-options need >>> to be identical across all m-sections what is the difference to a >>> session level attribute then (except that a receiver would need to >>> check for consistency of all attributes and reject)? >>> Is the reason only that ice-options in general are allowed in >>> m-sections and we can’t mandate the trickle option only to be used at >>> the session level ice-options? >> >> The general reason ice-options are allowed at the media level is to >> handle distributed media cases — some variety of 3PCC might be >> aggregating several different end systems’ ICE sessions. >> >> It seems possible this use case can’t be made to work for trickle, in >> which case we need to have the option aligned across all media sessions. >> (So a 3PCC would have to force all its controlled systems back to >> non-trickle if they don’t all support trickle, but that’d be reasonably >> straightforward to do.) > > Yes, that seems like a possibility (although perhaps unattractive - we > wouldn't get the benefits of Trickle until all the controlled systems > support it). How about this change? OLD Even if a signaling protocol does not include a capabilities discovery method, a user agent can provide an indication within the candidate information that it supports Trickle ICE, either at the session level or for every media stream at the media stream level (e.g., in SDP this would be a token of "trickle" in the ice-options attribute). NEW Even if a signaling protocol does not include a capabilities discovery method, a user agent can provide an indication within the candidate information that it supports Trickle ICE using a token of "trickle" in the ice-options attribute. This token MUST be provided either at the session level or, if at the media stream level, for every media stream (an agent MUST NOT specify Trickle ICE support for some media streams but not others). Peter From nobody Tue Apr 25 15:16:14 2017 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 9718A1294B2 for ; Tue, 25 Apr 2017 15:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7IczwMZWCsZv for ; Tue, 25 Apr 2017 15:16:11 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75D5128BB6 for ; Tue, 25 Apr 2017 15:16:10 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id y63so128286815qkd.1 for ; Tue, 25 Apr 2017 15:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AB8emxEanYXMUOjcG3215NR4OB72/EfZwj9iI4V9kgM=; b=ZgZTN4nna/310cyHGAFMfY/H2ABNAOMGHUchmJKHKLJW/iCQt1QjAr6PqzJr4L8idE RfN3Lg5qX4vUyKQ6FkEJ/cCJm/GTt7IxBxl5QwdCbR3nHzKPahMiNb5a3CP7t/QM3dM3 WCGYoizBs2qZQD9v46AcmQbQUahLuhO5XKd5jDeEN4CkqMmj+bWp8Jl6ZY7X+UEC+OHx X9WBtEGZvN7cEApQ1IDI8+ahLqf3/+IMaN7Vir5H90RUz7C38ZLs1U+sg9ijjbob1Zfh G96dhhtbEUK0rCG+XYMPY2D13UsKNvZaQMaqQtTDYiydVVSGNdOy8ZFY47y53bhGIxIF 4QrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AB8emxEanYXMUOjcG3215NR4OB72/EfZwj9iI4V9kgM=; b=YkvdUU75YSmYbSzVpnaIcBS14jNlaWiEoWZSSxhAFw3prGOABvQ5b7M2q4fj84EG1/ PKrJ2GxNSdkYG3ivbkBQDpT6Zq5N9FCuXQR/2Br8FEROWqqBlBPem3RbNPZOq2y2C1gT a04wOfsb/xJOH2ECiFVJ103Z2NH0e05FkHkC/cfEd2eH9VdnGV4SkGebpUIJcsKazfO2 50KdC7MKHQHAzR24bUarh7CdpItazsfXd6Z5UbxtLQd1O5zqj91cJnn0prcqFFFo3FLw 3DRQBXrQ+VZ63r+W1Pnjo/9Wcau/qVm+g3Y8bVtHO/LUZ5uFN6PfxiXpoo5Ua9iWDCKU vbgg== X-Gm-Message-State: AN3rC/4OAAfclly4qPgEiyeeYUql7r91/LUY09x9B31AyYMPL/YxUGhu ze9hsHfPRK77I441dd+jwrntdJWP+SBrraXyww== X-Received: by 10.55.18.91 with SMTP id c88mr34622777qkh.143.1493158569847; Tue, 25 Apr 2017 15:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Tue, 25 Apr 2017 15:16:09 -0700 (PDT) In-Reply-To: <23d521f7-35e6-79c2-af48-66c834f0a8aa@stpeter.im> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> <6eec7121-f612-b95c-0d7d-6c7a29da07ff@stpeter.im> <23d521f7-35e6-79c2-af48-66c834f0a8aa@stpeter.im> From: Taylor Brandstetter Date: Tue, 25 Apr 2017 15:16:09 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11473eca26594d054e05123c Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:16:13 -0000 --001a11473eca26594d054e05123c Content-Type: text/plain; charset=UTF-8 Right. Though we could simplify it to two rules like so: 1. If no other pairs in the column are Waiting, set the state to Waiting. 2. If another pair in the same column is Succeeded, set the state to Waiting. Also: it looks like version 09 will unfreeze the column if any pair *fails*: Case 3: If there is at least one pair in this column above the row of > the newly formed pair whose state is either Succeeded *or Failed*, set > the state to Waiting (e.g., this would be the case if the pair in > column 5, row 1 succeeded and two newly formed pairs were placed in > column 5, rows 3 and 4). Is this intentional? On Tue, Apr 25, 2017 at 10:13 AM, Peter Saint-Andre wrote: > On 4/24/17 9:05 PM, Peter Saint-Andre wrote: > > On 4/24/17 12:01 PM, Taylor Brandstetter wrote: > >> Does that mean we'd go directly from WFFFFF to SWWWWW? > >> > >> > >> Yes; when I was typing up the example I hadn't noticed that the "each > >> component of the media stream" part had been removed from 5245bis. > >> > >> My interpretation of Case 1 is that only the topmost pair for that > >> foundation is set to waiting, however you seem to interpret it to > mean > >> the topmost pair for that media stream. > >> > >> > >> No, I also interpret it as "topmost for foundation". > >> > >> I think the fix we need to make is to Case 3 (change "below" to > >> "above"). > >> > >> > >> I think you could merge cases 2 and 3 and make it "another pair in the > >> same column is in the Succeeded state." > > > > Maybe. I'll look at that more closely in the next day or two... > > If we only mention Succeeded, we would lose the part of Case 3 that > covers the Failed state... > > Peter > > > --001a11473eca26594d054e05123c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right. Though we could simplify it to two rules like so:
  1. If no other pairs in the column are Waiting, set the state to Wa= iting.
  2. If another pair in the same column is Succeeded, set the sta= te to Waiting.
Also: it looks like version 09 will unfreeze t= he column if any pair *fails*:

=C2=A0 =C2=A0Case 3: If there is at le= ast one pair in this column above the row of
=C2=A0 =C2=A0the newly form= ed pair whose state is either Succeeded or Failed, set
=C2=A0 =C2= =A0the state to Waiting (e.g., this would be the case if the pair in
=C2= =A0 =C2=A0column 5, row 1 succeeded and two newly formed pairs were placed = in
=C2=A0 =C2=A0column 5, rows 3 and 4).

Is this intentional?

On Tue, Apr 25, 2017 at 10:13 AM, Peter Saint-Andre <= span dir=3D"ltr"><stpeter@stpeter.im> wrote:
On 4/24/17 9:05 PM, Peter Saint-Andre wrote:
> On 4/24/17 12:01 PM, Taylor Brandstetter wrote:
>>=C2=A0 =C2=A0 =C2=A0Does that mean we'd go directly from WFFFFF= to SWWWWW?
>>
>>
>> Yes; when I was typing up the example I hadn't noticed that th= e "each
>> component of the media stream" part had been removed from 524= 5bis.
>>
>>=C2=A0 =C2=A0 =C2=A0My interpretation of Case 1 is that only the to= pmost pair for that
>>=C2=A0 =C2=A0 =C2=A0foundation is set to waiting, however you seem = to interpret it to mean
>>=C2=A0 =C2=A0 =C2=A0the topmost pair for that media stream.
>>
>>
>> No, I also interpret it as "topmost for foundation".
>>
>>=C2=A0 =C2=A0 =C2=A0 I think the fix we need to make is to Case 3 (= change "below" to
>>=C2=A0 =C2=A0 =C2=A0"above").
>>
>>
>> I think you could merge cases 2 and 3 and make it "another pa= ir in the
>> same column is in the Succeeded state."
>
> Maybe. I'll look at that more closely in the next day or two...
If we only mention Succeeded, we would lose the part of Case 3 that<= br> covers the Failed state...

Peter



--001a11473eca26594d054e05123c-- From nobody Tue Apr 25 15:22:14 2017 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 01D19128D8B for ; Tue, 25 Apr 2017 15:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 22-6PwZaZpXy for ; Tue, 25 Apr 2017 15:22:11 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 9672512785F for ; Tue, 25 Apr 2017 15:22:11 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id f76so77903386qke.2 for ; Tue, 25 Apr 2017 15:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wJZ7AZuFrl5a0DHCu+oot8PFl/jM7r866fGs8sAw/SA=; b=QsDkAlm/yhLplJymT0C0yN/x+2180Od22UBliS+4U3nl3MGsqn1Am58EKr6sloAVH8 soxcuS2p9QtaH+7O9el8++1zDkw464p374pTXpyt0L6FAhKc1DSguhYhEXvPbId+Vum6 AY2cPhs+ZfGuM+vwaMTKD/OHTBbS76yOZ78f5xO/wfT+7tj6y+6+xPM+UMpfwRewSw24 MmxFFyZWfkcNgQMLNzpj7y/7jBQJci/kRTju3PxyzPDt676gWqE0w7pXEtrlGfnQsv4O +YVdEyqrK7NX65ph7K47sLQEwaZmhlsMsNRuu1xL0U1tmkyP4zOCYFNZ6rnm+a3xKHdj 0bQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wJZ7AZuFrl5a0DHCu+oot8PFl/jM7r866fGs8sAw/SA=; b=DuMWZPwLsSBYhWjV1PlI8JfM3DAFKiPyKlG/Db2Qg7+6vw0FXFQyBjZPWWDMeIGNg1 Qjo8Iwy2Dxntggnbu06YwqkWvGfWxX2CTmr24CRHAQ9GNspfXn4ytV0o4ubrqehaJZmM iyVGSKW5YBnbHizp+j4b8QuKG7nN7pMbrP/JxUEw6clFR9p/VtO/gXpngXjYc89CDe/E RLX1lR2yIQoePQ84E53xfiL1HvhiOhsIJrRT+ZgcF1GHv5pgxpiWZpqKO7jcweu3ZuH8 NXjWn6034D/P+V8Wa+8XY4dM9P7OxHeCBMPWzJ12E15fJxlct4yY7Yrf9LUjGNixwnwg xMBg== X-Gm-Message-State: AN3rC/52kZLD0NRDFGxypCPGw2UfKVFwEwlE6hvW248R6ZDYexRbEy3K oM41UIYXNcnZFlo/uhfpj6pwv+d2sYt6 X-Received: by 10.55.110.70 with SMTP id j67mr31125828qkc.145.1493158930496; Tue, 25 Apr 2017 15:22:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Tue, 25 Apr 2017 15:22:09 -0700 (PDT) In-Reply-To: <7a8a6142-7e3d-353d-872a-1811ecee0337@stpeter.im> References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> <8b6c9412-2daf-7447-4292-ade4278a8be0@stpeter.im> <7a8a6142-7e3d-353d-872a-1811ecee0337@stpeter.im> From: Taylor Brandstetter Date: Tue, 25 Apr 2017 15:22:09 -0700 Message-ID: To: Peter Saint-Andre Cc: Jonathan Lennox , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05c29ea5e948054e05274c Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:22:14 -0000 --94eb2c05c29ea5e948054e05274c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds good to me. On Tue, Apr 25, 2017 at 10:35 AM, Peter Saint-Andre wrote: > On 4/24/17 9:03 PM, Peter Saint-Andre wrote: > > On 4/24/17 12:39 PM, Jonathan Lennox wrote: > >> > >>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier >>> > wrote: > >>> > >>> > >>>> On Apr 24, 2017, at 11:06, Taylor Brandstetter >>>> > wrote: > >>>> > >>>> Although this makes me wonder how to handle the situation where > >>>> all m-sections have the ice-options, but one indicates support > >>>> for trickle and another does not. > >>>> > >>>> > >>>> I believe this is exactly what brought up the issue. My suggestion i= s > >>>> to just make this illegal and interpret it as invalid SDP. > >>> > >>> I=E2=80=99m fine with that. But then I would think it should say MUST= NOT like > >>> Peter suggested to make it explicit. > >>> > >>> Probably I=E2=80=99m missing a point here, but if the trickle ice-opt= ions need > >>> to be identical across all m-sections what is the difference to a > >>> session level attribute then (except that a receiver would need to > >>> check for consistency of all attributes and reject)? > >>> Is the reason only that ice-options in general are allowed in > >>> m-sections and we can=E2=80=99t mandate the trickle option only to be= used at > >>> the session level ice-options? > >> > >> The general reason ice-options are allowed at the media level is to > >> handle distributed media cases =E2=80=94 some variety of 3PCC might be > >> aggregating several different end systems=E2=80=99 ICE sessions. > >> > >> It seems possible this use case can=E2=80=99t be made to work for tric= kle, in > >> which case we need to have the option aligned across all media session= s. > >> (So a 3PCC would have to force all its controlled systems back to > >> non-trickle if they don=E2=80=99t all support trickle, but that=E2=80= =99d be reasonably > >> straightforward to do.) > > > > Yes, that seems like a possibility (although perhaps unattractive - we > > wouldn't get the benefits of Trickle until all the controlled systems > > support it). > > How about this change? > > OLD > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > candidate information that it supports Trickle ICE, either at the > session level or for every media stream at the media stream level > (e.g., in SDP this would be a token of "trickle" in the ice-options > attribute). > > NEW > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > candidate information that it supports Trickle ICE using a token of > "trickle" in the ice-options attribute. This token MUST be provided > either at the session level or, if at the media stream level, for > every media stream (an agent MUST NOT specify Trickle ICE support for > some media streams but not others). > > Peter > > > --94eb2c05c29ea5e948054e05274c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me.

On Tue, Apr 25, 2017 at 10:35 AM, Peter Saint-Andre= <stpeter@stpeter.im> wrote:
On 4/24/17 9:03 PM, Peter Saint= -Andre wrote:
> On 4/24/17 12:39 PM, Jonathan Lennox wrote:
>>
>>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier <nohlmeier@mozilla.com
>>> <mailto:nohlmeier@= mozilla.com>> wrote:
>>>
>>>
>>>> On Apr 24, 2017, at 11:06, Taylor Brandstetter <deadbeef@google.com
>>>> <mailto:deadbeef= @google.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Although this makes me wonder how to ha= ndle the situation where
>>>>=C2=A0 =C2=A0 =C2=A0all m-sections have the ice-options, bu= t one indicates support
>>>>=C2=A0 =C2=A0 =C2=A0for trickle and another does not.
>>>>
>>>>
>>>> I believe this is exactly what brought up the issue. My su= ggestion is
>>>> to just make this illegal and interpret it as invalid SDP.=
>>>
>>> I=E2=80=99m fine with that. But then I would think it should s= ay MUST NOT like
>>> Peter suggested to make it explicit.
>>>
>>> Probably I=E2=80=99m missing a point here, but if the trickle = ice-options need
>>> to be identical across all m-sections what is the difference t= o a
>>> session level attribute then (except that a receiver would nee= d to
>>> check for consistency of all attributes and reject)?
>>> Is the reason only that ice-options in general are allowed in<= br> >>> m-sections and we can=E2=80=99t mandate the trickle option onl= y to be used at
>>> the session level ice-options?
>>
>> The general reason ice-options are allowed at the media level is t= o
>> handle distributed media cases =E2=80=94 some variety of 3PCC migh= t be
>> aggregating several different end systems=E2=80=99 ICE sessions. >>
>> It seems possible this use case can=E2=80=99t be made to work for = trickle, in
>> which case we need to have the option aligned across all media ses= sions.
>>=C2=A0 (So a 3PCC would have to force all its controlled systems ba= ck to
>> non-trickle if they don=E2=80=99t all support trickle, but that=E2= =80=99d be reasonably
>> straightforward to do.)
>
> Yes, that seems like a possibility (although perhaps unattractive - we=
> wouldn't get the benefits of Trickle until all the controlled syst= ems
> support it).

How about this change?

OLD
=C2=A0 =C2=A0Even if a signaling protocol does not include= a capabilities
=C2=A0 =C2=A0discovery method, a user agent can provide an indication withi= n the
=C2=A0 =C2=A0candidate information that it supports Trickle ICE, either at = the
=C2=A0 =C2=A0session level or for every media stream at the media stream le= vel
=C2=A0 =C2=A0(e.g., in SDP this would be a token of "trickle" in = the ice-options
=C2=A0 =C2=A0attribute).

NEW
=C2=A0 =C2=A0Even if a signaling protocol does not include a capabilities =C2=A0 =C2=A0discovery method, a user agent can provide an indication withi= n the
=C2=A0 =C2=A0candidate information that it supports Trickle ICE usin= g a token of
=C2=A0 =C2=A0"trickle" in the ice-options attribute.=C2=A0 This t= oken MUST be provided
=C2=A0 =C2=A0either at the session level or, if at the media stream level, = for
=C2=A0 =C2=A0every media stream (an agent MUST NOT specify Trickle ICE supp= ort for
=C2=A0 =C2=A0some media streams but not others).

Peter



--94eb2c05c29ea5e948054e05274c-- From nobody Tue Apr 25 15:34:03 2017 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 6E8DB1205F0 for ; Tue, 25 Apr 2017 15:33: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 O2rtxcdqMdUh for ; Tue, 25 Apr 2017 15:33:43 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 7889E1294D3 for ; Tue, 25 Apr 2017 15:33:43 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id r16so219500009ioi.2 for ; Tue, 25 Apr 2017 15:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mOT9fR4/7Xlxe2ZfqhFaQ16701T4bx2kNNwd4BRPR3w=; b=Qh7l8ujLBJuz+sD7mv/hH4lVar2WK0hZscfchnJ/EkqeciXJSU45caj6DPTYXGGtgk UtLgln5OfnAZSKQYbwkFLEMsS177xiln87ATkDvbslQkjKil28vHvn3hoznQqnn9SXL7 K7UDJgOgUQPnaRnq/qsuDSat9A9dMEm1B1KvA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mOT9fR4/7Xlxe2ZfqhFaQ16701T4bx2kNNwd4BRPR3w=; b=W/y4mhC1R7ZFl0YOKvJVqhIcWgOsMfRGcgOFtvofA3d9zSLgHFZ5idIH+NOaOycLa7 1LSuxDXxt3pBGUcvHqXjWUfhp8dINe+TLbwUCCGw7wPX5z1BGG3fo7Y8FCLysbZTIOsH vq+TZQ2xelGWwNpGBfHEMAaG9QeicC9/qCGvjB7T5JgnMvZYEr/nH7avYp0/r/q39FOn b/wcTlOA83cpD5mrm2zYL+4Tqdu4kFMdsC4RPc89l/L6bNUcuMc1y7j0iYjvl2zoPMqV cXw0he0CFdp138vO9c7K+g6OC393Zz5YXxRObzy/HpYewyaT0EYtdMRYXOpYOmsqK6lX 4BPw== X-Gm-Message-State: AN3rC/4DVk2ssw+jxKUA0LhmcvMaEvKpnl6Ez93lGdUQPkCdyl9lEEc0 Aa+XBUL8XWydKxWV X-Received: by 10.107.9.203 with SMTP id 72mr17464129ioj.2.1493159622823; Tue, 25 Apr 2017 15:33:42 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:2cbd:c196:e332:6007? ([2620:101:80fc:224:2cbd:c196:e332:6007]) by smtp.gmail.com with ESMTPSA id p75sm2634641itb.26.2017.04.25.15.33.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 15:33:41 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_359AE594-9744-4B02-BE8B-DE37C719EB9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Apr 2017 15:33:38 -0700 In-Reply-To: Cc: Peter Saint-Andre , Jonathan Lennox , "ice@ietf.org" To: Taylor Brandstetter References: <61aef274-1823-6a7c-4cd3-f3ffd1196009@stpeter.im> <8FBF1BA5-3C69-491F-8AD3-154786226E6C@mozilla.com> <600c23fe-ffa9-4b80-8cc3-fa6797bfaf64@stpeter.im> <20D91E2C-9923-4295-90DE-2B4FA61C14DD@mozilla.com> <8b6c9412-2daf-7447-4292-ade4278a8be0@stpeter.im> <7a8a6142-7e3d-353d-872a-1811ecee0337@stpeter.im> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ice] negotiating trickle: always session-level? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:33:48 -0000 --Apple-Mail=_359AE594-9744-4B02-BE8B-DE37C719EB9A Content-Type: multipart/alternative; boundary="Apple-Mail=_74D79FA1-BCD9-463E-8F8A-108ADF0E5208" --Apple-Mail=_74D79FA1-BCD9-463E-8F8A-108ADF0E5208 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Apr 25, 2017, at 15:22, Taylor Brandstetter = wrote: >=20 > Sounds good to me. >=20 > On Tue, Apr 25, 2017 at 10:35 AM, Peter Saint-Andre = > wrote: > On 4/24/17 9:03 PM, Peter Saint-Andre wrote: > > On 4/24/17 12:39 PM, Jonathan Lennox wrote: > >> > >>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier > >>> >> = wrote: > >>> > >>> > >>>> On Apr 24, 2017, at 11:06, Taylor Brandstetter = > >>>> >> wrote: > >>>> > >>>> Although this makes me wonder how to handle the situation = where > >>>> all m-sections have the ice-options, but one indicates = support > >>>> for trickle and another does not. > >>>> > >>>> > >>>> I believe this is exactly what brought up the issue. My = suggestion is > >>>> to just make this illegal and interpret it as invalid SDP. > >>> > >>> I=E2=80=99m fine with that. But then I would think it should say = MUST NOT like > >>> Peter suggested to make it explicit. > >>> > >>> Probably I=E2=80=99m missing a point here, but if the trickle = ice-options need > >>> to be identical across all m-sections what is the difference to a > >>> session level attribute then (except that a receiver would need to > >>> check for consistency of all attributes and reject)? > >>> Is the reason only that ice-options in general are allowed in > >>> m-sections and we can=E2=80=99t mandate the trickle option only to = be used at > >>> the session level ice-options? > >> > >> The general reason ice-options are allowed at the media level is to > >> handle distributed media cases =E2=80=94 some variety of 3PCC might = be > >> aggregating several different end systems=E2=80=99 ICE sessions. > >> > >> It seems possible this use case can=E2=80=99t be made to work for = trickle, in > >> which case we need to have the option aligned across all media = sessions. > >> (So a 3PCC would have to force all its controlled systems back to > >> non-trickle if they don=E2=80=99t all support trickle, but that=E2=80= =99d be reasonably > >> straightforward to do.) > > > > Yes, that seems like a possibility (although perhaps unattractive - = we > > wouldn't get the benefits of Trickle until all the controlled = systems > > support it). >=20 > How about this change? >=20 > OLD > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > candidate information that it supports Trickle ICE, either at the > session level or for every media stream at the media stream level > (e.g., in SDP this would be a token of "trickle" in the ice-options > attribute). >=20 > NEW > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > candidate information that it supports Trickle ICE using a token of > "trickle" in the ice-options attribute. This token MUST be = provided > either at the session level or, if at the media stream level, for > every media stream (an agent MUST NOT specify Trickle ICE support = for > some media streams but not others). >=20 > Peter >=20 >=20 >=20 --Apple-Mail=_74D79FA1-BCD9-463E-8F8A-108ADF0E5208 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On Apr 25, 2017, at 15:22, Taylor = Brandstetter <deadbeef@google.com> wrote:

Sounds good to me.

On Tue, Apr 25, 2017 at 10:35 AM, = Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 4/24/17 9:03 PM, Peter Saint-Andre = wrote:
> On 4/24/17 12:39 PM, Jonathan Lennox wrote:
>>
>>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier <nohlmeier@mozilla.com
>>> <mailto:nohlmeier@mozilla.com>> wrote:
>>>
>>>
>>>> On Apr 24, 2017, at 11:06, Taylor Brandstetter <deadbeef@google.com
>>>> <mailto:deadbeef@google.com>> wrote:
>>>>
>>>>     Although this makes me wonder how to = handle the situation where
>>>>     all m-sections have the ice-options, = but one indicates support
>>>>     for trickle and another does not.
>>>>
>>>>
>>>> I believe this is exactly what brought up the issue. My = suggestion is
>>>> to just make this illegal and interpret it as invalid = SDP.
>>>
>>> I=E2=80=99m fine with that. But then I would think it = should say MUST NOT like
>>> Peter suggested to make it explicit.
>>>
>>> Probably I=E2=80=99m missing a point here, but if the = trickle ice-options need
>>> to be identical across all m-sections what is the = difference to a
>>> session level attribute then (except that a receiver would = need to
>>> check for consistency of all attributes and reject)?
>>> Is the reason only that ice-options in general are allowed = in
>>> m-sections and we can=E2=80=99t mandate the trickle option = only to be used at
>>> the session level ice-options?
>>
>> The general reason ice-options are allowed at the media level = is to
>> handle distributed media cases =E2=80=94 some variety of 3PCC = might be
>> aggregating several different end systems=E2=80=99 ICE = sessions.
>>
>> It seems possible this use case can=E2=80=99t be made to work = for trickle, in
>> which case we need to have the option aligned across all media = sessions.
>>  (So a 3PCC would have to force all its controlled systems = back to
>> non-trickle if they don=E2=80=99t all support trickle, but = that=E2=80=99d be reasonably
>> straightforward to do.)
>
> Yes, that seems like a possibility (although perhaps unattractive - = we
> wouldn't get the benefits of Trickle until all the controlled = systems
> support it).

How about this change?

OLD
   Even if a signaling protocol does not = include a capabilities
   discovery method, a user agent can provide an indication = within the
   candidate information that it supports Trickle ICE, either = at the
   session level or for every media stream at the media stream = level
   (e.g., in SDP this would be a token of "trickle" in the = ice-options
   attribute).

NEW
   Even if a signaling protocol does not include a = capabilities
   discovery method, a user agent can provide an indication = within the
   candidate information that it supports Trickle ICE = using a token of
   "trickle" in the ice-options attribute.  This token = MUST be provided
   either at the session level or, if at the media stream = level, for
   every media stream (an agent MUST NOT specify Trickle ICE = support for
   some media streams but not others).

Peter




= --Apple-Mail=_74D79FA1-BCD9-463E-8F8A-108ADF0E5208-- --Apple-Mail=_359AE594-9744-4B02-BE8B-DE37C719EB9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/87CAAoJEJ3NnGfOORkkSgkQAKSgcH8hzufZ+7A9gPGBZmnn Ka9q/VfBUiDLNyJJYNm/1JsvHUoFFd7yW4QC80CcH0Ar89Nve5a8hL11Rf/8BoiD SzsgogWMeKZmqCaAt5Qwp8+lgBEXAYiLNJvapbCdCK4kq9EF1JvmrikYD9qVtu37 40FTXUJxDdDQb1Bo+JZGESTYd+FhlBtjtF4QU0eE5hAjlpU/VYwrf/cEjgPv43DA fJzRwy/f0T7t9oUiw/Utj0XlKtKuZM+8tHvlVhqgc537mfkjz6p+fOzitSSZyqS4 FDVtoQ3MX13ynid4Tsjmi6Ftlfdz1OULN4l+/FbMPnyVWjjyGYRc6h59mnuSeeWt 8Qpaa8EDgbKrOKPYhdTbVuswawEnXyRET7PihvouJKje2amqmFJJVCc/9i7PsEuF j2/yIG6pmkZUboWgprnBjSPaRLkWc8doZFIN0AUhpVRYS7TKudO1eyNMHHdi9+g4 0Fc0aZoPommj40sccU9IMZXoPkiDBY0GCvtdl8NZL5CFmzyN5VLdLGHz1LDyg/6J 73Sw+uu/BH6WzeVFNbiwD1ukz874WQs6Kr/TpbJhz4UPyIEzR1heChoJR6HvdkAa EMuzas63HPAx7ai975lNQZdNm2DPjHq0dit+UyTwdyhzKQ2VRRBjUHYyC/Wk3ZC3 TyUcMu45gId5sVWaMJPD =oA0U -----END PGP SIGNATURE----- --Apple-Mail=_359AE594-9744-4B02-BE8B-DE37C719EB9A-- From nobody Tue Apr 25 15:35:25 2017 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 A7C46127B31 for ; Tue, 25 Apr 2017 15:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=X7otJTE3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QB6dfEJd 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 T7ZzZUaFuslH for ; Tue, 25 Apr 2017 15:35:23 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3053A126B71 for ; Tue, 25 Apr 2017 15:35:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8955F21BD3; Tue, 25 Apr 2017 18:35:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 25 Apr 2017 18:35:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=y9vgbLCKqoUanEvo8y L3PXJ1J5xlZ+zuqHKnRJ0te34=; b=X7otJTE3TAvfDsbVO7ki/8ImxldwRbDwDg pyk9FKXI0aF3b5ZigAJWNz1xcg9UhsKQoE38aPHdX0Wb58pOZc3sKpfVcEZ6BaGa DGN2f9uQyu758V0mqAexgXipZeu+fyUOT8J0mB5+H1j+OUPXxw8BMXVa4BGkB1OT 9ZYKmmkfmr1WcXPHMyLJ85fuZBQ82vm1T86sNWq85TFSCX/fV+ORwcPXeC2B4mPh psgTU1tKIfD2j2mC+BXrHmUihAs/vhd4JVUcdPEsov4xXQ/5Pa5JI/mt1E3Oyxpr 6MDJcGkpSOofTvZy22fotl29YY7De+uWCfJ6ltvt2Q+Eee+9sG4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=y9vgbLCKqoUanEvo8yL3PXJ1J5xlZ+zuqHKnRJ0te34=; b=QB6dfEJd noNECYG3Te40HKb3SATS/ikyYpzFjkyg9Q4y8fsaXSMxMNErOLQRURVuuYLdL36i xvC/LMrxoQNZOIQ3Ut8vgavzPYDNLm9H8FZ2N7KqjlxuixanxXV03NEgz8izawmC GKj5hZE4Z0XanjnDd1KYGecRq+mj6Rq9UlxrhlAvd8q4b4W9GC6clQ2WJpbuLzrE YxULIuI50kFWlNoxhTgXNVRqkMH3YrYn4cnq2ejgkpqHYyFzIgp7fSaY3xe/dWS3 c4rtSjAyKFzMGzvpBllsD1rblo1VhLTSU+5piS8ksyIlC5zaipkmlnpsgJVdJ1Wm fxb8t9tV/lpxAA== X-ME-Sender: X-Sasl-enc: zEJiNZiiPAI2G/R9EJK7b3jJxUERHAoRSYvH/l+XYdkO 1493159722 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 01CD0241E1; Tue, 25 Apr 2017 18:35:21 -0400 (EDT) To: Taylor Brandstetter References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <032a6402-95d7-84ce-d121-a120574f3801@stpeter.im> <6eec7121-f612-b95c-0d7d-6c7a29da07ff@stpeter.im> <23d521f7-35e6-79c2-af48-66c834f0a8aa@stpeter.im> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <3863f536-308a-5eb6-8460-ac2a377d3ce6@stpeter.im> Date: Tue, 25 Apr 2017 16:35:20 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:35:25 -0000 On 4/25/17 4:16 PM, Taylor Brandstetter wrote: > Right. Though we could simplify it to two rules like so: > > 1. If no other pairs in the column are Waiting, set the state to Waiting. > 2. If another pair in the same column is Succeeded, set the state to > Waiting. > > Also: it looks like version 09 will unfreeze the column if any pair *fails*: > > Case 3: If there is at least one pair in this column above the row of > the newly formed pair whose state is either Succeeded *or > Failed*, set > the state to Waiting (e.g., this would be the case if the pair in > column 5, row 1 succeeded and two newly formed pairs were placed in > column 5, rows 3 and 4). > > > Is this intentional? Emil wrote the original text for this section and I'm not sure why he included the Failed condition. It seems a bit odd to me, too... Peter