From nobody Tue May 2 13:04:34 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 31211129C49 for ; Tue, 2 May 2017 13:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=Ru3kpCZY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yu12geUY 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 sGTH0rm1lsk9 for ; Tue, 2 May 2017 13:04:30 -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 B77E3129C6E for ; Tue, 2 May 2017 13:01:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EB61820BA7; Tue, 2 May 2017 16:01:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 02 May 2017 16:01:54 -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=Xffsfu9AIEONRQLt2N rUP+LOU7P/8+dxoxWz5/FyXwA=; b=Ru3kpCZYKTZ01vM5SK+DIIowkt1Of2NAVm tBu6cWglTKQEofofwGT7Jen3xSWFDCS1125BdFAI4kKoyr2MP1psnoM1qB3+F3AY ZAbpOLDQMqQnftJIzYBcEYOqEJzhb4cMODk1NSjWUJaVFq6cG+D/v/b13tTQ/B2O XOVpNS4XEgQYDAPoZPbj819gItwH+t8np329SKVlSPNubNzLObEhnuVf3fyvBDHS aLjT/TarqLJtS5p6SzopcLNTFz1lLo9+LjnyI6vUEG0UozMosKvW5AawxLIk1+S7 ojORyEVPAdLFNp2viKF3v6oYItMhf/LaUW9FRTzMTkV2/xvuUyzw== 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=Xffsfu9AIEONRQLt2NrUP+LOU7P/8+dxoxWz5/FyXwA=; b=Yu12geUY IOII3HBlj7jMnZDAUuCK1Ksf79HycdDyXb8p+FO8uZxn2PqIO7Ik9fYp2fTUgsQl HUHo6t88S/x98gvcv4HeoSCJ7WZHGfxCq+ujEtynPGM4EHinj4f776Xn+qNYXqHt LHuWYrhvWgjZwPUl9e0JP+wmAqGOZnuqlace1jjSgcfqVoP4Jbfw2QwAgVd7l+jT 9kDXFLUgEZk3dCUukKi3MBmqQAUk3EGyweabK7oekBXBisxMbsP7oSUOvfRR0Bxs 7sVGBzLU1LRXN91kCLwaPxMmMrrFc7ijPOpc5pxD5TNetLEODFiPxRZFuaXGdVB+ uvIbMn3/iaV9ag== X-ME-Sender: X-Sasl-enc: ShycxrdK69cSLUWoj+pKx+QAWw/xxNcHqeFEIqvLnJvK 1493755314 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 741F42415E; Tue, 2 May 2017 16:01:54 -0400 (EDT) To: Taylor Brandstetter , ice@ietf.org References: From: Peter Saint-Andre Message-ID: <1cf84dd3-42b7-a571-b3ad-d05a4d910e79@stpeter.im> Date: Tue, 2 May 2017 14:01: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=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, 02 May 2017 20:04:32 -0000 On 4/9/17 4: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". Emil and I just had a co-author sync on the spec because I made the changes in -09 without consultation. :-) He mentioned that, in the trickle context, the phrase "convey initial candidate information" (instead of the old "send initial ICE description") is confusing to implementers because the agent isn't necessarily sending any candidates at the beginning (i.e., the initial ICE description can be empty, and it's weird to say "the act of conveying initial candidate information might not actually convey any candidates!"). We'd prefer to revert to the older phrasing unless there are strenuous objections. Alternative suggestions are of course welcome. Peter From nobody Tue May 2 14:51: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 C053512946E for ; Tue, 2 May 2017 14:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuMjv-0ygW8Q for ; Tue, 2 May 2017 14:50:55 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 967611294DF for ; Tue, 2 May 2017 14:47:45 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id w10so14280339oif.0 for ; Tue, 02 May 2017 14:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FYuqVepu35gdYSHbXbphGTqsV64FuyWTlaIDGILXSc4=; b=zWBuekNWzfCaK5uSjf4DZMXn0Yp0qu9GVRJqtzOpWMuOGbw/FvSj2k7hgn7d4p6MzH GGtTZwFpGTp/v5a5IG1DajfqG9rgCiZuKRMAxga3Il6KZKM0nItNf5NfWr9K3csAC3Gd jXA3zCjLqFsh5y9Ri84ky7D8rc79hv2zEnFTjRo7zTgUqiotzHkUHslBaZqBzpo8LPdf SRT9u0UyojL6qBMwwPY39YMCw/iSe5RRRWtTMI/2OMaFktCnlIR1gt/wGDs/gVwf0x2I sTTuZG6+GXaZSeetDNvXpdLkvaqImimHrJLhwYThJjRCt3fikf7ev1UrxwwrgO/12J3o 0OQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FYuqVepu35gdYSHbXbphGTqsV64FuyWTlaIDGILXSc4=; b=aiB3SahG1p/KjJyqnJKYYlc+EvSaer9dd+/OvCeQPl+RKTI9QoDjr2SLFcQz6cT1Je 7F/dlx4GyNuQ1fGIo1tG+Ba9vj6qifsrRaW4ATRhsKOOUGLJbhqci2mOB4tVYJc8L1pk Ly0hPhilLTGiFsTO38eiQtQ9/B1nMpJ7xj6kP36ufpD0gDkHFZy7XQBrljB7q6/Z4cXq 3vo7gm/K+AKd8gOCTeFsLsXxgDGljGBGdKWOOMMFVWENMz7T/kp/5bJ3aTQpeRZB+f6B Q3GEbMmRLPGjZ6y806hABML5nmLQZCIIVR+dWYHxVB8VEY+byyr1lK1sMATDUzNGyVOJ otKw== X-Gm-Message-State: AN3rC/78urCh9B972SMmTRDQkk1tDvOR0/1vaBFs5/ATjgYY7N0IBuy5 ovP/V7GVOfW/0w== X-Received: by 10.202.185.135 with SMTP id j129mr12917323oif.178.1493761664602; Tue, 02 May 2017 14:47:44 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id r18sm8873706ota.37.2017.05.02.14.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 14:47:43 -0700 (PDT) To: Taylor Brandstetter , Peter Saint-Andre References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> Cc: ice@ietf.org From: Emil Ivov Message-ID: <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> Date: Tue, 2 May 2017 16:47:42 -0500 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; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ice] holes in the matrix (Was: 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, 02 May 2017 21:50:59 -0000 Hey, Apologies for coming in a bit late on this. On 4/18/17 8: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 > 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. So yes, I agree this is a difference with 5245bis, but it's intentional. I see this in part as a simplification (I don't think it is a meaningful optimization even for 5245bis) but more specifically I am reluctant to deal with situations where the candidate matrix is asymmetric for whatever weird reason and one side is trying checks for M2F3 but the other isn't responding because M2F3 is blocked after a hole in M2F2 and it is not supposed to be unfrozen yet. Or something along those lines. So, unless someone has a great reason for why we'd need an entire stream to succeed before unfreezing the foundation, I'd rather we kept things as they are. Emil > > 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 > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > -- https://jitsi.org From nobody Tue May 2 14:59: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 EE2EB12E6A3 for ; Tue, 2 May 2017 14:59:37 -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=AvPVR27J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pBFTRmdm 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 10ATx4DzUCqI for ; Tue, 2 May 2017 14:59: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 9ADC4129483 for ; Tue, 2 May 2017 14:56:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E289C208F0; Tue, 2 May 2017 17:56:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 02 May 2017 17:56:52 -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=h9CdwOigAp9WP5yjz0 nLtncEKM0axJgv7dPuZv8A3D0=; b=AvPVR27J4GVqVpT1qN42cnaV7DIp74pDbp OyEZgffXz/w1AOoZyhFvwBG3jsrFODowifByUEpYGSlxm7cCqlHb8aojTiZ0+7bH g+pvmtx3nXK92wD1YGfzMLc+92QBGhB71qxSNskfHikXKeCotEiBxtG1hlJo9tUQ xHQTa9AKanAHQiM43P9ooL2sb5/HfO/m/lZbE2l2crAhw1C3/9+IB23aPWqVy7FZ sN0w+qZP1BRq9cdzaG8p1fJGZ0UwIEaJqy8g32Z3bKtfnS7IthwWabsVKK6VcoQa orbDRSZ4gRy+jTTVy20Wh4OWkTl+vfPMv777RicLk0LUoMwD4IUw== 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=h9CdwOigAp9WP5yjz0nLtncEKM0axJgv7dPuZv8A3D0=; b=pBFTRmdm Y7vkWPP0C/jjOSidfMJp1REava9UNoHlLDlmGE/rmOgauCYVEK0XrFjCHGFZHOAO xn8QYdmUnuojEwhpYPthkdDZ5tL/5yo0tFgrTVZfhekhk9Ml1jf+ZpxGamoVBXXi 2y1WCd8Sb0TKnpwrDuPd6KP3vEu3W2N0m88JFtRDPz6Vx+6a96i2KvA5aydGjvHQ L5n9IXftjg9lt8zLNTYwGWGePi2kOsRHZZpV+6zTxXfyLi4NfvRBaVufu3CVKlpm Q+9Vk4mNVXXCaR4IBVMjE4OxnJnobzk/ZlIpYtgf7E8Fg+1KrrXG0rjop6hWMnAc c0oglqVeUV0+5w== X-ME-Sender: X-Sasl-enc: KpX4s4RBB8JTyHtWNOyqMERBpcum0BiQ16Fjk2Cjbm0G 1493762212 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B767241E3; Tue, 2 May 2017 17:56:52 -0400 (EDT) To: Taylor Brandstetter , ice@ietf.org References: <1cf84dd3-42b7-a571-b3ad-d05a4d910e79@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Tue, 2 May 2017 15:56:50 -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: <1cf84dd3-42b7-a571-b3ad-d05a4d910e79@stpeter.im> Content-Type: text/plain; charset=windows-1252 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, 02 May 2017 21:59:38 -0000 On 5/2/17 2:01 PM, Peter Saint-Andre wrote: > On 4/9/17 4: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". > > Emil and I just had a co-author sync on the spec because I made the > changes in -09 without consultation. :-) He mentioned that, in the > trickle context, the phrase "convey initial candidate information" > (instead of the old "send initial ICE description") is confusing to > implementers because the agent isn't necessarily sending any candidates > at the beginning (i.e., the initial ICE description can be empty, and > it's weird to say "the act of conveying initial candidate information > might not actually convey any candidates!"). We'd prefer to revert to > the older phrasing unless there are strenuous objections. Alternative > suggestions are of course welcome. Another option, which Taylor suggested originally, is "convey initial ICE parameters". Personally I'm of the opinion that scrubbing every last word that (horrors!) sounds like it might have come from SDP is a little silly, but if we hate "description" that much then "parameters" doesn't seem terrible. Peter From nobody Tue May 2 15:09: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 536FB120725 for ; Tue, 2 May 2017 15:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ4CAk_YAui4 for ; Tue, 2 May 2017 15:09:28 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 E046E12DFDB for ; Tue, 2 May 2017 15:07:19 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id l18so13795114oig.2 for ; Tue, 02 May 2017 15:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=oX3jS/1u6pCFVtOriaVEnfBE5rkAcWlwY9WCVztMy8Q=; b=EXMISO64J9Dq/CZN1TGqFPIdg1qowDRi211vw4kznGuBvwmiTCHJW1HkjuZg5siFe0 JtMIraT1CxWgoHybgn9Jocp2lsMUWra/XkMFTDZX8SB8wWNCDAcVMlYdrzEQrlsxApwS XQOiU/XxXco9OYHZIE1XQ9z1L3XNKGapvVEOwVPgVrSskxvk1wuRhfUWia94gK3W2cLe iSN6jjJNiq/g8Fk7KhHe6xFEeSOQk4XyxBOxGfFpnrVobNE0v1QzAw++PI5tOivhuWLV 7qy8cNaPVAtHBrJ/OZnTAUq9c9ZEh/wK3IVENXHSsaQI1LCMfMTHLm96Q4OsdfvioBbz 1+6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oX3jS/1u6pCFVtOriaVEnfBE5rkAcWlwY9WCVztMy8Q=; b=Ub+auJSQzF2iXykr6qhM37Je6674tkuhNyEMVcQ42BjgOPI9tB/4b5IuKG1bHLyd8y c1vwBdtEXq5JMnObNKWZ2j7ij8gf5QVLYFFJS0x+496v6lc/HU843+aWhX9MBJD5S9zg CkYDfNW5pUOc6dix2+IgiLDCe+dQiOP2AGH+YE4TYWrqX69Icx7Gr+Ajz3PdC/3aw6u2 7WhAtaqOV2A0wTwGERjjTSFrkG7MQ0t/Hg5PQ2zRoTp1l43s3f6soaFv8g7Kfw4x+csu CMnUSqppOyEC81gp1/E56AKnFUc7qAs7HffXcfPrIP4nBvdhMRAm7tq8YGCNvtX+aafy 4GWA== X-Gm-Message-State: AN3rC/6qivL6KVwbmwYIcLZaL8biPRDoKWgsp5OVG3qrfYfA6iWPqXjq 7NHfN7GlxSxgVA== X-Received: by 10.157.7.86 with SMTP id 80mr12833049ote.91.1493762839093; Tue, 02 May 2017 15:07:19 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id o35sm8300118oto.45.2017.05.02.15.07.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 15:07:17 -0700 (PDT) To: Peter Saint-Andre , 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> <3863f536-308a-5eb6-8460-ac2a377d3ce6@stpeter.im> Cc: ice@ietf.org From: Emil Ivov Message-ID: <58f37883-fa70-003f-9c34-89e6c3489ced@jitsi.org> Date: Tue, 2 May 2017 17:07:16 -0500 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: <3863f536-308a-5eb6-8460-ac2a377d3ce6@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed 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, 02 May 2017 22:09:29 -0000 On 4/25/17 5:35 PM, Peter Saint-Andre wrote: > 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... In short: unless you do this you would otherwise never unfreeze them and never fully check a foundation where one of the top pairs has failed. The fact that the state has moved to Failed is indication that enough time has been spent waiting on this, so unfreezing the following pairs for that foundation isn't going to penalize ICE processing as a whole. Emil -- https://jitsi.org From nobody Tue May 2 15:11:23 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 C808112869B for ; Tue, 2 May 2017 15:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKp-T73EuhMg for ; Tue, 2 May 2017 15:11:18 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 96845129B00 for ; Tue, 2 May 2017 15:08:51 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id l18so13831715oig.2 for ; Tue, 02 May 2017 15:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=rOOD2UJs1ydlOFJwuGBUrXfeH6wWxRsJF4rIAKqhtKs=; b=wEVCDjklXZkSVaT+xWlhiej5CB/27/PgYjVkSBRorSlQsdbP+MMHbwiMPiJ7XDEp30 /C8IBe2nBm61knpiwaML/4zQbwmAcBUZJEFw5u+Ef3C6Bfm/te4bYQyG1ZIsxtcOjJi4 IQrvJWBuL0dOEOnnfsjIcB4gGrSoLGYk4QncT7IjKY8vlGzB2vCWou1G743WlJjNskHN jr+uqpWCLGql5jB3ZxCmJfKvhTqyr9O3AXLFqJfk/N6r8B0VGAAfdEe3Q6Dmgigw0u75 e1ntuctx37kpNgvTTaw3STtO2ZnudwqLbzKpBOQ68RomE85Kc+pc0yqsQYWekohv6qN1 +Nmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rOOD2UJs1ydlOFJwuGBUrXfeH6wWxRsJF4rIAKqhtKs=; b=roWrppXtO/ge2DSGMUsbz5fm9RMQfXdg1O6oPaCFeOrzjKVXeRJDezqD/DZLx7SsH7 pw5ZwfGVAKeJl1C6iH2KQKwSB33l7Upk/04VV2qMiJURt7ZdxMqKnWaNQCUpg0plL5+S 6PjwbPSGEkQxvmPvY72Jz7YrowtVOQzS+6hUq23TGUZvtBAHHgphiiu0T1xfTD+a4gt0 I31+dXAMfzEON1WoE/SeEX3f7qayefcZDD0KFSVrrYwPKJf1ScfA7nPSjkBbLTFV58x/ cfA5oC0xpxDIEw2E8mjsegcCOCKn0Iq0fzXo304FCtfcUViTS9/ll356kiPHS0QeFwAV 2xjw== X-Gm-Message-State: AN3rC/4+up/ayoOEjDeiTSP5CnPbtoqtKILKGkGfaTXxQaL2yDqMvGep Vw9aCwaqc54eqg== X-Received: by 10.157.51.12 with SMTP id f12mr13937387otc.189.1493762930887; Tue, 02 May 2017 15:08:50 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id 92sm2491951otc.42.2017.05.02.15.08.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 15:08:49 -0700 (PDT) To: Peter Saint-Andre , Taylor Brandstetter , ice@ietf.org References: <1cf84dd3-42b7-a571-b3ad-d05a4d910e79@stpeter.im> From: Emil Ivov Message-ID: <93ee2546-9fd1-87f5-3a83-72c13e0d4193@jitsi.org> Date: Tue, 2 May 2017 17:08:48 -0500 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; format=flowed 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, 02 May 2017 22:11:21 -0000 On 5/2/17 4:56 PM, Peter Saint-Andre wrote: > On 5/2/17 2:01 PM, Peter Saint-Andre wrote: >> On 4/9/17 4: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". >> >> Emil and I just had a co-author sync on the spec because I made the >> changes in -09 without consultation. :-) He mentioned that, in the >> trickle context, the phrase "convey initial candidate information" >> (instead of the old "send initial ICE description") is confusing to >> implementers because the agent isn't necessarily sending any candidates >> at the beginning (i.e., the initial ICE description can be empty, and >> it's weird to say "the act of conveying initial candidate information >> might not actually convey any candidates!"). We'd prefer to revert to >> the older phrasing unless there are strenuous objections. Alternative >> suggestions are of course welcome. > > Another option, which Taylor suggested originally, is "convey initial > ICE parameters". > > Personally I'm of the opinion that scrubbing every last word that > (horrors!) sounds like it might have come from SDP is a little silly, > but if we hate "description" that much then "parameters" doesn't seem > terrible. I don't understand what the problem is with ICE description. Would someone please enlighten me? Emil -- https://jitsi.org From nobody Tue May 2 15:12: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 2934D12940F for ; Tue, 2 May 2017 15:12: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=TDp1WKAi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MhoUaEm2 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 t9zeN7hT6qY8 for ; Tue, 2 May 2017 15:12:56 -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 E9214120724 for ; Tue, 2 May 2017 15:10:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5E02020937; Tue, 2 May 2017 18:10:29 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 02 May 2017 18:10:29 -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=0pTAUTmye0WsMHnJs0 rKTJibDxlaV1Zoz/h8xKt6Vtg=; b=TDp1WKAiN7PWXRVpMd/Wi8lAjRXaa2/HEe eop3g9uhil+QkGPgpOhbFAbRuSozApwmkbNyb+dLoDLxO5+7xVkm/Reggn2QXbNl 8pcRGF5NMCkSjMF2quQQRg4nq9BRl6P9q40Zznu15BGSnDLJMxuGvH2rFM9oDDLq LCvhH+92/4btlaoH5rCeXrUSweLGKziFmy+l7DLw5ESvNDByvI3kSZJuXql58tzY UZoiH6VXNoM8UTDn/4OOooG4+1yDJHGX66j9Goe7eFc9cBjvujdlDwnHyuesofRq Ei00i7fnWsPXjvC7UB1nu04sMj8T+PN79X62nWsQZ4DVA7vpLcZA== 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=0pTAUTmye0WsMHnJs0rKTJibDxlaV1Zoz/h8xKt6Vtg=; b=MhoUaEm2 jyvd5J8gq6lYbd47SXXCfpFQQv3a2VS8hqPbkzaoF0mol8iLqmC42BQdCwLpvvRF kNHsjvUEtQjskETJ24vIV7kDRleZ2Ubhw0D641Um5SuunGXvsl1bzSISo0Q1CD7v 4Q/wDguWYJhI9sgxRMIqgP8Ko5a+5FVLbkihEJnQHq/Zg3Lr0NtuBEC90QPpguKj 6uYEEWkgrpNtpkY4vX/wUMR9sF8Mca1nJRqD3g80jQx6D9MdaDsbVXhRHKReMmd4 ixS0aOE0llQE/XtG7fLTvTeiEeaSJpceOIbNmwkOnqn5X9czUU4jJzDDtg/AFtvM 9NTeOC1UqkzCLA== X-ME-Sender: X-Sasl-enc: OIJQnZhImEy2UQE899d7GupKKdoQJ0DvsXxIoZp2lDYv 1493763029 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id D0302244AB; Tue, 2 May 2017 18:10:28 -0400 (EDT) To: Emil Ivov , Taylor Brandstetter , ice@ietf.org References: <1cf84dd3-42b7-a571-b3ad-d05a4d910e79@stpeter.im> <93ee2546-9fd1-87f5-3a83-72c13e0d4193@jitsi.org> From: Peter Saint-Andre Message-ID: <383337ee-d88c-72a1-5f43-c654ed83eccf@stpeter.im> Date: Tue, 2 May 2017 16:10:27 -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: <93ee2546-9fd1-87f5-3a83-72c13e0d4193@jitsi.org> Content-Type: text/plain; charset=windows-1252 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, 02 May 2017 22:12:58 -0000 On 5/2/17 4:08 PM, Emil Ivov wrote: > > > On 5/2/17 4:56 PM, Peter Saint-Andre wrote: >> On 5/2/17 2:01 PM, Peter Saint-Andre wrote: >>> On 4/9/17 4: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". >>> >>> Emil and I just had a co-author sync on the spec because I made the >>> changes in -09 without consultation. :-) He mentioned that, in the >>> trickle context, the phrase "convey initial candidate information" >>> (instead of the old "send initial ICE description") is confusing to >>> implementers because the agent isn't necessarily sending any candidates >>> at the beginning (i.e., the initial ICE description can be empty, and >>> it's weird to say "the act of conveying initial candidate information >>> might not actually convey any candidates!"). We'd prefer to revert to >>> the older phrasing unless there are strenuous objections. Alternative >>> suggestions are of course welcome. >> >> Another option, which Taylor suggested originally, is "convey initial >> ICE parameters". >> >> Personally I'm of the opinion that scrubbing every last word that >> (horrors!) sounds like it might have come from SDP is a little silly, >> but if we hate "description" that much then "parameters" doesn't seem >> terrible. > > I don't understand what the problem is with ICE description. Would > someone please enlighten me? It contains the word "description", and so does "session description protocol". :-) Peter From nobody Tue May 2 15:14:20 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 5415F129511 for ; Tue, 2 May 2017 15:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=WfVU9icN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Lkm4iGNk 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 cJhQ4mtkKooF for ; Tue, 2 May 2017 15:14:17 -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 413FC12762F for ; Tue, 2 May 2017 15:11:40 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A949120B0E; Tue, 2 May 2017 18:11:39 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 02 May 2017 18:11:39 -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=ygTtLnAnzIo5DQOp3v /0esDEAHBQ4G1uFQ+aGV9JNKA=; b=WfVU9icNybFZ+zjEZwm+SfVmARu6bnCe3l swgw9+UEb47y0vmHywfMijRk14cYMIZSZoWmBM6pSPT/XxPJ7Bp7tQ3RbU8dMVub SFSF2E2eN+Mw9aH+xgyBJ3KT07DZ92BbMrFK8TNtwKmVmQGV7eZpTJ5JoJ+LoYX3 zOj7OySVB9ffLzRJxko7sQ63x1WkM1+UPTPqa9/Fse16TVlbXfvK731jkFLtYAwk RgdqF08gzx8zJUZ1j0vK0nvpZTWkAsFnx8oKQD0hkhJ2RxEi6YZOxWE30zXXsPYG xbGgz2h9zRN7riiolZofWcYJRCQzdJwBCXYYHx9OkASiqmX/EZfw== 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=ygTtLnAnzIo5DQOp3v/0esDEAHBQ4G1uFQ+aGV9JNKA=; b=Lkm4iGNk aURhhxP9UwDQbjzVzBdKoq86MHJZvDboaqIMUjehTgvjI2ahvGMvaMFn9WcM6O2g 3VyQj3wyhnETnDVdZZqLmEslpqSBaq1Za06Z3VFCDDgpl16m8cXQCSIKt208mR9z OvMhQ8xgdBMTj75cMYxalt/q2dSwGEd8VOIucuXMD/iULhbVdL+9A2VICByczaLp iTJegTqJChrGuCI6qlbYMR48WRT7JJB/qfEauPS8aGHk7ak9rW3muteZgogwugSI e1Ny0H+oXjXeWiLZp63IvLjHi5O8FriHzwKhJenFqTDkFT3ss5LNCPDiv7FbCIlc 3vTfX2BdPHnYcg== X-ME-Sender: X-Sasl-enc: yPaRC1qmMQ986ZYKAih4bkwAaUG6PR2gfE42ZMFbiGlN 1493763099 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2C2ED24033; Tue, 2 May 2017 18:11:39 -0400 (EDT) To: Emil Ivov , 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> <3863f536-308a-5eb6-8460-ac2a377d3ce6@stpeter.im> <58f37883-fa70-003f-9c34-89e6c3489ced@jitsi.org> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <2fb5522c-0cff-0188-bc4a-0f0953c940f9@stpeter.im> Date: Tue, 2 May 2017 16:11: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: <58f37883-fa70-003f-9c34-89e6c3489ced@jitsi.org> Content-Type: text/plain; charset=windows-1252 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, 02 May 2017 22:14:18 -0000 On 5/2/17 4:07 PM, Emil Ivov wrote: > > > On 4/25/17 5:35 PM, Peter Saint-Andre wrote: >> 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... > > In short: unless you do this you would otherwise never unfreeze them and > never fully check a foundation where one of the top pairs has failed. > > The fact that the state has moved to Failed is indication that enough > time has been spent waiting on this, so unfreezing the following pairs > for that foundation isn't going to penalize ICE processing as a whole. Sure, that makes sense. Thanks for the explanation! Peter From nobody Tue May 2 18:43: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 A711112960D for ; Tue, 2 May 2017 18:43:43 -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 ko0YGNloZQpN for ; Tue, 2 May 2017 18:43:40 -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 C76FA129413 for ; Tue, 2 May 2017 18:39:39 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id c45so126886725qtb.1 for ; Tue, 02 May 2017 18:39:39 -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=NO/oqKbt/l1ybyOAMpktpFESR0v17OTNSNzkVvHuDLE=; b=UlDvyamSef7eOONQC/RIFzhF8r4gBaqd0dVFjZ5o5GvLCzWqIxKQSifh0wAhZlji2I rew60ZeL2c3AZEkTYYnEPWD3lJkfmYur8026u59DsKwy1YjujI6JgyJQr2/eAQc49tIK ocBDdVKKGXUl7seBwZicNz93ZCi2KYG8p7PJOTIf5MVY5AcRWL6Ow78vBMnSE5Ry8GiL CbVetoDNNzFo3XZsyvspq1n50GWnTZZMHLQTtcNENBfIU+bwFbAtdKij2y7BHFIDMvSx yit9IwGpIdcprAZg8DEgf7zl5386SQpsTW6yRFhakTUcQ8aYAUjuDjiolxbnjOiHGtj+ iugQ== 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=NO/oqKbt/l1ybyOAMpktpFESR0v17OTNSNzkVvHuDLE=; b=Ra/HT0WIJrKShs5N/AhMMiFRlWihsUxTVGyxrGFDj8qzKCb15j9s1gXTXYJHAWR5oX Ho1I1k5ryIzYY8Urpg5Aq+cLl9o+llV4T0WDlijFIwWha7pvUmrskaoMXnMefSF8Gke5 p5/iD3X+9bTz4sRpD5J8ObTw0zvh7cd+3truKQFZs73gbRU6yAbFoBDml7HNE2v7RT3Y n4vK3q7E8X+utYffBHhThH2xfsI0kL7lw4eFg2lvTiPJWzApcCeB9ER8wGn3Rz1HkVT0 d8FMYL3JeJlp+d5uBemHhol4f3RUGi+X3rtt3r4V7CKlhwv5yMlp6irfeFBzsvfQFkUa zVzg== X-Gm-Message-State: AN3rC/4ko8bT/jwx2Pf4FdZMGUo35REu2/YemlgjgUnIPrZqJn0HILKr Ylj4VvrhK9m3IUeZ38NLMA2oZ50ihMzt X-Received: by 10.200.33.245 with SMTP id 50mr28227601qtz.64.1493775578799; Tue, 02 May 2017 18:39:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Tue, 2 May 2017 18:39:38 -0700 (PDT) In-Reply-To: <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> From: Taylor Brandstetter Date: Tue, 2 May 2017 18:39:38 -0700 Message-ID: To: Emil Ivov Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=001a11402e0ebffc32054e94bac8 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 01:43:43 -0000 --001a11402e0ebffc32054e94bac8 Content-Type: text/plain; charset=UTF-8 > > I am reluctant to deal with situations where the candidate matrix is > asymmetric That example doesn't have asymmetric candidate matrices though; it's just 3 media streams with 2 components each, and one foundation. > So, unless someone has a great reason for why we'd need an entire stream > to succeed before unfreezing the foundation, I'd rather we kept things as > they are. Actually, what I was concerned about is that even after an entire stream succeeds, new candidate pairs with that foundation may start as frozen. On Tue, May 2, 2017 at 2:47 PM, Emil Ivov wrote: > Hey, > > Apologies for coming in a bit late on this. > > On 4/18/17 8: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 >> 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. >> > > So yes, I agree this is a difference with 5245bis, but it's intentional. I > see this in part as a simplification (I don't think it is a meaningful > optimization even for 5245bis) but more specifically I am reluctant to deal > with situations where the candidate matrix is asymmetric for whatever weird > reason and one side is trying checks for M2F3 but the other isn't > responding because M2F3 is blocked after a hole in M2F2 and it is not > supposed to be unfrozen yet. Or something along those lines. > > So, unless someone has a great reason for why we'd need an entire stream > to succeed before unfreezing the foundation, I'd rather we kept things as > they are. > > Emil > > >> 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 >> >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > -- > https://jitsi.org > --001a11402e0ebffc32054e94bac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0I am reluctant to deal with situations where= the candidate matrix is asymmetric

= That example doesn't have asymmetric candidate matrices though; it'= s just 3 media streams with 2 components each, and one foundation.
=C2=A0
So, unless someone has a great reason for why we'= d need an entire stream to succeed before unfreezing the foundation, I'= d rather we kept things as they are.

Actually, what I was concerned about is that even after an entire stream s= ucceeds, new candidate pairs with that foundation may start as frozen.

On Tue, Ma= y 2, 2017 at 2:47 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 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&= quot;,
where "S" is "succeeded", "W" is "waitin= g", 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=A01. Only the RTP candidate pair for the first media stream is unfrozen=
=C2=A0 =C2=A0 initially.
=C2=A0 =C2=A0 State: WFFFFF
=C2=A02. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
=C2=A0 =C2=A0 State: SWFFFF
=C2=A03. Check succeeds for RTCP pair. /All/ the other pairs with the same<= br> =C2=A0 =C2=A0 foundation are now unfrozen.
=C2=A0 =C2=A0 State: SSWWWW

With trickle ICE, here's what could happen:

=C2=A01. Candidates for the first media stream are trickled in. Starts out<= br> =C2=A0 =C2=A0 just like normal ICE.
=C2=A0 =C2=A0 State: WF
=C2=A02. Checks for both pairs succeed. Still waiting for candidates for =C2=A0 =C2=A0 other media streams.
=C2=A0 =C2=A0 State: SS
=C2=A03. Candidates for the other media streams arrive, and pairs are forme= d.
=C2=A0 =C2=A0 The topmost pair is set to waiting, but not the others.
=C2=A0 =C2=A0 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.

So yes, I agree this is a difference with 5245bis, but it's intentional= . I see this in part as a simplification (I don't think it is a meaning= ful optimization even for 5245bis) but more specifically I am reluctant to = deal with situations where the candidate matrix is asymmetric for whatever = weird reason and one side is trying checks for M2F3 but the other isn't= responding because M2F3 is blocked after a hole in M2F2 and it is not supp= osed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire strea= m to succeed before unfreezing the foundation, I'd rather we kept thing= s as they are.

Emil


On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

=C2=A0 =C2=A0 [areas of seeming agreement elided]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0* In section 8.1.1: In general I like the im= provements that have
=C2=A0 =C2=A0 been
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0made. However:
=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 "Frozen"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't complet= ely match standard ICE; at least the part
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "me= dia stream" completes, pairs from other media
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching f= oundations are unfrozen. With the current
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1,= only the topmost remaining pair in each
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guarantee= d to be unfrozen. Is this difference
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, w= e should at least acknowledge it, and not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impressi= on by saying "Trickle ICE preserves all
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] r= ules."

=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 is guaranteed to be unfrozen".

=C2=A0 =C2=A0 In particular, your statement doesn't seem to match the r= ules defined in
=C2=A0 =C2=A0 the Trickle spec. I've tried to spell them out in greater= detail (with
=C2=A0 =C2=A0 examples) in the following proposed text.

=C2=A0 =C2=A0 ###


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Consider the following tabular representation of= all checklists in an
=C2=A0 =C2=A0 =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 =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=A0Figure 1: Example of Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Each row in the table represents a component for= a given media stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP compo= nents for audio).
=C2=A0 =C2=A0 =C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Eac= h cell represents one
=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When an agent commences ICE processing, in accor= dance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting state) the topmost candidate pair in eve= ry column (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This s= tate is shown in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following table, with candidate pairs in the Wai= ting 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 Figure 2: Initial Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, 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 the Suc= ceeded state (denoted
=C2=A0 =C2=A0 =C2=A0 =C2=A0here by "s-cp"), the agent will unfree= ze all pairs for the same media
=C2=A0 =C2=A0 =C2=A0 =C2=A0stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
=C2=A0 =C2=A0 =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 =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=A0Figure 3: Che= ck List State after Succeeded Check

=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies that, if all the pairs in a m= edia stream for one
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 = and 2 representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0both components for the audio stream), then all = of the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., c= olumn 1, rows 3 and
=C2=A0 =C2=A0 =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 =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=A0Figure 4: Check List= State with Unfrozen Media Stream

=C2=A0 =C2=A0 =C2=A0 =C2=A0Trickle ICE preserves all of these rules as they= apply to what we
=C2=A0 =C2=A0 =C2=A0 =C2=A0might call "static" check list sets.= =C2=A0 This implies that if, for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0reason, a Trickle agent were to begin connectivi= ty checks with all of
=C2=A0 =C2=A0 =C2=A0 =C2=A0its pairs already present, the way that pair sta= tes change is
=C2=A0 =C2=A0 =C2=A0 =C2=A0indistinguishable from that of a regular ICE age= nt.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost = pair in this column,
=C2=A0 =C2=A0 =C2=A0 =C2=A0set the state to Waiting (e.g., this would be th= e case if the newly
=C2=A0 =C2=A0 =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 =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=A0Figure 5: Check List State = with Newly Formed Pair, Case 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 2: If the pair immediately above the newly = formed pair in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0column is in the Succeeded state, set the state = to Waiting (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0this would be the case if the pair in column 4, = row 2 succeeded and
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair were placed in column 4, r= ow 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=A0Figure 6: Check List State = with Newly Formed Pair, Case 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 3: If there is at least one pair in this co= lumn below the row of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair whose state is either Succ= eeded or Failed
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., this would be the case if the pair in col= umn 4, row 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded and the newly 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 | 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=A0Figure 7: Check List State = with Newly Formed Pair, Case 3

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

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 Peter




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


--
https://= jitsi.org

--001a11402e0ebffc32054e94bac8-- From nobody Tue May 2 18:46: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 4E97D12EA76 for ; Tue, 2 May 2017 18:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUtYu1N0obQM for ; Tue, 2 May 2017 18:46:24 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1661312EAE9 for ; Tue, 2 May 2017 18:43:11 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id m123so40107510wma.0 for ; Tue, 02 May 2017 18:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IFFoNtqHPjPksv+3be2EbPjL45HVXvoLDX1lS15f3V4=; b=LaSfBG/1vuUlHQ3GLaCBxm/WTP7fFBcYy5Djslgwk1LDuoF/3TOVWIYF1LVXEOernx CFeZ6zYVZ+F+/UgBeEUKmAvCbOwBOEDpT6EPuO/S7rBY0Z82ChZcMsV/QISuEx9KV0kT O5VFcudYhw8urDO39bJWBrg7YN069IpfOTSVaazYVjnjBjJ2tnf6saKSF7ev4dSCS84s AB3xe6F0CrCG23fpp2FQr/L45xF5wS7tZTWRsfzJFj81CwA/L5x9bH15b59iCdMmC4HY Q5FidHuYJsXeIHVP9T0JACDHy7Pe8Alql1bjVcyH3slJGsNFmAkD1lM3+kkMpFPF3EVx WKfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IFFoNtqHPjPksv+3be2EbPjL45HVXvoLDX1lS15f3V4=; b=JVYFH3bJK0yrnhdKHfObEJ3BDl25YIQ1h+R5Duk35y3JQhcTPeNczbnsBniuCFiJlj eceJxMXytL0ed304VeidOBH4LCbWc0cHMjoMG+VrU+xumdUUMOPQLxspi8FArL7D5bIw mPu2DZCwYeH7CiFVJk9F1GdjfAZfl/9sCIGj8NxeuBSvY5rLH/FaYkypWVu7JbJbcRM9 4N+A9JlI7mnYukGk2Tev1osWqBrPAi7EeriEGS4glUL6ZiRdVEahxIEwx62UJluQ74vR OyXpqT89vvzhMvUpjJV+pU26TU4jgwmrdEDVR0cNs+mJw7rSGEreQK058UFVp/OR8ssc j4Aw== X-Gm-Message-State: AN3rC/5eeKmv5aiDetRRpt9FepZcuI/teJ/T+7yt9OqBl8dkrJllPUj0 9QUezAkNbF474bkx1FGVh9lUIpOFfQ== X-Received: by 10.80.178.228 with SMTP id p91mr25688903edd.131.1493775790316; Tue, 02 May 2017 18:43:10 -0700 (PDT) MIME-Version: 1.0 References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> In-Reply-To: From: Emil Ivov Date: Wed, 03 May 2017 01:42:59 +0000 Message-ID: To: Taylor Brandstetter Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=f403045c7f4e5b310c054e94c707 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 01:46:28 -0000 --f403045c7f4e5b310c054e94c707 Content-Type: text/plain; charset=UTF-8 On Tue, 2 May 2017 at 20:39, Taylor Brandstetter wrote: > I am reluctant to deal with situations where the candidate matrix is >> asymmetric > > > That example doesn't have asymmetric candidate matrices though; it's just > 3 media streams with 2 components each, and one foundation. > I wasn't refering to that example. > > >> So, unless someone has a great reason for why we'd need an entire stream >> to succeed before unfreezing the foundation, I'd rather we kept things as >> they are. > > > Actually, what I was concerned about is that even after an entire stream > succeeds, new candidate pairs with that foundation may start as frozen. > Em. You mean in your example above? Emil > > On Tue, May 2, 2017 at 2:47 PM, Emil Ivov wrote: > >> Hey, >> >> Apologies for coming in a bit late on this. >> >> On 4/18/17 8: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 >>> 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. >>> >> >> So yes, I agree this is a difference with 5245bis, but it's intentional. >> I see this in part as a simplification (I don't think it is a meaningful >> optimization even for 5245bis) but more specifically I am reluctant to deal >> with situations where the candidate matrix is asymmetric for whatever weird >> reason and one side is trying checks for M2F3 but the other isn't >> responding because M2F3 is blocked after a hole in M2F2 and it is not >> supposed to be unfrozen yet. Or something along those lines. >> >> So, unless someone has a great reason for why we'd need an entire stream >> to succeed before unfreezing the foundation, I'd rather we kept things as >> they are. >> >> Emil >> >> >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >> -- >> https://jitsi.org >> > > -- sent from my mobile --f403045c7f4e5b310c054e94c707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, 2 May 2017 at 20:39, Taylo= r Brandstetter <deadbeef@google.c= om> wrote:
=C2= =A0I am reluctant to deal with situations where the candidate matrix is asy= mmetric

That example does= n't have asymmetric candidate matrices though; it's just 3 media st= reams with 2 components each, and one foundation.
<= div>
I wasn't refering to that example.
=C2=A0
So, = unless someone has a great reason for why we'd need an entire stream to= succeed before unfreezing the foundation, I'd rather we kept things as= they are.

Actually, what= I was concerned about is that even after an entire stream succeeds, new ca= ndidate pairs with that foundation may start as frozen.

Em. You mean in your example above?

=
Emil
<= div class=3D"gmail_extra">
On Tue, May 2, 201= 7 at 2:47 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 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&= quot;,
where "S" is "succeeded", "W" is "waitin= g", 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=A01. Only the RTP candidate pair for the first media stream is unfrozen=
=C2=A0 =C2=A0 initially.
=C2=A0 =C2=A0 State: WFFFFF
=C2=A02. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
=C2=A0 =C2=A0 State: SWFFFF
=C2=A03. Check succeeds for RTCP pair. /All/ the other pairs with the same<= br> =C2=A0 =C2=A0 foundation are now unfrozen.
=C2=A0 =C2=A0 State: SSWWWW

With trickle ICE, here's what could happen:

=C2=A01. Candidates for the first media stream are trickled in. Starts out<= br> =C2=A0 =C2=A0 just like normal ICE.
=C2=A0 =C2=A0 State: WF
=C2=A02. Checks for both pairs succeed. Still waiting for candidates for =C2=A0 =C2=A0 other media streams.
=C2=A0 =C2=A0 State: SS
=C2=A03. Candidates for the other media streams arrive, and pairs are forme= d.
=C2=A0 =C2=A0 The topmost pair is set to waiting, but not the others.
=C2=A0 =C2=A0 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.

So yes, I agree this is a difference with 5245bis, but it's intentional= . I see this in part as a simplification (I don't think it is a meaning= ful optimization even for 5245bis) but more specifically I am reluctant to = deal with situations where the candidate matrix is asymmetric for whatever = weird reason and one side is trying checks for M2F3 but the other isn't= responding because M2F3 is blocked after a hole in M2F2 and it is not supp= osed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire strea= m to succeed before unfreezing the foundation, I'd rather we kept thing= s as they are.

Emil


On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

=C2=A0 =C2=A0 [areas of seeming agreement elided]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0* In section 8.1.1: In general I like the im= provements that have
=C2=A0 =C2=A0 been
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0made. However:
=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 "Frozen"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't complet= ely match standard ICE; at least the part
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "me= dia stream" completes, pairs from other media
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching f= oundations are unfrozen. With the current
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1,= only the topmost remaining pair in each
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guarantee= d to be unfrozen. Is this difference
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, w= e should at least acknowledge it, and not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impressi= on by saying "Trickle ICE preserves all
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] r= ules."

=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 is guaranteed to be unfrozen".

=C2=A0 =C2=A0 In particular, your statement doesn't seem to match the r= ules defined in
=C2=A0 =C2=A0 the Trickle spec. I've tried to spell them out in greater= detail (with
=C2=A0 =C2=A0 examples) in the following proposed text.

=C2=A0 =C2=A0 ###


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Consider the following tabular representation of= all checklists in an
=C2=A0 =C2=A0 =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 =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=A0Figure 1: Example of Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Each row in the table represents a component for= a given media stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP compo= nents for audio).
=C2=A0 =C2=A0 =C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Eac= h cell represents one
=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When an agent commences ICE processing, in accor= dance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting state) the topmost candidate pair in eve= ry column (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This s= tate is shown in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following table, with candidate pairs in the Wai= ting 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 Figure 2: Initial Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, 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 the Suc= ceeded state (denoted
=C2=A0 =C2=A0 =C2=A0 =C2=A0here by "s-cp"), the agent will unfree= ze all pairs for the same media
=C2=A0 =C2=A0 =C2=A0 =C2=A0stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
=C2=A0 =C2=A0 =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 =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=A0Figure 3: Che= ck List State after Succeeded Check

=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies that, if all the pairs in a m= edia stream for one
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 = and 2 representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0both components for the audio stream), then all = of the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., c= olumn 1, rows 3 and
=C2=A0 =C2=A0 =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 =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=A0Figure 4: Check List= State with Unfrozen Media Stream

=C2=A0 =C2=A0 =C2=A0 =C2=A0Trickle ICE preserves all of these rules as they= apply to what we
=C2=A0 =C2=A0 =C2=A0 =C2=A0might call "static" check list sets.= =C2=A0 This implies that if, for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0reason, a Trickle agent were to begin connectivi= ty checks with all of
=C2=A0 =C2=A0 =C2=A0 =C2=A0its pairs already present, the way that pair sta= tes change is
=C2=A0 =C2=A0 =C2=A0 =C2=A0indistinguishable from that of a regular ICE age= nt.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost = pair in this column,
=C2=A0 =C2=A0 =C2=A0 =C2=A0set the state to Waiting (e.g., this would be th= e case if the newly
=C2=A0 =C2=A0 =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 =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=A0Figure 5: Check List State = with Newly Formed Pair, Case 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 2: If the pair immediately above the newly = formed pair in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0column is in the Succeeded state, set the state = to Waiting (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0this would be the case if the pair in column 4, = row 2 succeeded and
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair were placed in column 4, r= ow 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=A0Figure 6: Check List State = with Newly Formed Pair, Case 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 3: If there is at least one pair in this co= lumn below the row of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair whose state is either Succ= eeded or Failed
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., this would be the case if the pair in col= umn 4, row 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded and the newly 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 | 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=A0Figure 7: Check List State = with Newly Formed Pair, Case 3

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

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 Peter




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


--
https://= jitsi.org

--
sent from my mobile
--f403045c7f4e5b310c054e94c707-- From nobody Tue May 2 19:02:52 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 0150F12EADD for ; Tue, 2 May 2017 19:02:51 -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 1t62iGUShfxf for ; Tue, 2 May 2017 19:02:47 -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 C421612EAE4 for ; Tue, 2 May 2017 19:00:04 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id q1so4025241qkd.2 for ; Tue, 02 May 2017 19:00:04 -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=H02+oqiBXnzAwUbyshxHtdgOMd83Vj7I8sfIMmycFW0=; b=Juiszlyb1TBBZqlnT7mXIgpdED4H3bPM4WtOIsgDo3iS45l3f1DQBvAWpkwuLVO0XW yA4kWjIt5uQyD55F3RmpZucBmACt501Q/MFlWsuR3o2ZhaSIQ3ZlXsyFXUpia2aeG792 mPcCENRZMWB1PzvxP+KFiMBm0eq7wEPvQo5ehVx3l/iETMbWSOv5SSOZhHai4GeEtIkD cGzrBtOHkmrHd9YO+grG5Ua+jlR6MTLBDNkVrBDSHs7IdujcieQGVu/E/MFbV0h2Nleb EE/8RvoA+QcOOB3+FFpFD10Ea906bZjyrgdP/Btcij+1kmpblf1sU5HSjEzXiRxxfcUz rHfw== 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=H02+oqiBXnzAwUbyshxHtdgOMd83Vj7I8sfIMmycFW0=; b=Qzn3rdZpaYN5YAKAnC4MMX/Vzy1WEl/3Yb64YsVNM9xwXXBcmaTeDJZosHjkF9QYxJ azouvanasoW/MW/KnLu9y6MMjxDnYuYoYap0vixEG4jbSyjWTwzs/gT67BCfO0ZlzxcA OQvB1iE6opUC85sgTLvCh2ZFTNd9QztdPUxWoxUXxJl5jMZSiX7UGs63GxmYXz9++KVz 6ddIi8DqEksbQTuBht46Cp1c3NOAJeqcbebyAKzN5tghPESQcpmvCkAdAYaQqrs3K6m4 IEX1garYRMYpmKn40wllmM2a4BeMQPHLimD8XfsDv5yxizfq1amDp8lRA/MGaNlbdUU8 3Vpw== X-Gm-Message-State: AN3rC/7eQ4eBlZZI/4E+oApYww2AJOzmPt83/u8sZ9o4jkvt9dYzXCpJ zBMTF3QpnKL3siT4/ujl0NswGPQYGSHp X-Received: by 10.55.18.91 with SMTP id c88mr876086qkh.143.1493776803611; Tue, 02 May 2017 19:00:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Tue, 2 May 2017 19:00:03 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> From: Taylor Brandstetter Date: Tue, 2 May 2017 19:00:03 -0700 Message-ID: To: Emil Ivov Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=001a11473ecac118fd054e9503b6 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 02:02:51 -0000 --001a11473ecac118fd054e9503b6 Content-Type: text/plain; charset=UTF-8 Sorry, I thought you were responding to my example since it was quoted above. Nevermind. On Tue, May 2, 2017 at 6:42 PM, Emil Ivov wrote: > > On Tue, 2 May 2017 at 20:39, Taylor Brandstetter > wrote: > >> I am reluctant to deal with situations where the candidate matrix is >>> asymmetric >> >> >> That example doesn't have asymmetric candidate matrices though; it's just >> 3 media streams with 2 components each, and one foundation. >> > > I wasn't refering to that example. > >> >> >>> So, unless someone has a great reason for why we'd need an entire stream >>> to succeed before unfreezing the foundation, I'd rather we kept things as >>> they are. >> >> >> Actually, what I was concerned about is that even after an entire stream >> succeeds, new candidate pairs with that foundation may start as frozen. >> > > Em. You mean in your example above? > > Emil > >> >> On Tue, May 2, 2017 at 2:47 PM, Emil Ivov wrote: >> >>> Hey, >>> >>> Apologies for coming in a bit late on this. >>> >>> On 4/18/17 8: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 >>>> 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. >>>> >>> >>> So yes, I agree this is a difference with 5245bis, but it's intentional. >>> I see this in part as a simplification (I don't think it is a meaningful >>> optimization even for 5245bis) but more specifically I am reluctant to deal >>> with situations where the candidate matrix is asymmetric for whatever weird >>> reason and one side is trying checks for M2F3 but the other isn't >>> responding because M2F3 is blocked after a hole in M2F2 and it is not >>> supposed to be unfrozen yet. Or something along those lines. >>> >>> So, unless someone has a great reason for why we'd need an entire stream >>> to succeed before unfreezing the foundation, I'd rather we kept things as >>> they are. >>> >>> Emil >>> >>> >>>> 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 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>>> >>> -- >>> https://jitsi.org >>> >> >> -- > sent from my mobile > --001a11473ecac118fd054e9503b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I thought you were responding to my example since i= t was quoted above. Nevermind.

On Tue, May 2, 2017 at 6:42 PM, Emil Ivov <emcho@jitsi.or= g> wrote:

On Tue, 2 May 2017 at 20:39, Taylo= r Brandstetter <deadbeef@google.com> wrote:
=C2=A0I am reluctant to deal with situations where the candid= ate matrix is asymmetric

= That example doesn't have asymmetric candidate matrices though; it'= s just 3 media streams with 2 components each, and one foundation.

I wasn't refering to that ex= ample.
=C2=A0
So, unless someone has a great reason = for why we'd need an entire stream to succeed before unfreezing the fou= ndation, I'd rather we kept things as they are.

Actually, what I was concerned about is that eve= n after an entire stream succeeds, new candidate pairs with that foundation= may start as frozen.

Em= . You mean in your example above?

Emil
<= div class=3D"h5">

On Tue, May 2, 2017 at= 2:47 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 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&= quot;,
where "S" is "succeeded", "W" is "waitin= g", 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=A01. Only the RTP candidate pair for the first media stream is unfrozen=
=C2=A0 =C2=A0 initially.
=C2=A0 =C2=A0 State: WFFFFF
=C2=A02. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
=C2=A0 =C2=A0 State: SWFFFF
=C2=A03. Check succeeds for RTCP pair. /All/ the other pairs with the same<= br> =C2=A0 =C2=A0 foundation are now unfrozen.
=C2=A0 =C2=A0 State: SSWWWW

With trickle ICE, here's what could happen:

=C2=A01. Candidates for the first media stream are trickled in. Starts out<= br> =C2=A0 =C2=A0 just like normal ICE.
=C2=A0 =C2=A0 State: WF
=C2=A02. Checks for both pairs succeed. Still waiting for candidates for =C2=A0 =C2=A0 other media streams.
=C2=A0 =C2=A0 State: SS
=C2=A03. Candidates for the other media streams arrive, and pairs are forme= d.
=C2=A0 =C2=A0 The topmost pair is set to waiting, but not the others.
=C2=A0 =C2=A0 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.

So yes, I agree this is a difference with 5245bis, but it's intentional= . I see this in part as a simplification (I don't think it is a meaning= ful optimization even for 5245bis) but more specifically I am reluctant to = deal with situations where the candidate matrix is asymmetric for whatever = weird reason and one side is trying checks for M2F3 but the other isn't= responding because M2F3 is blocked after a hole in M2F2 and it is not supp= osed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire strea= m to succeed before unfreezing the foundation, I'd rather we kept thing= s as they are.

Emil


On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

=C2=A0 =C2=A0 [areas of seeming agreement elided]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0* In section 8.1.1: In general I like the im= provements that have
=C2=A0 =C2=A0 been
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0made. However:
=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 "Frozen"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't complet= ely match standard ICE; at least the part
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "me= dia stream" completes, pairs from other media
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching f= oundations are unfrozen. With the current
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1,= only the topmost remaining pair in each
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guarantee= d to be unfrozen. Is this difference
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, w= e should at least acknowledge it, and not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impressi= on by saying "Trickle ICE preserves all
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] r= ules."

=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 is guaranteed to be unfrozen".

=C2=A0 =C2=A0 In particular, your statement doesn't seem to match the r= ules defined in
=C2=A0 =C2=A0 the Trickle spec. I've tried to spell them out in greater= detail (with
=C2=A0 =C2=A0 examples) in the following proposed text.

=C2=A0 =C2=A0 ###


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Consider the following tabular representation of= all checklists in an
=C2=A0 =C2=A0 =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 =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=A0Figure 1: Example of Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Each row in the table represents a component for= a given media stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP compo= nents for audio).
=C2=A0 =C2=A0 =C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Eac= h cell represents one
=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When an agent commences ICE processing, in accor= dance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting state) the topmost candidate pair in eve= ry column (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This s= tate is shown in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following table, with candidate pairs in the Wai= ting 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 Figure 2: Initial Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, 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 the Suc= ceeded state (denoted
=C2=A0 =C2=A0 =C2=A0 =C2=A0here by "s-cp"), the agent will unfree= ze all pairs for the same media
=C2=A0 =C2=A0 =C2=A0 =C2=A0stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
=C2=A0 =C2=A0 =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 =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=A0Figure 3: Che= ck List State after Succeeded Check

=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies that, if all the pairs in a m= edia stream for one
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 = and 2 representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0both components for the audio stream), then all = of the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., c= olumn 1, rows 3 and
=C2=A0 =C2=A0 =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 =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=A0Figure 4: Check List= State with Unfrozen Media Stream

=C2=A0 =C2=A0 =C2=A0 =C2=A0Trickle ICE preserves all of these rules as they= apply to what we
=C2=A0 =C2=A0 =C2=A0 =C2=A0might call "static" check list sets.= =C2=A0 This implies that if, for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0reason, a Trickle agent were to begin connectivi= ty checks with all of
=C2=A0 =C2=A0 =C2=A0 =C2=A0its pairs already present, the way that pair sta= tes change is
=C2=A0 =C2=A0 =C2=A0 =C2=A0indistinguishable from that of a regular ICE age= nt.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost = pair in this column,
=C2=A0 =C2=A0 =C2=A0 =C2=A0set the state to Waiting (e.g., this would be th= e case if the newly
=C2=A0 =C2=A0 =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 =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=A0Figure 5: Check List State = with Newly Formed Pair, Case 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 2: If the pair immediately above the newly = formed pair in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0column is in the Succeeded state, set the state = to Waiting (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0this would be the case if the pair in column 4, = row 2 succeeded and
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair were placed in column 4, r= ow 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=A0Figure 6: Check List State = with Newly Formed Pair, Case 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 3: If there is at least one pair in this co= lumn below the row of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair whose state is either Succ= eeded or Failed
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., this would be the case if the pair in col= umn 4, row 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded and the newly 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 | 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=A0Figure 7: Check List State = with Newly Formed Pair, Case 3

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

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 Peter




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


--
https://= jitsi.org

--
sent from my mobile

--001a11473ecac118fd054e9503b6-- From nobody Tue May 2 19:06: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 370711294B2 for ; Tue, 2 May 2017 19:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtG6yFEKUQVe for ; Tue, 2 May 2017 19:06:36 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78DC612EB19 for ; Tue, 2 May 2017 19:03:48 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id r190so40712145wme.1 for ; Tue, 02 May 2017 19:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zhLjXGig52dcPVir5Bv+CkawfspxJXzao6OGphIfdnU=; b=xW8rvWRQRWVI1oHoXnyGRsJABeBd1ppv0rvBO7a/VFgU/iMqj97D8ER1cgzoN3KC4W YvHPaD+IMZteVGSVnE8hzUMf9TksvKxH2bvk89dveTzIz4E6knv81IyHSZdGFmMRwk7U 9VT3A7hQQBUxSgobuKRX3o5EvP0nArOnxOPjrK4MMGeB9Ie2W1h5INkAaduZQbLgNxEZ s8nO4SdRkZ3YS4XzdHm+q9NIBASDpA5iknDWc14GLJ7epCehZu8a1TDryekWn/wy2Vpw b11qWfE2hzKzTlcuraZoqj5YEH5Yt9QDZCwHWVWh3oNx2+6FOldN5AOnFhWFIkXojq9t iblw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zhLjXGig52dcPVir5Bv+CkawfspxJXzao6OGphIfdnU=; b=rla/ZOwW8R25RmhOv99wvhALT+dWIFjc3kFiaIF/O0nOm77H3mfkTl1gQJUYLsQ7d2 R5qihfvJWfh9GwNIYkRUsIBacrTMluhpipcMcUZ7yPWIqHrcsUUMvxqx6x1Q3jgY6QF4 1e00w6LrI+Xhxszd5SBy3Ot2noWTR92X9HPRBCnwUrqgvrYurW3fNtDxx8Lrr67xWFq3 SzX4tgc67hbOFzu+UGzIk+ERqBOv0da0APkXxsnZ9T19QZd61v8DymZzmN/zmi8tcJA9 tZBm8iz3n17y4RiBqjsnLgsFHa+hv34t+jB4e5GDNJeo+Ehl+nvZYflcFMJqUtoTqbOK VraQ== X-Gm-Message-State: AN3rC/4LMaD9Sw5wfJiT4W+hO14f8wHyyCZ39vSwbAe4VlWWfzDkuRkl mHq4oGJFr3DR9k09bYHmyQIjK+zgR3BQ X-Received: by 10.80.144.203 with SMTP id d11mr24485206eda.162.1493777026879; Tue, 02 May 2017 19:03:46 -0700 (PDT) MIME-Version: 1.0 References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> In-Reply-To: From: Emil Ivov Date: Wed, 03 May 2017 02:03:36 +0000 Message-ID: To: Taylor Brandstetter Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0c3ad00fa95b054e951187 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 02:06:40 -0000 --94eb2c0c3ad00fa95b054e951187 Content-Type: text/plain; charset=UTF-8 On Tue, 2 May 2017 at 21:00, Taylor Brandstetter wrote: > Sorry, I thought you were responding to my example since it was quoted > above. Nevermind. > I was responding to your comment on how the new rules do not guarantee that both components of the stream would have to succeed before a new stream for that foundation gets unfrozen. So I was saying that this is true but I don't think preserving this property is essential. I thought you were objecting to that. Should I understand you are good then? Emil > > On Tue, May 2, 2017 at 6:42 PM, Emil Ivov wrote: > >> >> On Tue, 2 May 2017 at 20:39, Taylor Brandstetter >> wrote: >> >>> I am reluctant to deal with situations where the candidate matrix is >>>> asymmetric >>> >>> >>> That example doesn't have asymmetric candidate matrices though; it's >>> just 3 media streams with 2 components each, and one foundation. >>> >> >> I wasn't refering to that example. >> >>> >>> >>>> So, unless someone has a great reason for why we'd need an entire >>>> stream to succeed before unfreezing the foundation, I'd rather we kept >>>> things as they are. >>> >>> >>> Actually, what I was concerned about is that even after an entire stream >>> succeeds, new candidate pairs with that foundation may start as frozen. >>> >> >> Em. You mean in your example above? >> >> Emil >> >>> >>> On Tue, May 2, 2017 at 2:47 PM, Emil Ivov wrote: >>> >>>> Hey, >>>> >>>> Apologies for coming in a bit late on this. >>>> >>>> On 4/18/17 8: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 >>>>> 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. >>>>> >>>> >>>> So yes, I agree this is a difference with 5245bis, but it's >>>> intentional. I see this in part as a simplification (I don't think it is a >>>> meaningful optimization even for 5245bis) but more specifically I am >>>> reluctant to deal with situations where the candidate matrix is asymmetric >>>> for whatever weird reason and one side is trying checks for M2F3 but the >>>> other isn't responding because M2F3 is blocked after a hole in M2F2 and it >>>> is not supposed to be unfrozen yet. Or something along those lines. >>>> >>>> So, unless someone has a great reason for why we'd need an entire >>>> stream to succeed before unfreezing the foundation, I'd rather we kept >>>> things as they are. >>>> >>>> Emil >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ice mailing list >>>>> Ice@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ice >>>>> >>>>> >>>> -- >>>> https://jitsi.org >>>> >>> >>> -- >> sent from my mobile >> > > -- sent from my mobile --94eb2c0c3ad00fa95b054e951187 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, 2 May 2017 at 21:00, Taylo= r Brandstetter <deadbeef@google.c= om> wrote:
Sorry, I tho= ught you were responding to my example since it was quoted above. Nevermind= .

I was responding to your comment on= how the new rules do not guarantee that both components of the stream woul= d have to succeed before a new stream for that foundation gets unfrozen.

So I was saying that this is true but I don't th= ink preserving this property is essential.

I thoug= ht you were objecting to that.

Should I understand= you are good then?

Emil

On Tue, May 2, 2017 at 6:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

<= div>On Tue, 2 May 2017 at 20:39, Taylor Brandstetter <deadbeef@google.com> wrote:
=C2=A0I am reluctant to= deal with situations where the candidate matrix is asymmetric

That example doesn't have asymmet= ric candidate matrices though; it's just 3 media streams with 2 compone= nts each, and one foundation.

I wasn't refering to that example.
=C2=A0
So, unles= s someone has a great reason for why we'd need an entire stream to succ= eed before unfreezing the foundation, I'd rather we kept things as they= are.

Actually, what I wa= s concerned about is that even after an entire stream succeeds, new candida= te pairs with that foundation may start as frozen.
=

Em. You mean in your example above?
Emil

=
On Tue, May 2, 2017 at 2:47 PM, Emil Ivov = <emcho@jitsi.org> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 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&= quot;,
where "S" is "succeeded", "W" is "waitin= g", 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=A01. Only the RTP candidate pair for the first media stream is unfrozen=
=C2=A0 =C2=A0 initially.
=C2=A0 =C2=A0 State: WFFFFF
=C2=A02. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
=C2=A0 =C2=A0 State: SWFFFF
=C2=A03. Check succeeds for RTCP pair. /All/ the other pairs with the same<= br> =C2=A0 =C2=A0 foundation are now unfrozen.
=C2=A0 =C2=A0 State: SSWWWW

With trickle ICE, here's what could happen:

=C2=A01. Candidates for the first media stream are trickled in. Starts out<= br> =C2=A0 =C2=A0 just like normal ICE.
=C2=A0 =C2=A0 State: WF
=C2=A02. Checks for both pairs succeed. Still waiting for candidates for =C2=A0 =C2=A0 other media streams.
=C2=A0 =C2=A0 State: SS
=C2=A03. Candidates for the other media streams arrive, and pairs are forme= d.
=C2=A0 =C2=A0 The topmost pair is set to waiting, but not the others.
=C2=A0 =C2=A0 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.

So yes, I agree this is a difference with 5245bis, but it's intentional= . I see this in part as a simplification (I don't think it is a meaning= ful optimization even for 5245bis) but more specifically I am reluctant to = deal with situations where the candidate matrix is asymmetric for whatever = weird reason and one side is trying checks for M2F3 but the other isn't= responding because M2F3 is blocked after a hole in M2F2 and it is not supp= osed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire strea= m to succeed before unfreezing the foundation, I'd rather we kept thing= s as they are.

Emil


On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

=C2=A0 =C2=A0 [areas of seeming agreement elided]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0* In section 8.1.1: In general I like the im= provements that have
=C2=A0 =C2=A0 been
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0made. However:
=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 "Frozen"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't complet= ely match standard ICE; at least the part
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "me= dia stream" completes, pairs from other media
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching f= oundations are unfrozen. With the current
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1,= only the topmost remaining pair in each
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guarantee= d to be unfrozen. Is this difference
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, w= e should at least acknowledge it, and not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impressi= on by saying "Trickle ICE preserves all
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] r= ules."

=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 is guaranteed to be unfrozen".

=C2=A0 =C2=A0 In particular, your statement doesn't seem to match the r= ules defined in
=C2=A0 =C2=A0 the Trickle spec. I've tried to spell them out in greater= detail (with
=C2=A0 =C2=A0 examples) in the following proposed text.

=C2=A0 =C2=A0 ###


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Consider the following tabular representation of= all checklists in an
=C2=A0 =C2=A0 =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 =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=A0Figure 1: Example of Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Each row in the table represents a component for= a given media stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP compo= nents for audio).
=C2=A0 =C2=A0 =C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Eac= h cell represents one
=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When an agent commences ICE processing, in accor= dance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting state) the topmost candidate pair in eve= ry column (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This s= tate is shown in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following table, with candidate pairs in the Wai= ting 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 Figure 2: Initial Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, 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 the Suc= ceeded state (denoted
=C2=A0 =C2=A0 =C2=A0 =C2=A0here by "s-cp"), the agent will unfree= ze all pairs for the same media
=C2=A0 =C2=A0 =C2=A0 =C2=A0stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
=C2=A0 =C2=A0 =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 =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=A0Figure 3: Che= ck List State after Succeeded Check

=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies that, if all the pairs in a m= edia stream for one
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 = and 2 representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0both components for the audio stream), then all = of the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., c= olumn 1, rows 3 and
=C2=A0 =C2=A0 =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 =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=A0Figure 4: Check List= State with Unfrozen Media Stream

=C2=A0 =C2=A0 =C2=A0 =C2=A0Trickle ICE preserves all of these rules as they= apply to what we
=C2=A0 =C2=A0 =C2=A0 =C2=A0might call "static" check list sets.= =C2=A0 This implies that if, for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0reason, a Trickle agent were to begin connectivi= ty checks with all of
=C2=A0 =C2=A0 =C2=A0 =C2=A0its pairs already present, the way that pair sta= tes change is
=C2=A0 =C2=A0 =C2=A0 =C2=A0indistinguishable from that of a regular ICE age= nt.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost = pair in this column,
=C2=A0 =C2=A0 =C2=A0 =C2=A0set the state to Waiting (e.g., this would be th= e case if the newly
=C2=A0 =C2=A0 =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 =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=A0Figure 5: Check List State = with Newly Formed Pair, Case 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 2: If the pair immediately above the newly = formed pair in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0column is in the Succeeded state, set the state = to Waiting (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0this would be the case if the pair in column 4, = row 2 succeeded and
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair were placed in column 4, r= ow 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=A0Figure 6: Check List State = with Newly Formed Pair, Case 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 3: If there is at least one pair in this co= lumn below the row of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair whose state is either Succ= eeded or Failed
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., this would be the case if the pair in col= umn 4, row 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded and the newly 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 | 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=A0Figure 7: Check List State = with Newly Formed Pair, Case 3

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

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 Peter




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


--
https://= jitsi.org

--
sent from my mobile

--
sent from my mobile
--94eb2c0c3ad00fa95b054e951187-- From nobody Tue May 2 22:05:20 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 1F82E12949F for ; Tue, 2 May 2017 22:05:19 -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 5ksxn7Zkg8c8 for ; Tue, 2 May 2017 22:05:14 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 5CED9120727 for ; Tue, 2 May 2017 22:03:21 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id c45so128980099qtb.1 for ; Tue, 02 May 2017 22:03:21 -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=VuQ/u3Ne0RK4gB6160gr1VA01I2/WUHsv6pGd9wF5Cg=; b=JTFy6A9fAZzMrrwrRPw2iUreehxZRNOIfpzRxYf+/3+xouJx16US+XyDLF0yJWwudb xE3yhHEuKocDhbBKhkL/yWDozA540txlqjHCe5Vkg41UiVLHtlKO9PNM+o64ntmXBuSI C1jWBqpKrzdqHKwXHnjNlFSjC0fHwFnGCkjOQDpfhL6vsmieQFvYuJKy0Kx39wTF+rzX 6oYY53G6Vp7EcIe6LvI2p/BB2L1BNTGNlBDpzpC1L1KQxH59CPw3A/bXgtx20PHLl3sN 2+RdHi+9lgE3Wjp15VBfMLmngSnQXiHK91V981Q99Na3qKMyu58zLNdfyG1yCwMmmpa8 /y4w== 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=VuQ/u3Ne0RK4gB6160gr1VA01I2/WUHsv6pGd9wF5Cg=; b=C5tWc9ztjswxL+113SkZ8kK+MnYjNtPby57V6fpySyqQo7MlrW8vCmrVUiNRbypDxl DCKSdFUbCqh4Gg6eNXvanQ6oH4e4Coryn1utFaE8KvPc9WfRUfrLujLjFZOZH1FyJ7Eq HNXyXetsXsTh3YWBcZvFCFQQhQPpEcogdgTeV+1mh37OWVWbCiGLw9X6En3gk/38x02a rf+QBh590oK4Q3GRpgCzt9PpIXY9i0SgYSJwvM74MM0wNVCA8/W5NqIFeG6Xch9SDu9H Qj8ffi2XiPtWoje00JUI4VkeMiIR8z3KPgN/2tTJRW/3ht6Y4bigzmKGoyyad6PwWGie +SSw== X-Gm-Message-State: AN3rC/5bsuWJX0P4Rxc+bGAV4lJEhMEt5XUe1+Pw8F12LvisyJfclZ7Z ug9i+2j2+K6P+ohyJyICmFoupsez10Bd X-Received: by 10.200.33.245 with SMTP id 50mr28697183qtz.64.1493787800277; Tue, 02 May 2017 22:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Tue, 2 May 2017 22:03:19 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> From: Taylor Brandstetter Date: Tue, 2 May 2017 22:03:19 -0700 Message-ID: To: Emil Ivov Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=001a11402e0e34f74c054e97938f Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 05:05:19 -0000 --001a11402e0e34f74c054e97938f Content-Type: text/plain; charset=UTF-8 When I said "trickle ICE only guarantees that one of them is", I meant "only guarantees that one pair is unfrozen". I'm glad that the "both components of a media stream" part is removed from ICEbis, but the property I thought does make sense to preserve is "once one pair in a foundation succeeds, every pair with that foundation is unfrozen". On Tue, May 2, 2017 at 7:03 PM, Emil Ivov wrote: > > On Tue, 2 May 2017 at 21:00, Taylor Brandstetter > wrote: > >> Sorry, I thought you were responding to my example since it was quoted >> above. Nevermind. >> > > I was responding to your comment on how the new rules do not guarantee > that both components of the stream would have to succeed before a new > stream for that foundation gets unfrozen. > > So I was saying that this is true but I don't think preserving this > property is essential. > > I thought you were objecting to that. > > Should I understand you are good then? > > Emil > >> >> On Tue, May 2, 2017 at 6:42 PM, Emil Ivov wrote: >> >>> >>> On Tue, 2 May 2017 at 20:39, Taylor Brandstetter >>> wrote: >>> >>>> I am reluctant to deal with situations where the candidate matrix is >>>>> asymmetric >>>> >>>> >>>> That example doesn't have asymmetric candidate matrices though; it's >>>> just 3 media streams with 2 components each, and one foundation. >>>> >>> >>> I wasn't refering to that example. >>> >>>> >>>> >>>>> So, unless someone has a great reason for why we'd need an entire >>>>> stream to succeed before unfreezing the foundation, I'd rather we kept >>>>> things as they are. >>>> >>>> >>>> Actually, what I was concerned about is that even after an entire >>>> stream succeeds, new candidate pairs with that foundation may start as >>>> frozen. >>>> >>> >>> Em. You mean in your example above? >>> >>> Emil >>> >>>> >>>> On Tue, May 2, 2017 at 2:47 PM, Emil Ivov wrote: >>>> >>>>> Hey, >>>>> >>>>> Apologies for coming in a bit late on this. >>>>> >>>>> On 4/18/17 8: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 >>>>>> 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. >>>>>> >>>>> >>>>> So yes, I agree this is a difference with 5245bis, but it's >>>>> intentional. I see this in part as a simplification (I don't think it is a >>>>> meaningful optimization even for 5245bis) but more specifically I am >>>>> reluctant to deal with situations where the candidate matrix is asymmetric >>>>> for whatever weird reason and one side is trying checks for M2F3 but the >>>>> other isn't responding because M2F3 is blocked after a hole in M2F2 and it >>>>> is not supposed to be unfrozen yet. Or something along those lines. >>>>> >>>>> So, unless someone has a great reason for why we'd need an entire >>>>> stream to succeed before unfreezing the foundation, I'd rather we kept >>>>> things as they are. >>>>> >>>>> Emil >>>>> >>>>> >>>>>> On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre < >>>>>> 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 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ice mailing list >>>>>> Ice@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ice >>>>>> >>>>>> >>>>> -- >>>>> https://jitsi.org >>>>> >>>> >>>> -- >>> sent from my mobile >>> >> >> -- > sent from my mobile > --001a11402e0e34f74c054e97938f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I said "trickle= ICE only guarantees that one of them is", I meant "only guarante= es that one pair is unfrozen".=C2=A0I'm glad that the "both components of a media stream" p= art is removed from ICEbis, but the property I thought does make sense to p= reserve is "once one pair in a foundation succeeds, every pair with th= at foundation is unfrozen".
On Tue, May 2, 2017 at 7:03 PM, Emil Ivov <emcho= @jitsi.org> wrote:
On Tue, 2 May 2017 at 21:= 00, Taylor Brandstetter <deadbeef@google.com> wrote:
Sorry, I thought you were responding to my example since= it was quoted above. Nevermind.

I was responding to your comment on how the new rules do not guarantee t= hat both components of the stream would have to succeed before a new stream= for that foundation gets unfrozen.

So I was sayin= g that this is true but I don't think preserving this property is essen= tial.

I thought you were objecting to that.
<= div>
Should I understand you are good then?

Emil

On Tue, M= ay 2, 2017 at 6:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Tue, 2 = May 2017 at 20:39, Taylor Brandstetter <deadbeef@google.com> wrote:
=C2=A0I am reluctant to deal with sit= uations where the candidate matrix is asymmetric
That example doesn't have asymmetric candidate = matrices though; it's just 3 media streams with 2 components each, and = one foundation.

I wasn&#= 39;t refering to that example.
=C2=A0
So, unless someone has a = great reason for why we'd need an entire stream to succeed before unfre= ezing the foundation, I'd rather we kept things as they are.

Actually, what I was concerned abou= t is that even after an entire stream succeeds, new candidate pairs with th= at foundation may start as frozen.

<= /span>
Em. You mean in your example above?

Emi= l
=
On Tue, May 2, 2017 at 2:47 PM, Emil Ivov <emcho@jitsi.or= g> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 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&= quot;,
where "S" is "succeeded", "W" is "waitin= g", 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=A01. Only the RTP candidate pair for the first media stream is unfrozen=
=C2=A0 =C2=A0 initially.
=C2=A0 =C2=A0 State: WFFFFF
=C2=A02. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
=C2=A0 =C2=A0 State: SWFFFF
=C2=A03. Check succeeds for RTCP pair. /All/ the other pairs with the same<= br> =C2=A0 =C2=A0 foundation are now unfrozen.
=C2=A0 =C2=A0 State: SSWWWW

With trickle ICE, here's what could happen:

=C2=A01. Candidates for the first media stream are trickled in. Starts out<= br> =C2=A0 =C2=A0 just like normal ICE.
=C2=A0 =C2=A0 State: WF
=C2=A02. Checks for both pairs succeed. Still waiting for candidates for =C2=A0 =C2=A0 other media streams.
=C2=A0 =C2=A0 State: SS
=C2=A03. Candidates for the other media streams arrive, and pairs are forme= d.
=C2=A0 =C2=A0 The topmost pair is set to waiting, but not the others.
=C2=A0 =C2=A0 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.

So yes, I agree this is a difference with 5245bis, but it's intentional= . I see this in part as a simplification (I don't think it is a meaning= ful optimization even for 5245bis) but more specifically I am reluctant to = deal with situations where the candidate matrix is asymmetric for whatever = weird reason and one side is trying checks for M2F3 but the other isn't= responding because M2F3 is blocked after a hole in M2F2 and it is not supp= osed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire strea= m to succeed before unfreezing the foundation, I'd rather we kept thing= s as they are.

Emil


On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

=C2=A0 =C2=A0 [areas of seeming agreement elided]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0* In section 8.1.1: In general I like the im= provements that have
=C2=A0 =C2=A0 been
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0made. However:
=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 "Frozen"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't complet= ely match standard ICE; at least the part
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "me= dia stream" completes, pairs from other media
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching f= oundations are unfrozen. With the current
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1,= only the topmost remaining pair in each
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guarantee= d to be unfrozen. Is this difference
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, w= e should at least acknowledge it, and not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impressi= on by saying "Trickle ICE preserves all
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] r= ules."

=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 is guaranteed to be unfrozen".

=C2=A0 =C2=A0 In particular, your statement doesn't seem to match the r= ules defined in
=C2=A0 =C2=A0 the Trickle spec. I've tried to spell them out in greater= detail (with
=C2=A0 =C2=A0 examples) in the following proposed text.

=C2=A0 =C2=A0 ###


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Consider the following tabular representation of= all checklists in an
=C2=A0 =C2=A0 =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 =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=A0Figure 1: Example of Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Each row in the table represents a component for= a given media stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP compo= nents for audio).
=C2=A0 =C2=A0 =C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Eac= h cell represents one
=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When an agent commences ICE processing, in accor= dance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting state) the topmost candidate pair in eve= ry column (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This s= tate is shown in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following table, with candidate pairs in the Wai= ting 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 Figure 2: Initial Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, 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 the Suc= ceeded state (denoted
=C2=A0 =C2=A0 =C2=A0 =C2=A0here by "s-cp"), the agent will unfree= ze all pairs for the same media
=C2=A0 =C2=A0 =C2=A0 =C2=A0stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
=C2=A0 =C2=A0 =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 =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=A0Figure 3: Che= ck List State after Succeeded Check

=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies that, if all the pairs in a m= edia stream for one
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 = and 2 representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0both components for the audio stream), then all = of the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., c= olumn 1, rows 3 and
=C2=A0 =C2=A0 =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 =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=A0Figure 4: Check List= State with Unfrozen Media Stream

=C2=A0 =C2=A0 =C2=A0 =C2=A0Trickle ICE preserves all of these rules as they= apply to what we
=C2=A0 =C2=A0 =C2=A0 =C2=A0might call "static" check list sets.= =C2=A0 This implies that if, for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0reason, a Trickle agent were to begin connectivi= ty checks with all of
=C2=A0 =C2=A0 =C2=A0 =C2=A0its pairs already present, the way that pair sta= tes change is
=C2=A0 =C2=A0 =C2=A0 =C2=A0indistinguishable from that of a regular ICE age= nt.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost = pair in this column,
=C2=A0 =C2=A0 =C2=A0 =C2=A0set the state to Waiting (e.g., this would be th= e case if the newly
=C2=A0 =C2=A0 =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 =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=A0Figure 5: Check List State = with Newly Formed Pair, Case 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 2: If the pair immediately above the newly = formed pair in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0column is in the Succeeded state, set the state = to Waiting (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0this would be the case if the pair in column 4, = row 2 succeeded and
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair were placed in column 4, r= ow 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=A0Figure 6: Check List State = with Newly Formed Pair, Case 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 3: If there is at least one pair in this co= lumn below the row of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair whose state is either Succ= eeded or Failed
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., this would be the case if the pair in col= umn 4, row 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded and the newly 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 | 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=A0Figure 7: Check List State = with Newly Formed Pair, Case 3

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

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 Peter




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


--
https://= jitsi.org

--
sent from my mobile

--
sen= t from my mobile

--001a11402e0e34f74c054e97938f-- From nobody Tue May 2 23:14: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 96898129C6E for ; Tue, 2 May 2017 23:14: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, 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 7YtN_SuoIec4 for ; Tue, 2 May 2017 23:14:24 -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 51F62128954 for ; Tue, 2 May 2017 23:12:14 -0700 (PDT) X-AuditID: c1b4fb3a-f56d89a000005025-c9-590974bc7077 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.34.20517.CB479095; Wed, 3 May 2017 08:12:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Wed, 3 May 2017 08:12:11 +0200 From: Christer Holmberg To: Taylor Brandstetter , Emil Ivov CC: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt) Thread-Index: AQHSw44yG+8l/JxG+UWcffU9JI4fXaHhs50AgAAA74CAAATFgIAAAP4AgAAyNoCAAEbqAA== Date: Wed, 3 May 2017 06:12:10 +0000 Message-ID: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> In-Reply-To: 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.17] Content-Type: multipart/alternative; boundary="_000_D52F4DC91C013christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7t+6eEs5Ig6MflC0ur3jIarFm5wQW i28Xai2O7elndmDxWLCp1GPJkp9MHv/fBHrM3fOCOYAlissmJTUnsyy1SN8ugSvjwN8dbAVz njJVvFj5iqWBsWkxUxcjJ4eEgIlEw8luti5GLg4hgSOMEn92L2YBSQgJLGaUOHdcs4uRg4NN wEKi+582SFhEwEvi9r8NYL3MAp4Sj4/vYgIpERZIkOiY4QtRkiix6uIlRgg7TOL5vHcsICUs AioSk17JgJi8AtYS91o9IJY+ZJE4dm8vM0g5p0CgxJoth8BaGQXEJL6fWgO1SVzi1pP5UBcL SCzZc54ZwhaVePn4HyuILSqgJ7Hv31c2kPkSAooSy/vlQExmoMOW7CoDqeAVEJQ4OfMJywRG 0VlIhs5CqJqFpAqixEDi/bn5zBC2tsSyha+hbH2JjV/OMkK0Wku8b05HVrKAkWMVo2hxanFx brqRkV5qUWZycXF+nl5easkmRmB8Htzy22oH48HnjocYBTgYlXh4FU5yRAqxJpYVV+YeYpTg YFYS4T1szRkpxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dU A2NVj2fl5ECj8t4ePeFHe25GqXTfaLjLtdvaoue/D6swg6FpishX6zMpclenq908Y3tANls1 VLB7TQZ/wPXsx7s+bVZjFu5U7i8N+iAVfsP8L6uRxKprkca/GgoLlfNP3JR/oOczKbb3W/0E Tvf5vimHXY3Lmo9eULN7z8zpEvP557YDzdfKlViKMxINtZiLihMB+zBiPMsCAAA= Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 06:14:29 -0000 --_000_D52F4DC91C013christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I am a little confused, because I don=92t know if you talk about text curre= ntly in 5245bis, or text that you would like to see in 5245bis :) CURRENTLY in 5245bis, once a pair succeeds, all other pairs for the same fo= undation are unfrozen. There is no rule saying that, for a given stream, al= l components have to succeed before the other streams are unfrozen. Is that how you want it? Do you want to change that? Or, don=92t you agree = that is what 5245bis currently says in the first place? Regards, Christer From: Ice > on behalf of = Taylor Brandstetter > Date: Wednesday 3 May 2017 at 08:03 To: Emil Ivov > Cc: "stpeter@stpeter.im" >, "ice@ietf.org" > Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-= ice-trickle-08.txt) When I said "trickle ICE only guarantees that one of them is", I meant "onl= y guarantees that one pair is unfrozen". I'm glad that the "both components= of a media stream" part is removed from ICEbis, but the property I thought= does make sense to preserve is "once one pair in a foundation succeeds, ev= ery pair with that foundation is unfrozen". On Tue, May 2, 2017 at 7:03 PM, Emil Ivov > wrote: On Tue, 2 May 2017 at 21:00, Taylor Brandstetter > wrote: Sorry, I thought you were responding to my example since it was quoted abov= e. Nevermind. I was responding to your comment on how the new rules do not guarantee that= both components of the stream would have to succeed before a new stream fo= r that foundation gets unfrozen. So I was saying that this is true but I don't think preserving this propert= y is essential. I thought you were objecting to that. Should I understand you are good then? Emil On Tue, May 2, 2017 at 6:42 PM, Emil Ivov > wrote: On Tue, 2 May 2017 at 20:39, Taylor Brandstetter > wrote: I am reluctant to deal with situations where the candidate matrix is asymm= etric That example doesn't have asymmetric candidate matrices though; it's just 3= media streams with 2 components each, and one foundation. I wasn't refering to that example. So, unless someone has a great reason for why we'd need an entire stream to= succeed before unfreezing the foundation, I'd rather we kept things as the= y are. Actually, what I was concerned about is that even after an entire stream su= cceeds, new candidate pairs with that foundation may start as frozen. Em. You mean in your example above? Emil On Tue, May 2, 2017 at 2:47 PM, Emil Ivov > wrote: Hey, Apologies for coming in a bit late on this. On 4/18/17 8: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 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. So yes, I agree this is a difference with 5245bis, but it's intentional. I = see this in part as a simplification (I don't think it is a meaningful opti= mization even for 5245bis) but more specifically I am reluctant to deal wit= h situations where the candidate matrix is asymmetric for whatever weird re= ason and one side is trying checks for M2F3 but the other isn't responding = because M2F3 is blocked after a hole in M2F2 and it is not supposed to be u= nfrozen yet. Or something along those lines. So, unless someone has a great reason for why we'd need an entire stream to= succeed before unfreezing the foundation, I'd rather we kept things as the= y are. Emil 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 med= ia > streams with matching foundations are unfrozen. With the curr= ent > rules in section 8.1.1, only the topmost remaining pair in ea= ch > 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 al= l > 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 i= n 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 a= n 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 strea= m (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 (denote= d here by "s-cp"), the agent will unfreeze all pairs for the same medi= a 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 o= f 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 o= f 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 _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice -- https://jitsi.org -- sent from my mobile -- sent from my mobile --_000_D52F4DC91C013christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4AB60D29EAD6DA4DBAE3EF45EF01880B@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

I am a little confused, because I don=92t know if you talk about text = currently in 5245bis, or text that you would like to see in 5245bis :)

CURRENTLY in 5245bis, once a pair succeeds, all other pairs for the sa= me foundation are unfrozen. There is no rule saying that, for a given strea= m, all components have to succeed before the other streams are unfrozen.

Is that how you want it? Do you want to change that? Or, don=92t you a= gree that is what 5245bis currently says in the first place?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Taylor Brandst= etter <deadbeef@google.com>= ;
Date: Wednesday 3 May 2017 at 08:03=
To: Emil Ivov <emcho@jitsi.org>
Cc: "stpeter@stpeter.im" <stpeter@stpeter.im>, "= ice@ietf.org" <ice@ietf.org= >
Subject: Re: [Ice] holes in the mat= rix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt)

When I said "trickle= ICE only guarantees that one of them is", I meant "only guarante= es that one pair is unfrozen". I'm glad that the "both components of a media stream" part is removed from ICEbis, but the property I thought does make sense to pres= erve is "once one pair in a foundation succeeds, every pair with that = foundation is unfrozen".

On Tue, May 2, 2017 at 7:03 PM, Emil Ivov <emcho@jitsi.org> wrote:

Sorry, I thought you were responding to my example since it was quoted= above. Nevermind.

I was responding to your comment on how the new rules do not guarantee= that both components of the stream would have to succeed before a new stre= am for that foundation gets unfrozen.

So I was saying that this is true but I don't think preserving this pr= operty is essential.

I thought you were objecting to that.

Should I understand you are good then?

Emil

On Tue, May 2, 2017 at 6:42 PM, Emil Ivov = <emcho@jitsi.org> wrote:

 I am reluctant to deal with situatio= ns where the candidate matrix is asymmetric

That example doesn't have asymmetric candidate matrices though; it's j= ust 3 media streams with 2 components each, and one foundation.

I wasn't refering to that example.
 
So, unless someone has a great reason for = why we'd need an entire stream to succeed before unfreezing the foundation,= I'd rather we kept things as they are.

Actually, what I was concerned about is that even after an entire stre= am succeeds, new candidate pairs with that foundation may start as frozen.<= /div>

Em. You mean in your example above?

Emil

On Tue, May 2, 2017 at 2:47 PM, Emil Ivov = <emcho@jitsi.org> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8: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 "waitin= g", 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<= br>     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<= br>     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 forme= d.
    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.

So yes, I agree this is a difference with 5245bis, but it's intentional. I = see this in part as a simplification (I don't think it is a meaningful opti= mization even for 5245bis) but more specifically I am reluctant to deal wit= h situations where the candidate matrix is asymmetric for whatever weird reason and one side is trying chec= ks for M2F3 but the other isn't responding because M2F3 is blocked after a = hole in M2F2 and it is not supposed to be unfrozen yet. Or something along = those lines.

So, unless someone has a great reason for why we'd need an entire stream to= succeed before unfreezing the foundation, I'd rather we kept things as the= y are.

Emil


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 like the im= provements 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 "me= dia stream" completes, pairs from other media
    >         streams with matching f= oundations are unfrozen. With the current
    >         rules in section 8.1.1,= only the topmost remaining pair in each
    >         foundation is guarantee= d to be unfrozen. Is this difference
    >         acceptable? If it is, w= e should at least acknowledge it, and not
    >         give the wrong impressi= on by saying "Trickle ICE preserves all
    >         of [the standard ICE] r= ules."

    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 det= ail (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  |  f= 4  |  f5  |
       +-----------------+------+-----= -+------+------+------+
       | m1 (Audio.RTP)  |  cp  |  = cp  |  cp  |      |      |
       +-----------------+------+-----= -+------+------+------+
       | m2 (Audio.RTCP) |  cp  |  cp&nb= sp; |  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 compo= nents for audio).
       Each column represents one foundation.  Eac= h cell represents one
       candidate pair.

       When an agent commences ICE processing, in accor= dance with
       Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
       Waiting state) the topmost candidate pair in eve= ry column (i.e., the
       pair with the lowest component ID).  This s= tate is shown in the
       following table, with candidate pairs in the Wai= ting state marked by
       "w-cp".


       +-----------------+------+-----= -+------+------+------+
       |             = ;    |  f1  |  f2  |  f3  |  f= 4  |  f5  |
       +-----------------+------+-----= -+------+------+------+
       | m1 (Audio.RTP)  | w-cp | w-cp | w-cp |&nb= sp;     |      |
       +-----------------+------+-----= -+------+------+------+
       | m2 (Audio.RTCP) |  cp  |  cp&nb= sp; |  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 Suc= ceeded state (denoted
       here by "s-cp"), the agent will unfree= ze all pairs for the same media
       stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
       then the agent will unfreeze the pair in column = 1, row 2).


       +-----------------+------+-----= -+------+------+------+
       |             = ;    |  f1  |  f2  |  f3  |  f= 4  |  f5  |
       +-----------------+------+-----= -+------+------+------+
       | m1 (Audio.RTP)  | s-cp | w-cp | w-cp |&nb= sp;     |      |
       +-----------------+------+-----= -+------+------+------+
       | m2 (Audio.RTCP) | w-cp |  cp  | = ; cp  | w-cp |      |
       +-----------------+------+-----= -+------+------+------+
       | m3 (Video.RTP)  |  cp  |  =     |      |      | w-cp |
       +-----------------+------+-----= -+------+------+------+
       | m4 (Video.RTCP) |  cp  |   = ;   |      |      |  cp  |
       +-----------------+------+-----= -+------+------+------+


                 Figure 3: Che= ck List State after Succeeded Check

       ICE also specifies that, if all the pairs in a m= edia 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., c= olumn 1, rows 3 and
       4).



       +-----------------+------+-----= -+------+------+------+
       |             = ;    |  f1  |  f2  |  f3  |  f= 4  |  f5  |
       +-----------------+------+-----= -+------+------+------+
       | m1 (Audio.RTP)  | s-cp | w-cp | w-cp |&nb= sp;     |      |
       +-----------------+------+-----= -+------+------+------+
       | m2 (Audio.RTCP) | w-cp |  cp  | = ; cp  | w-cp |      |
       +-----------------+------+-----= -+------+------+------+
       | m3 (Video.RTP)  | w-cp |    &nb= sp; |      |      | 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.&n= bsp; This implies that if, for some
       reason, a Trickle agent were to begin connectivi= ty checks with all of
       its pairs already present, the way that pair sta= tes change is
       indistinguishable from that of a regular ICE age= nt.

       Of course, the major difference with Trickle ICE= is that check list
       sets can be dynamically updated because candidat= es can arrive after
       connectivity checks have started.  When thi= s 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 th= e case if the newly
       formed pair were placed in column 4, row 1).


       +-----------------+------+-----= -+------+------+------+
       |             = ;    |  f1  |  f2  |  f3  |  f= 4  |  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 |    &nb= sp; |      |      | 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, r= ow 3);


       +-----------------+------+-----= -+------+------+------+
       |             = ;    |  f1  |  f2  |  f3  |  f= 4  |  f5  |
       +-----------------+------+-----= -+------+------+------+
       | m1 (Audio.RTP)  | s-cp | w-cp | w-cp |&nb= sp;     |      |
       +-----------------+------+-----= -+------+------+------+
       | m2 (Audio.RTCP) | w-cp |  cp  | = ; cp  | s-cp |      |
       +-----------------+------+-----= -+------+------+------+
       | m3 (Video.RTP)  | w-cp |    &nb= sp; |      | 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 co= lumn below the row of
       the newly formed pair whose state is either Succ= eeded or Failed
       (e.g., this would be the case if the pair in col= umn 4, row 2
       succeeded and the newly formed pair were placed = in column 4, row 1).


       +-----------------+------+-----= -+------+------+------+
       |             = ;    |  f1  |  f2  |  f3  |  f= 4  |  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 |    &nb= sp; |      | 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 Fro= zen.

    ###

    Peter




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


--
https://= jitsi.org

--
sent from my mobile

--
sent from my mobile

 --_000_D52F4DC91C013christerholmbergericssoncom_-- From nobody Wed May 3 09:03:06 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 C20B9129B47 for ; Wed, 3 May 2017 09:03:03 -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 Xkb-Cwndmbn6 for ; Wed, 3 May 2017 09:02:59 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 BE078129B6D for ; Wed, 3 May 2017 09:00:30 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c45so141197519qtb.1 for ; Wed, 03 May 2017 09:00:30 -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=toHE7TKjHL79v7R5OdjaivFlFzVu/VEPJ4WX/3L0Sko=; b=N3diTWs+Dn1F9oSCvBIwPoGzCsDNHiSrSESDcH+mEOAZSFWEDwy9HYzN3+nQK9LR6i 76wfHHNMMg453Wf8zqYzbz33PsXu3MgEoUUou+TIzvOvXXukBPuhrV6hDnieWrDawizY 4H4+ymEkPSF7Tm2+X9txW37RD4FPNInaIi/J6zqm4vgESJBT4a6IT2Wowcv51EDst2FW P/G4Vq6x5qnf3OCMINIFMkckcylvsrwwCLZvKfYebr7DA/8CVdRA+tFt58/tZoO5pSeV j9/tKWcQi2HjRaBomQ8A7blo3lZI/1MLTwmP+PXREReVlNDQUVD31+rx2gYLzS4nLXgf Z3Sg== 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=toHE7TKjHL79v7R5OdjaivFlFzVu/VEPJ4WX/3L0Sko=; b=gtL7MXDl9jsk4Gzz4xFcnYt8veRqzRP28RQcgilO+H3LoSQxLHrPfPmHA+TER+l2od v8z/TM6kM48SAD5cSXZYLGYkviWvdmyThwMfe+UPKZhAcyrwf914VMN/bcUQsqspxEnr gNyatT11Z1HZGSzdg74tdw1XDw6b+bfLnxhfl6CrYLkOSLVos4H3Ta3GIVh5lmZR0Zzz omKGmtvxfoLrExM7QN0TYUt5v+/36PvwxFWghLvV0uUibzQXPIcLOTLGsOWQC6KU7P3W UH0LqZLKzvR3ePyZH69Bt9hZ8ILmfTv30WHnVLu6wYuafWI0DJdn5x4k0LNukHk32f8t 1XMw== X-Gm-Message-State: AN3rC/7xKUBq5ozIlFZGLvn+p9xUpI2xZPc3e66zw0BLqG5k+TtxNuMJ tm8WvnOAB1w2f0OXTg4xyNasn3/6cFUK X-Received: by 10.237.36.103 with SMTP id s36mr34253734qtc.71.1493827229537; Wed, 03 May 2017 09:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Wed, 3 May 2017 09:00:29 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> From: Taylor Brandstetter Date: Wed, 3 May 2017 09:00:29 -0700 Message-ID: To: Christer Holmberg Cc: Emil Ivov , Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a1145ea1c5fbbf8054ea0c15c Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 16:03:04 -0000 --001a1145ea1c5fbbf8054ea0c15c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Is that how you want it? Yes. 5245 had this rule, 5245bis does not, and I'm happy with that. I'm glad that the "both components of a media stream" part is removed from > ICEbis > On Tue, May 2, 2017 at 11:12 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > I am a little confused, because I don=E2=80=99t know if you talk about te= xt > currently in 5245bis, or text that you would like to see in 5245bis :) > > CURRENTLY in 5245bis, once a pair succeeds, all other pairs for the same > foundation are unfrozen. There is no rule saying that, for a given stream= , > all components have to succeed before the other streams are unfrozen. > > Is that how you want it? Do you want to change that? Or, don=E2=80=99t yo= u agree > that is what 5245bis currently says in the first place? > > Regards, > > Christer > > From: Ice on behalf of Taylor Brandstetter < > deadbeef@google.com> > Date: Wednesday 3 May 2017 at 08:03 > To: Emil Ivov > Cc: "stpeter@stpeter.im" , "ice@ietf.org" < > ice@ietf.org> > Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of > draft-ietf-ice-trickle-08.txt) > > When I said "trickle ICE only guarantees that one of them is", I meant > "only guarantees that one pair is unfrozen". I'm glad that the "both > components of a media stream" part is removed from ICEbis, but the proper= ty > I thought does make sense to preserve is "once one pair in a foundation > succeeds, every pair with that foundation is unfrozen". > > On Tue, May 2, 2017 at 7:03 PM, Emil Ivov wrote: > >> >> On Tue, 2 May 2017 at 21:00, Taylor Brandstetter >> wrote: >> >>> Sorry, I thought you were responding to my example since it was quoted >>> above. Nevermind. >>> >> >> I was responding to your comment on how the new rules do not guarantee >> that both components of the stream would have to succeed before a new >> stream for that foundation gets unfrozen. >> >> So I was saying that this is true but I don't think preserving this >> property is essential. >> >> I thought you were objecting to that. >> >> Should I understand you are good then? >> >> Emil >> >>> >>> On Tue, May 2, 2017 at 6:42 PM, Emil Ivov wrote: >>> >>>> >>>> On Tue, 2 May 2017 at 20:39, Taylor Brandstetter >>>> wrote: >>>> >>>>> I am reluctant to deal with situations where the candidate matrix is >>>>>> asymmetric >>>>> >>>>> >>>>> That example doesn't have asymmetric candidate matrices though; it's >>>>> just 3 media streams with 2 components each, and one foundation. >>>>> >>>> >>>> I wasn't refering to that example. >>>> >>>>> >>>>> >>>>>> So, unless someone has a great reason for why we'd need an entire >>>>>> stream to succeed before unfreezing the foundation, I'd rather we ke= pt >>>>>> things as they are. >>>>> >>>>> >>>>> Actually, what I was concerned about is that even after an entire >>>>> stream succeeds, new candidate pairs with that foundation may start a= s >>>>> frozen. >>>>> >>>> >>>> Em. You mean in your example above? >>>> >>>> Emil >>>> >>>>> >>>>> On Tue, May 2, 2017 at 2:47 PM, Emil Ivov wrote: >>>>> >>>>>> Hey, >>>>>> >>>>>> Apologies for coming in a bit late on this. >>>>>> >>>>>> On 4/18/17 8: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". An= d >>>>>>> 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 sa= me >>>>>>> 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 o= ut >>>>>>> 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 wo= rk >>>>>>> (for both components of a media stream), all other pairs with that >>>>>>> foundation are unfrozen, trickle ICE only guarantees that one of >>>>>>> them is. >>>>>>> >>>>>> >>>>>> So yes, I agree this is a difference with 5245bis, but it's >>>>>> intentional. I see this in part as a simplification (I don't think i= t is a >>>>>> meaningful optimization even for 5245bis) but more specifically I am >>>>>> reluctant to deal with situations where the candidate matrix is asym= metric >>>>>> for whatever weird reason and one side is trying checks for M2F3 but= the >>>>>> other isn't responding because M2F3 is blocked after a hole in M2F2 = and it >>>>>> is not supposed to be unfrozen yet. Or something along those lines. >>>>>> >>>>>> So, unless someone has a great reason for why we'd need an entire >>>>>> stream to succeed before unfreezing the foundation, I'd rather we ke= pt >>>>>> things as they are. >>>>>> >>>>>> Emil >>>>>> >>>>>> >>>>>>> On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre < >>>>>>> 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 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 detai= l >>>>>>> (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., plac= e >>>>>>> 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, row= s >>>>>>> 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 Strea= m >>>>>>> >>>>>>> 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 i= s >>>>>>> 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 arriv= e >>>>>>> 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 th= e >>>>>>> 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, Cas= e >>>>>>> 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, Cas= e >>>>>>> 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, Cas= e >>>>>>> 3 >>>>>>> >>>>>>> Case 4: In all other cases, set the state to Frozen. >>>>>>> >>>>>>> ### >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ice mailing list >>>>>>> Ice@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ice >>>>>>> >>>>>>> >>>>>> -- >>>>>> https://jitsi.org >>>>>> >>>>> >>>>> -- >>>> sent from my mobile >>>> >>> >>> -- >> sent from my mobile >> > > --001a1145ea1c5fbbf8054ea0c15c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is that = how you want it?

Yes. 5245 had this rule, 5= 245bis does not, and I'm happy with that.

I= 'm glad that the "both components of a media stream" part is = removed from ICEbis

On Tue, May 2, 2017 at 11:12 PM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=

Hi,

I am a little confused, because I don=E2=80=99t know if you talk about= text currently in 5245bis, or text that you would like to see in 5245bis := )

CURRENTLY in 5245bis, once a pair succeeds, all other pairs for the sa= me foundation are unfrozen. There is no rule saying that, for a given strea= m, all components have to succeed before the other streams are unfrozen.

Is that how you want it? Do you want to change that? Or, don=E2=80=99t= you agree that is what 5245bis currently says in the first place?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of Taylor Brandstetter <deadbeef@google.com>
Date: Wednesday 3 May 2017 at 08:03=
To: Emil Ivov <emcho@jitsi.org>
Cc: "stpeter@stpeter.im" <stpeter@stpeter.im>, &q= uot;ice@ietf.org"= ; <ice@ietf.org>= ;
Subject: Re: [Ice] holes in the mat= rix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt)

When I said "trickle= ICE only guarantees that one of them is", I meant "only guarante= es that one pair is unfrozen".=C2=A0I'm glad that the "both components of a media stream" p= art is removed from ICEbis, but the property I thought does make sense to pres= erve is "once one pair in a foundation succeeds, every pair with that = foundation is unfrozen".

On Tue, May 2, 2017 at 7:03 PM, Emil Ivov <emcho@jitsi.org> wrote:

Sorry, I thought you were responding to my example since it was quoted= above. Nevermind.

I was responding to your comment on how the new rules do not guarantee= that both components of the stream would have to succeed before a new stre= am for that foundation gets unfrozen.

So I was saying that this is true but I don't think preserving thi= s property is essential.

I thought you were objecting to that.

Should I understand you are good then?

Emil

On Tue, May 2, 2017 at 6:42 PM, Emil Ivov = <emcho@jitsi.org> wrote:

=C2=A0I am reluctant to deal with situatio= ns where the candidate matrix is asymmetric

That example doesn't have asymmetric candidate matrices though; it= 's just 3 media streams with 2 components each, and one foundation.

I wasn't refering to that example.
=C2=A0
So, unless someone has a great reason for = why we'd need an entire stream to succeed before unfreezing the foundat= ion, I'd rather we kept things as they are.

Actually, what I was concerned about is that even after an entire stre= am succeeds, new candidate pairs with that foundation may start as frozen.<= /div>

Em. You mean in your example above?

Emil

On Tue, May 2, 2017 at 2:47 PM, Emil Ivov = <emcho@jitsi.org> wrote:
Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 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&= quot;,
where "S" is "succeeded", "W" is "waitin= g", 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=A01. Only the RTP candidate pair for the first media stream is unfrozen=
=C2=A0 =C2=A0 initially.
=C2=A0 =C2=A0 State: WFFFFF
=C2=A02. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
=C2=A0 =C2=A0 State: SWFFFF
=C2=A03. Check succeeds for RTCP pair. /All/ the other pairs with the same<= br> =C2=A0 =C2=A0 foundation are now unfrozen.
=C2=A0 =C2=A0 State: SSWWWW

With trickle ICE, here's what could happen:

=C2=A01. Candidates for the first media stream are trickled in. Starts out<= br> =C2=A0 =C2=A0 just like normal ICE.
=C2=A0 =C2=A0 State: WF
=C2=A02. Checks for both pairs succeed. Still waiting for candidates for =C2=A0 =C2=A0 other media streams.
=C2=A0 =C2=A0 State: SS
=C2=A03. Candidates for the other media streams arrive, and pairs are forme= d.
=C2=A0 =C2=A0 The topmost pair is set to waiting, but not the others.
=C2=A0 =C2=A0 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.

So yes, I agree this is a difference with 5245bis, but it's intentional= . I see this in part as a simplification (I don't think it is a meaning= ful optimization even for 5245bis) but more specifically I am reluctant to = deal with situations where the candidate matrix is asymmetric for whatever weird reason and one side is trying chec= ks for M2F3 but the other isn't responding because M2F3 is blocked afte= r a hole in M2F2 and it is not supposed to be unfrozen yet. Or something al= ong those lines.

So, unless someone has a great reason for why we'd need an entire strea= m to succeed before unfreezing the foundation, I'd rather we kept thing= s as they are.

Emil


On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 3/30/17 11:28 PM, Taylor Brandstetter wrote:

=C2=A0 =C2=A0 [areas of seeming agreement elided]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0* In section 8.1.1: In general I like the im= provements that have
=C2=A0 =C2=A0 been
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0made. However:
=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 "Frozen"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state don't complet= ely match standard ICE; at least the part
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where when one "me= dia stream" completes, pairs from other media
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams with matching f= oundations are unfrozen. With the current
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules in section 8.1.1,= only the topmost remaining pair in each
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foundation is guarantee= d to be unfrozen. Is this difference
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable? If it is, w= e should at least acknowledge it, and not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0give the wrong impressi= on by saying "Trickle ICE preserves all
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of [the standard ICE] r= ules."

=C2=A0 =C2=A0 Taylor, would you mind spelling this out a bit more fully and= point to
=C2=A0 =C2=A0 discrepancies between the text of 5245bis and the text of the= Trickle
=C2=A0 =C2=A0 spec? I'm sure I'm missing something, but I don't= yet see the truth of
=C2=A0 =C2=A0 your statement that "only the topmost remaining pair in = each foundation
=C2=A0 =C2=A0 is guaranteed to be unfrozen".

=C2=A0 =C2=A0 In particular, your statement doesn't seem to match the r= ules defined in
=C2=A0 =C2=A0 the Trickle spec. I've tried to spell them out in greater= detail (with
=C2=A0 =C2=A0 examples) in the following proposed text.

=C2=A0 =C2=A0 ###


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Consider the following tabular representation of= all checklists in an
=C2=A0 =C2=A0 =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 =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=A0Figure 1: Example of Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Each row in the table represents a component for= a given media stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., m1 and m2 might be the RTP and RTCP compo= nents for audio).
=C2=A0 =C2=A0 =C2=A0 =C2=A0Each column represents one foundation.=C2=A0 Eac= h cell represents one
=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When an agent commences ICE processing, in accor= dance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.3.6 of [rfc5245bis] it will unfreeze= (i.e., place in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting state) the topmost candidate pair in eve= ry column (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pair with the lowest component ID).=C2=A0 This s= tate is shown in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following table, with candidate pairs in the Wai= ting 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 Figure 2: Initial Check List State

=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, 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 the Suc= ceeded state (denoted
=C2=A0 =C2=A0 =C2=A0 =C2=A0here by "s-cp"), the agent will unfree= ze all pairs for the same media
=C2=A0 =C2=A0 =C2=A0 =C2=A0stream and foundation (e.g., if the pair in colu= mn 1, row 1 succeeds
=C2=A0 =C2=A0 =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 =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=A0Figure 3: Che= ck List State after Succeeded Check

=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies that, if all the pairs in a m= edia stream for one
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation are unfrozen (e.g., column 1, rows 1 = and 2 representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0both components for the audio stream), then all = of the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0pairs in the entire column are unfrozen (e.g., c= olumn 1, rows 3 and
=C2=A0 =C2=A0 =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 =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=A0Figure 4: Check List= State with Unfrozen Media Stream

=C2=A0 =C2=A0 =C2=A0 =C2=A0Trickle ICE preserves all of these rules as they= apply to what we
=C2=A0 =C2=A0 =C2=A0 =C2=A0might call "static" check list sets.= =C2=A0 This implies that if, for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0reason, a Trickle agent were to begin connectivi= ty checks with all of
=C2=A0 =C2=A0 =C2=A0 =C2=A0its pairs already present, the way that pair sta= tes change is
=C2=A0 =C2=A0 =C2=A0 =C2=A0indistinguishable from that of a regular ICE age= nt.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 1: If the newly formed pair is the topmost = pair in this column,
=C2=A0 =C2=A0 =C2=A0 =C2=A0set the state to Waiting (e.g., this would be th= e case if the newly
=C2=A0 =C2=A0 =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 =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=A0Figure 5: Check List State = with Newly Formed Pair, Case 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 2: If the pair immediately above the newly = formed pair in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0column is in the Succeeded state, set the state = to Waiting (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0this would be the case if the pair in column 4, = row 2 succeeded and
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair were placed in column 4, r= ow 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=A0Figure 6: Check List State = with Newly Formed Pair, Case 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0Case 3: If there is at least one pair in this co= lumn below the row of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the newly formed pair whose state is either Succ= eeded or Failed
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., this would be the case if the pair in col= umn 4, row 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded and the newly 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 | 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=A0Figure 7: Check List State = with Newly Formed Pair, Case 3

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

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 Peter




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


--
https://= jitsi.org

--
sent from my mobile

--
sent from my mobile

--001a1145ea1c5fbbf8054ea0c15c-- From nobody Wed May 3 09:32:11 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 C3BDF129B31 for ; Wed, 3 May 2017 09:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYqvmX66o_pA for ; Wed, 3 May 2017 09:32:07 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4C3127342 for ; Wed, 3 May 2017 09:30:05 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id r16so189712999ioi.2 for ; Wed, 03 May 2017 09:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=o5wbVZg1aWhG/NXW6Z90Ii9LbLO0YZ2fv0vqk4shnlQ=; b=Cj0lM9J7ABUJJlTG/Alx6sWKMeabAuvv61O/CC3r0DNv5plMDM55TRYwL63ApJ399V ypHRmjwxYsp0M82pUGpTw5MXJlE5da551C3IC1PlFttVxEs4hS5bvk4pZnhuEWfh+kcE DcxhanX6hF5OW1TNITX7yvvIZ29kcF021hnf553kWPmTl2MzQhPYt67IKazVAbJeqy2n g7t+0zNFLLh73nEg4I6tyYJqpHouldwfk4btvZCA5NvV7y47beyHtQgVViXmvUidOHah M4ex7BNctAu+gdqNm+/c6SisIb0UqGx5RVhWgs9ZBnqsMF3exD0IdE23B7zALHOqqQYo 7s8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=o5wbVZg1aWhG/NXW6Z90Ii9LbLO0YZ2fv0vqk4shnlQ=; b=En37bj7CzJBaMcJXFe9tQvPtwlaAoBAsxUWuoOoj7V8ivv74wZ+Y0hZYtdNNpncSod VWs3IbOB/ynwBpf8ky8sgglVFmWTRJeEC4tB701hiLiQ/BVCtTgQNaP6HQXsYU82YfF3 rT7YqihLHhgx7B3SqTpVdGEKOLh0DISr1OeNqIP9MMQ+rdgGplu4Vh8FIsQ/7+Pt7l0f rvuA3N497I0P4faH2tNcM2I8RkERqm9gV+J2ura6pPmSVAvetR8FMAtRp76EOTZCjLCG 7csOKz45j/pHXfwMmewmEEOh3tSMTlC96O4zSEv0v5Hvmyq2FXeeJob1SCYf1WqywA1/ XFjA== X-Gm-Message-State: AN3rC/5wOaCVkGa5dwaEu1xF4M2B6ND4nBYwWhcgtmJGA9hg8a7B0B++ HLnILN0XhT8ovCpMnv8= X-Received: by 10.157.44.70 with SMTP id f64mr13297182otb.257.1493829003912; Wed, 03 May 2017 09:30:03 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id m2sm4082602oif.21.2017.05.03.09.30.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 09:30:02 -0700 (PDT) To: Taylor Brandstetter References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> Cc: Peter Saint-Andre , ice@ietf.org From: Emil Ivov Message-ID: Date: Wed, 3 May 2017 11:30:01 -0500 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; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 16:32:11 -0000 On 5/3/17 12:03 AM, Taylor Brandstetter wrote: > When I said "trickle ICE only guarantees that one of them is", I meant > "only guarantees that one pair is unfrozen". I'm glad that the "both > components of a media stream" part is removed from ICEbis, I'll skip the 5245bis part of the discussion until we are done with the trickle one. > but the > property I thought does make sense to preserve is "once one pair in a > foundation succeeds, every pair with that foundation is unfrozen". I am not sure I follow. Why is this not preserved? State changes themselves happen as they do in 5245bis. Trickle only defines what happens with newly added candidates and for the case you mention we have this: 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). Which translates to exactly what you have in the quotes above. What's bothering you about it? Emil > > On Tue, May 2, 2017 at 7:03 PM, Emil Ivov > wrote: > > > On Tue, 2 May 2017 at 21:00, Taylor Brandstetter > > wrote: > > Sorry, I thought you were responding to my example since it was > quoted above. Nevermind. > > > I was responding to your comment on how the new rules do not > guarantee that both components of the stream would have to succeed > before a new stream for that foundation gets unfrozen. > > So I was saying that this is true but I don't think preserving this > property is essential. > > I thought you were objecting to that. > > Should I understand you are good then? > > Emil > > > On Tue, May 2, 2017 at 6:42 PM, Emil Ivov > wrote: > > > On Tue, 2 May 2017 at 20:39, Taylor Brandstetter > > wrote: > > I am reluctant to deal with situations where the > candidate matrix is asymmetric > > > That example doesn't have asymmetric candidate matrices > though; it's just 3 media streams with 2 components > each, and one foundation. > > > I wasn't refering to that example. > > > > So, unless someone has a great reason for why we'd > need an entire stream to succeed before unfreezing > the foundation, I'd rather we kept things as they are. > > > Actually, what I was concerned about is that even after > an entire stream succeeds, new candidate pairs with that > foundation may start as frozen. > > > Em. You mean in your example above? > > Emil > > > On Tue, May 2, 2017 at 2:47 PM, Emil Ivov > > wrote: > > Hey, > > Apologies for coming in a bit late on this. > > On 4/18/17 8: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 > 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. > > > So yes, I agree this is a difference with 5245bis, > but it's intentional. I see this in part as a > simplification (I don't think it is a meaningful > optimization even for 5245bis) but more specifically > I am reluctant to deal with situations where the > candidate matrix is asymmetric for whatever weird > reason and one side is trying checks for M2F3 but > the other isn't responding because M2F3 is blocked > after a hole in M2F2 and it is not supposed to be > unfrozen yet. Or something along those lines. > > So, unless someone has a great reason for why we'd > need an entire stream to succeed before unfreezing > the foundation, I'd rather we kept things as they are. > > Emil > > > 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 > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > > -- > https://jitsi.org > > > -- > sent from my mobile > > > -- > sent from my mobile > > -- https://jitsi.org From nobody Wed May 3 09:48:04 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 1F4A9129512 for ; Wed, 3 May 2017 09:48:04 -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 x2PfjwYYC9Cl for ; Wed, 3 May 2017 09:47:58 -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 73085128A32 for ; Wed, 3 May 2017 09:45:38 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m91so9485522qte.3 for ; Wed, 03 May 2017 09:45:38 -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=+DYgJVJ3Z6R3q5XZgfERwgAYrJQ2tb8fRKbwWIfsaaA=; b=CAA9Et2DhVbJRsHOnJ3q4Fs6bhnfpon0YxY0wVS6EvPwRmSGDjoQRxl0VClmtPiTwA EOM5Nzio6keBZrGUhuqM9sp/7M3fjx7EuSa4fzeUHjYe65mEUeCjhiNBXznziDXXaa0I qzV28C1+RO8QkyrydN4MVVGVjxYFzJK1HyVT09ovbsWD0vk6zm8tyhsFZ4HzqWVMo0wb H1Qj+pat2VT2iP1SMgLmDNn55pFK6QFlbOFDJkaZ+YBWayeZ0qHmgrjCAIh09Fq01iwj QZgdstZeDE8d19GrfJe0OYz2VAE/5EuNmxkMDopaxAYK8wF/AV2FAlgUoSK+PzkYMpMA FO/g== 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=+DYgJVJ3Z6R3q5XZgfERwgAYrJQ2tb8fRKbwWIfsaaA=; b=nwkqIdRXL6bopks9W/bDblpdBBl1i+Fd+Jq6Q7t6sMwqcHNFU0p1Ev4i/n6UofQiCU uuvCUSkz6n5J0SzXgt8hUv53hPKMO3sW6NG74qblW5LJpoh2nB3jOwmlyu1aqkksSnTe CmgRE501NPw+6yuNAPB0Mg47zeQuKUtCYsC+Pc3CLKF0ICni9q5agowo9oV6K6cvi+IF d96lpAb2tlRz6henbwM0Yjr2TWxf6gjnt6YpRVppMbO0ZlSTrPpjFq7qqrN8dwiG4Q7w KjSFzvU8m9GymH4sOmYhXLUuSlnVPrrpEgjSZ0GNelp9V2lNpnTHKPXBIA0G26mh6aJ8 QiFg== X-Gm-Message-State: AN3rC/7OvqsfYb43Pf54LN1+6LV9j3IB8+qklwR1JWfJfcGK+ZRvsgU1 bGCcE6PQFvP77yXSmlf8NgeIFXZmaKNFz17QJA== X-Received: by 10.200.1.26 with SMTP id e26mr8056014qtg.75.1493829937274; Wed, 03 May 2017 09:45:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Wed, 3 May 2017 09:45:36 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> From: Taylor Brandstetter Date: Wed, 3 May 2017 09:45:36 -0700 Message-ID: To: Emil Ivov Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=f403045f41eec47a92054ea16243 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 03 May 2017 16:48:04 -0000 --f403045f41eec47a92054ea16243 Content-Type: text/plain; charset=UTF-8 > > I am not sure I follow. Why is this not preserved? State changes > themselves happen as they do in 5245bis. Trickle only defines what happens > with newly added candidates and for the case you mention we have this: > > 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). > > Which translates to exactly what you have in the quotes above. > > What's bothering you about it? > I think we're on the same page, just mis-communicating. My email quoted at the start of this thread was talking about version 08; the problem is fixed in version 09. The only thing that concerns me about version 09 is the "or Failed" part (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA). On Wed, May 3, 2017 at 9:30 AM, Emil Ivov wrote: > > > On 5/3/17 12:03 AM, Taylor Brandstetter wrote: > >> When I said "trickle ICE only guarantees that one of them is", I meant >> "only guarantees that one pair is unfrozen". I'm glad that the "both >> components of a media stream" part is removed from ICEbis, >> > > I'll skip the 5245bis part of the discussion until we are done with the > trickle one. > > but the >> property I thought does make sense to preserve is "once one pair in a >> foundation succeeds, every pair with that foundation is unfrozen". >> > > I am not sure I follow. Why is this not preserved? State changes > themselves happen as they do in 5245bis. Trickle only defines what happens > with newly added candidates and for the case you mention we have this: > > 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). > > Which translates to exactly what you have in the quotes above. > > What's bothering you about it? > > Emil > > > > > >> On Tue, May 2, 2017 at 7:03 PM, Emil Ivov > > wrote: >> >> >> On Tue, 2 May 2017 at 21:00, Taylor Brandstetter >> > wrote: >> >> Sorry, I thought you were responding to my example since it was >> quoted above. Nevermind. >> >> >> I was responding to your comment on how the new rules do not >> guarantee that both components of the stream would have to succeed >> before a new stream for that foundation gets unfrozen. >> >> So I was saying that this is true but I don't think preserving this >> property is essential. >> >> I thought you were objecting to that. >> >> Should I understand you are good then? >> >> Emil >> >> >> On Tue, May 2, 2017 at 6:42 PM, Emil Ivov > > wrote: >> >> >> On Tue, 2 May 2017 at 20:39, Taylor Brandstetter >> > wrote: >> >> I am reluctant to deal with situations where the >> candidate matrix is asymmetric >> >> >> That example doesn't have asymmetric candidate matrices >> though; it's just 3 media streams with 2 components >> each, and one foundation. >> >> >> I wasn't refering to that example. >> >> >> >> So, unless someone has a great reason for why we'd >> need an entire stream to succeed before unfreezing >> the foundation, I'd rather we kept things as they are. >> >> >> Actually, what I was concerned about is that even after >> an entire stream succeeds, new candidate pairs with that >> foundation may start as frozen. >> >> >> Em. You mean in your example above? >> >> Emil >> >> >> On Tue, May 2, 2017 at 2:47 PM, Emil Ivov >> > wrote: >> >> Hey, >> >> Apologies for coming in a bit late on this. >> >> On 4/18/17 8: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 >> 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. >> >> >> So yes, I agree this is a difference with 5245bis, >> but it's intentional. I see this in part as a >> simplification (I don't think it is a meaningful >> optimization even for 5245bis) but more specifically >> I am reluctant to deal with situations where the >> candidate matrix is asymmetric for whatever weird >> reason and one side is trying checks for M2F3 but >> the other isn't responding because M2F3 is blocked >> after a hole in M2F2 and it is not supposed to be >> unfrozen yet. Or something along those lines. >> >> So, unless someone has a great reason for why we'd >> need an entire stream to succeed before unfreezing >> the foundation, I'd rather we kept things as they are. >> >> Emil >> >> >> 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 >> >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> >> >> -- >> https://jitsi.org >> >> >> -- >> sent from my mobile >> >> >> -- >> sent from my mobile >> >> >> > -- > https://jitsi.org > --f403045f41eec47a92054ea16243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpO3BhZGRpbmctbGVmdDoxZXgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5JIGFt IG5vdCBzdXJlIEkgZm9sbG93LiBXaHkgaXMgdGhpcyBub3QgcHJlc2VydmVkPyBTdGF0ZSBjaGFu Z2VzIHRoZW1zZWx2ZXMgaGFwcGVuIGFzIHRoZXkgZG8gaW4gNTI0NWJpcy4gVHJpY2tsZSBvbmx5 IGRlZmluZXMgd2hhdCBoYXBwZW5zIHdpdGggbmV3bHkgYWRkZWQgY2FuZGlkYXRlcyBhbmQgZm9y IHRoZSBjYXNlIHlvdSBtZW50aW9uIHdlIGhhdmUgdGhpczo8L3NwYW4+PGJyIHN0eWxlPSJmb250 LXNpemU6MTIuOHB4Ij48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuOHB4Ij7CoCDCoENhc2UgMzogSWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25lIHBh aXIgaW4gdGhpcyBjb2x1bW4gYWJvdmUgdGhlIHJvdyBvZjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQt c2l6ZToxMi44cHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij7CoCDCoHRoZSBuZXds eSBmb3JtZWQgcGFpciB3aG9zZSBzdGF0ZSBpcyBlaXRoZXIgU3VjY2VlZGVkIG9yIEZhaWxlZCwg c2V0PC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbC1pbSIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgi Pjxicj7CoCDCoHRoZSBzdGF0ZSB0byBXYWl0aW5nIChlLmcuLCB0aGlzIHdvdWxkIGJlIHRoZSBj YXNlIGlmIHRoZSBwYWlyIGluPGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhw eCI+wqAgwqBjb2x1bW4gNSwgcm93IDEgc3VjY2VlZGVkIGFuZCB0d28gbmV3bHkgZm9ybWVkIHBh aXJzIHdlcmUgcGxhY2VkIGluPC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPsKgIMKgY29sdW1uIDUsIHJvd3MgMyBhbmQgNCku PC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PGJyIHN0eWxlPSJmb250LXNpemU6 MTIuOHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+V2hpY2ggdHJhbnNsYXRlcyB0 byBleGFjdGx5IHdoYXQgeW91IGhhdmUgaW4gdGhlIHF1b3RlcyBhYm92ZS48L3NwYW4+PGJyIHN0 eWxlPSJmb250LXNpemU6MTIuOHB4Ij48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5XaGF0JiMzOTtzIGJvdGhlcmluZyB5b3UgYWJvdXQg aXQ/PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHRoaW5rIHdl JiMzOTtyZSBvbiB0aGUgc2FtZSBwYWdlLCBqdXN0IG1pcy1jb21tdW5pY2F0aW5nLiBNeSBlbWFp bCBxdW90ZWQgYXQgdGhlIHN0YXJ0IG9mIHRoaXMgdGhyZWFkIHdhcyB0YWxraW5nIGFib3V0IHZl cnNpb24gMDg7IHRoZSBwcm9ibGVtIGlzIGZpeGVkIGluIHZlcnNpb24gMDkuIFRoZSBvbmx5IHRo aW5nIHRoYXQgY29uY2VybnMgbWUgYWJvdXQgdmVyc2lvbiAwOSBpcyB0aGUgJnF1b3Q7b3IgRmFp bGVkJnF1b3Q7IHBhcnQgKHNlZTrCoDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvaWNlLzZvRGY2eU5hbkNnamoxeUhYRTNpZGxtb2J5QSI+aHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pY2UvNm9EZjZ5TmFuQ2dqajF5SFhFM2lkbG1vYnlB PC9hPikuPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBNYXkgMywgMjAxNyBhdCA5OjMw IEFNLCBFbWlsIEl2b3YgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZW1jaG9A aml0c2kub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZW1jaG9Aaml0c2kub3JnPC9hPiZndDs8L3NwYW4+ IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48 c3BhbiBjbGFzcz0iIj48YnI+DQo8YnI+DQpPbiA1LzMvMTcgMTI6MDMgQU0sIFRheWxvciBCcmFu ZHN0ZXR0ZXIgd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQpXaGVuIEkgc2FpZCAmcXVvdDt0cmlja2xlIElDRSBvbmx5IGd1YXJhbnRlZXMg dGhhdCBvbmUgb2YgdGhlbSBpcyZxdW90OywgSSBtZWFudDxicj4NCiZxdW90O29ubHkgZ3VhcmFu dGVlcyB0aGF0IG9uZSBwYWlyIGlzIHVuZnJvemVuJnF1b3Q7LiBJJiMzOTttIGdsYWQgdGhhdCB0 aGUgJnF1b3Q7Ym90aDxicj4NCmNvbXBvbmVudHMgb2YgYSBtZWRpYSBzdHJlYW0mcXVvdDsgcGFy dCBpcyByZW1vdmVkIGZyb20gSUNFYmlzLDxicj4NCjwvYmxvY2txdW90ZT4NCjxicj48L3NwYW4+ DQpJJiMzOTtsbCBza2lwIHRoZSA1MjQ1YmlzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gdW50aWwg d2UgYXJlIGRvbmUgd2l0aCB0aGUgdHJpY2tsZSBvbmUuPHNwYW4gY2xhc3M9IiI+PGJyPg0KPGJy Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpidXQgdGhl PGJyPg0KcHJvcGVydHkgSSB0aG91Z2h0IGRvZXMgbWFrZSBzZW5zZSB0byBwcmVzZXJ2ZSBpcyAm cXVvdDtvbmNlIG9uZSBwYWlyIGluIGE8YnI+DQpmb3VuZGF0aW9uIHN1Y2NlZWRzLCBldmVyeSBw YWlyIHdpdGggdGhhdCBmb3VuZGF0aW9uIGlzIHVuZnJvemVuJnF1b3Q7Ljxicj4NCjwvYmxvY2tx dW90ZT4NCjxicj48L3NwYW4+DQpJIGFtIG5vdCBzdXJlIEkgZm9sbG93LiBXaHkgaXMgdGhpcyBu b3QgcHJlc2VydmVkPyBTdGF0ZSBjaGFuZ2VzIHRoZW1zZWx2ZXMgaGFwcGVuIGFzIHRoZXkgZG8g aW4gNTI0NWJpcy4gVHJpY2tsZSBvbmx5IGRlZmluZXMgd2hhdCBoYXBwZW5zIHdpdGggbmV3bHkg YWRkZWQgY2FuZGlkYXRlcyBhbmQgZm9yIHRoZSBjYXNlIHlvdSBtZW50aW9uIHdlIGhhdmUgdGhp czo8YnI+DQo8YnI+DQrCoCDCoENhc2UgMzogSWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25lIHBhaXIg aW4gdGhpcyBjb2x1bW4gYWJvdmUgdGhlIHJvdyBvZjxicj4NCsKgIMKgdGhlIG5ld2x5IGZvcm1l ZCBwYWlyIHdob3NlIHN0YXRlIGlzIGVpdGhlciBTdWNjZWVkZWQgb3IgRmFpbGVkLCBzZXQ8c3Bh biBjbGFzcz0iIj48YnI+DQrCoCDCoHRoZSBzdGF0ZSB0byBXYWl0aW5nIChlLmcuLCB0aGlzIHdv dWxkIGJlIHRoZSBjYXNlIGlmIHRoZSBwYWlyIGluPGJyPjwvc3Bhbj4NCsKgIMKgY29sdW1uIDUs IHJvdyAxIHN1Y2NlZWRlZCBhbmQgdHdvIG5ld2x5IGZvcm1lZCBwYWlycyB3ZXJlIHBsYWNlZCBp bjxicj4NCsKgIMKgY29sdW1uIDUsIHJvd3MgMyBhbmQgNCkuPGJyPg0KPGJyPg0KV2hpY2ggdHJh bnNsYXRlcyB0byBleGFjdGx5IHdoYXQgeW91IGhhdmUgaW4gdGhlIHF1b3RlcyBhYm92ZS48YnI+ DQo8YnI+DQpXaGF0JiMzOTtzIGJvdGhlcmluZyB5b3UgYWJvdXQgaXQ/PGJyPg0KPGJyPg0KRW1p bDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPjxzcGFuIGNsYXNzPSIiPg0KT24gVHVlLCBNYXkgMiwg MjAxNyBhdCA3OjAzIFBNLCBFbWlsIEl2b3YgJmx0OzxhIGhyZWY9Im1haWx0bzplbWNob0BqaXRz aS5vcmciIHRhcmdldD0iX2JsYW5rIj5lbWNob0BqaXRzaS5vcmc8L2E+PGJyPjwvc3Bhbj48c3Bh biBjbGFzcz0iIj4NCiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGppdHNpLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmVtY2hvQGppdHNpLm9yZzwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8 YnI+DQo8YnI+DQrCoCDCoCBPbiBUdWUsIDIgTWF5IDIwMTcgYXQgMjE6MDAsIFRheWxvciBCcmFu ZHN0ZXR0ZXI8YnI+PC9zcGFuPjxzcGFuIGNsYXNzPSIiPg0KwqAgwqAgJmx0OzxhIGhyZWY9Im1h aWx0bzpkZWFkYmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGVhZGJlZWZAZ29vZ2xl LmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRlYWRiZWVmQGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgU29ycnksIEkgdGhvdWdodCB5b3Ugd2VyZSByZXNwb25kaW5n IHRvIG15IGV4YW1wbGUgc2luY2UgaXQgd2FzPGJyPg0KwqAgwqAgwqAgwqAgcXVvdGVkIGFib3Zl LiBOZXZlcm1pbmQuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgSSB3YXMgcmVzcG9uZGluZyB0byB5 b3VyIGNvbW1lbnQgb24gaG93IHRoZSBuZXcgcnVsZXMgZG8gbm90PGJyPg0KwqAgwqAgZ3VhcmFu dGVlIHRoYXQgYm90aCBjb21wb25lbnRzIG9mIHRoZSBzdHJlYW0gd291bGQgaGF2ZSB0byBzdWNj ZWVkPGJyPg0KwqAgwqAgYmVmb3JlIGEgbmV3IHN0cmVhbSBmb3IgdGhhdCBmb3VuZGF0aW9uIGdl dHMgdW5mcm96ZW4uPGJyPg0KPGJyPg0KwqAgwqAgU28gSSB3YXMgc2F5aW5nIHRoYXQgdGhpcyBp cyB0cnVlIGJ1dCBJIGRvbiYjMzk7dCB0aGluayBwcmVzZXJ2aW5nIHRoaXM8YnI+DQrCoCDCoCBw cm9wZXJ0eSBpcyBlc3NlbnRpYWwuPGJyPg0KPGJyPg0KwqAgwqAgSSB0aG91Z2h0IHlvdSB3ZXJl IG9iamVjdGluZyB0byB0aGF0Ljxicj4NCjxicj4NCsKgIMKgIFNob3VsZCBJIHVuZGVyc3RhbmQg eW91IGFyZSBnb29kIHRoZW4/PGJyPg0KPGJyPg0KwqAgwqAgRW1pbDxicj4NCjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIE9uIFR1ZSwgTWF5IDIsIDIwMTcgYXQgNjo0MiBQTSwgRW1pbCBJdm92ICZs dDs8YSBocmVmPSJtYWlsdG86ZW1jaG9Aaml0c2kub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZW1jaG9A aml0c2kub3JnPC9hPjxicj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+DQrCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzplbWNob0BqaXRzaS5vcmciIHRhcmdldD0iX2JsYW5rIj5l bWNob0BqaXRzaS5vcmc8L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgT24gVHVlLCAyIE1heSAyMDE3IGF0IDIwOjM5LCBUYXlsb3IgQnJhbmRzdGV0 dGVyPGJyPjwvc3Bhbj48c3BhbiBjbGFzcz0iIj4NCsKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBo cmVmPSJtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRlYWRiZWVm QGdvb2dsZS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRlYWRiZWVmQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kZWFkYmVlZkBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdy b3RlOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSSBhbSByZWx1 Y3RhbnQgdG8gZGVhbCB3aXRoIHNpdHVhdGlvbnMgd2hlcmUgdGhlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgY2FuZGlkYXRlIG1hdHJpeCBpcyBhc3ltbWV0cmljPGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhhdCBleGFtcGxlIGRvZXNuJiMzOTt0 IGhhdmUgYXN5bW1ldHJpYyBjYW5kaWRhdGUgbWF0cmljZXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0aG91Z2g7IGl0JiMzOTtzIGp1c3QgMyBtZWRpYSBzdHJlYW1zIHdpdGggMiBjb21w b25lbnRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZWFjaCwgYW5kIG9uZSBmb3VuZGF0 aW9uLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIEkgd2FzbiYjMzk7dCByZWZl cmluZyB0byB0aGF0IGV4YW1wbGUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgU28sIHVubGVzcyBzb21lb25lIGhhcyBhIGdyZWF0IHJlYXNvbiBm b3Igd2h5IHdlJiMzOTtkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbmVlZCBh biBlbnRpcmUgc3RyZWFtIHRvIHN1Y2NlZWQgYmVmb3JlIHVuZnJlZXppbmc8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgZm91bmRhdGlvbiwgSSYjMzk7ZCByYXRoZXIgd2Ug a2VwdCB0aGluZ3MgYXMgdGhleSBhcmUuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgQWN0dWFsbHksIHdoYXQgSSB3YXMgY29uY2VybmVkIGFib3V0IGlzIHRoYXQgZXZl biBhZnRlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuIGVudGlyZSBzdHJlYW0gc3Vj Y2VlZHMsIG5ldyBjYW5kaWRhdGUgcGFpcnMgd2l0aCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgZm91bmRhdGlvbiBtYXkgc3RhcnQgYXMgZnJvemVuLjxicj4NCjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIEVtLiBZb3UgbWVhbiBpbiB5b3VyIGV4YW1wbGUgYWJvdmU/PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgRW1pbDxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIE9uIFR1ZSwgTWF5IDIsIDIwMTcgYXQgMjo0NyBQTSwgRW1pbCBJdm92 PGJyPjwvc3Bhbj48ZGl2PjxkaXYgY2xhc3M9Img1Ij4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICZsdDs8YSBocmVmPSJtYWlsdG86ZW1jaG9Aaml0c2kub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZW1j aG9Aaml0c2kub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzplbWNob0BqaXRzaS5v cmciIHRhcmdldD0iX2JsYW5rIj5lbWNob0BqaXRzaS5vcmc8L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSGV5LDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFwb2xvZ2llcyBmb3IgY29taW5nIGluIGEgYml0 IGxhdGUgb24gdGhpcy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBP biA0LzE4LzE3IDg6NDQgUE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgd3JvdGU6PGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGF5bG9yLCB3b3VsZCB5 b3UgbWluZCBzcGVsbGluZyB0aGlzIG91dCBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgYml0IG1vcmUgZnVsbHkgYW5kIHBvaW50IHRvPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGlzY3JlcGFuY2llcyBiZXR3ZWVuIHRoZSB0 ZXh0IG9mIDUyNDViaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBh bmQgdGhlIHRleHQgb2YgdGhlIFRyaWNrbGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBzcGVjPyBJJiMzOTttIHN1cmUgSSYjMzk7bSBtaXNzaW5nIHNvbWV0 aGluZywgYnV0IEk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb24m IzM5O3QgeWV0IHNlZSB0aGUgdHJ1dGggb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB5b3VyIHN0YXRlbWVudCB0aGF0ICZxdW90O29ubHkgdGhlIHRvcG1v c3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZW1haW5pbmcgcGFp ciBpbiBlYWNoIGZvdW5kYXRpb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpcyBndWFyYW50ZWVkIHRvIGJlIHVuZnJvemVuJnF1b3Q7Ljxicj4NCjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFN1cmU7IGxldCBtZSB0 cnkgdG8gZ2l2ZSBhbiBleGFtcGxlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFN1cHBvc2UgSSBoYXZlIHRocmVlIG1lZGlhIHN0cmVhbXMsIGFuZCBvbmU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmb3VuZGF0aW9uIChsZXQm IzM5O3Mga2VlcCBpdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNp bXBsZSkuIEkmIzM5O2xsIHJlcHJlc2VudCB0aGUgc3RhdGVzIGxpa2UgdGhpcyBmb3I8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBicmV2aXR5OiAmcXVvdDtTV0ZGRkYm cXVvdDssPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2hlcmUgJnF1 b3Q7UyZxdW90OyBpcyAmcXVvdDtzdWNjZWVkZWQmcXVvdDssICZxdW90O1cmcXVvdDsgaXMgJnF1 b3Q7d2FpdGluZyZxdW90OywgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJnF1b3Q7RiZxdW90OyBpcyAmcXVvdDtmcm96ZW4mcXVvdDsuIEFuZDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZXkmIzM5O3JlIG9yZGVyZWQgaW4gdGhl IHNhbWUgd2F5IGFzIHRoZSByb3dzIGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgeW91ciB0YWJsZSBhYm92ZS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBXaXRoIG5vbi10cmlja2xlIElDRSwgaGVyZSYjMzk7cyB3aGF0IHdv dWxkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHlwaWNhbGx5IGhh cHBlbjo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDEu IE9ubHkgdGhlIFJUUCBjYW5kaWRhdGUgcGFpciBmb3IgdGhlIGZpcnN0PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbWVkaWEgc3RyZWFtIGlzIHVuZnJvemVuPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5pdGlhbGx5Ljxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFN0YXRlOiBXRkZGRkY8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDIuIENoZWNrIHN1Y2Nl ZWRzIGZvciBSVFAgY2FuZGlkYXRlIHBhaXIuIFJUQ1A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBwYWlyIHVuZnJvemVuLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFN0YXRlOiBTV0ZGRkY8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoDMuIENoZWNrIHN1Y2NlZWRzIGZvciBSVENQIHBhaXIuIC9B bGwvIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG90aGVyIHBh aXJzIHdpdGggdGhlIHNhbWU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBmb3VuZGF0aW9uIGFyZSBub3cgdW5mcm96ZW4uPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3RhdGU6IFNTV1dXVzxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdpdGggdHJpY2tsZSBJQ0UsIGhlcmUmIzM5 O3Mgd2hhdCBjb3VsZCBoYXBwZW46PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAxLiBDYW5kaWRhdGVzIGZvciB0aGUgZmlyc3QgbWVkaWEgc3RyZWFtIGFy ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRyaWNrbGVkIGluLiBT dGFydHMgb3V0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg anVzdCBsaWtlIG5vcm1hbCBJQ0UuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgU3RhdGU6IFdGPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAyLiBDaGVja3MgZm9yIGJvdGggcGFpcnMgc3VjY2VlZC4gU3RpbGwgd2FpdGluZzxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZvciBjYW5kaWRhdGVzIGZv cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG90aGVyIG1l ZGlhIHN0cmVhbXMuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgU3RhdGU6IFNTPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAz LiBDYW5kaWRhdGVzIGZvciB0aGUgb3RoZXIgbWVkaWEgc3RyZWFtczxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFycml2ZSwgYW5kIHBhaXJzIGFyZSBmb3JtZWQuPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlIHRvcG1vc3Qg cGFpciBpcyBzZXQgdG8gd2FpdGluZywgYnV0IG5vdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHRoZSBvdGhlcnMuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgU3RhdGU6IFNTV0ZGRjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNvLCB3aGVyZSBub3JtYWwgSUNFIGVuc3VyZXMgdGhhdCBv bmNlIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmb3VuZGF0aW9u IGlzIHByb3ZlbiB0byB3b3JrPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKGZvciBib3RoIGNvbXBvbmVudHMgb2YgYSBtZWRpYSBzdHJlYW0pLCBhbGw8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvdGhlciBwYWlycyB3aXRoIHRoYXQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmb3VuZGF0aW9uIGFyZSB1bmZy b3plbiwgdHJpY2tsZSBJQ0Ugb25seTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGd1YXJhbnRlZXMgdGhhdCBvbmUgb2YgdGhlbSBpcy48YnI+DQo8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTbyB5ZXMsIEkgYWdyZWUgdGhpcyBpcyBhIGRp ZmZlcmVuY2Ugd2l0aCA1MjQ1YmlzLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGJ1dCBpdCYjMzk7cyBpbnRlbnRpb25hbC4gSSBzZWUgdGhpcyBpbiBwYXJ0IGFzIGE8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaW1wbGlmaWNhdGlvbiAoSSBkb24mIzM5O3Qg dGhpbmsgaXQgaXMgYSBtZWFuaW5nZnVsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgb3B0aW1pemF0aW9uIGV2ZW4gZm9yIDUyNDViaXMpIGJ1dCBtb3JlIHNwZWNpZmljYWxseTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgYW0gcmVsdWN0YW50IHRvIGRlYWwg d2l0aCBzaXR1YXRpb25zIHdoZXJlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGNhbmRpZGF0ZSBtYXRyaXggaXMgYXN5bW1ldHJpYyBmb3Igd2hhdGV2ZXIgd2VpcmQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWFzb24gYW5kIG9uZSBzaWRlIGlzIHRy eWluZyBjaGVja3MgZm9yIE0yRjMgYnV0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdGhlIG90aGVyIGlzbiYjMzk7dCByZXNwb25kaW5nIGJlY2F1c2UgTTJGMyBpcyBibG9ja2Vk PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWZ0ZXIgYSBob2xlIGluIE0yRjIg YW5kIGl0IGlzIG5vdCBzdXBwb3NlZCB0byBiZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHVuZnJvemVuIHlldC4gT3Igc29tZXRoaW5nIGFsb25nIHRob3NlIGxpbmVzLjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNvLCB1bmxlc3Mgc29tZW9uZSBo YXMgYSBncmVhdCByZWFzb24gZm9yIHdoeSB3ZSYjMzk7ZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIG5lZWQgYW4gZW50aXJlIHN0cmVhbSB0byBzdWNjZWVkIGJlZm9yZSB1bmZy ZWV6aW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIGZvdW5kYXRpb24s IEkmIzM5O2QgcmF0aGVyIHdlIGtlcHQgdGhpbmdzIGFzIHRoZXkgYXJlLjxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVtaWw8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiBNb24sIEFwciAxNywgMjAxNyBhdCA4OjE2 IFBNLCBQZXRlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNhaW50 LUFuZHJlICZsdDs8YSBocmVmPSJtYWlsdG86c3RwZXRlckBzdHBldGVyLmltIiB0YXJnZXQ9Il9i bGFuayI+c3RwZXRlckBzdHBldGVyLmltPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5p bSIgdGFyZ2V0PSJfYmxhbmsiPnN0cGV0ZXJAc3RwZXRlci5pbTwvYT4mZ3Q7PGJyPjwvZGl2Pjwv ZGl2Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86c3RwZXRlckBzdHBldGVyLmltIiB0YXJnZXQ9Il9ibGFuayI+c3RwZXRlckBz dHBldGVyLmltPC9hPjxkaXY+PGRpdiBjbGFzcz0iaDUiPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN0cGV0ZXJAc3Rw ZXRlci5pbSIgdGFyZ2V0PSJfYmxhbmsiPnN0cGV0ZXJAc3RwZXRlci5pbTwvYT4mZ3Q7Jmd0OyZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgT24gMy8zMC8xNyAxMToyOCBQTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZTo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbYXJlYXMg b2Ygc2VlbWluZyBhZ3JlZW1lbnQgZWxpZGVkXTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCogSW4gc2VjdGlvbiA4LjEuMTogSW4g Z2VuZXJhbCBJIGxpa2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0 aGUgaW1wcm92ZW1lbnRzIHRoYXQgaGF2ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGJlZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBtYWRlLiBIb3dldmVyOjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDCoCDCoG8gVGhlIHJ1bGVzIGZv ciBob3cgYSBuZXcgcGFpciBnZXRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgZWl0aGVyIGEgJnF1b3Q7V2FpdGluZyZxdW90OyBvcjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O0Zyb3plbiZxdW90Ozxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDCoCDCoCDCoHN0 YXRlIGRvbiYjMzk7dCBjb21wbGV0ZWx5IG1hdGNoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgc3RhbmRhcmQgSUNFOyBhdCBsZWFzdCB0aGUgcGFydDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDCoCDCoCDCoHdo ZXJlIHdoZW4gb25lICZxdW90O21lZGlhIHN0cmVhbSZxdW90Ozxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbXBsZXRlcywgcGFpcnMgZnJvbSBvdGhlciBtZWRpYTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDC oCDCoCDCoHN0cmVhbXMgd2l0aCBtYXRjaGluZyBmb3VuZGF0aW9uczxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZSB1bmZyb3plbi4gV2l0aCB0aGUgY3VycmVudDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDC oCDCoCDCoHJ1bGVzIGluIHNlY3Rpb24gOC4xLjEsIG9ubHkgdGhlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG9wbW9zdCByZW1haW5pbmcgcGFpciBpbiBlYWNoPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmd0O8KgIMKgIMKg IMKgIMKgZm91bmRhdGlvbiBpcyBndWFyYW50ZWVkIHRvIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdW5mcm96ZW4uIElzIHRoaXMgZGlmZmVyZW5jZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDCoCDCoCDC oGFjY2VwdGFibGU/IElmIGl0IGlzLCB3ZSBzaG91bGQgYXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBsZWFzdCBhY2tub3dsZWRnZSBpdCwgYW5kIG5vdDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDCoCDCoCDC oGdpdmUgdGhlIHdyb25nIGltcHJlc3Npb24gYnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzYXlpbmcgJnF1b3Q7VHJpY2tsZSBJQ0UgcHJlc2VydmVzIGFsbDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDvCoCDCoCDCoCDC oCDCoG9mIFt0aGUgc3RhbmRhcmQgSUNFXSBydWxlcy4mcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUYXlsb3IsIHdvdWxkIHlvdSBtaW5k IHNwZWxsaW5nIHRoaXMgb3V0IGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBiaXQgbW9yZSBmdWxseSBhbmQgcG9pbnQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaXNjcmVwYW5jaWVzIGJldHdlZW4gdGhlIHRleHQgb2Yg NTI0NWJpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuZCB0aGUg dGV4dCBvZiB0aGUgVHJpY2tsZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHNwZWM/IEkmIzM5O20gc3VyZSBJJiMzOTttIG1pc3Npbmcgc29tZXRoaW5nLCBi dXQgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvbiYjMzk7dCB5 ZXQgc2VlIHRoZSB0cnV0aCBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHlvdXIgc3RhdGVtZW50IHRoYXQgJnF1b3Q7b25seSB0aGUgdG9wbW9zdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlbWFpbmluZyBwYWlyIGluIGVh Y2ggZm91bmRhdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGlzIGd1YXJhbnRlZWQgdG8gYmUgdW5mcm96ZW4mcXVvdDsuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSW4gcGFydGljdWxhciwgeW91ciBz dGF0ZW1lbnQgZG9lc24mIzM5O3Qgc2VlbTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHRvIG1hdGNoIHRoZSBydWxlcyBkZWZpbmVkIGluPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIFRyaWNrbGUgc3BlYy4gSSYjMzk7dmUg dHJpZWQgdG8gc3BlbGwgdGhlbTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIG91dCBpbiBncmVhdGVyIGRldGFpbCAod2l0aDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4YW1wbGVzKSBpbiB0aGUgZm9sbG93aW5nIHByb3Bvc2Vk IHRleHQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgIyMjPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgOC4xLjEuwqAgSW5zZXJ0aW5nIGEgTmV3IFBhaXIgaW4gYSBDaGVjayBMaXN0PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBD b25zaWRlciB0aGUgZm9sbG93aW5nIHRhYnVsYXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCByZXByZXNlbnRhdGlvbiBvZiBhbGwgY2hlY2tsaXN0cyBpbiBhbjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWdlbnQ6PGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIGYxwqAgfMKgIGYywqAgfMKgIGYzwqAgfDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGY0wqAgfMKgIGY1wqAgfDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgbTEgKEF1ZGlv LlJUUCnCoCB8wqAgY3DCoCB8wqAgY3DCoCB8wqAgY3DCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIHw8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0r LS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IG0yIChBdWRpby5SVENQKSB8wqAgY3DCoCB8 wqAgY3DCoCB8wqAgY3DCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgY3DCoCB8wqAgwqAgwqAgfDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0r LS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHwgbTMgKFZpZGVvLlJUUCnCoCB8wqAgY3DCoCB8wqAgwqAgwqAgfMKgIMKgIMKg IHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgY3DC oCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKzxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBtNCAo VmlkZW8uUlRDUCkgfMKgIGNwwqAgfMKgIMKgIMKgIHzCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIGNwwqAgfDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQo8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoEZpZ3VyZSAxOiBFeGFtcGxlIG9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgQ2hlY2sgTGlzdCBTdGF0ZTxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgRWFjaCByb3cgaW4gdGhlIHRhYmxl IHJlcHJlc2VudHMgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNv bXBvbmVudCBmb3IgYSBnaXZlbiBtZWRpYSBzdHJlYW08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoChlLmcuLCBtMSBhbmQgbTIgbWlnaHQgYmUgdGhl IFJUUCBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSVENQIGNv bXBvbmVudHMgZm9yIGF1ZGlvKS48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoEVhY2ggY29sdW1uIHJlcHJlc2VudHMgb25lIGZvdW5kYXRpb24uPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRWFjaCBjZWxsIHJlcHJlc2Vu dHMgb25lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBjYW5kaWRhdGUgcGFpci48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoFdoZW4gYW4gYWdlbnQgY29tbWVuY2VzIElDRSBwcm9jZXNzaW5n LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluIGFjY29yZGFuY2Ug d2l0aDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg U2VjdGlvbiA1LjEuMy42IG9mIFtyZmM1MjQ1YmlzXSBpdCB3aWxsPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdW5mcmVlemUgKGkuZS4sIHBsYWNlIGluIHRoZTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgV2FpdGluZyBz dGF0ZSkgdGhlIHRvcG1vc3QgY2FuZGlkYXRlIHBhaXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBpbiBldmVyeSBjb2x1bW4gKGkuZS4sIHRoZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGFpciB3aXRoIHRoZSBsb3dl c3QgY29tcG9uZW50IElEKS7CoCBUaGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgc3RhdGUgaXMgc2hvd24gaW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb2xsb3dpbmcgdGFibGUsIHdpdGggY2FuZGlkYXRl IHBhaXJzIGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIFdh aXRpbmcgc3RhdGUgbWFya2VkIGJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAmcXVvdDt3LWNwJnF1b3Q7Ljxicj4NCjxicj4NCjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHzCoCBmMcKgIHzCoCBmMsKgIHzCoCBmM8KgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBmNMKgIHzCoCBmNcKgIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0t PHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IG0xIChBdWRpby5SVFApwqAgfCB3LWNwIHwgdy1j cCB8IHctY3AgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHzCoCDCoCDCoCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0r LS0tLS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgfCBtMiAoQXVkaW8uUlRDUCkgfMKgIGNwwqAgfMKgIGNwwqAgfMKgIGNwwqAgfDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHctY3AgfMKgIMKgIMKgIHw8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IG0zIChWaWRlby5SVFAp wqAgfMKgIGNwwqAgfMKgIMKgIMKgIHzCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCB3LWNwIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdi cj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IG00IChWaWRlby5SVENQKSB8wqAgY3DCoCB8wqAgwqAg wqAgfMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8wqAgY3DCoCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKzxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZpZ3VyZSAyOiBJbml0 aWFsIENoZWNrPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTGlzdCBT dGF0ZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgVGhlbiwgYXMgdGhlIGNoZWNrcyBwcm9jZWVkIChzZWUgU2VjdGlvbjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDYuMS4yLjQuMi4zIG9mPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBbcmZjNTI0NWJpc10pLCBm b3IgZWFjaCBwYWlyIHRoYXQgZW50ZXJzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgdGhlIFN1Y2NlZWRlZCBzdGF0ZSAoZGVub3RlZDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGVyZSBieSAmcXVvdDtzLWNwJnF1b3Q7 KSwgdGhlIGFnZW50IHdpbGwgdW5mcmVlemU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBhbGwgcGFpcnMgZm9yIHRoZSBzYW1lIG1lZGlhPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdHJlYW0gYW5kIGZvdW5kYXRpb24g KGUuZy4sIGlmIHRoZSBwYWlyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaW4gY29sdW1uIDEsIHJvdyAxIHN1Y2NlZWRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGVuIHRoZSBhZ2VudCB3aWxsIHVuZnJlZXplIHRo ZSBwYWlyIGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29sdW1u IDEsIHJvdyAyKS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdicj4tLS0rLS0t LS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgZjHCoCB8wqAgZjLC oCB8wqAgZjPCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZjTC oCB8wqAgZjXCoCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0r LS0tLS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgfCBtMSAoQXVkaW8uUlRQKcKgIHwgcy1jcCB8IHctY3AgfCB3LWNwIHw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgfDxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgbTIgKEF1ZGlvLlJUQ1ApIHwg dy1jcCB8wqAgY3DCoCB8wqAgY3DCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgdy1jcCB8wqAgwqAgwqAgfDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHwgbTMgKFZpZGVvLlJUUCnCoCB8wqAgY3DCoCB8wqAgwqAgwqAgfMKg IMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 IHctY3AgfDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Ky0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0t LSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwg bTQgKFZpZGVvLlJUQ1ApIHzCoCBjcMKgIHzCoCDCoCDCoCB8wqAgwqAgwqAgfDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCBjcMKgIHw8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBGaWd1cmUgMzogQ2hlY2sgTGlzdCBTdGF0ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGFmdGVyIFN1Y2NlZWRlZCBDaGVjazxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSUNFIGFsc28gc3BlY2lm aWVzIHRoYXQsIGlmIGFsbCB0aGUgcGFpcnM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpbiBhIG1lZGlhIHN0cmVhbSBmb3Igb25lPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb3VuZGF0aW9uIGFyZSB1bmZyb3plbiAo ZS5nLiwgY29sdW1uIDEsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cm93cyAxIGFuZCAyIHJlcHJlc2VudGluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgYm90aCBjb21wb25lbnRzIGZvciB0aGUgYXVkaW8gc3RyZWFt KSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGVuIGFsbCBvZiB0 aGUgY2FuZGlkYXRlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBwYWlycyBpbiB0aGUgZW50aXJlIGNvbHVtbiBhcmUgdW5mcm96ZW48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoZS5nLiwgY29sdW1uIDEsIHJvd3MgMyBh bmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDQp Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0r LS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCBmMcKgIHzCoCBmMsKgIHzC oCBmM8KgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmNMKgIHzC oCBmNcKgIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8 IG0xIChBdWRpby5SVFApwqAgfCBzLWNwIHwgdy1jcCB8IHctY3AgfDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCB8PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKzxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBtMiAoQXVkaW8uUlRDUCkgfCB3LWNw IHzCoCBjcMKgIHzCoCBjcMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB3LWNwIHzCoCDCoCDCoCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0t LSstLS0tLS0rLS0tLS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfCBtMyAoVmlkZW8uUlRQKcKgIHwgdy1jcCB8wqAgwqAgwqAgfMKgIMKgIMKg IHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IHctY3Ag fDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgbTQgKFZp ZGVvLlJUQ1ApIHwgdy1jcCB8wqAgwqAgwqAgfMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgY3DCoCB8PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t Ky0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKzxicj4NCjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgRmln dXJlIDQ6IENoZWNrIExpc3QgU3RhdGUgd2l0aDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFVuZnJvemVuIE1lZGlhIFN0cmVhbTxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVHJpY2tsZSBJQ0UgcHJlc2VydmVz IGFsbCBvZiB0aGVzZSBydWxlczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGFzIHRoZXkgYXBwbHkgdG8gd2hhdCB3ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbWlnaHQgY2FsbCAmcXVvdDtzdGF0aWMmcXVvdDsgY2hl Y2sgbGlzdCBzZXRzLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRo aXMgaW1wbGllcyB0aGF0IGlmLCBmb3Igc29tZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVhc29uLCBhIFRyaWNrbGUgYWdlbnQgd2VyZSB0byBi ZWdpbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbm5lY3Rpdml0 eSBjaGVja3Mgd2l0aCBhbGwgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGl0cyBwYWlycyBhbHJlYWR5IHByZXNlbnQsIHRoZSB3YXkgdGhhdDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBhaXIgc3RhdGVzIGNoYW5n ZSBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg aW5kaXN0aW5ndWlzaGFibGUgZnJvbSB0aGF0IG9mIGEgcmVndWxhcjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElDRSBhZ2VudC48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE9mIGNvdXJzZSwgdGhlIG1ham9y IGRpZmZlcmVuY2Ugd2l0aDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFRyaWNrbGUgSUNFIGlzIHRoYXQgY2hlY2sgbGlzdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2V0cyBjYW4gYmUgZHluYW1pY2FsbHkgdXBkYXRl ZCBiZWNhdXNlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2FuZGlk YXRlcyBjYW4gYXJyaXZlIGFmdGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBjb25uZWN0aXZpdHkgY2hlY2tzIGhhdmUgc3RhcnRlZC7CoCBXaGVu PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhpcyBoYXBwZW5zLCBh biBhZ2VudCBzZXRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB0aGUgc3RhdGUgb2YgdGhlIG5ld2x5IGZvcm1lZCBwYWlyIGFzPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVzY3JpYmVkIGJlbG93Ljxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQ2FzZSAxOiBJ ZiB0aGUgbmV3bHkgZm9ybWVkIHBhaXIgaXMgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgdG9wbW9zdCBwYWlyIGluIHRoaXMgY29sdW1uLDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2V0IHRoZSBzdGF0ZSB0byBX YWl0aW5nIChlLmcuLCB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgd291bGQgYmUgdGhlIGNhc2UgaWYgdGhlIG5ld2x5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb3JtZWQgcGFpciB3ZXJlIHBsYWNlZCBpbiBj b2x1bW4gNCwgcm93IDEpLjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0t LSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCBmMcKgIHzC oCBmMsKgIHzCoCBmM8KgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBmNMKgIHzCoCBmNcKgIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0t LS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB8IG0xIChBdWRpby5SVFApwqAgfCBzLWNwIHwgdy1jcCB8IHctY3AgfDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHctY3AgfMKgIMKgIMKgIHw8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IG0yIChBdWRpby5SVENQ KSB8IHctY3AgfMKgIGNwwqAgfMKgIGNwwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHctY3AgfMKgIMKgIMKgIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdicj4t LS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8IG0zIChWaWRlby5SVFApwqAgfCB3LWNwIHzCoCDCoCDCoCB8 wqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgdy1jcCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fCBtNCAoVmlkZW8uUlRDUCkgfCB3LWNwIHzCoCDCoCDCoCB8wqAgwqAgwqAgfDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCBjcMKgIHw8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBGaWd1cmUgNTogQ2hlY2sgTGlzdCBTdGF0ZSB3aXRoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgTmV3bHkgRm9ybWVkIFBhaXIsIENhc2UgMTxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQ2FzZSAyOiBJZiB0 aGUgcGFpciBpbW1lZGlhdGVseSBhYm92ZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBuZXdseSBmb3JtZWQgcGFpciBpbiB0aGlzPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb2x1bW4gaXMgaW4gdGhlIFN1Y2Nl ZWRlZCBzdGF0ZSwgc2V0IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHN0YXRlIHRvIFdhaXRpbmcgKGUuZy4sPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlIGlmIHRoZSBwYWly IGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29sdW1uIDQsIHJv dyAyIHN1Y2NlZWRlZCBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHRoZSBuZXdseSBmb3JtZWQgcGFpciB3ZXJlIHBsYWNlZCBpbjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbHVtbiA0LCByb3cgMyk7PGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAr LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Kzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIGYxwqAgfMKgIGYywqAgfMKgIGYzwqAgfDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGY0wqAgfMKgIGY1wqAgfDxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgbTEgKEF1ZGlvLlJU UCnCoCB8IHMtY3AgfCB3LWNwIHwgdy1jcCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdicj4t LS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8IG0yIChBdWRpby5SVENQKSB8IHctY3AgfMKgIGNwwqAgfMKg IGNwwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHMtY3AgfMKg IMKgIMKgIHw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8 IG0zIChWaWRlby5SVFApwqAgfCB3LWNwIHzCoCDCoCDCoCB8wqAgwqAgwqAgfDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHctY3AgfCB3LWNwIHw8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0rLS0tPHdicj4tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IG00IChWaWRlby5SVENQKSB8IHct Y3AgfMKgIMKgIMKgIHzCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfMKgIGNwwqAgfDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEZpZ3VyZSA2OiBDaGVjayBMaXN0 IFN0YXRlIHdpdGg8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOZXds eSBGb3JtZWQgUGFpciwgQ2FzZSAyPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBDYXNlIDM6IElmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBw YWlyIGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhpcyBjb2x1 bW4gYmVsb3cgdGhlIHJvdyBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgdGhlIG5ld2x5IGZvcm1lZCBwYWlyIHdob3NlIHN0YXRlIGlzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZWl0aGVyIFN1Y2NlZWRlZCBvciBG YWlsZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oChlLmcuLCB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlIGlmIHRoZSBwYWlyPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW4gY29sdW1uIDQsIHJvdyAyPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdWNjZWVkZWQgYW5kIHRo ZSBuZXdseSBmb3JtZWQgcGFpciB3ZXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgcGxhY2VkIGluIGNvbHVtbiA0LCByb3cgMSkuPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfMKgIGYxwqAgfMKgIGYywqAgfMKgIGYzwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGY0wqAgfMKgIGY1wqAgfDxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSst LS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgbTEgKEF1ZGlvLlJUUCnCoCB8IHMtY3AgfCB3 LWNwIHwgdy1jcCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdy1j cCB8wqAgwqAgwqAgfDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0t Ky0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHwgbTIgKEF1ZGlvLlJUQ1ApIHwgdy1jcCB8wqAgY3DCoCB8wqAgY3DCoCB8PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcy1jcCB8wqAgwqAgwqAgfDxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLSstLS08d2JyPi0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgbTMgKFZpZGVvLlJUUCnC oCB8IHctY3AgfMKgIMKgIMKgIHzCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgdy1jcCB8IHctY3AgfDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS08d2JyPi0t LSstLS0tLS0rLS0tLS0tKy0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHwgbTQgKFZpZGVvLlJUQ1ApIHwgdy1jcCB8wqAgwqAgwqAgfMKg IMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 wqAgY3DCoCB8PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLTx3YnI+LS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKzxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgRmlndXJlIDc6IENoZWNrIExpc3QgU3RhdGUgd2l0aDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5ld2x5IEZvcm1lZCBQYWlyLCBD YXNlIDM8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoENhc2UgNDogSW4gYWxsIG90aGVyIGNhc2VzLCBzZXQgdGhlIHN0YXRlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gRnJvemVuLjxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICMjIzxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFBldGVyPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEljZSBtYWlsaW5nIGxpc3Q8YnI+PC9k aXY+PC9kaXY+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJt YWlsdG86SWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWNlQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JY2VA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2w8d2JyPmlzdGluZm8vaWNlPC9hPjxzcGFuIGNsYXNzPSIiPjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ljZSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL2ljZTwvYT4mZ3Q7PGJyPg0K PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS08YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJodHRwczovL2ppdHNpLm9yZyIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaXRzaS5vcmc8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgLS08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBzZW50 IGZyb20gbXkgbW9iaWxlPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgLS08YnI+DQrCoCDCoCBzZW50 IGZyb20gbXkgbW9iaWxlPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjwvYmxvY2txdW90ZT48c3Bh biBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8YnI+DQotLSA8YnI+DQo8 YSBocmVmPSJodHRwczovL2ppdHNpLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9qaXRzaS5vcmc8L2E+PGJyPg0KPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+ PC9kaXY+PGJyPjwvZGl2Pg0K --f403045f41eec47a92054ea16243-- From nobody Wed May 3 19:06: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 28B8B12957A for ; Wed, 3 May 2017 19:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=n3rqjZCU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jyCRxMXf 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 UHkW9Dqv7Lo6 for ; Wed, 3 May 2017 19:06:54 -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 081EF12953F for ; Wed, 3 May 2017 19:06:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 269B0208CB; Wed, 3 May 2017 22:06:53 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 03 May 2017 22:06: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=JFVDZb3vOLSKh4w3AQ ih3dyVKg/QcvFB48MEb9qys28=; b=n3rqjZCUlGcK763PzsZ8G6devoIWPTW+0+ qu8m1midsfY0lXTudW4gfeaGo5ac5OM6a3DUkFrLEmyGz8a1cu8iqvGPlo/v1bGW YcDvtruqprxaMI1rKBT0sJE6ftEAaZHLwc1EpylOnNr3hcKBFhP/08kh6AKplwU5 oxaSNeDMhobTUG8Q0//sCELbBKQeivR0/uxzLKmuVTIsq50bvvlQ8u4etvQ/ePWw umipfIaAVN2oyVvFdZwEjDJH7djUZ0qufH3Md/A/QGsjKTPmCigNYI0dhvEottaP SVU1SPTAtVsBi+UJR9Ymc21Jm0zGOkIA0BqCrwemS+YFVz0QYFDQ== 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=JFVDZb3vOLSKh4w3AQih3dyVKg/QcvFB48MEb9qys28=; b=jyCRxMXf rPMBnUGL6592XEPqo5s7toQ3Ex+qXLyWeL/dyNzt0g2pul4mQIaDxeCRWb5d1WkO G6WhBPIAOwwkK7PWOQRu6oDKjVv8k8qyvhWivAV9NX/FXB/h10KVxbwkbLZTS3+Y P+4JumJOBt+lEspzHepemUnFn1nyu+UPFiJlwnoOYpulFBxYXgNbgVar4TTeD6KQ Y/XgbJlHMJ0E5A7JIbty9MdbE7TlIQx6BnuIobIlS+OXY22ZApDBP8jCkSdUUfGS 4MxyDS30RroghT4cF81r+Gtd28Hgp2DxJmPXirq9FBIGDv76M2rKLTzXpKAhKkVn 0J4ksccTBGLTUg== X-ME-Sender: X-Sasl-enc: a31zCm7eq8eISiUtXieEzvHRkYh8N4/OdJHFsbOkCSN2 1493863612 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 932AC7E316; Wed, 3 May 2017 22:06:52 -0400 (EDT) To: Taylor Brandstetter , Emil Ivov References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: Date: Wed, 3 May 2017 20:06: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] holes in the matrix (Was: 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: Thu, 04 May 2017 02:06:56 -0000 On 5/3/17 10:45 AM, Taylor Brandstetter wrote: > I am not sure I follow. Why is this not preserved? State changes > themselves happen as they do in 5245bis. Trickle only defines what > happens with newly added candidates and for the case you mention we > have this: > > 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). > > Which translates to exactly what you have in the quotes above. > > What's bothering you about it? > > > I think we're on the same page, just mis-communicating. My email quoted > at the start of this thread was talking about version 08; the problem is > fixed in version 09. The only thing that concerns me about version 09 is > the "or Failed" part > (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA). Emil posted in this thread about that yesterday. His explanation was: The fact that the state has moved to Failed is indication that enough time has been spent waiting on this, so unfreezing the following pairs for that foundation isn't going to penalize ICE processing as a whole. Does that ring true to you, and if so do you think we need to add explanatory text to that effect? Peter From nobody Thu May 4 07:00: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 982A31296B3 for ; Thu, 4 May 2017 07:00:44 -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 rTJF9oCy-5zK for ; Thu, 4 May 2017 07:00:42 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 5D091129601 for ; Thu, 4 May 2017 07:00:42 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m91so10649619qte.3 for ; Thu, 04 May 2017 07:00:42 -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=+5oQeuJzhSrvyKT6WXtCHJTwf/UzV5hhwMPC4jG7QJU=; b=k/v6GCULAOyHtNjbTrp9OxPDQdlAS9hzAgao1CsPPqdFKB7+uwKyze8TgK+MKElo5P nQWY00hnjt32MMsZJDfezcLy+k3cvOuKcqi6H0e/Ks+4K5wndyoqDDya7qlHTHIymgD0 V5pl5ZReIow9D+jjB0C7HE2d+/dYB2+UN5p/8oHqogT+vSbQsk7r7m3CEHf6h/UDme6n hmJQmX/VeemcibsZNh2ttIIGuIUOevY1IiEPKJ9Z38pLaTsGc05k9j7AXN1Xr0J4C+eT jrCptmJx+iOI91TBFQx1hCKmvKcRi9OjzwpJvLSOqgWZX7QsyBI/2FJy4Vb2L5dBXU9R 8+qg== 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=+5oQeuJzhSrvyKT6WXtCHJTwf/UzV5hhwMPC4jG7QJU=; b=nEnUClZWBEFfSZs2FvWyJZ0Vkjf8XUnqFWMxi9XK9AQUJ5H68puN8pZgsxorjd34zF /JoncWY/z1OczrLm20+oD+77zRU1aoctj9P8CLX0e8evaGDecLCL2gw6vSQ6PSsHsYVl OZo0rz5Q+j6WMUsMu7b2i3nJaw/fzOcTDo7XHqqpHchuq2RmXuAW+n0aaqEbpN/fFR/j XLtGdyuGRsyX+KknnFZWflZgAl9uceGq8IG0qga+yp7Cbe5dn+TrTLwn8pgAAjVkvIVJ pnFoAW9KXFWPuBJfO0K/XEgsZDgSxXXdCBi5v29KQlgijFsqxTSVDCq7pKWnWxunjcEL K38w== X-Gm-Message-State: AODbwcADGlbUMTv8AqhcYyd6Cb5BH9V8+knip3G2NZPyzoGlBF9emzHL qNRkQkFFCH2tGSpGNVqVEbZhvdEStRHOrEs= X-Received: by 10.200.51.172 with SMTP id c41mr1145201qtb.71.1493906441440; Thu, 04 May 2017 07:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Thu, 4 May 2017 07:00:40 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> From: Taylor Brandstetter Date: Thu, 4 May 2017 07:00:40 -0700 Message-ID: To: Peter Saint-Andre Cc: Emil Ivov , ice@ietf.org Content-Type: multipart/alternative; boundary=001a11426c9cc5535b054eb332a5 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 14:00:45 -0000 --001a11426c9cc5535b054eb332a5 Content-Type: text/plain; charset=UTF-8 That's not always necessarily true, since the state may go to Failed due to reasons other than a timeout. It would be unfortunate if this rule resulted in more time slots given to a foundation that doesn't work, and less to a foundation that does. It also seems odd that there's no equivalent condition in ICEbis; every other condition has a parallel of some sort. On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre wrote: > On 5/3/17 10:45 AM, Taylor Brandstetter wrote: > > I am not sure I follow. Why is this not preserved? State changes > > themselves happen as they do in 5245bis. Trickle only defines what > > happens with newly added candidates and for the case you mention we > > have this: > > > > 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). > > > > Which translates to exactly what you have in the quotes above. > > > > What's bothering you about it? > > > > > > I think we're on the same page, just mis-communicating. My email quoted > > at the start of this thread was talking about version 08; the problem is > > fixed in version 09. The only thing that concerns me about version 09 is > > the "or Failed" part > > (see: https://mailarchive.ietf.org/arch/msg/ice/ > 6oDf6yNanCgjj1yHXE3idlmobyA). > > Emil posted in this thread about that yesterday. His explanation was: > > The fact that the state has moved to Failed is indication that > enough time has been spent waiting on this, so unfreezing the > following pairs for that foundation isn't going to penalize ICE > processing as a whole. > > Does that ring true to you, and if so do you think we need to add > explanatory text to that effect? > > Peter > > --001a11426c9cc5535b054eb332a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's not always necessarily true, since the state ma= y go to Failed due to reasons other than a timeout. It would be unfortunate= if this rule resulted in more time slots given to a foundation that doesn&= #39;t work, and less to a foundation that does. It also seems odd that ther= e's no equivalent condition in ICEbis; every other condition has a para= llel of some sort.

On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre = <stpeter@stpeter= .im> wrote:
On 5/3/17 10:45 AM, Taylor Brandstetter wrote:
>=C2=A0 =C2=A0 =C2=A0I am not sure I follow. Why is this not preserved? = State changes
>=C2=A0 =C2=A0 =C2=A0themselves happen as they do in 5245bis. Trickle on= ly defines what
>=C2=A0 =C2=A0 =C2=A0happens with newly added candidates and for the cas= e you mention we
>=C2=A0 =C2=A0 =C2=A0have this:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Case 3: If there is at least one pair in th= is column above the row of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the newly formed pair whose state is either= Succeeded or Failed, set
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the state to Waiting (e.g., this would be t= he case if the pair in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 column 5, row 1 succeeded and two newly for= med pairs were placed in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 column 5, rows 3 and 4).
>
>=C2=A0 =C2=A0 =C2=A0Which translates to exactly what you have in the qu= otes above.
>
>=C2=A0 =C2=A0 =C2=A0What's bothering you about it?
>
>
> I think we're on the same page, just mis-communicating. My email q= uoted
> at the start of this thread was talking about version 08; the problem = is
> fixed in version 09. The only thing that concerns me about version 09 = is
> the "or Failed" part
> (see: https://mailarchive.= ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA).

Emil posted in this thread about that yesterday. His explanation was= :

=C2=A0 =C2=A0The fact that the state has moved to Failed is indication that=
=C2=A0 =C2=A0enough time has been spent waiting on this, so unfreezing the<= br> =C2=A0 =C2=A0following pairs for that foundation isn't going to penaliz= e ICE
=C2=A0 =C2=A0processing as a whole.

Does that ring true to you, and if so do you think we need to add
explanatory text to that effect?

Peter


--001a11426c9cc5535b054eb332a5-- From nobody Thu May 4 07:58: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 0A2FC1204DA for ; Thu, 4 May 2017 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SdJAOWBm9ki for ; Thu, 4 May 2017 07:58:38 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 9EB0812441E for ; Thu, 4 May 2017 07:58:32 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id f102so25305848ioi.2 for ; Thu, 04 May 2017 07:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=vloQW5Wf4E6GblPJKbhF6s2mel/QoJFOpI1f7gnKLCY=; b=0ZSZRspvwCc85xf+s5g4/o6TyrvNCi8ezkKjCRtD9dwfglgPA6jHemKKp0hfL2xOYN 3U9TcJayhESVz88iw1MDf9qKkT7s5Y6YpIP+20YF8NhJMC3bx3SBpAPXqH0+yQzoKzHK Euoa5LM6gfZrRBLfQTaT5D1isoD9nJm8JCpmwrKF/RrPP5/IfiBSSwpLJybpKSk2CDEY EAaxrTn6JFB0PsMNMU6LCQIyML309XKO9q8ubbtxfw1j/OVaHhhLq6SjoPGNJ3RB0kPH J0VvMNFOIqF7pAnPVV0G0C1y7KvRJ36ualOLzVcNNha+h6jN0MZm+kMwcI+GJDtqdcWK qGIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vloQW5Wf4E6GblPJKbhF6s2mel/QoJFOpI1f7gnKLCY=; b=l9qORC+cJMVF9k6Y/M27C8Y2xBDiBUzAO+bpcUPo0k4XK/KF0l5vd+gKuF7pioD8pD 7FcAiArC7+MO6+CpjNBfnu1ZMCwexSxKqHs9sqzYm53aCLEABp1CX9zHw+ZYbUNSXfjF ACThCEoHhpJ2XANQpP1/bIxHJ6fGhXGixuhmXlYLlyrAdQryVE2+2mMkt9BNU82h+S3c 1uAM6NZZCQ4RYPW9dhB5HsdbCq3SFeLyQm0ZdxDwc5jH3JJBHqMJKUnC6Z8YqkLaYek7 1pPu3V1pv78/YCYU86QwttfSxpedUmWPHM9+U4SScTsHJnnFNN1rUaFgsZ2yJ1Mi8NS6 0HSg== X-Gm-Message-State: AN3rC/60Yd2iZKCbqglS0UUWf6QmIUKF8d7FDLsbX4tvN+RXg/qErCUA smDoiaXE8cxIKA== X-Received: by 10.157.35.17 with SMTP id j17mr14390078otb.132.1493909910396; Thu, 04 May 2017 07:58:30 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id q187sm1164532oia.39.2017.05.04.07.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 07:58:29 -0700 (PDT) To: Taylor Brandstetter References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> Cc: Peter Saint-Andre , ice@ietf.org From: Emil Ivov Message-ID: <022a4401-91ff-9709-6d9e-b2a4c8d8286c@jitsi.org> Date: Thu, 4 May 2017 09:58:29 -0500 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; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 14:58:42 -0000 On 5/3/17 11:45 AM, Taylor Brandstetter wrote: > I am not sure I follow. Why is this not preserved? State changes > themselves happen as they do in 5245bis. Trickle only defines what > happens with newly added candidates and for the case you mention we > have this: > > 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). > > Which translates to exactly what you have in the quotes above. > > What's bothering you about it? > > > I think we're on the same page, just mis-communicating. My email quoted > at the start of this thread was talking about version 08; the problem is > fixed in version 09. That rule was actually there since 08: Waiting: if the pair immediately above the newly formed pair in this column is in the Succeeded state; which is why was confused. I do like the current wording better though. > The only thing that concerns me about version 09 is > the "or Failed" part > (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA). Will respond on the other thread. Emil > > > On Wed, May 3, 2017 at 9:30 AM, Emil Ivov > wrote: > > > > On 5/3/17 12:03 AM, Taylor Brandstetter wrote: > > When I said "trickle ICE only guarantees that one of them is", I > meant > "only guarantees that one pair is unfrozen". I'm glad that the "both > components of a media stream" part is removed from ICEbis, > > > I'll skip the 5245bis part of the discussion until we are done with > the trickle one. > > but the > property I thought does make sense to preserve is "once one pair > in a > foundation succeeds, every pair with that foundation is unfrozen". > > > I am not sure I follow. Why is this not preserved? State changes > themselves happen as they do in 5245bis. Trickle only defines what > happens with newly added candidates and for the case you mention we > have this: > > 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). > > Which translates to exactly what you have in the quotes above. > > What's bothering you about it? > > Emil > > > > > > On Tue, May 2, 2017 at 7:03 PM, Emil Ivov > >> wrote: > > > On Tue, 2 May 2017 at 21:00, Taylor Brandstetter > > >> wrote: > > Sorry, I thought you were responding to my example since > it was > quoted above. Nevermind. > > > I was responding to your comment on how the new rules do not > guarantee that both components of the stream would have to > succeed > before a new stream for that foundation gets unfrozen. > > So I was saying that this is true but I don't think > preserving this > property is essential. > > I thought you were objecting to that. > > Should I understand you are good then? > > Emil > > > On Tue, May 2, 2017 at 6:42 PM, Emil Ivov > > >> wrote: > > > On Tue, 2 May 2017 at 20:39, Taylor Brandstetter > > >> wrote: > > I am reluctant to deal with situations > where the > candidate matrix is asymmetric > > > That example doesn't have asymmetric candidate > matrices > though; it's just 3 media streams with 2 components > each, and one foundation. > > > I wasn't refering to that example. > > > > So, unless someone has a great reason for > why we'd > need an entire stream to succeed before > unfreezing > the foundation, I'd rather we kept things as > they are. > > > Actually, what I was concerned about is that > even after > an entire stream succeeds, new candidate pairs > with that > foundation may start as frozen. > > > Em. You mean in your example above? > > Emil > > > On Tue, May 2, 2017 at 2:47 PM, Emil Ivov > > >> wrote: > > Hey, > > Apologies for coming in a bit late on this. > > On 4/18/17 8: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 > 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. > > > So yes, I agree this is a difference with > 5245bis, > but it's intentional. I see this in part as a > simplification (I don't think it is a meaningful > optimization even for 5245bis) but more > specifically > I am reluctant to deal with situations where the > candidate matrix is asymmetric for whatever > weird > reason and one side is trying checks for > M2F3 but > the other isn't responding because M2F3 is > blocked > after a hole in M2F2 and it is not supposed > to be > unfrozen yet. Or something along those lines. > > So, unless someone has a great reason for > why we'd > need an entire stream to succeed before > unfreezing > the foundation, I'd rather we kept things as > they are. > > Emil > > > 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 > > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ice > > > > > > > -- > https://jitsi.org > > > -- > sent from my mobile > > > -- > sent from my mobile > > > > -- > https://jitsi.org > > -- https://jitsi.org From nobody Thu May 4 08:40:51 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 48B4D1286CA for ; Thu, 4 May 2017 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8e7--AxGK_y for ; Thu, 4 May 2017 08:40:47 -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 98CE1127863 for ; Thu, 4 May 2017 08:40:47 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id c15so342227ith.0 for ; Thu, 04 May 2017 08:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hehTm4aasVKdFFZSO3OQrsNI8P3Uue+y4B/Hb42azTQ=; b=kBQ7YJ6gFrZ0KDGWlEdfuFLspqtHI5Jk9EagzmXYb78cEdenRQBhxj6hktxumuCMnt pxTNeObuphFmGFAw90wUTWJG2ANeddJJRuRouejArjG1Q74kNiNZBwk7+iVWJG/oeuei H7YiKrbDWRY4SMlDovayw3wELwlqudIvz0HynMIVMdulIKgfyzK2gRN5JdMCmjl8lsMK Yg6H7diWbDwmm7ozNCqdZoTGkGWEVudRMx/kibJSjX83Lehwshf8V+mW1U0tPItoICfm Vkl//sUCDpeTiZp54WU81KJfuWB5FKv0TgDYlEEhYhmdlNg0a4zTlobq19d64cZ2p2M4 FBHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hehTm4aasVKdFFZSO3OQrsNI8P3Uue+y4B/Hb42azTQ=; b=SpAWAVh4hZtrb2XjmD+hd/M8lVoohkZs/+6dqzzHCGQ/oOnriKlx9dUsDdPpthk3ts 4q3g2yW9QHWAzuAmHhNT5gBvsE9TS/pLZvNuQ3Br7R2ylYxnr/z0q88OKUyopxIx9Am8 mDD9yFxdrwIbYL0oobWr2KGcKTVNXGJjUQJxprJuuegD5KoDhtZh9tPslgKqF8ZQ9vhB Z2I3b+cbdK9w7SRNi2QfLts96p0/w8j8imH2XgxvdPVm+k6briB+BIYhNljaFdscqNmr 7A/CSNoMYJOPifOEQKd1JAuBUKYE5cSb/SDdLh6tlm01/w2dY4KkaeHSalDp2XbeEETG Vdaw== X-Gm-Message-State: AN3rC/69Z909FoUXvV+qeLK+/Jb1taxQZSfjNagqLGSeZ2dBwpn+SDXN ffxoKcnB4CFiUQ== X-Received: by 10.202.72.17 with SMTP id v17mr1912289oia.78.1493912446726; Thu, 04 May 2017 08:40:46 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id w127sm1224740oie.1.2017.05.04.08.40.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 08:40:45 -0700 (PDT) To: Taylor Brandstetter , Peter Saint-Andre References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> Cc: ice@ietf.org From: Emil Ivov Message-ID: <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> Date: Thu, 4 May 2017 10:40:44 -0500 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; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 15:40:49 -0000 On 5/4/17 9:00 AM, Taylor Brandstetter wrote: > That's not always necessarily true, since the state may go to Failed due > to reasons other than a timeout. Yes, indeed. That could happen and the reason would be something like a transport error or an ICMP port unreachable. We could optimize for this by adding a second go at the end where all the failed foundations are given another attempt. This wouldn't be trivial to write up and I am reluctant to do it because: 1. it adds complexity to both the specification and implementations for low value: you only save one time slot per pair. You don't even have to worry about retransmissions. 2. the timeout case is arguably significantly more common One alternative that I would find acceptable is to simply scratch the entire foundation if the first pair there fails. I think that would work fine and it would be simple to write up but I know people on this list feel strongly about trying every pair and I get that point of view too. > It would be unfortunate if this rule > resulted in more time slots given to a foundation that doesn't work, and > less to a foundation that does. I don't believe this statement is accurate. You may end up giving slots in the wrong order but I don't see how you could give more to the non-working and less to the working. Emil > It also seems odd that there's no > equivalent condition in ICEbis; every other condition has a parallel of > some sort. > > On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre > wrote: > > On 5/3/17 10:45 AM, Taylor Brandstetter wrote: > > I am not sure I follow. Why is this not preserved? State changes > > themselves happen as they do in 5245bis. Trickle only defines what > > happens with newly added candidates and for the case you mention we > > have this: > > > > 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). > > > > Which translates to exactly what you have in the quotes above. > > > > What's bothering you about it? > > > > > > I think we're on the same page, just mis-communicating. My email quoted > > at the start of this thread was talking about version 08; the problem is > > fixed in version 09. The only thing that concerns me about version 09 is > > the "or Failed" part > > (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA ). > > Emil posted in this thread about that yesterday. His explanation was: > > The fact that the state has moved to Failed is indication that > enough time has been spent waiting on this, so unfreezing the > following pairs for that foundation isn't going to penalize ICE > processing as a whole. > > Does that ring true to you, and if so do you think we need to add > explanatory text to that effect? > > Peter > > -- https://jitsi.org From nobody Thu May 4 09:17:55 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 AB9B0127863 for ; Thu, 4 May 2017 09:17:53 -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 7MUbRQcTzuhd for ; Thu, 4 May 2017 09:17:51 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006391286CA for ; Thu, 4 May 2017 09:17:49 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id u75so15047313qka.3 for ; Thu, 04 May 2017 09:17:49 -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=6cAxVlN/jH+SZdgFE/X+gG72haT8Aox3FHlYWAbNqZ0=; b=FQZ20q3yzSsy/v8vdi1ChoE57c904l4jqgK/LdhiWJY/C0QDfE+TDv/ROYqAXzbukZ 9jd4jgFEP31sVw0ewO+7fnnrF6x0uJPkIvD9ovy9seBVJRyenbi1xv6eorO8e5p/H8W7 ewXkTNBTSrppSqaWccC59sBZUgME+fqFYSwJs8WY0hzlmg9NFWf01uYh1+mW7HtEeapC WU4CF6w4gBKQqlQq15o3hdR27ZpZ797+Qk6Ur/IgMXNtkh1EBIoBLPDv9il5Ua2yWhbU wJw/VplQFPqWT8ABtgREjTJhrkZt4g51O+isZZ1kIUyJE2uCHW/FSo46Q2wAK0DINF1y Recg== 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=6cAxVlN/jH+SZdgFE/X+gG72haT8Aox3FHlYWAbNqZ0=; b=f5Mx7nubqQKrcp3+89Ij+qAD3CSmm2VDXKszsunyqUiDNUBv3uQzTBwACt/x2Z9ClK 24HnYZTQ+lMjsQcLnVPkjTJhc3ROVSTPUDXRPYnjQfOAUgPucE0ClnkMnhAvn2457c3W +zdJpqYw64UMtmgX0F4jBW6aDDfbUMfVrEEqbNJaFLU6Lr4LvIcDHA/De/oqc47UrKUc R/OQi97dH5OJMkX4A/ySGItQuhfKRGUlmuFtPZAT24gSY+t4SUBun/JiBKNA4z8EzClF Gci7+XcAXIIakinAag6OL0uzRL0bdL8RX0QTHYyUvmXo98wTawz4sNc0mK1OSqqIrOIx WPAQ== X-Gm-Message-State: AN3rC/4red890mNYf6ZDp01c1nnrYAaxdpjyx5s+tggYCqpWWmGLqID7 exOmUrRG/+9r0sG8fGqCOT0WY+1jomS9oJMEVA== X-Received: by 10.55.18.91 with SMTP id c88mr9321231qkh.143.1493914668886; Thu, 04 May 2017 09:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.134 with HTTP; Thu, 4 May 2017 09:17:48 -0700 (PDT) In-Reply-To: <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> From: Taylor Brandstetter Date: Thu, 4 May 2017 09:17:48 -0700 Message-ID: To: Emil Ivov Cc: Peter Saint-Andre , ice@ietf.org Content-Type: multipart/alternative; boundary=001a11473eca2a6df5054eb51d08 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 16:17:54 -0000 --001a11473eca2a6df5054eb51d08 Content-Type: text/plain; charset=UTF-8 > > We could optimize for this by adding a second go at the end where all the > failed foundations are given another attempt. This already happens with ICEbis, though: Whenever Ta fires, the agent will perform a check for a candidate pair within the selected CHECK LIST as follows: ... o If there is no candidate pair in the Waiting state, and if there are one or more pairs in the Frozen state, for each pair in the > Frozen state the the agent checks the foundation associated with > the pair. For a given foundation, if there is no pair (in any > CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress > state, the agent performs a connectivity check on the pair and > puts the pair state to In-Prograss. That's why I don't see the need for trickle ICE to do anything special with Failed candidate pairs. It's already guaranteed that failed foundations will be tried *eventually*, so what's gained by unfreezing these pairs earlier? On Thu, May 4, 2017 at 8:40 AM, Emil Ivov wrote: > > > On 5/4/17 9:00 AM, Taylor Brandstetter wrote: > >> That's not always necessarily true, since the state may go to Failed due >> to reasons other than a timeout. >> > > Yes, indeed. That could happen and the reason would be something like a > transport error or an ICMP port unreachable. We could optimize for this by > adding a second go at the end where all the failed foundations are given > another attempt. > > This wouldn't be trivial to write up and I am reluctant to do it because: > > 1. it adds complexity to both the specification and implementations for > low value: you only save one time slot per pair. You don't even have to > worry about retransmissions. > 2. the timeout case is arguably significantly more common > > One alternative that I would find acceptable is to simply scratch the > entire foundation if the first pair there fails. I think that would work > fine and it would be simple to write up but I know people on this list feel > strongly about trying every pair and I get that point of view too. > > It would be unfortunate if this rule >> resulted in more time slots given to a foundation that doesn't work, and >> less to a foundation that does. >> > > I don't believe this statement is accurate. You may end up giving slots in > the wrong order but I don't see how you could give more to the non-working > and less to the working. > > Emil > > It also seems odd that there's no >> equivalent condition in ICEbis; every other condition has a parallel of >> some sort. >> > > > > >> On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre > > wrote: >> >> On 5/3/17 10:45 AM, Taylor Brandstetter wrote: >> > I am not sure I follow. Why is this not preserved? State changes >> > themselves happen as they do in 5245bis. Trickle only defines >> what >> > happens with newly added candidates and for the case you >> mention we >> > have this: >> > >> > 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). >> > >> > Which translates to exactly what you have in the quotes above. >> > >> > What's bothering you about it? >> > >> > >> > I think we're on the same page, just mis-communicating. My email >> quoted >> > at the start of this thread was talking about version 08; the >> problem is >> > fixed in version 09. The only thing that concerns me about version >> 09 is >> > the "or Failed" part >> > (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE >> 3idlmobyA > E3idlmobyA>). >> >> Emil posted in this thread about that yesterday. His explanation was: >> >> The fact that the state has moved to Failed is indication that >> enough time has been spent waiting on this, so unfreezing the >> following pairs for that foundation isn't going to penalize ICE >> processing as a whole. >> >> Does that ring true to you, and if so do you think we need to add >> explanatory text to that effect? >> >> Peter >> >> >> > -- > https://jitsi.org > --001a11473eca2a6df5054eb51d08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We could optimize for this by adding a second go a= t the end where all the failed foundations are given another attempt.

This already happens with ICEbis, though:=

=C2=A0 =C2=A0Whenever Ta fires, the agent will perform a c= heck for a candidate
=C2=A0 =C2=A0pair within= the selected CHECK LIST as follows: ...
=C2= =A0
=C2=A0 =C2=A0o=C2=A0 If there is no candidate pair in th= e Waiting state, and if there
=C2=A0 =C2=A0 = =C2=A0 are one or more pairs in the Frozen state, for each pair in the
= =C2=A0 =C2=A0 =C2=A0 Frozen state the the agent checks the foundation assoc= iated with
=C2=A0 =C2=A0 =C2=A0 the pair.=C2=A0 For a given foundation, = if there is no pair (in any
=C2=A0 =C2=A0 =C2=A0 CHECK LIST in the CHECK= LIST SET) in the Waiting or In-Progress
=C2=A0 =C2=A0 =C2=A0 state, the= agent performs a connectivity check on the pair and
=C2=A0 =C2=A0 =C2= =A0 puts the pair state to In-Prograss.

<= div>That's why I don't see the need for trickle ICE to do anything = special with Failed candidate pairs. It's already guaranteed that faile= d foundations will be tried eventually, so what's gained by unfr= eezing these pairs earlier?

=C2=A0

On Thu, May 4, = 2017 at 8:40 AM, Emil Ivov <emcho@jitsi.org> wrote:


On 5/4/17 9:00 AM, Taylor Brandstetter wrote:
That's not always necessarily true, since the state may go to Failed du= e
to reasons other than a timeout.

 Yes, indeed. That could happen and the reason would be something like a tra= nsport error or an ICMP port unreachable. We could optimize for this by add= ing a second go at the end where all the failed foundations are given anoth= er attempt.

This wouldn't be trivial to write up and I am reluctant to do it becaus= e:

1. it adds complexity to both the specification and implementations for low= value: you only save one time slot per pair. You don't even have to wo= rry about retransmissions.
2. the timeout case is arguably significantly more common

One alternative that I would find acceptable is to simply scratch the entir= e foundation if the first pair there fails. I think that would work fine an= d it would be simple to write up but I know people on this list feel strong= ly about trying every pair and I get that point of view too.

It would be unfortunate if this rule
resulted in more time slots given to a foundation that doesn't work, an= d
less to a foundation that does.

 I don't believe this statement is accurate. You may end up giving slots= in the wrong order but I don't see how you could give more to the non-= working and less to the working.

Emil

It also seems odd that there's no
equivalent condition in ICEbis; every other condition has a parallel of
some sort.




On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre <stpeter@stpeter.im
 <mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 On 5/3/17 10:45 AM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am not sure I follow. Why is this n= ot preserved? State changes
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0themselves happen as they do in 5245b= is. Trickle only defines what
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0happens with newly added candidates a= nd for the case you mention we
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0have this:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Case 3: If there is at least = one pair in this column above the row of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the newly formed pair whose s= tate is either Succeeded or Failed, set
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the state to Waiting (e.g., t= his would be the case if the pair in
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 column 5, row 1 succeeded and= two newly formed pairs were placed in
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 column 5, rows 3 and 4).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Which translates to exactly what you = have in the quotes above.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0What's bothering you about it? =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I think we're on the same page, just mis-communicati= ng. My email quoted
=C2=A0 =C2=A0 > at the start of this thread was talking about version 08= ; the problem is
=C2=A0 =C2=A0 > fixed in version 09. The only thing that concerns me abo= ut version 09 is
=C2=A0 =C2=A0 > the "or Failed" part
 =C2=A0 =C2=A0 > (see: https:= //mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA <https://mailarchive.ietf= .org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA>).

=C2=A0 =C2=A0 Emil posted in this thread about that yesterday. His explanat= ion was:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The fact that the state has moved to Failed is i= ndication that
=C2=A0 =C2=A0 =C2=A0 =C2=A0enough time has been spent waiting on this, so u= nfreezing the
=C2=A0 =C2=A0 =C2=A0 =C2=A0following pairs for that foundation isn't go= ing to penalize ICE
=C2=A0 =C2=A0 =C2=A0 =C2=A0processing as a whole.

=C2=A0 =C2=A0 Does that ring true to you, and if so do you think we need to= add
=C2=A0 =C2=A0 explanatory text to that effect?

=C2=A0 =C2=A0 Peter



--
https://= jitsi.org

--001a11473eca2a6df5054eb51d08-- From nobody Thu May 4 09:28: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 8C17112952E for ; Thu, 4 May 2017 09:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omAg74EAeJQT for ; Thu, 4 May 2017 09:28:25 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568CC129527 for ; Thu, 4 May 2017 09:28:24 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id 142so151561wma.1 for ; Thu, 04 May 2017 09:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hb5dlAmq36FSfmVrWxKCI0jntGwAt3ig6YTObD5lPCs=; b=Du+9eYqzcOA3Zobel/aBgzKTXVW7z133kDXtCrRBezRU0zKs6hrzVLVvFWzcrXQw/c YTuJjr0Kw/ERhYvVLrhzC45IPceEnJV6W08zb41G1Z0hZTgsMepdEB3RnFs7zHG/V5nP VaQXHfO40WvH/YxRcd1Nd8P3aei2bCNIogeNCOoERcOhaBuyOhpkZXOxCIdOr1ZX/dMy nuRJpXHhCVULE98lEus0AaaiMRz6rTyjZHMqN7vhegav7GSSBNLkgIJ0xjZJ2WMdKl8v akbfQ0N2UQjjLHA7i3yG4lh7gDiTUX8h45VQpqgCtqqybRwCQEoRc74vlN7RZNTv+7s7 r3qg== 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=hb5dlAmq36FSfmVrWxKCI0jntGwAt3ig6YTObD5lPCs=; b=V1EOPn6MCajb8rU/oJJN8KlNKh9miHNjI6UoMIhKZQaOZcX6Wi0MAiPghqEjUZ04tC cIuula6ShhlV5kKspYceJPTiCn32/eOcxAhNf7g8VDeKk1Bk1KQ7YK3HUyUWCuutHDok aMXdzqfht9kEiSmxwpo/DZomSpruw2ifi/+OPBUNLrcH/tXw3WJR2C+v3MYwG82haoHS EDjNnkYjdJuMGrtZ6x4al2PkbIyqmjNPRBA6tH8T+8UAVcispjxBKnw8WtYQh+gBUFqz VAFfaeKOWuZP5mVWJf4Q3TU16auKEtfnqCtJ/uig0KVyfHxzIHpICH2Wj1kt4lUwkWMq h/Qw== X-Gm-Message-State: AN3rC/69VCHJhEKDgLrQPcSYt8kWDxUxqPQ7SxtvY3IMGeYsNkQeN8kX +1a7qNGMejdii2cH5qk/+xQEvcF+nxmX X-Received: by 10.80.144.203 with SMTP id d11mr29485636eda.162.1493915302760; Thu, 04 May 2017 09:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.177.52 with HTTP; Thu, 4 May 2017 09:28:02 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> From: Emil Ivov Date: Thu, 4 May 2017 11:28:02 -0500 Message-ID: To: Taylor Brandstetter Cc: Peter Saint-Andre , ice@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 16:28:28 -0000 On Thu, May 4, 2017 at 11:17 AM, Taylor Brandstetter wrote: >> We could optimize for this by adding a second go at the end where all the >> failed foundations are given another attempt. > > > This already happens with ICEbis, though: > >> Whenever Ta fires, the agent will perform a check for a candidate >> >> pair within the selected CHECK LIST as follows: ... >> >> >> >> o If there is no candidate pair in the Waiting state, and if there >> >> are one or more pairs in the Frozen state, for each pair in the >> Frozen state the the agent checks the foundation associated with >> the pair. For a given foundation, if there is no pair (in any >> CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress >> state, the agent performs a connectivity check on the pair and >> puts the pair state to In-Prograss. > > > That's why I don't see the need for trickle ICE to do anything special with > Failed candidate pairs. It's already guaranteed that failed foundations will > be tried eventually, so what's gained by unfreezing these pairs earlier? I was actually just rereading the same part. I think you've won me over. I'll remove this in a minute. Emil > > > > On Thu, May 4, 2017 at 8:40 AM, Emil Ivov wrote: >> >> >> >> On 5/4/17 9:00 AM, Taylor Brandstetter wrote: >>> >>> That's not always necessarily true, since the state may go to Failed due >>> to reasons other than a timeout. >> >> >> Yes, indeed. That could happen and the reason would be something like a >> transport error or an ICMP port unreachable. We could optimize for this by >> adding a second go at the end where all the failed foundations are given >> another attempt. >> >> This wouldn't be trivial to write up and I am reluctant to do it because: >> >> 1. it adds complexity to both the specification and implementations for >> low value: you only save one time slot per pair. You don't even have to >> worry about retransmissions. >> 2. the timeout case is arguably significantly more common >> >> One alternative that I would find acceptable is to simply scratch the >> entire foundation if the first pair there fails. I think that would work >> fine and it would be simple to write up but I know people on this list feel >> strongly about trying every pair and I get that point of view too. >> >>> It would be unfortunate if this rule >>> resulted in more time slots given to a foundation that doesn't work, and >>> less to a foundation that does. >> >> >> I don't believe this statement is accurate. You may end up giving slots in >> the wrong order but I don't see how you could give more to the non-working >> and less to the working. >> >> Emil >> >>> It also seems odd that there's no >>> equivalent condition in ICEbis; every other condition has a parallel of >>> some sort. >> >> >> >> >>> >>> On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre >> > wrote: >>> >>> On 5/3/17 10:45 AM, Taylor Brandstetter wrote: >>> > I am not sure I follow. Why is this not preserved? State >>> changes >>> > themselves happen as they do in 5245bis. Trickle only defines >>> what >>> > happens with newly added candidates and for the case you >>> mention we >>> > have this: >>> > >>> > 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). >>> > >>> > Which translates to exactly what you have in the quotes above. >>> > >>> > What's bothering you about it? >>> > >>> > >>> > I think we're on the same page, just mis-communicating. My email >>> quoted >>> > at the start of this thread was talking about version 08; the >>> problem is >>> > fixed in version 09. The only thing that concerns me about version >>> 09 is >>> > the "or Failed" part >>> > (see: >>> https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA >>> ). >>> >>> Emil posted in this thread about that yesterday. His explanation was: >>> >>> The fact that the state has moved to Failed is indication that >>> enough time has been spent waiting on this, so unfreezing the >>> following pairs for that foundation isn't going to penalize ICE >>> processing as a whole. >>> >>> Does that ring true to you, and if so do you think we need to add >>> explanatory text to that effect? >>> >>> Peter >>> >>> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Thu May 4 09:31:18 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 5A0A1129AF3 for ; Thu, 4 May 2017 09:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2rTbap8kF8O for ; Thu, 4 May 2017 09:31:14 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 12DAF1294E7 for ; Thu, 4 May 2017 09:31:11 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 142so233885wma.1 for ; Thu, 04 May 2017 09:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B1j6e3jf/9pf9agl9Giy4zu0Y6vhK3Jd4L76Aok9Znk=; b=MmZxxQMBxd91g7ZPb/C1qiYhxxEPDo2i4OD/+2VGuNiHUBLnGgpaE2okojvuhMK2fw W9BzD6CDVp2uORIlM1G4HgWnMSxz9gEDVx78f3hV+IPPQIqgZcsh0YuwgOZioh3AkLUx 6PGKI636Y4nLtYR8VbRpoQbF0q8eBgMje8+HIKCGsLArRxdaBRD3s50hMfjWbBC0MI4k yt3nvs1xF6zZP+seHR6jv5qLIc3+YsKuhXB368/xxNG8nKBs+voG75Na/PHpfuH/Z0Am d6i+xroNILD4gSAgYoCx7Blzi5Uj0gDTyupHp8j/DW4rBw3Lu/npJ5ULyMS5oGRGqF11 IKjg== 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=B1j6e3jf/9pf9agl9Giy4zu0Y6vhK3Jd4L76Aok9Znk=; b=JlUKuhMudYAjMSuRxBz5o5OyxlBsaa32dRdm+YqdsPu9KQTHt6ipGBqGbYQa89egFd wcUcjq9cJNw4iWmCTEAjD7w1o1H5FJ5QKY/MEN7QxTIF1uBvf1144f6j8o7HCoEnUEPO /C9kFdJstoQQSLgYteoY1qFRnDsVSHq5xTkV4oKHd/3rPqojIBAlHqMsn0iJ2ASgEdrr sC7yvFcw3RQAGeCJ2qdv+BXxkBguVGVHOrJ4iC4ddoAWyIluVU6nm48mCAOpDPTEBA1D fkxBbU3jSyFH5Oz3/bPVUv7ToHqEBkIm3W7si3Fyve1Ma+snQZ3Fmf8Xx8EjhvWOLEag G/Aw== X-Gm-Message-State: AN3rC/5BIriveKJZJrp501dfYUmbDs+/evLVsf+TzUg2Db3Fx4J7Pi0/ FcpsHQHTDjj+876qDhtMi65bATumqOu1 X-Received: by 10.80.174.99 with SMTP id c90mr30439708edd.136.1493915469517; Thu, 04 May 2017 09:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.177.52 with HTTP; Thu, 4 May 2017 09:30:48 -0700 (PDT) In-Reply-To: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> From: Emil Ivov Date: Thu, 4 May 2017 11:30:48 -0500 Message-ID: To: Taylor Brandstetter Cc: Peter Saint-Andre , ice@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 16:31:16 -0000 On Thu, May 4, 2017 at 11:28 AM, Emil Ivov wrote: > On Thu, May 4, 2017 at 11:17 AM, Taylor Brandstetter > wrote: >>> We could optimize for this by adding a second go at the end where all the >>> failed foundations are given another attempt. >> >> >> This already happens with ICEbis, though: >> >>> Whenever Ta fires, the agent will perform a check for a candidate >>> >>> pair within the selected CHECK LIST as follows: ... >>> >>> >>> >>> o If there is no candidate pair in the Waiting state, and if there >>> >>> are one or more pairs in the Frozen state, for each pair in the >>> Frozen state the the agent checks the foundation associated with >>> the pair. For a given foundation, if there is no pair (in any >>> CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress >>> state, the agent performs a connectivity check on the pair and >>> puts the pair state to In-Prograss. >> >> >> That's why I don't see the need for trickle ICE to do anything special with >> Failed candidate pairs. It's already guaranteed that failed foundations will >> be tried eventually, so what's gained by unfreezing these pairs earlier? > > I was actually just rereading the same part. > > I think you've won me over. I'll remove this in a minute. Done. > > Emil >> >> >> >> On Thu, May 4, 2017 at 8:40 AM, Emil Ivov wrote: >>> >>> >>> >>> On 5/4/17 9:00 AM, Taylor Brandstetter wrote: >>>> >>>> That's not always necessarily true, since the state may go to Failed due >>>> to reasons other than a timeout. >>> >>> >>> Yes, indeed. That could happen and the reason would be something like a >>> transport error or an ICMP port unreachable. We could optimize for this by >>> adding a second go at the end where all the failed foundations are given >>> another attempt. >>> >>> This wouldn't be trivial to write up and I am reluctant to do it because: >>> >>> 1. it adds complexity to both the specification and implementations for >>> low value: you only save one time slot per pair. You don't even have to >>> worry about retransmissions. >>> 2. the timeout case is arguably significantly more common >>> >>> One alternative that I would find acceptable is to simply scratch the >>> entire foundation if the first pair there fails. I think that would work >>> fine and it would be simple to write up but I know people on this list feel >>> strongly about trying every pair and I get that point of view too. >>> >>>> It would be unfortunate if this rule >>>> resulted in more time slots given to a foundation that doesn't work, and >>>> less to a foundation that does. >>> >>> >>> I don't believe this statement is accurate. You may end up giving slots in >>> the wrong order but I don't see how you could give more to the non-working >>> and less to the working. >>> >>> Emil >>> >>>> It also seems odd that there's no >>>> equivalent condition in ICEbis; every other condition has a parallel of >>>> some sort. >>> >>> >>> >>> >>>> >>>> On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre >>> > wrote: >>>> >>>> On 5/3/17 10:45 AM, Taylor Brandstetter wrote: >>>> > I am not sure I follow. Why is this not preserved? State >>>> changes >>>> > themselves happen as they do in 5245bis. Trickle only defines >>>> what >>>> > happens with newly added candidates and for the case you >>>> mention we >>>> > have this: >>>> > >>>> > 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). >>>> > >>>> > Which translates to exactly what you have in the quotes above. >>>> > >>>> > What's bothering you about it? >>>> > >>>> > >>>> > I think we're on the same page, just mis-communicating. My email >>>> quoted >>>> > at the start of this thread was talking about version 08; the >>>> problem is >>>> > fixed in version 09. The only thing that concerns me about version >>>> 09 is >>>> > the "or Failed" part >>>> > (see: >>>> https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA >>>> ). >>>> >>>> Emil posted in this thread about that yesterday. His explanation was: >>>> >>>> The fact that the state has moved to Failed is indication that >>>> enough time has been spent waiting on this, so unfreezing the >>>> following pairs for that foundation isn't going to penalize ICE >>>> processing as a whole. >>>> >>>> Does that ring true to you, and if so do you think we need to add >>>> explanatory text to that effect? >>>> >>>> Peter >>>> >>>> >>> >>> -- >>> https://jitsi.org >> >> > > > > -- > https://jitsi.org -- https://jitsi.org From nobody Thu May 4 11:40: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 E3F561293EC for ; Thu, 4 May 2017 11:40:22 -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 NJjgohI3Nnox for ; Thu, 4 May 2017 11:40:20 -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 B04F9129505 for ; Thu, 4 May 2017 11:40:16 -0700 (PDT) X-AuditID: c1b4fb2d-b25ff7000000196b-44-590b758e295b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.4A.06507.E857B095; Thu, 4 May 2017 20:40:14 +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; Thu, 4 May 2017 20:40:13 +0200 From: Christer Holmberg To: Taylor Brandstetter , Emil Ivov CC: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt) Thread-Index: AQHSw44yG+8l/JxG+UWcffU9JI4fXaHhs50AgAAA74CAAATFgIAAAP4AgAAyNoCAAL/dgIAABFoAgACc0ICAAMdwAIAAG/YAgAAKWwCAAEgEgA== Date: Thu, 4 May 2017 18:40:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> 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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB93375ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7rm5fKXekweUtphaXVzxktVizcwKL xbcLtRbH9vQzO7B4LNhU6rFkyU8mj/9vAj3m7nnBHMASxWWTkpqTWZZapG+XwJVxfatGwYQj jBWT3lxia2D8sY+xi5GDQ0LARGLacZMuRi4OIYEjjBJ3J95jhnAWM0rcevqIDaSITcBCovuf dhcjJ4eIgJfE7X8bmEBsZgFPicfHd4HZwgIJEs3nG9ghahIlVl28xAhh10kc7TgDVsMioCLx 6uFtsL28Ar4STxbqQay6wC5xuamNGSTOKRAocfCzDkg5o4CYxPdTa6BWiUvcejIfzJYQEJBY suc8M4QtKvHy8T9WCFtJYtHtz1D1+RLHp9wEi/MKCEqcnPmEZQKjyCwko2YhKZuFpGwW0BXM ApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZG YNQd3PJbdwfj6teOhxgFOBiVeHgVcrgjhVgTy4orcw8xSnAwK4nw2mYDhXhTEiurUovy44tK c1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamBk1Pnzd29wCqe4WceUee2fjvhH JCTJnV1h8S25a2bWsXsWZnrs8jopLyMCZP5pGRR/e6is97r7KcuXEGFbrvjJTNGXGf+kzlp7 1kh67bJ5dyMXRzmyTXt37pHppUuLzQ8E5P87NfmW6OrrOkb/WllMVe7P88h8dim2fzV/edSG uNXpz0zOVJsrsRRnJBpqMRcVJwIAtYPfnrYCAAA= Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 18:40:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB93375ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlbGF0ZWQgdG8gdGhlIHRleHQgYmVsb3csIG5vdGUgdGhhdCBpdCBtYXkgYWN0dWFs bHkgdHJpZ2dlciBtdWx0aXBsZSBjaGVja3Mgc2ltdWx0YW5lb3VzbHkgKG5vcm1hbGx5IG9ubHkg YSBzaW5nbGUgY2hlY2sgaXMgdHJpZ2dlcmVkIHdoZW5ldmVyIFRhIGZpcmVzKS4gQXJlIHdlIG9r IHdpdGggdGhhdD8gSWYgbm90LCBJIGd1ZXNzIHdlIHdvdWxkIGhhdmUgdG8gc2VsZWN0IHRoZSBw YWlyIHdpdGggdGhlIGhpZ2hlc3QgcHJpb3JpdHkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN CkZyb206IEljZSBbbWFpbHRvOmljZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGF5 bG9yIEJyYW5kc3RldHRlcg0KU2VudDogMDQgTWF5IDIwMTcgMTg6MTgNClRvOiBFbWlsIEl2b3Yg PGVtY2hvQGppdHNpLm9yZz4NCkNjOiBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVy LmltPjsgaWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0ljZV0gaG9sZXMgaW4gdGhlIG1hdHJp eCAoV2FzOiBUYXlsb3IncyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZS0wOC50eHQp DQoNCldlIGNvdWxkIG9wdGltaXplIGZvciB0aGlzIGJ5IGFkZGluZyBhIHNlY29uZCBnbyBhdCB0 aGUgZW5kIHdoZXJlIGFsbCB0aGUgZmFpbGVkIGZvdW5kYXRpb25zIGFyZSBnaXZlbiBhbm90aGVy IGF0dGVtcHQuDQoNClRoaXMgYWxyZWFkeSBoYXBwZW5zIHdpdGggSUNFYmlzLCB0aG91Z2g6DQoN CiAgIFdoZW5ldmVyIFRhIGZpcmVzLCB0aGUgYWdlbnQgd2lsbCBwZXJmb3JtIGEgY2hlY2sgZm9y IGEgY2FuZGlkYXRlDQogICBwYWlyIHdpdGhpbiB0aGUgc2VsZWN0ZWQgQ0hFQ0sgTElTVCBhcyBm b2xsb3dzOiAuLi4NCg0KICAgbyAgSWYgdGhlcmUgaXMgbm8gY2FuZGlkYXRlIHBhaXIgaW4gdGhl IFdhaXRpbmcgc3RhdGUsIGFuZCBpZiB0aGVyZQ0KICAgICAgYXJlIG9uZSBvciBtb3JlIHBhaXJz IGluIHRoZSBGcm96ZW4gc3RhdGUsIGZvciBlYWNoIHBhaXIgaW4gdGhlDQogICAgICBGcm96ZW4g c3RhdGUgdGhlIHRoZSBhZ2VudCBjaGVja3MgdGhlIGZvdW5kYXRpb24gYXNzb2NpYXRlZCB3aXRo DQogICAgICB0aGUgcGFpci4gIEZvciBhIGdpdmVuIGZvdW5kYXRpb24sIGlmIHRoZXJlIGlzIG5v IHBhaXIgKGluIGFueQ0KICAgICAgQ0hFQ0sgTElTVCBpbiB0aGUgQ0hFQ0sgTElTVCBTRVQpIGlu IHRoZSBXYWl0aW5nIG9yIEluLVByb2dyZXNzDQogICAgICBzdGF0ZSwgdGhlIGFnZW50IHBlcmZv cm1zIGEgY29ubmVjdGl2aXR5IGNoZWNrIG9uIHRoZSBwYWlyIGFuZA0KICAgICAgcHV0cyB0aGUg cGFpciBzdGF0ZSB0byBJbi1Qcm9ncmFzcy4NCg0KVGhhdCdzIHdoeSBJIGRvbid0IHNlZSB0aGUg bmVlZCBmb3IgdHJpY2tsZSBJQ0UgdG8gZG8gYW55dGhpbmcgc3BlY2lhbCB3aXRoIEZhaWxlZCBj YW5kaWRhdGUgcGFpcnMuIEl0J3MgYWxyZWFkeSBndWFyYW50ZWVkIHRoYXQgZmFpbGVkIGZvdW5k YXRpb25zIHdpbGwgYmUgdHJpZWQgZXZlbnR1YWxseSwgc28gd2hhdCdzIGdhaW5lZCBieSB1bmZy ZWV6aW5nIHRoZXNlIHBhaXJzIGVhcmxpZXI/DQoNCg0KDQpPbiBUaHUsIE1heSA0LCAyMDE3IGF0 IDg6NDAgQU0sIEVtaWwgSXZvdiA8ZW1jaG9Aaml0c2kub3JnPG1haWx0bzplbWNob0BqaXRzaS5v cmc+PiB3cm90ZToNCg0KDQpPbiA1LzQvMTcgOTowMCBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3 cm90ZToNClRoYXQncyBub3QgYWx3YXlzIG5lY2Vzc2FyaWx5IHRydWUsIHNpbmNlIHRoZSBzdGF0 ZSBtYXkgZ28gdG8gRmFpbGVkIGR1ZQ0KdG8gcmVhc29ucyBvdGhlciB0aGFuIGEgdGltZW91dC4N Cg0KWWVzLCBpbmRlZWQuIFRoYXQgY291bGQgaGFwcGVuIGFuZCB0aGUgcmVhc29uIHdvdWxkIGJl IHNvbWV0aGluZyBsaWtlIGEgdHJhbnNwb3J0IGVycm9yIG9yIGFuIElDTVAgcG9ydCB1bnJlYWNo YWJsZS4gV2UgY291bGQgb3B0aW1pemUgZm9yIHRoaXMgYnkgYWRkaW5nIGEgc2Vjb25kIGdvIGF0 IHRoZSBlbmQgd2hlcmUgYWxsIHRoZSBmYWlsZWQgZm91bmRhdGlvbnMgYXJlIGdpdmVuIGFub3Ro ZXIgYXR0ZW1wdC4NCg0KVGhpcyB3b3VsZG4ndCBiZSB0cml2aWFsIHRvIHdyaXRlIHVwIGFuZCBJ IGFtIHJlbHVjdGFudCB0byBkbyBpdCBiZWNhdXNlOg0KDQoxLiBpdCBhZGRzIGNvbXBsZXhpdHkg dG8gYm90aCB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgaW1wbGVtZW50YXRpb25zIGZvciBsb3cgdmFs dWU6IHlvdSBvbmx5IHNhdmUgb25lIHRpbWUgc2xvdCBwZXIgcGFpci4gWW91IGRvbid0IGV2ZW4g aGF2ZSB0byB3b3JyeSBhYm91dCByZXRyYW5zbWlzc2lvbnMuDQoyLiB0aGUgdGltZW91dCBjYXNl IGlzIGFyZ3VhYmx5IHNpZ25pZmljYW50bHkgbW9yZSBjb21tb24NCg0KT25lIGFsdGVybmF0aXZl IHRoYXQgSSB3b3VsZCBmaW5kIGFjY2VwdGFibGUgaXMgdG8gc2ltcGx5IHNjcmF0Y2ggdGhlIGVu dGlyZSBmb3VuZGF0aW9uIGlmIHRoZSBmaXJzdCBwYWlyIHRoZXJlIGZhaWxzLiBJIHRoaW5rIHRo YXQgd291bGQgd29yayBmaW5lIGFuZCBpdCB3b3VsZCBiZSBzaW1wbGUgdG8gd3JpdGUgdXAgYnV0 IEkga25vdyBwZW9wbGUgb24gdGhpcyBsaXN0IGZlZWwgc3Ryb25nbHkgYWJvdXQgdHJ5aW5nIGV2 ZXJ5IHBhaXIgYW5kIEkgZ2V0IHRoYXQgcG9pbnQgb2YgdmlldyB0b28uDQpJdCB3b3VsZCBiZSB1 bmZvcnR1bmF0ZSBpZiB0aGlzIHJ1bGUNCnJlc3VsdGVkIGluIG1vcmUgdGltZSBzbG90cyBnaXZl biB0byBhIGZvdW5kYXRpb24gdGhhdCBkb2Vzbid0IHdvcmssIGFuZA0KbGVzcyB0byBhIGZvdW5k YXRpb24gdGhhdCBkb2VzLg0KDQpJIGRvbid0IGJlbGlldmUgdGhpcyBzdGF0ZW1lbnQgaXMgYWNj dXJhdGUuIFlvdSBtYXkgZW5kIHVwIGdpdmluZyBzbG90cyBpbiB0aGUgd3Jvbmcgb3JkZXIgYnV0 IEkgZG9uJ3Qgc2VlIGhvdyB5b3UgY291bGQgZ2l2ZSBtb3JlIHRvIHRoZSBub24td29ya2luZyBh bmQgbGVzcyB0byB0aGUgd29ya2luZy4NCg0KRW1pbA0KSXQgYWxzbyBzZWVtcyBvZGQgdGhhdCB0 aGVyZSdzIG5vDQplcXVpdmFsZW50IGNvbmRpdGlvbiBpbiBJQ0ViaXM7IGV2ZXJ5IG90aGVyIGNv bmRpdGlvbiBoYXMgYSBwYXJhbGxlbCBvZg0Kc29tZSBzb3J0Lg0KDQoNCg0KT24gV2VkLCBNYXkg MywgMjAxNyBhdCA3OjA2IFBNLCBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmlt PG1haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW0+DQo8bWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbTxt YWlsdG86c3RwZXRlckBzdHBldGVyLmltPj4+IHdyb3RlOg0KDQogICAgT24gNS8zLzE3IDEwOjQ1 IEFNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIHdyb3RlOg0KICAgID4gICAgIEkgYW0gbm90IHN1cmUg SSBmb2xsb3cuIFdoeSBpcyB0aGlzIG5vdCBwcmVzZXJ2ZWQ/IFN0YXRlIGNoYW5nZXMNCiAgICA+ ICAgICB0aGVtc2VsdmVzIGhhcHBlbiBhcyB0aGV5IGRvIGluIDUyNDViaXMuIFRyaWNrbGUgb25s eSBkZWZpbmVzIHdoYXQNCiAgICA+ICAgICBoYXBwZW5zIHdpdGggbmV3bHkgYWRkZWQgY2FuZGlk YXRlcyBhbmQgZm9yIHRoZSBjYXNlIHlvdSBtZW50aW9uIHdlDQogICAgPiAgICAgaGF2ZSB0aGlz Og0KICAgID4NCiAgICA+ICAgICAgICBDYXNlIDM6IElmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBw YWlyIGluIHRoaXMgY29sdW1uIGFib3ZlIHRoZSByb3cgb2YNCiAgICA+ICAgICAgICB0aGUgbmV3 bHkgZm9ybWVkIHBhaXIgd2hvc2Ugc3RhdGUgaXMgZWl0aGVyIFN1Y2NlZWRlZCBvciBGYWlsZWQs IHNldA0KICAgID4gICAgICAgIHRoZSBzdGF0ZSB0byBXYWl0aW5nIChlLmcuLCB0aGlzIHdvdWxk IGJlIHRoZSBjYXNlIGlmIHRoZSBwYWlyIGluDQogICAgPiAgICAgICAgY29sdW1uIDUsIHJvdyAx IHN1Y2NlZWRlZCBhbmQgdHdvIG5ld2x5IGZvcm1lZCBwYWlycyB3ZXJlIHBsYWNlZCBpbg0KICAg ID4gICAgICAgIGNvbHVtbiA1LCByb3dzIDMgYW5kIDQpLg0KICAgID4NCiAgICA+ICAgICBXaGlj aCB0cmFuc2xhdGVzIHRvIGV4YWN0bHkgd2hhdCB5b3UgaGF2ZSBpbiB0aGUgcXVvdGVzIGFib3Zl Lg0KICAgID4NCiAgICA+ICAgICBXaGF0J3MgYm90aGVyaW5nIHlvdSBhYm91dCBpdD8NCiAgICA+ DQogICAgPg0KICAgID4gSSB0aGluayB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlLCBqdXN0IG1pcy1j b21tdW5pY2F0aW5nLiBNeSBlbWFpbCBxdW90ZWQNCiAgICA+IGF0IHRoZSBzdGFydCBvZiB0aGlz IHRocmVhZCB3YXMgdGFsa2luZyBhYm91dCB2ZXJzaW9uIDA4OyB0aGUgcHJvYmxlbSBpcw0KICAg ID4gZml4ZWQgaW4gdmVyc2lvbiAwOS4gVGhlIG9ubHkgdGhpbmcgdGhhdCBjb25jZXJucyBtZSBh Ym91dCB2ZXJzaW9uIDA5IGlzDQogICAgPiB0aGUgIm9yIEZhaWxlZCIgcGFydA0KICAgID4gKHNl ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pY2UvNm9EZjZ5TmFuQ2dq ajF5SFhFM2lkbG1vYnlBIDxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lj ZS82b0RmNnlOYW5DZ2pqMXlIWEUzaWRsbW9ieUE+KS4NCg0KICAgIEVtaWwgcG9zdGVkIGluIHRo aXMgdGhyZWFkIGFib3V0IHRoYXQgeWVzdGVyZGF5LiBIaXMgZXhwbGFuYXRpb24gd2FzOg0KDQog ICAgICAgVGhlIGZhY3QgdGhhdCB0aGUgc3RhdGUgaGFzIG1vdmVkIHRvIEZhaWxlZCBpcyBpbmRp Y2F0aW9uIHRoYXQNCiAgICAgICBlbm91Z2ggdGltZSBoYXMgYmVlbiBzcGVudCB3YWl0aW5nIG9u IHRoaXMsIHNvIHVuZnJlZXppbmcgdGhlDQogICAgICAgZm9sbG93aW5nIHBhaXJzIGZvciB0aGF0 IGZvdW5kYXRpb24gaXNuJ3QgZ29pbmcgdG8gcGVuYWxpemUgSUNFDQogICAgICAgcHJvY2Vzc2lu ZyBhcyBhIHdob2xlLg0KDQogICAgRG9lcyB0aGF0IHJpbmcgdHJ1ZSB0byB5b3UsIGFuZCBpZiBz byBkbyB5b3UgdGhpbmsgd2UgbmVlZCB0byBhZGQNCiAgICBleHBsYW5hdG9yeSB0ZXh0IHRvIHRo YXQgZWZmZWN0Pw0KDQogICAgUGV0ZXINCg0KDQotLQ0KaHR0cHM6Ly9qaXRzaS5vcmcNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB93375ESESSMB109erics_ 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 c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5SZWxhdGVkIHRvIHRoZSB0ZXh0IGJlbG93LCBub3RlIHRoYXQgaXQgbWF5IGFjdHVh bGx5IHRyaWdnZXIgbXVsdGlwbGUgY2hlY2tzIHNpbXVsdGFuZW91c2x5IChub3JtYWxseSBvbmx5 IGEgc2luZ2xlIGNoZWNrIGlzIHRyaWdnZXJlZA0KIHdoZW5ldmVyIFRhIGZpcmVzKS4gQXJlIHdl IG9rIHdpdGggdGhhdD8gSWYgbm90LCBJIGd1ZXNzIHdlIHdvdWxkIGhhdmUgdG8gc2VsZWN0IHRo ZSBwYWlyIHdpdGggdGhlIGhpZ2hlc3QgcHJpb3JpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJY2Ug W21haWx0bzppY2UtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGF5bG9y IEJyYW5kc3RldHRlcjxicj4NCjxiPlNlbnQ6PC9iPiAwNCBNYXkgMjAxNyAxODoxODxicj4NCjxi PlRvOjwvYj4gRW1pbCBJdm92ICZsdDtlbWNob0BqaXRzaS5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBQZXRlciBTYWludC1BbmRyZSAmbHQ7c3RwZXRlckBzdHBldGVyLmltJmd0OzsgaWNlQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWNlXSBob2xlcyBpbiB0aGUgbWF0cml4IChX YXM6IFRheWxvcidzIHJldmlldyBvZiBkcmFmdC1pZXRmLWljZS10cmlja2xlLTA4LnR4dCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+V2UgY291bGQgb3B0aW1pemUgZm9yIHRoaXMgYnkgYWRkaW5n IGEgc2Vjb25kIGdvIGF0IHRoZSBlbmQgd2hlcmUgYWxsIHRoZSBmYWlsZWQgZm91bmRhdGlvbnMg YXJlIGdpdmVuIGFub3RoZXIgYXR0ZW1wdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFscmVhZHkgaGFwcGVu cyB3aXRoIElDRWJpcywgdGhvdWdoOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7V2hlbmV2ZXIgVGEgZmlyZXMs IHRoZSBhZ2VudCB3aWxsIHBlcmZvcm0gYSBjaGVjayBmb3IgYSBjYW5kaWRhdGU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsgJm5ic3A7cGFpciB3aXRoaW4gdGhlIHNlbGVjdGVkIENIRUNLIExJU1QgYXMgZm9sbG93 czogLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyBJZiB0aGVyZSBpcyBubyBjYW5kaWRhdGUgcGFpciBpbiB0 aGUgV2FpdGluZyBzdGF0ZSwgYW5kIGlmIHRoZXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgYXJlIG9uZSBvciBtb3JlIHBhaXJzIGluIHRoZSBGcm96ZW4gc3RhdGUsIGZvciBlYWNoIHBh aXIgaW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgRnJvemVuIHN0YXRlIHRoZSB0aGUg YWdlbnQgY2hlY2tzIHRoZSBmb3VuZGF0aW9uIGFzc29jaWF0ZWQgd2l0aDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IHRoZSBwYWlyLiZuYnNwOyBGb3IgYSBnaXZlbiBmb3VuZGF0aW9uLCBpZiB0 aGVyZSBpcyBubyBwYWlyIChpbiBhbnk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBDSEVDSyBM SVNUIGluIHRoZSBDSEVDSyBMSVNUIFNFVCkgaW4gdGhlIFdhaXRpbmcgb3IgSW4tUHJvZ3Jlc3M8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdGF0ZSwgdGhlIGFnZW50IHBlcmZvcm1zIGEgY29u bmVjdGl2aXR5IGNoZWNrIG9uIHRoZSBwYWlyIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHB1dHMgdGhlIHBhaXIgc3RhdGUgdG8gSW4tUHJvZ3Jhc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIHdo eSBJIGRvbid0IHNlZSB0aGUgbmVlZCBmb3IgdHJpY2tsZSBJQ0UgdG8gZG8gYW55dGhpbmcgc3Bl Y2lhbCB3aXRoIEZhaWxlZCBjYW5kaWRhdGUgcGFpcnMuIEl0J3MgYWxyZWFkeSBndWFyYW50ZWVk IHRoYXQgZmFpbGVkIGZvdW5kYXRpb25zIHdpbGwgYmUgdHJpZWQNCjxpPmV2ZW50dWFsbHk8L2k+ LCBzbyB3aGF0J3MgZ2FpbmVkIGJ5IHVuZnJlZXppbmcgdGhlc2UgcGFpcnMgZWFybGllcj88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBNYXkgNCwgMjAxNyBhdCA4OjQwIEFNLCBFbWlsIEl2b3YgJmx0OzxhIGhy ZWY9Im1haWx0bzplbWNob0BqaXRzaS5vcmciIHRhcmdldD0iX2JsYW5rIj5lbWNob0BqaXRzaS5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiA1LzQvMTcgOTowMCBBTSwgVGF5bG9yIEJyYW5kc3Rl dHRlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0J3Mgbm90IGFsd2F5cyBuZWNlc3NhcmlseSB0cnVlLCBzaW5jZSB0aGUgc3RhdGUg bWF5IGdvIHRvIEZhaWxlZCBkdWU8YnI+DQp0byByZWFzb25zIG90aGVyIHRoYW4gYSB0aW1lb3V0 LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpZZXMsIGluZGVlZC4gVGhhdCBjb3VsZCBo YXBwZW4gYW5kIHRoZSByZWFzb24gd291bGQgYmUgc29tZXRoaW5nIGxpa2UgYSB0cmFuc3BvcnQg ZXJyb3Igb3IgYW4gSUNNUCBwb3J0IHVucmVhY2hhYmxlLiBXZSBjb3VsZCBvcHRpbWl6ZSBmb3Ig dGhpcyBieSBhZGRpbmcgYSBzZWNvbmQgZ28gYXQgdGhlIGVuZCB3aGVyZSBhbGwgdGhlIGZhaWxl ZCBmb3VuZGF0aW9ucyBhcmUgZ2l2ZW4gYW5vdGhlciBhdHRlbXB0Ljxicj4NCjxicj4NClRoaXMg d291bGRuJ3QgYmUgdHJpdmlhbCB0byB3cml0ZSB1cCBhbmQgSSBhbSByZWx1Y3RhbnQgdG8gZG8g aXQgYmVjYXVzZTo8YnI+DQo8YnI+DQoxLiBpdCBhZGRzIGNvbXBsZXhpdHkgdG8gYm90aCB0aGUg c3BlY2lmaWNhdGlvbiBhbmQgaW1wbGVtZW50YXRpb25zIGZvciBsb3cgdmFsdWU6IHlvdSBvbmx5 IHNhdmUgb25lIHRpbWUgc2xvdCBwZXIgcGFpci4gWW91IGRvbid0IGV2ZW4gaGF2ZSB0byB3b3Jy eSBhYm91dCByZXRyYW5zbWlzc2lvbnMuPGJyPg0KMi4gdGhlIHRpbWVvdXQgY2FzZSBpcyBhcmd1 YWJseSBzaWduaWZpY2FudGx5IG1vcmUgY29tbW9uPGJyPg0KPGJyPg0KT25lIGFsdGVybmF0aXZl IHRoYXQgSSB3b3VsZCBmaW5kIGFjY2VwdGFibGUgaXMgdG8gc2ltcGx5IHNjcmF0Y2ggdGhlIGVu dGlyZSBmb3VuZGF0aW9uIGlmIHRoZSBmaXJzdCBwYWlyIHRoZXJlIGZhaWxzLiBJIHRoaW5rIHRo YXQgd291bGQgd29yayBmaW5lIGFuZCBpdCB3b3VsZCBiZSBzaW1wbGUgdG8gd3JpdGUgdXAgYnV0 IEkga25vdyBwZW9wbGUgb24gdGhpcyBsaXN0IGZlZWwgc3Ryb25nbHkgYWJvdXQgdHJ5aW5nIGV2 ZXJ5IHBhaXIgYW5kIEkNCiBnZXQgdGhhdCBwb2ludCBvZiB2aWV3IHRvby48bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSB1bmZvcnR1 bmF0ZSBpZiB0aGlzIHJ1bGU8YnI+DQpyZXN1bHRlZCBpbiBtb3JlIHRpbWUgc2xvdHMgZ2l2ZW4g dG8gYSBmb3VuZGF0aW9uIHRoYXQgZG9lc24ndCB3b3JrLCBhbmQ8YnI+DQpsZXNzIHRvIGEgZm91 bmRhdGlvbiB0aGF0IGRvZXMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkkgZG9uJ3Qg YmVsaWV2ZSB0aGlzIHN0YXRlbWVudCBpcyBhY2N1cmF0ZS4gWW91IG1heSBlbmQgdXAgZ2l2aW5n IHNsb3RzIGluIHRoZSB3cm9uZyBvcmRlciBidXQgSSBkb24ndCBzZWUgaG93IHlvdSBjb3VsZCBn aXZlIG1vcmUgdG8gdGhlIG5vbi13b3JraW5nIGFuZCBsZXNzIHRvIHRoZSB3b3JraW5nLjxicj4N Cjxicj4NCkVtaWw8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdCBhbHNvIHNlZW1zIG9kZCB0aGF0IHRoZXJlJ3Mgbm88YnI+DQplcXVpdmFsZW50IGNv bmRpdGlvbiBpbiBJQ0ViaXM7IGV2ZXJ5IG90aGVyIGNvbmRpdGlvbiBoYXMgYSBwYXJhbGxlbCBv Zjxicj4NCnNvbWUgc29ydC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBXZWQsIE1heSAzLCAyMDE3IGF0IDc6MDYgUE0s IFBldGVyIFNhaW50LUFuZHJlICZsdDs8YSBocmVmPSJtYWlsdG86c3RwZXRlckBzdHBldGVyLmlt IiB0YXJnZXQ9Il9ibGFuayI+c3RwZXRlckBzdHBldGVyLmltPC9hPjxicj4NCiZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbSIgdGFyZ2V0PSJfYmxhbmsiPnN0cGV0 ZXJAc3RwZXRlci5pbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IE9uIDUvMy8xNyAxMDo0NSBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZTo8YnI+DQombmJz cDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0kgYW0gbm90IHN1cmUgSSBmb2xsb3cu IFdoeSBpcyB0aGlzIG5vdCBwcmVzZXJ2ZWQ/IFN0YXRlIGNoYW5nZXM8YnI+DQombmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZW1zZWx2ZXMgaGFwcGVuIGFzIHRoZXkgZG8g aW4gNTI0NWJpcy4gVHJpY2tsZSBvbmx5IGRlZmluZXMgd2hhdDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aGFwcGVucyB3aXRoIG5ld2x5IGFkZGVkIGNhbmRpZGF0 ZXMgYW5kIGZvciB0aGUgY2FzZSB5b3UgbWVudGlvbiB3ZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7aGF2ZSB0aGlzOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYXNlIDM6 IElmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBwYWlyIGluIHRoaXMgY29sdW1uIGFib3ZlIHRoZSBy b3cgb2Y8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg dGhlIG5ld2x5IGZvcm1lZCBwYWlyIHdob3NlIHN0YXRlIGlzIGVpdGhlciBTdWNjZWVkZWQgb3Ig RmFpbGVkLCBzZXQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgdGhlIHN0YXRlIHRvIFdhaXRpbmcgKGUuZy4sIHRoaXMgd291bGQgYmUgdGhlIGNhc2Ug aWYgdGhlIHBhaXIgaW48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgY29sdW1uIDUsIHJvdyAxIHN1Y2NlZWRlZCBhbmQgdHdvIG5ld2x5IGZvcm1lZCBw YWlycyB3ZXJlIHBsYWNlZCBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBjb2x1bW4gNSwgcm93cyAzIGFuZCA0KS48YnI+DQombmJzcDsgJm5ic3A7 ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1doaWNoIHRy YW5zbGF0ZXMgdG8gZXhhY3RseSB3aGF0IHlvdSBoYXZlIGluIHRoZSBxdW90ZXMgYWJvdmUuPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDtXaGF0J3MgYm90aGVyaW5nIHlvdSBhYm91dCBpdD88YnI+DQombmJzcDsgJm5ic3A7 ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSSB0 aGluayB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlLCBqdXN0IG1pcy1jb21tdW5pY2F0aW5nLiBNeSBl bWFpbCBxdW90ZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgYXQgdGhlIHN0YXJ0IG9mIHRoaXMg dGhyZWFkIHdhcyB0YWxraW5nIGFib3V0IHZlcnNpb24gMDg7IHRoZSBwcm9ibGVtIGlzPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IGZpeGVkIGluIHZlcnNpb24gMDkuIFRoZSBvbmx5IHRoaW5nIHRo YXQgY29uY2VybnMgbWUgYWJvdXQgdmVyc2lvbiAwOSBpczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyB0aGUgJnF1b3Q7b3IgRmFpbGVkJnF1b3Q7IHBhcnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsg KHNlZTogPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pY2Uv Nm9EZjZ5TmFuQ2dqajF5SFhFM2lkbG1vYnlBIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ljZS82b0RmNnlOYW5DZ2pqMXlIWEUzaWRsbW9i eUE8L2E+ICZsdDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2ljZS82b0RmNnlOYW5DZ2pqMXlIWEUzaWRsbW9ieUEiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ljZS82b0RmNnlOYW5DZ2pqMXlIWEUzaWRs bW9ieUE8L2E+Jmd0OykuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBFbWlsIHBvc3RlZCBpbiB0 aGlzIHRocmVhZCBhYm91dCB0aGF0IHllc3RlcmRheS4gSGlzIGV4cGxhbmF0aW9uIHdhczo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgZmFjdCB0aGF0IHRoZSBzdGF0 ZSBoYXMgbW92ZWQgdG8gRmFpbGVkIGlzIGluZGljYXRpb24gdGhhdDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2Vub3VnaCB0aW1lIGhhcyBiZWVuIHNwZW50IHdhaXRpbmcgb24gdGhp cywgc28gdW5mcmVlemluZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb2xs b3dpbmcgcGFpcnMgZm9yIHRoYXQgZm91bmRhdGlvbiBpc24ndCBnb2luZyB0byBwZW5hbGl6ZSBJ Q0U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwcm9jZXNzaW5nIGFzIGEgd2hvbGUu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBEb2VzIHRoYXQgcmluZyB0cnVlIHRvIHlvdSwgYW5k IGlmIHNvIGRvIHlvdSB0aGluayB3ZSBuZWVkIHRvIGFkZDxicj4NCiZuYnNwOyAmbmJzcDsgZXhw bGFuYXRvcnkgdGV4dCB0byB0aGF0IGVmZmVjdD88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFBl dGVyPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9 ImhvZW56YiI+LS0gPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPjxhIGhyZWY9Imh0 dHBzOi8vaml0c2kub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaXRzaS5vcmc8L2E+PC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB93375ESESSMB109erics_-- From nobody Thu May 4 12:00: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 C437F12EAE0 for ; Thu, 4 May 2017 12:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i99ucMKvHTAB for ; Thu, 4 May 2017 12:00:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9B7129B44 for ; Thu, 4 May 2017 12:00:17 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m123so4076536wma.0 for ; Thu, 04 May 2017 12:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VyubkBm75RdMeIcohWIT34BpfPdC+F4djcK2r3AJCww=; b=Jhv0Vgv2DqC2bmX4s1+hXx6GKz2fqj0HeylVyeFqM5rx2dJ9OqbTzou4KO0nV/pck5 B1qt+BhZTRh5+hlI6t+k/LNvtl4VA8zjlz/sAxOe+rsWOtmt6n+rVhcP4x5PyYDsUwzt HAghIZ/ZWim7TTHwcfKQ0JoNzAhMoufSHBgbqQWDhI/XTyf9Dbm1HZHLu7pBxVocKzMs soLBDaD/+Yfc9wqcguF/ZPUmtCwD6rSulI0ZROfENQyWYewk7SanQrRBIdX7TYAzMYij 6icsypwvcLRjegI9cBhFFseutw+5fCf1nrqCoOO3R0k5nIvRcXCwrTwrIrPxo0npC3FQ hOBA== 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=VyubkBm75RdMeIcohWIT34BpfPdC+F4djcK2r3AJCww=; b=foOgtggR62c9TXRMufso9iYp4qMF35hRm9ZsWgHiaBY1i351/6m7wEcGdHtwzYuiXx NdTdK/WQ0OYcS0L6W+/DkKJOTJZT8EUstrrxnYmCnt9DAprvbPahabQulm4Xn1lZBTeL SfkTZWo7IvjnIrEICigLAppCAS6EWbr9+jm8Fi5bXv/BpaURHTZ7mZepqx2r7mdnf1/x V9l+hcuAsZIT5FaEMC8E/H3+Bx0o2ZrXzpVd94PeuKqQPQYTIuJ7uwTaxCgcaq3KWNEX 2tzrAyQvHt77fMPzd6Fw4fRaBCwB9q9/eIkUfN/2nG5mpfloSb9HOn8W+gi7/lkbc5oU N/7A== X-Gm-Message-State: AN3rC/7X4UfD9YCDCOJZv7ebZeHtlXJCg+JLGNXzlGMr+xyiE1bN9WAR noUeFewMASOPPbXc+s5/mY2YFyXb1hZk X-Received: by 10.80.140.164 with SMTP id q33mr24470658edq.77.1493924416296; Thu, 04 May 2017 12:00:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.177.52 with HTTP; Thu, 4 May 2017 11:59:55 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> From: Emil Ivov Date: Thu, 4 May 2017 13:59:55 -0500 Message-ID: To: Christer Holmberg Cc: Taylor Brandstetter , Peter Saint-Andre , "ice@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 19:00:26 -0000 In all fairness I find that text rather hard to follow. It's definitely clearer in 5245. I am curious what the reason for changing it was? And to answer your question: yes, performing multiple transactions at the same time directly breaks pacing. Emil On Thu, May 4, 2017 at 1:40 PM, Christer Holmberg wrote: > Hi, > > > > Related to the text below, note that it may actually trigger multiple checks > simultaneously (normally only a single check is triggered whenever Ta > fires). Are we ok with that? If not, I guess we would have to select the > pair with the highest priority. > > > > Regards, > > > > Christer > > > > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Taylor Brandstetter > Sent: 04 May 2017 18:18 > To: Emil Ivov > Cc: Peter Saint-Andre ; ice@ietf.org > Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of > draft-ietf-ice-trickle-08.txt) > > > > We could optimize for this by adding a second go at the end where all the > failed foundations are given another attempt. > > > > This already happens with ICEbis, though: > > > > Whenever Ta fires, the agent will perform a check for a candidate > > pair within the selected CHECK LIST as follows: ... > > > > o If there is no candidate pair in the Waiting state, and if there > > are one or more pairs in the Frozen state, for each pair in the > Frozen state the the agent checks the foundation associated with > the pair. For a given foundation, if there is no pair (in any > CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress > state, the agent performs a connectivity check on the pair and > puts the pair state to In-Prograss. > > > > That's why I don't see the need for trickle ICE to do anything special with > Failed candidate pairs. It's already guaranteed that failed foundations will > be tried eventually, so what's gained by unfreezing these pairs earlier? > > > > > > > > On Thu, May 4, 2017 at 8:40 AM, Emil Ivov wrote: > > > > On 5/4/17 9:00 AM, Taylor Brandstetter wrote: > > That's not always necessarily true, since the state may go to Failed due > to reasons other than a timeout. > > > Yes, indeed. That could happen and the reason would be something like a > transport error or an ICMP port unreachable. We could optimize for this by > adding a second go at the end where all the failed foundations are given > another attempt. > > This wouldn't be trivial to write up and I am reluctant to do it because: > > 1. it adds complexity to both the specification and implementations for low > value: you only save one time slot per pair. You don't even have to worry > about retransmissions. > 2. the timeout case is arguably significantly more common > > One alternative that I would find acceptable is to simply scratch the entire > foundation if the first pair there fails. I think that would work fine and > it would be simple to write up but I know people on this list feel strongly > about trying every pair and I get that point of view too. > > It would be unfortunate if this rule > resulted in more time slots given to a foundation that doesn't work, and > less to a foundation that does. > > > I don't believe this statement is accurate. You may end up giving slots in > the wrong order but I don't see how you could give more to the non-working > and less to the working. > > Emil > > It also seems odd that there's no > equivalent condition in ICEbis; every other condition has a parallel of > some sort. > > > > > On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre > wrote: > > On 5/3/17 10:45 AM, Taylor Brandstetter wrote: > > I am not sure I follow. Why is this not preserved? State changes > > themselves happen as they do in 5245bis. Trickle only defines what > > happens with newly added candidates and for the case you mention > we > > have this: > > > > 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). > > > > Which translates to exactly what you have in the quotes above. > > > > What's bothering you about it? > > > > > > I think we're on the same page, just mis-communicating. My email > quoted > > at the start of this thread was talking about version 08; the problem > is > > fixed in version 09. The only thing that concerns me about version 09 > is > > the "or Failed" part > > (see: > https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA > ). > > Emil posted in this thread about that yesterday. His explanation was: > > The fact that the state has moved to Failed is indication that > enough time has been spent waiting on this, so unfreezing the > following pairs for that foundation isn't going to penalize ICE > processing as a whole. > > Does that ring true to you, and if so do you think we need to add > explanatory text to that effect? > > Peter > > > -- > https://jitsi.org > > -- https://jitsi.org From nobody Thu May 4 12:19:49 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 E8CE112869B for ; Thu, 4 May 2017 12:19:47 -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 lXNikax8EmRk for ; Thu, 4 May 2017 12:19:45 -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 6F6DD12946B for ; Thu, 4 May 2017 12:19:45 -0700 (PDT) X-AuditID: c1b4fb25-08bff70000006049-6f-590b7ecc144f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9C.DF.24649.CCE7B095; Thu, 4 May 2017 21:19:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Thu, 4 May 2017 21:19:40 +0200 From: Christer Holmberg To: Emil Ivov CC: Taylor Brandstetter , Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt) Thread-Index: AQHSw44yG+8l/JxG+UWcffU9JI4fXaHhs50AgAAA74CAAATFgIAAAP4AgAAyNoCAAL/dgIAABFoAgACc0ICAAMdwAIAAG/YAgAAKWwCAAEgEgP//5UeAgAAkcrA= Date: Thu, 4 May 2017 19:19:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB9345B@ESESSMB109.ericsson.se> References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbFdQvd8HXekwe3pehaXVzxktVizcwKL xbcLtRbH9vQzO7B4LNhU6rFkyU8mj/9vAj3m7nnBHMASxWWTkpqTWZZapG+XwJWx/ucP9oIr jhU7ttxjbGD8Y9/FyMkhIWAise77MbYuRi4OIYEjjBKbn/xggXAWM0rMOT4fyOHgYBOwkOj+ pw3SICIgL9HdtogJxGYWKJP4u3YymC0skCDRfL6BHaImUWLVxUuMIHNEBLoYJT4v+gRWxCKg IvHv63ywIl4BX4mFLZfYIZbd5pC4tqAPrIhTIFBi7avVzCA2o4CYxPdTa6C2iUvcejKfCeJs AYkle84zQ9iiEi8f/2OFsJUkFt3+zARyNLOApsT6XfoQrYoSU7ofQu0VlDg58wnLBEbRWUim zkLomIWkYxaSjgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPp4JbfqjsYL79xPMQo wMGoxMOrkMMdKcSaWFZcmXuIUYKDWUmE1zYbKMSbklhZlVqUH19UmpNafIhRmoNFSZzXcd+F CCGB9MSS1OzU1ILUIpgsEwenVANj4vRABtfYfcqiP66FvVx9+PKtlIAPs4JbZgXMTc1Z+u+0 0Ntz6Zd/XPwYxbb0jOfUJNV3tg0bJRq1mV13xjuXPZrlzVi8/e/LO/c2rqp85GX14Hhq5u/f 65KfZCjm/p5cPMeteW6OzZ/E4qOXfj04vqKnIGvjh0sLCm856x6Yvet49q5V62ad1lJiKc5I NNRiLipOBAC8LodpoAIAAA== Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Thu, 04 May 2017 19:19:48 -0000 SGksDQoNCj5JbiBhbGwgZmFpcm5lc3MgSSBmaW5kIHRoYXQgdGV4dCByYXRoZXIgaGFyZCB0byBm b2xsb3cuIA0KDQpXZWxsLCB3aGVuZXZlciBJIHN1Z2dlc3RlZCBuZXcgdGV4dCBJIHByZXNlbnRl ZCBpdCB0byB0aGUgbGlzdC4gTm9ib2R5IHNhaWQgYW55dGhpbmcuLi4NCg0KPkl0J3MgZGVmaW5p dGVseSBjbGVhcmVyIGluIDUyNDUuIEkgYW0gY3VyaW91cyB3aGF0IHRoZSByZWFzb24gZm9yIGNo YW5naW5nIGl0IHdhcz8NCg0KSXQncyBhbGwgbW9yZSBvciBsZXNzIGEgc2lkZSBlZmZlY3Qgb2Yg dGhlIGFkZGl0aW9uIG9mICJFbWlsJ3MgbGlzdCIgOikgDQoNCkhvd2V2ZXIsIEkgcGVyc29uYWxs eSB0aGluayB0aGF0IHRoZSBwcm9jZWR1cmVzIGFyZSBlYXNpZXIgdG8gdW5kZXJzdGFuZCBub3cu DQoNCj5BbmQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb246IHllcywgcGVyZm9ybWluZyBtdWx0aXBs ZSB0cmFuc2FjdGlvbnMgYXQgdGhlIHNhbWUgdGltZSA+ZGlyZWN0bHkgYnJlYWtzIHBhY2luZy4N Cg0KU28sIHBlcmhhcHMgd2UgbmVlZCB0byBmaXggdGhhdC4gDQoNCkFsc28sIHRoZSBjYXNlIHNo b3VsZCBvbmx5IG9jY3VyIChhdCBsZWFzdCB3aXRob3V0IHRyaWNrbGUpIHdoZW4gYSBwcmV2aW91 cyBjaGVjayBmb3IgdGhlIHNhbWUgZm91bmRhdGlvbihzKSBoYXZlIGZhaWxlZC4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQpPbiBUaHUsIE1heSA0LCAyMDE3IGF0IDE6NDAgUE0sIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBI aSwNCj4NCj4NCj4NCj4gUmVsYXRlZCB0byB0aGUgdGV4dCBiZWxvdywgbm90ZSB0aGF0IGl0IG1h eSBhY3R1YWxseSB0cmlnZ2VyIG11bHRpcGxlIA0KPiBjaGVja3Mgc2ltdWx0YW5lb3VzbHkgKG5v cm1hbGx5IG9ubHkgYSBzaW5nbGUgY2hlY2sgaXMgdHJpZ2dlcmVkIA0KPiB3aGVuZXZlciBUYSBm aXJlcykuIEFyZSB3ZSBvayB3aXRoIHRoYXQ/IElmIG5vdCwgSSBndWVzcyB3ZSB3b3VsZCBoYXZl IA0KPiB0byBzZWxlY3QgdGhlIHBhaXIgd2l0aCB0aGUgaGlnaGVzdCBwcmlvcml0eS4NCj4NCj4N Cj4NCj4gUmVnYXJkcywNCj4NCj4NCj4NCj4gQ2hyaXN0ZXINCj4NCj4NCj4NCj4gRnJvbTogSWNl IFttYWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUYXlsb3IgDQo+IEJy YW5kc3RldHRlcg0KPiBTZW50OiAwNCBNYXkgMjAxNyAxODoxOA0KPiBUbzogRW1pbCBJdm92IDxl bWNob0BqaXRzaS5vcmc+DQo+IENjOiBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVy LmltPjsgaWNlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWNlXSBob2xlcyBpbiB0aGUgbWF0 cml4IChXYXM6IFRheWxvcidzIHJldmlldyBvZg0KPiBkcmFmdC1pZXRmLWljZS10cmlja2xlLTA4 LnR4dCkNCj4NCj4NCj4NCj4gV2UgY291bGQgb3B0aW1pemUgZm9yIHRoaXMgYnkgYWRkaW5nIGEg c2Vjb25kIGdvIGF0IHRoZSBlbmQgd2hlcmUgYWxsIA0KPiB0aGUgZmFpbGVkIGZvdW5kYXRpb25z IGFyZSBnaXZlbiBhbm90aGVyIGF0dGVtcHQuDQo+DQo+DQo+DQo+IFRoaXMgYWxyZWFkeSBoYXBw ZW5zIHdpdGggSUNFYmlzLCB0aG91Z2g6DQo+DQo+DQo+DQo+ICAgIFdoZW5ldmVyIFRhIGZpcmVz LCB0aGUgYWdlbnQgd2lsbCBwZXJmb3JtIGEgY2hlY2sgZm9yIGEgY2FuZGlkYXRlDQo+DQo+ICAg IHBhaXIgd2l0aGluIHRoZSBzZWxlY3RlZCBDSEVDSyBMSVNUIGFzIGZvbGxvd3M6IC4uLg0KPg0K Pg0KPg0KPiAgICBvICBJZiB0aGVyZSBpcyBubyBjYW5kaWRhdGUgcGFpciBpbiB0aGUgV2FpdGlu ZyBzdGF0ZSwgYW5kIGlmIHRoZXJlDQo+DQo+ICAgICAgIGFyZSBvbmUgb3IgbW9yZSBwYWlycyBp biB0aGUgRnJvemVuIHN0YXRlLCBmb3IgZWFjaCBwYWlyIGluIHRoZQ0KPiAgICAgICBGcm96ZW4g c3RhdGUgdGhlIHRoZSBhZ2VudCBjaGVja3MgdGhlIGZvdW5kYXRpb24gYXNzb2NpYXRlZCB3aXRo DQo+ICAgICAgIHRoZSBwYWlyLiAgRm9yIGEgZ2l2ZW4gZm91bmRhdGlvbiwgaWYgdGhlcmUgaXMg bm8gcGFpciAoaW4gYW55DQo+ICAgICAgIENIRUNLIExJU1QgaW4gdGhlIENIRUNLIExJU1QgU0VU KSBpbiB0aGUgV2FpdGluZyBvciBJbi1Qcm9ncmVzcw0KPiAgICAgICBzdGF0ZSwgdGhlIGFnZW50 IHBlcmZvcm1zIGEgY29ubmVjdGl2aXR5IGNoZWNrIG9uIHRoZSBwYWlyIGFuZA0KPiAgICAgICBw dXRzIHRoZSBwYWlyIHN0YXRlIHRvIEluLVByb2dyYXNzLg0KPg0KPg0KPg0KPiBUaGF0J3Mgd2h5 IEkgZG9uJ3Qgc2VlIHRoZSBuZWVkIGZvciB0cmlja2xlIElDRSB0byBkbyBhbnl0aGluZyBzcGVj aWFsIA0KPiB3aXRoIEZhaWxlZCBjYW5kaWRhdGUgcGFpcnMuIEl0J3MgYWxyZWFkeSBndWFyYW50 ZWVkIHRoYXQgZmFpbGVkIA0KPiBmb3VuZGF0aW9ucyB3aWxsIGJlIHRyaWVkIGV2ZW50dWFsbHks IHNvIHdoYXQncyBnYWluZWQgYnkgdW5mcmVlemluZyB0aGVzZSBwYWlycyBlYXJsaWVyPw0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPiBPbiBUaHUsIE1heSA0LCAyMDE3IGF0IDg6NDAgQU0sIEVtaWwg SXZvdiA8ZW1jaG9Aaml0c2kub3JnPiB3cm90ZToNCj4NCj4NCj4NCj4gT24gNS80LzE3IDk6MDAg QU0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgd3JvdGU6DQo+DQo+IFRoYXQncyBub3QgYWx3YXlzIG5l Y2Vzc2FyaWx5IHRydWUsIHNpbmNlIHRoZSBzdGF0ZSBtYXkgZ28gdG8gRmFpbGVkIA0KPiBkdWUg dG8gcmVhc29ucyBvdGhlciB0aGFuIGEgdGltZW91dC4NCj4NCj4NCj4gWWVzLCBpbmRlZWQuIFRo YXQgY291bGQgaGFwcGVuIGFuZCB0aGUgcmVhc29uIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlIA0K PiBhIHRyYW5zcG9ydCBlcnJvciBvciBhbiBJQ01QIHBvcnQgdW5yZWFjaGFibGUuIFdlIGNvdWxk IG9wdGltaXplIGZvciANCj4gdGhpcyBieSBhZGRpbmcgYSBzZWNvbmQgZ28gYXQgdGhlIGVuZCB3 aGVyZSBhbGwgdGhlIGZhaWxlZCBmb3VuZGF0aW9ucyANCj4gYXJlIGdpdmVuIGFub3RoZXIgYXR0 ZW1wdC4NCj4NCj4gVGhpcyB3b3VsZG4ndCBiZSB0cml2aWFsIHRvIHdyaXRlIHVwIGFuZCBJIGFt IHJlbHVjdGFudCB0byBkbyBpdCBiZWNhdXNlOg0KPg0KPiAxLiBpdCBhZGRzIGNvbXBsZXhpdHkg dG8gYm90aCB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgaW1wbGVtZW50YXRpb25zIA0KPiBmb3IgbG93 DQo+IHZhbHVlOiB5b3Ugb25seSBzYXZlIG9uZSB0aW1lIHNsb3QgcGVyIHBhaXIuIFlvdSBkb24n dCBldmVuIGhhdmUgdG8gDQo+IHdvcnJ5IGFib3V0IHJldHJhbnNtaXNzaW9ucy4NCj4gMi4gdGhl IHRpbWVvdXQgY2FzZSBpcyBhcmd1YWJseSBzaWduaWZpY2FudGx5IG1vcmUgY29tbW9uDQo+DQo+ IE9uZSBhbHRlcm5hdGl2ZSB0aGF0IEkgd291bGQgZmluZCBhY2NlcHRhYmxlIGlzIHRvIHNpbXBs eSBzY3JhdGNoIHRoZSANCj4gZW50aXJlIGZvdW5kYXRpb24gaWYgdGhlIGZpcnN0IHBhaXIgdGhl cmUgZmFpbHMuIEkgdGhpbmsgdGhhdCB3b3VsZCANCj4gd29yayBmaW5lIGFuZCBpdCB3b3VsZCBi ZSBzaW1wbGUgdG8gd3JpdGUgdXAgYnV0IEkga25vdyBwZW9wbGUgb24gdGhpcyANCj4gbGlzdCBm ZWVsIHN0cm9uZ2x5IGFib3V0IHRyeWluZyBldmVyeSBwYWlyIGFuZCBJIGdldCB0aGF0IHBvaW50 IG9mIHZpZXcgdG9vLg0KPg0KPiBJdCB3b3VsZCBiZSB1bmZvcnR1bmF0ZSBpZiB0aGlzIHJ1bGUN Cj4gcmVzdWx0ZWQgaW4gbW9yZSB0aW1lIHNsb3RzIGdpdmVuIHRvIGEgZm91bmRhdGlvbiB0aGF0 IGRvZXNuJ3Qgd29yaywgDQo+IGFuZCBsZXNzIHRvIGEgZm91bmRhdGlvbiB0aGF0IGRvZXMuDQo+ DQo+DQo+IEkgZG9uJ3QgYmVsaWV2ZSB0aGlzIHN0YXRlbWVudCBpcyBhY2N1cmF0ZS4gWW91IG1h eSBlbmQgdXAgZ2l2aW5nIA0KPiBzbG90cyBpbiB0aGUgd3Jvbmcgb3JkZXIgYnV0IEkgZG9uJ3Qg c2VlIGhvdyB5b3UgY291bGQgZ2l2ZSBtb3JlIHRvIA0KPiB0aGUgbm9uLXdvcmtpbmcgYW5kIGxl c3MgdG8gdGhlIHdvcmtpbmcuDQo+DQo+IEVtaWwNCj4NCj4gSXQgYWxzbyBzZWVtcyBvZGQgdGhh dCB0aGVyZSdzIG5vDQo+IGVxdWl2YWxlbnQgY29uZGl0aW9uIGluIElDRWJpczsgZXZlcnkgb3Ro ZXIgY29uZGl0aW9uIGhhcyBhIHBhcmFsbGVsIA0KPiBvZiBzb21lIHNvcnQuDQo+DQo+DQo+DQo+ DQo+IE9uIFdlZCwgTWF5IDMsIDIwMTcgYXQgNzowNiBQTSwgUGV0ZXIgU2FpbnQtQW5kcmUgPHN0 cGV0ZXJAc3RwZXRlci5pbSANCj4gPG1haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW0+PiB3cm90ZToN Cj4NCj4gICAgIE9uIDUvMy8xNyAxMDo0NSBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZToN Cj4gICAgID4gICAgIEkgYW0gbm90IHN1cmUgSSBmb2xsb3cuIFdoeSBpcyB0aGlzIG5vdCBwcmVz ZXJ2ZWQ/IFN0YXRlIGNoYW5nZXMNCj4gICAgID4gICAgIHRoZW1zZWx2ZXMgaGFwcGVuIGFzIHRo ZXkgZG8gaW4gNTI0NWJpcy4gVHJpY2tsZSBvbmx5IGRlZmluZXMgd2hhdA0KPiAgICAgPiAgICAg aGFwcGVucyB3aXRoIG5ld2x5IGFkZGVkIGNhbmRpZGF0ZXMgYW5kIGZvciB0aGUgY2FzZSB5b3Ug bWVudGlvbg0KPiB3ZQ0KPiAgICAgPiAgICAgaGF2ZSB0aGlzOg0KPiAgICAgPg0KPiAgICAgPiAg ICAgICAgQ2FzZSAzOiBJZiB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgcGFpciBpbiB0aGlzIGNvbHVt biBhYm92ZSB0aGUNCj4gcm93IG9mDQo+ICAgICA+ICAgICAgICB0aGUgbmV3bHkgZm9ybWVkIHBh aXIgd2hvc2Ugc3RhdGUgaXMgZWl0aGVyIFN1Y2NlZWRlZCBvcg0KPiBGYWlsZWQsIHNldA0KPiAg ICAgPiAgICAgICAgdGhlIHN0YXRlIHRvIFdhaXRpbmcgKGUuZy4sIHRoaXMgd291bGQgYmUgdGhl IGNhc2UgaWYgdGhlIHBhaXINCj4gaW4NCj4gICAgID4gICAgICAgIGNvbHVtbiA1LCByb3cgMSBz dWNjZWVkZWQgYW5kIHR3byBuZXdseSBmb3JtZWQgcGFpcnMgd2VyZQ0KPiBwbGFjZWQgaW4NCj4g ICAgID4gICAgICAgIGNvbHVtbiA1LCByb3dzIDMgYW5kIDQpLg0KPiAgICAgPg0KPiAgICAgPiAg ICAgV2hpY2ggdHJhbnNsYXRlcyB0byBleGFjdGx5IHdoYXQgeW91IGhhdmUgaW4gdGhlIHF1b3Rl cyBhYm92ZS4NCj4gICAgID4NCj4gICAgID4gICAgIFdoYXQncyBib3RoZXJpbmcgeW91IGFib3V0 IGl0Pw0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBJIHRoaW5rIHdlJ3JlIG9uIHRoZSBzYW1l IHBhZ2UsIGp1c3QgbWlzLWNvbW11bmljYXRpbmcuIE15IGVtYWlsIA0KPiBxdW90ZWQNCj4gICAg ID4gYXQgdGhlIHN0YXJ0IG9mIHRoaXMgdGhyZWFkIHdhcyB0YWxraW5nIGFib3V0IHZlcnNpb24g MDg7IHRoZSANCj4gcHJvYmxlbSBpcw0KPiAgICAgPiBmaXhlZCBpbiB2ZXJzaW9uIDA5LiBUaGUg b25seSB0aGluZyB0aGF0IGNvbmNlcm5zIG1lIGFib3V0IA0KPiB2ZXJzaW9uIDA5IGlzDQo+ICAg ICA+IHRoZSAib3IgRmFpbGVkIiBwYXJ0DQo+ICAgICA+IChzZWU6DQo+IGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWNlLzZvRGY2eU5hbkNnamoxeUhYRTNpZGxtb2J5QQ0K PiA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pY2UvNm9EZjZ5TmFuQ2dq ajF5SFhFM2lkbG1vYnlBPikuDQo+DQo+ICAgICBFbWlsIHBvc3RlZCBpbiB0aGlzIHRocmVhZCBh Ym91dCB0aGF0IHllc3RlcmRheS4gSGlzIGV4cGxhbmF0aW9uIHdhczoNCj4NCj4gICAgICAgIFRo ZSBmYWN0IHRoYXQgdGhlIHN0YXRlIGhhcyBtb3ZlZCB0byBGYWlsZWQgaXMgaW5kaWNhdGlvbiB0 aGF0DQo+ICAgICAgICBlbm91Z2ggdGltZSBoYXMgYmVlbiBzcGVudCB3YWl0aW5nIG9uIHRoaXMs IHNvIHVuZnJlZXppbmcgdGhlDQo+ICAgICAgICBmb2xsb3dpbmcgcGFpcnMgZm9yIHRoYXQgZm91 bmRhdGlvbiBpc24ndCBnb2luZyB0byBwZW5hbGl6ZSBJQ0UNCj4gICAgICAgIHByb2Nlc3Npbmcg YXMgYSB3aG9sZS4NCj4NCj4gICAgIERvZXMgdGhhdCByaW5nIHRydWUgdG8geW91LCBhbmQgaWYg c28gZG8geW91IHRoaW5rIHdlIG5lZWQgdG8gYWRkDQo+ICAgICBleHBsYW5hdG9yeSB0ZXh0IHRv IHRoYXQgZWZmZWN0Pw0KPg0KPiAgICAgUGV0ZXINCj4NCj4NCj4gLS0NCj4gaHR0cHM6Ly9qaXRz aS5vcmcNCj4NCj4NCg0KDQoNCi0tDQpodHRwczovL2ppdHNpLm9yZw0K From nobody Thu May 4 18:57:37 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 8290D129353 for ; Thu, 4 May 2017 18:57:35 -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=VXPyBjfV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dqu1wp/F 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 Ni_Y-MSnrBNd for ; Thu, 4 May 2017 18:57:34 -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 E0E45128D6F for ; Thu, 4 May 2017 18:57:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3267A20B5B; Thu, 4 May 2017 21:57:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 04 May 2017 21:57:31 -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=rVBAxe5JXhRz8RDH/5 WWFGeHLH9fILaFZmPAc4zC6mc=; b=VXPyBjfVvakLU/TVMNlqNEzmjEAgVPP2vd 8aZ4I02fb+ZXgBl287y0KmJzi/h/dTNwyoa49qDcb7fYJcOzUmli89B7YqKPeQ0G qXC0vHNpAYsrsUwkA24ZeKD2rbC2kmRpZ5o9zVw3QKnAk+FEVVF7RWDylOV+i25k gAjCElTvFGjuy58Wt8hCoBw3peGWpTejWk3xzLtm6rWUyP9cIszR0iAJiYdo73tk FzDZzMyeutVWQDqFSK0BcRMOho+Vxq1h56AQdAq/4ZXSGPWi1HavByWZ2wZYjSjd 2KNs71LH8TjaJxmqy//zzF7Ss7bAzaB5GE7lTsB6w6zaFzUeAckg== 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=rVBAxe5JXhRz8RDH/5WWFGeHLH9fILaFZmPAc4zC6mc=; b=Dqu1wp/F ORAX1Hfs3RFza67rTfar/RqLSAughnioxSjnCU0lpT00DlU0DeyAKltHs6HcEbjn zlV2viNjqPhdHENOODmX7X9BlS6fc/3PcGMknAAbDdNEW/cpM5w/lh4Xj8D4NpAJ 8FXiWBVKCxQFsboSgYlzcUDm93rwGnuXGORCMqcrYUEIULDrn2XD7mXoKTGDxRsQ JV6smFmZM211rFokrHV9DbePEZ8IKbjl5UyyexW+w59asqmL8KVJeOqifyRrpmbO jAccjR5PvonDfRAkF3yQyj17+NOsNDPkx4q0uS10TyD8QlWr7FEvrZNA9mloSgFW GOTYPNxfrN72Rg== X-ME-Sender: X-Sasl-enc: 0981UDWmDMXe0O3PnFwfGxOgEL/FNZD+FTAhulRPjHFi 1493949450 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9AE5F2436D; Thu, 4 May 2017 21:57:30 -0400 (EDT) To: Emil Ivov , Taylor Brandstetter References: <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <66f7502d-ca3c-be46-6e38-2e33af55811c@stpeter.im> Date: Thu, 4 May 2017 19:57:28 -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] holes in the matrix (Was: 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: Fri, 05 May 2017 01:57:35 -0000 On 5/4/17 10:30 AM, Emil Ivov wrote: > On Thu, May 4, 2017 at 11:28 AM, Emil Ivov wrote: >> On Thu, May 4, 2017 at 11:17 AM, Taylor Brandstetter >> wrote: >>>> We could optimize for this by adding a second go at the end where all the >>>> failed foundations are given another attempt. >>> >>> >>> This already happens with ICEbis, though: >>> >>>> Whenever Ta fires, the agent will perform a check for a candidate >>>> >>>> pair within the selected CHECK LIST as follows: ... >>>> >>>> >>>> >>>> o If there is no candidate pair in the Waiting state, and if there >>>> >>>> are one or more pairs in the Frozen state, for each pair in the >>>> Frozen state the the agent checks the foundation associated with >>>> the pair. For a given foundation, if there is no pair (in any >>>> CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress >>>> state, the agent performs a connectivity check on the pair and >>>> puts the pair state to In-Prograss. >>> >>> >>> That's why I don't see the need for trickle ICE to do anything special with >>> Failed candidate pairs. It's already guaranteed that failed foundations will >>> be tried eventually, so what's gained by unfreezing these pairs earlier? >> >> I was actually just rereading the same part. >> >> I think you've won me over. I'll remove this in a minute. > > Done. Co-author +1 :-) Peter From nobody Tue May 9 10:11:39 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 5305612932A; Tue, 9 May 2017 10:11:37 -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: <149434989730.30014.15887010702179980747@ietfa.amsl.com> Date: Tue, 09 May 2017 10:11:37 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-10.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: Tue, 09 May 2017 17:11:37 -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-10.txt Pages : 32 Date : 2017-05-09 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 9 10:14:22 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 DB57A1294E7 for ; Tue, 9 May 2017 10:14:01 -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=XLYRpq2i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gKgd+29C 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 pC4Mwz0Lt3uW for ; Tue, 9 May 2017 10:14:00 -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 B1E6112940E for ; Tue, 9 May 2017 10:13:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2135E206E5; Tue, 9 May 2017 13:13:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 09 May 2017 13:13:59 -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=jmmHfDhvYTNYp1ddRD eFopc/X2F4s2z65yvGxsD9WPQ=; b=XLYRpq2i0fWxTNV3UgnxxAOY91Gn1vIkGK EtXsYLneXwLdYE7vVZX0oxB9LNb6oNmPz0+kzzJV2AhplPMIOCCPDnsk7B3ZcYss D3NbCtp2x42HQSoAtA9N7A7jh3cFIPL++U8XPQjEoR5c0m/6r3hGtv5MXNOVojQU 7BvxbK4WpPcfho25Gs/c+eBp922Y2tttu2GTIaDmaOk1LUyp4JD8wmDDILfqaSus aO9m6yfXid28p7TuuAn41IwHQEyi7OvxykmrA9zR93WblFvB5puyc7R/EN7fMM+X 9s9CaNF6DXeHB2M8qkUm64mTfSJtJMutLZJnbfUeRXNxqkdNaGMw== 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=jmmHfDhvYTNYp1ddRDeFopc/X2F4s2z65yvGxsD9WPQ=; b=gKgd+29C yqsBlD9i85WX0tZVQkMTU3Pt05oikj+w7wmH92+PmF4kh38numZX8rGigkP+QsCH P9DGzCWBOTuqJzbNjLRqELb2g9bE3ogW2J0TGqL6G+b/luyacAn6OWe/RMdAXHUW p2wpfF6m+HwnqcBY85tyMmYARFuM9YnEwovlgEFizQVB5AR6wlJASiqxHkTodwBR RkWivb4IosefH9/BiAmK65NPbrXsDX4/vIvy80DD7s5NXZNHd5g+NVGCuCehjLQ4 0uxJ6xpRqnQXIEwn6Uh/q54FJn8heJIjKvx0FONA47lXyQsq5ePiUFeIVy42LW1z eh+wNOUxG1doUw== X-ME-Sender: X-Sasl-enc: fHiMf1PZFnpP2sCjSoMpTbs2T4zoTP7RsJobbdQ3z1ma 1494350038 Received: from iphone.reunionmetro.org (unknown [65.101.226.12]) by mail.messagingengine.com (Postfix) with ESMTPA id A35157E887; Tue, 9 May 2017 13:13:58 -0400 (EDT) References: <149434989730.30014.15887010702179980747@ietfa.amsl.com> To: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> Date: Tue, 9 May 2017 11:13:57 -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: <149434989730.30014.15887010702179980747@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-10.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, 09 May 2017 17:14:02 -0000 Some adjustments to reflect recent list discussion. This should be ready for working group last call! Peter On 5/9/17 11:11 AM, internet-drafts@ietf.org wrote: > > 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-10.txt > Pages : 32 > Date : 2017-05-09 > > 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-10 > https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-10 > > > 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/ > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Fri May 12 13:12: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 EBD3D1270FC for ; Fri, 12 May 2017 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-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 PGc9e4iaTbxv for ; Fri, 12 May 2017 13:12:33 -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 B3483129464 for ; Fri, 12 May 2017 13:08:01 -0700 (PDT) X-AuditID: c1b4fb2d-eff839a00000196b-fe-5916161fd915 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.07.06507.F1616195; Fri, 12 May 2017 22:07:59 +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, 12 May 2017 22:07:56 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] I-D Action: draft-ietf-ice-trickle-10.txt Thread-Index: AQHSyOdUU+i1FPPivkG5V67B/XaSmqHsG/OAgATnmYA= Date: Fri, 12 May 2017 20:07:55 +0000 Message-ID: <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> References: <149434989730.30014.15887010702179980747@ietfa.amsl.com> <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> In-Reply-To: <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <046ADD5573AEB44A81067BBF57B1D75B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7rq68mFikwbNLlhbfLtRaHNvTz+zA 5LFkyU8mj7l7XjAHMEVx2aSk5mSWpRbp2yVwZWzbK1nQxF7xcmcLawPjPtYuRk4OCQETiX9/ zrF3MXJxCAkcYZToO3OXCcJZwijxo2kCWBWbgL3E5DUfGUFsEQEtiUvX+oA6ODiYBRQlXu5V AwkLC9hIrNr5ggWixFbi0NEvrBC2lcSU5i5mEJtFQFWi8XkDO4jNCzSy5+c+MFtIoELiyYun YPWcAnYS07Y3gM1hFBCT+H5qDROIzSwgLnHryXwmiKMFJJbsOc8MYYtKvHz8D+oZJYm1h7ez QNTrSdyYOoUNwraW+LTuBzuErS2xbOFrZogbBCVOznzCMoFRbBaSFbOQtM9C0j4LSfssJO0L GFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG1MEtv3V3MK5+7XiIUYCDUYmH98F+0Ugh 1sSy4srcQ4wSHMxKIry5LGKRQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5N LUgtgskycXBKNTAyT+Pqj8o6UcvV2nfRN885a8eWH7u/i7SfNWNrS6j3ETzBJDojqohDnzv/ +R+1P4Wmk+X13NdZl07bGl6xrFf+5q3iFvYEqxsMd/5FlZX7/W8yDHq186SZN/vZks1sntvb rzCdLjrS/P98kUj3j9sH73WH8C0Vauyu6uLe2n7uZWlEzMmYU0osxRmJhlrMRcWJAH+rabql AgAA Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-10.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: Fri, 12 May 2017 20:12:35 -0000 Thanks Peter! I reviewed the changes and they looked good to me. Below some editorial com= ments. Unfortunately some of the section numbers of ICE-bis have changed and this = document still refers to the old numbers. Here's what I spotted: Section 7.1: > The ICE specification [rfc5245bis], Section 5.1.5, requires that Now Section 5.1.4 Section 8.1.1: > When an agent commences ICE processing, in accordance with > Section 5.1.3.6 of [rfc5245bis]=20 I think you mean 5.1.2.6 ("Computing Candidate Pair States").=20 Also in: > Then, as the checks proceed (see Section 6.1.2.4.2.3 of [rfc5245bis]=20 Now Section 6.2.5.3.4.=20 Same issue in section 7.2. Section 12: > ICE processing described in Section 6.2 of [rfc5245bis], and Trickle Now Section 7. Finally, in Section 16: > c=3DIN IP4 2001:db8:a0b:12f0::1 s/IP4/IP6/ Cheers, Ari From nobody Fri May 12 13:16:05 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 D28501314A2 for ; Fri, 12 May 2017 13:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=XJLOwCWF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FZiEyZiL 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 t0cP1OZyN4Cd for ; Fri, 12 May 2017 13:16: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 D09941314FB for ; Fri, 12 May 2017 13:11:33 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id F039920BDC; Fri, 12 May 2017 16:11:32 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 12 May 2017 16:11:32 -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=FQJKksrjS1tyVQAzrw W7JORKjS2I4SjMx/fy3Ycrd6M=; b=XJLOwCWFVmHKe2I9DIq2lbodnSei89rq5o BmguPJZH32cPXvk/qGMWoKGkN4n8Zf0O5RkPFDvtXAQ6cfPMwX5bHikTbbSv2xdY L0q+MYpiZcVjk7XH+NUTDmq8m+cq7k1Q8zTaiJD2foeFnJDgMl1DRKZETyg6Iew3 p4aUTyPPEBO21iFOTY2NkS34UOCS/bdf8WQ5ST3TUK70H+eekT+zUagyrdPuvMw5 +DQAOIsn07eiwEDM2zPVE6ffIMxLdYpqrlFoDPhqZIfleMhQXOXd5XB1jgKIykKO ltqzHjslX/uibxBiAh4vWt7ir9nxi9ABbzWJ/B4v2zci0DyJh/QQ== 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=FQJKksrjS1tyVQAzrwW7JORKjS2I4SjMx/fy3Ycrd6M=; b=FZiEyZiL +bD0Yvu9dF8llaJO72OLFWPqTLdBs+MN/rLqaBKrnV10KqFh6ICsJzDZWNh6yBAH DBkrdbTjGgAOQgfguOuU/vGoitpQVGM2o+NzenxOxCIaW9G5pvYQt7tR6IkVcwjp Ca+HnLfTK6Tn1CyMYWlDfCJvWeToZLYPXGVs8CZcOE1vLTDN60sS79+eR4FZld/n 7rkKd1CYDnBPdAuZ8s28JiWuUVQZGKw/kNALwnuxgljzn1ofFMgfBnvk08sXgXYH QdrlXWn9LKb4ndGKBxcfe46MHuo/m6GsVcmLrk6/B4iFW7qpovXl3bVDSKEuVQEn XG1A3wIKd6fsMA== X-ME-Sender: X-Sasl-enc: pTQETy3q1UvtmmAjnXz9hEHjP4Ym+4JokIr09KXj9n0u 1494619892 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 80A2A7E5C8; Fri, 12 May 2017 16:11:32 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <149434989730.30014.15887010702179980747@ietfa.amsl.com> <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <7ee09acb-33e9-8a40-5329-32b24f8f7e26@stpeter.im> Date: Fri, 12 May 2017 14:11:31 -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: <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-10.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: Fri, 12 May 2017 20:16:04 -0000 On 5/12/17 2:07 PM, Ari Keränen wrote: > Thanks Peter! > > I reviewed the changes and they looked good to me. Below some editorial comments. Thanks, Ari, those are good catches. We'll double-check all cross-references and fix the things you've found. Shall we spin a -11 to address these? Also, do we foresee section numbers changing again in 5245bis? If so, it might make more sense to remove the specific references (although I think they're helpful because it can be difficult to find exact text in 5245bis without the section numbers). Peter > > Unfortunately some of the section numbers of ICE-bis have changed and this document still refers to the old numbers. Here's what I spotted: > > Section 7.1: >> The ICE specification [rfc5245bis], Section 5.1.5, requires that > > Now Section 5.1.4 > > Section 8.1.1: >> When an agent commences ICE processing, in accordance with >> Section 5.1.3.6 of [rfc5245bis] > > I think you mean 5.1.2.6 ("Computing Candidate Pair States"). > > Also in: >> Then, as the checks proceed (see Section 6.1.2.4.2.3 of [rfc5245bis] > > Now Section 6.2.5.3.4. > > Same issue in section 7.2. > > Section 12: >> ICE processing described in Section 6.2 of [rfc5245bis], and Trickle > > Now Section 7. > > Finally, in Section 16: >> c=IN IP4 2001:db8:a0b:12f0::1 > > s/IP4/IP6/ > > > Cheers, > Ari > From nobody Fri May 12 13:31:32 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 6C08412EB97 for ; Fri, 12 May 2017 13:31:30 -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 Fdde7U4985da for ; Fri, 12 May 2017 13:31:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97B013010C for ; Fri, 12 May 2017 13:27:31 -0700 (PDT) X-AuditID: c1b4fb30-29dff7000000015f-12-59161ab03929 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.E7.00351.0BA16195; Fri, 12 May 2017 22:27:30 +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; Fri, 12 May 2017 22:27:28 +0200 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] I-D Action: draft-ietf-ice-trickle-10.txt Thread-Index: AQHSyOdUU+i1FPPivkG5V67B/XaSmqHsG/OAgATnmYCAAAECgIAABHOA Date: Fri, 12 May 2017 20:27:27 +0000 Message-ID: <019E38A0-B530-4719-B3F3-6A4DD49B57ED@ericsson.com> References: <149434989730.30014.15887010702179980747@ietfa.amsl.com> <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> <7ee09acb-33e9-8a40-5329-32b24f8f7e26@stpeter.im> In-Reply-To: <7ee09acb-33e9-8a40-5329-32b24f8f7e26@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="Windows-1252" Content-ID: <154BE30365AC634FA7187B3AE3C08ECE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7uu4mKbFIg1m3JCy+Xai1OLann9mB yWPJkp9MHnP3vGAOYIrisklJzcksSy3St0vgytj1/hhzwQaBil9Xv7M0MDbxdjFyckgImEic 2LeNEcQWEjjCKPH/WyiEvYRRon8LD4jNJuAocerhWlYQW0RAS+LStT72LkYODmYBRYmXe9VA wsICNhKrdr5ggSixlTh09AtUuZvExEfH2UBsFgFVifVzPoPV8ArYS0y7exQozgW06hGjxJxf T5lBEpwCdhKNc6+DFTEKiEl8P7WGCcRmFhCXuPVkPhPEzQISS/acZ4awRSVePv7HCmErSTQu ecIKUW8g8f7cfGYI21ri196F7BC2tsSyha+ZIY4QlDg58wnLBEaxWUhWzELSPgtJ+ywk7bOQ tC9gZF3FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERhTB7f8NtjB+PK54yFGAQ5GJR7eB/tF I4VYE8uKK3MPMUpwMCuJ8DqJi0UK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1 OzW1ILUIJsvEwSnVwKhpeM9UrOPxk+7bc21fPOi77vH0zR+1WTeddFLmPOvQVNMNv3fSvnhy 9Ab+huMGT7cfW7Pv3NOAnnVvNY9MdJJojD4zZ2v1BdO4dZsWrg+7Mbf2qGaZhs/e9faX3tie FTpxcH2+W6g9l8iK2pjNF7xM2qWUExcczL1+0fTsq4OZSVv2rYryTL2oxFKckWioxVxUnAgA RXEL7qUCAAA= Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-10.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: Fri, 12 May 2017 20:31:30 -0000 > On 12 May 2017, at 23:11, Peter Saint-Andre wrote: >=20 > On 5/12/17 2:07 PM, Ari Ker=E4nen wrote: >> Thanks Peter! >>=20 >> I reviewed the changes and they looked good to me. Below some editorial = comments. >=20 > Thanks, Ari, those are good catches. We'll double-check all > cross-references and fix the things you've found. Shall we spin a -11 to > address these? Thanks! Peter Thatcher is also reviewing the doc to make sure we didn't mis= s anything. You may want to wait for his comments/OK, but either way is fin= e for me. > Also, do we foresee section numbers changing again in 5245bis? If so, it > might make more sense to remove the specific references (although I > think they're helpful because it can be difficult to find exact text in > 5245bis without the section numbers). They may change; but we'll try to avoid that. And I agree specific referenc= es are good. Luckily it's relatively easy to update them by comparing the s= ection numbers of the different versions wrt references in this draft. If y= ou don't mind doing that, please keep the specific ones. Cheers, Ari > Peter >=20 >>=20 >> Unfortunately some of the section numbers of ICE-bis have changed and th= is document still refers to the old numbers. Here's what I spotted: >>=20 >> Section 7.1: >>> The ICE specification [rfc5245bis], Section 5.1.5, requires that >>=20 >> Now Section 5.1.4 >>=20 >> Section 8.1.1: >>> When an agent commences ICE processing, in accordance with >>> Section 5.1.3.6 of [rfc5245bis]=20 >>=20 >> I think you mean 5.1.2.6 ("Computing Candidate Pair States").=20 >>=20 >> Also in: >>> Then, as the checks proceed (see Section 6.1.2.4.2.3 of [rfc5245bis]= =20 >>=20 >> Now Section 6.2.5.3.4.=20 >>=20 >> Same issue in section 7.2. >>=20 >> Section 12: >>> ICE processing described in Section 6.2 of [rfc5245bis], and Trickle >>=20 >> Now Section 7. >>=20 >> Finally, in Section 16: >>> c=3DIN IP4 2001:db8:a0b:12f0::1 >>=20 >> s/IP4/IP6/ >>=20 >>=20 >> Cheers, >> Ari >>=20 >=20 From nobody Fri May 12 18:28:18 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 023A2127866 for ; Fri, 12 May 2017 18:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 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, 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=FJWEl0TK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aSY0JK/f 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 hSVHkOaYt8rs for ; Fri, 12 May 2017 18:28:15 -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 6EE36129C40 for ; Fri, 12 May 2017 18:25:42 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5938C20970; Fri, 12 May 2017 21:25:41 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 12 May 2017 21:25:41 -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=cLeXNEERhXrLUYv7Xz znsAamHjv7zljdkhY0iQ7POsY=; b=FJWEl0TKj36KbM51MFI0QWv5mIHFPIyJ27 tgJdNaxofTS3hJ3Jx3DJblOlpSTed23byvcJ331832eugKpQd+n2izNKO/KSKYtw TBV0Jm6JGsaYFvDCM5rLHhWZgAYs88sPVcAVrH2w/oCX0SjaawstpfScknd68G7c joqrqv40LYaHQi5zYXb2XFCeybVaRokUHfaDQBdhE9jp8n12CQ0jiPwThwIQKQ/+ zkB4ZDYCL4ox0bWxCqzdTegHDpvuuemicmRQSYNI2gLwUWjgavrQD9Fbw/w08x3d sufpfJUuEFzj/f+vRIYBkI4B9d3ns6yDexrwwvjccDF+0Vi0s9aw== 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=cLeXNEERhXrLUYv7XzznsAamHjv7zljdkhY0iQ7POsY=; b=aSY0JK/f noVesT3k++BxPHk5/5zpkHxqcixOvcDfjLKoybrqSZxHxkobJ6H2Q1XuEMjG1exk /+qv2F3f6az5FJAxorYS6mv4MYqeU5J6dEIi0Zw6BbJLf0spV2NbsZQBGpaeLUOp m0ksxZirTP19HqbNrFhY3UbLvK9aIY1ehKdpvNOm0ysuLihDMdUuWx75AGJdzZ98 MtzQG5ByEmV4YFaTzHzjLtmZmWynNClosvTMZEOZaXDmVRkJCFpododknJ1omUEV Mkl9vYONbH3wNqn/gLZqqQYzNZwOzdirVUW2WMN2K6CsG5wqe6wTsvJROpwzMpf8 2GUp4BLRkfZ2qA== X-ME-Sender: X-Sasl-enc: LxrzIa251rG6KGzYWRen1rWisgP6MeYWC16yV2WrApJL 1494638741 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id E28E624950; Fri, 12 May 2017 21:25:40 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <149434989730.30014.15887010702179980747@ietfa.amsl.com> <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> <7ee09acb-33e9-8a40-5329-32b24f8f7e26@stpeter.im> <019E38A0-B530-4719-B3F3-6A4DD49B57ED@ericsson.com> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <17d36f4c-67ae-6f17-2883-f5d941979176@stpeter.im> Date: Fri, 12 May 2017 19:25: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: <019E38A0-B530-4719-B3F3-6A4DD49B57ED@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-10.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, 13 May 2017 01:28:17 -0000 On 5/12/17 2:27 PM, Ari Keränen wrote: > >> On 12 May 2017, at 23:11, Peter Saint-Andre wrote: >> >> On 5/12/17 2:07 PM, Ari Keränen wrote: >>> Thanks Peter! >>> >>> I reviewed the changes and they looked good to me. Below some editorial comments. >> >> Thanks, Ari, those are good catches. We'll double-check all >> cross-references and fix the things you've found. Shall we spin a -11 to >> address these? > > Thanks! Peter Thatcher is also reviewing the doc to make sure we didn't miss anything. You may want to wait for his comments/OK, but either way is fine for me. > >> Also, do we foresee section numbers changing again in 5245bis? If so, it >> might make more sense to remove the specific references (although I >> think they're helpful because it can be difficult to find exact text in >> 5245bis without the section numbers). > > They may change; but we'll try to avoid that. And I agree specific references are good. Luckily it's relatively easy to update them by comparing the section numbers of the different versions wrt references in this draft. If you don't mind doing that, please keep the specific ones. That all makes sense. I think we'll wait to hear from Peter before posting a revised I-D. Peter From nobody Sat May 13 17:09: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 AFE9A1292F5 for ; Sat, 13 May 2017 17:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=AtOCZ6R9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pUPZzDNU 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 9dKXqbSUNdqS for ; Sat, 13 May 2017 17:09:40 -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 ACDD51241FC for ; Sat, 13 May 2017 17:07:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 941DC20692; Sat, 13 May 2017 20:07:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 13 May 2017 20:07:37 -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=1xRjtxB5mZIklF7/vd irOSQCsTNCxA3HeureVxYbhCw=; b=AtOCZ6R9l68Jm+3SMfXF4S/c8mDCEC7GhP 9FxPg4icYGWg4AFFIcb/dbcIZYuLGN/w/HaKZk7Rd0LLlqgGcknVWrjGUb2QwD26 EFYpyRAyX5zcNwi3q0+sz3E1KNsZX08TUo82vUdNgAHKMYl9relL0AeXwH/b6wjP fKRggsxVe5M7wjTLfsd3fwJ7iOA0CMF3GagG9EFS0c3tf/esSE89xAl6zkOwLZKf 5fZVRAkgEVvWJNMAKbrU0gDFwoDXqoJyPZVBX5SvfltuBy9dAbCVkrcXQbTn2hQp oW42i+buYBiLRPrC/dApWsFtye3+zsAG+qmn5ObVOc2XnHWGI3Jw== 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=1xRjtxB5mZIklF7/vdirOSQCsTNCxA3HeureVxYbhCw=; b=pUPZzDNU cWrgJDUFbFfrOkbq/MP7PTGhY7I6JPUNqVgcevTKayAaARw9735UC5wM3f4IkOeb XzZFP9enpBCu7sbCHwEKMWh4qry7N2u3fjRSRXZ0O9dZNawaeogzbdVwkZkO/YWo 7WwEVzSZ2b+dQq1EQY6jA/wSXL4EDCYnETx2iwfsCHzgrdFRQ/L0tLmMQ4lgi/aM SYXfRhudSeB58EgD1X6Wmpa7RcmlIh32OlTwOIn+GgtfHxwRJiCOW5Z8ux8+xnLv 16gmHrEqGMPeWOzArVBehwaC07NKG91is9lZrE9Farkn16+ngYOZ8K3+NCSEY39a S712ClhXVxF/kA== X-ME-Sender: X-Sasl-enc: I0jb/k/zxxcUyVa1xfxtNcCTRt2lYaKiEOODdib7w7SN 1494720457 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 247BE7E2E3; Sat, 13 May 2017 20:07:37 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <149434989730.30014.15887010702179980747@ietfa.amsl.com> <6b28504d-2ee9-24ee-fbc9-2ea7d47fcf4a@stpeter.im> <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <7fe82373-f972-bdf0-2896-acee4aea4207@stpeter.im> Date: Sat, 13 May 2017 18:07:36 -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: <9FA29A61-A72B-4F2E-89DF-2A8FA29E8B30@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-10.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, 14 May 2017 00:09:42 -0000 On 5/12/17 2:07 PM, Ari Keränen wrote: > Also in: >> Then, as the checks proceed (see Section 6.1.2.4.2.3 of [rfc5245bis] > > Now Section 6.2.5.3.4. > > Same issue in section 7.2. I think that's actually 6.2.5.4, right? Peter From nobody Tue May 16 04:08: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 6B5B1129B6F for ; Tue, 16 May 2017 04:08:43 -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 daGQEjj3VE8j for ; Tue, 16 May 2017 04:08:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E581296B0 for ; Tue, 16 May 2017 04:04:35 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-ed-591adcc167ac Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EF.CD.00351.1CCDA195; Tue, 16 May 2017 13:04:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Tue, 16 May 2017 13:04:23 +0200 From: Christer Holmberg To: Emil Ivov CC: Taylor Brandstetter , Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt) Thread-Index: AQHSw44yG+8l/JxG+UWcffU9JI4fXaHhs50AgAAA74CAAATFgIAAAP4AgAAyNoCAAL/dgIAABFoAgACc0ICAAMdwAIAAG/YAgAAKWwCAAEgEgP//5UeAgBKK9oA= Date: Tue, 16 May 2017 11:04:22 +0000 Message-ID: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> In-Reply-To: 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.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2ADBABBB00C7FB4F94E9FD004E47DA0A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7q+7BO1KRBg8bFC0ur3jIarFm5wQW i28Xai2O7elndmDxWLCp1GPJkp9MHv/fBHrM3fOCOYAlissmJTUnsyy1SN8ugSujYfYR9oLL hhULXx5kbWA8q9rFyMkhIWAisbrxCUsXIxeHkMARRokFF3eyQzhLGCVebj8GlOHgYBOwkOj+ pw3SICIgL9HdtogJxGYWKJP4u3YyE0iJsECCRMcMX4iSRIlVFy8xgowREehilLjce4gFJMEi oCrxasttsHpeAWuJq2czIVbd5pC4tqAPbCanQKDE2lermUFsRgExie+n1kDtEpe49WQ+E8TR AhJL9pxnhrBFJV4+/scKYosK6Ens+/eVDSKuKPHx1T5GiF49iRtTp7BB2NYSbzt62CFsbYll C1+DzeEVEJQ4OfMJywRG8VlI1s1C0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKSXWpSZXFyc n6eXl1qyiREYkQe3/DbYwfjyueMhRgEORiUe3gpgpAqxJpYVV+YeYpTgYFYS4U27ABTiTUms rEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBsUs685HYlrr+2/u+ XS5WzjqpMmOVEuvhdRZxQVf89+WLerIVVHkukFLf/i5rZebKGer/F16om7yc/dIhtvW/ZOZy le7Z2yu38iTTGWHmB5wnt281WDnr3sSz6l/lT6cbe882X31GeOnteSr3f7dOsZ5s/G/Do1lt l5xC1y/YJW3JMs9w/ZygTceUWIozEg21mIuKEwEZIIM5xAIAAA== Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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, 16 May 2017 11:08:43 -0000 Hi, I=B9ve created a pull request, which ensures that multiple connectivity checks won=B9t be triggered at the same time. https://github.com/ice-wg/rfc5245bis/pull/33 (Note that the only case when, for a given foundation, there will be no pair in the Waiting/In-Progress state, is when a check for that foundation has failed.) Regards, Christer On 04/05/17 21:59, "Emil Ivov" wrote: >In all fairness I find that text rather hard to follow. It's >definitely clearer in 5245. I am curious what the reason for changing >it was? > >And to answer your question: yes, performing multiple transactions at >the same time directly breaks pacing. > >Emil > >On Thu, May 4, 2017 at 1:40 PM, Christer Holmberg > wrote: >> Hi, >> >> >> >> Related to the text below, note that it may actually trigger multiple >>checks >> simultaneously (normally only a single check is triggered whenever Ta >> fires). Are we ok with that? If not, I guess we would have to select the >> pair with the highest priority. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Taylor Brandstetter >> Sent: 04 May 2017 18:18 >> To: Emil Ivov >> Cc: Peter Saint-Andre ; ice@ietf.org >> Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of >> draft-ietf-ice-trickle-08.txt) >> >> >> >> We could optimize for this by adding a second go at the end where all >>the >> failed foundations are given another attempt. >> >> >> >> This already happens with ICEbis, though: >> >> >> >> Whenever Ta fires, the agent will perform a check for a candidate >> >> pair within the selected CHECK LIST as follows: ... >> >> >> >> o If there is no candidate pair in the Waiting state, and if there >> >> are one or more pairs in the Frozen state, for each pair in the >> Frozen state the the agent checks the foundation associated with >> the pair. For a given foundation, if there is no pair (in any >> CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress >> state, the agent performs a connectivity check on the pair and >> puts the pair state to In-Prograss. >> >> >> >> That's why I don't see the need for trickle ICE to do anything special >>with >> Failed candidate pairs. It's already guaranteed that failed foundations >>will >> be tried eventually, so what's gained by unfreezing these pairs earlier? >> >> >> >> >> >> >> >> On Thu, May 4, 2017 at 8:40 AM, Emil Ivov wrote: >> >> >> >> On 5/4/17 9:00 AM, Taylor Brandstetter wrote: >> >> That's not always necessarily true, since the state may go to Failed due >> to reasons other than a timeout. >> >> >> Yes, indeed. That could happen and the reason would be something like a >> transport error or an ICMP port unreachable. We could optimize for this >>by >> adding a second go at the end where all the failed foundations are given >> another attempt. >> >> This wouldn't be trivial to write up and I am reluctant to do it >>because: >> >> 1. it adds complexity to both the specification and implementations for >>low >> value: you only save one time slot per pair. You don't even have to >>worry >> about retransmissions. >> 2. the timeout case is arguably significantly more common >> >> One alternative that I would find acceptable is to simply scratch the >>entire >> foundation if the first pair there fails. I think that would work fine >>and >> it would be simple to write up but I know people on this list feel >>strongly >> about trying every pair and I get that point of view too. >> >> It would be unfortunate if this rule >> resulted in more time slots given to a foundation that doesn't work, and >> less to a foundation that does. >> >> >> I don't believe this statement is accurate. You may end up giving slots >>in >> the wrong order but I don't see how you could give more to the >>non-working >> and less to the working. >> >> Emil >> >> It also seems odd that there's no >> equivalent condition in ICEbis; every other condition has a parallel of >> some sort. >> >> >> >> >> On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre > > wrote: >> >> On 5/3/17 10:45 AM, Taylor Brandstetter wrote: >> > I am not sure I follow. Why is this not preserved? State >>changes >> > themselves happen as they do in 5245bis. Trickle only defines >>what >> > happens with newly added candidates and for the case you >>mention >> we >> > have this: >> > >> > 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). >> > >> > Which translates to exactly what you have in the quotes above. >> > >> > What's bothering you about it? >> > >> > >> > I think we're on the same page, just mis-communicating. My email >> quoted >> > at the start of this thread was talking about version 08; the >>problem >> is >> > fixed in version 09. The only thing that concerns me about >>version 09 >> is >> > the "or Failed" part >> > (see: >> https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA >>=20 >>). >> >> Emil posted in this thread about that yesterday. His explanation >>was: >> >> The fact that the state has moved to Failed is indication that >> enough time has been spent waiting on this, so unfreezing the >> following pairs for that foundation isn't going to penalize ICE >> processing as a whole. >> >> Does that ring true to you, and if so do you think we need to add >> explanatory text to that effect? >> >> Peter >> >> >> -- >> https://jitsi.org >> >> > > > >--=20 >https://jitsi.org From nobody Tue May 16 19:03:16 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 898041314AC for ; Tue, 16 May 2017 19:03:14 -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=fh3mykuI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YblBvxUg 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 9-w6lPJQzezn for ; Tue, 16 May 2017 19:03:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992D912ECA3 for ; Tue, 16 May 2017 18:59:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D7632209ED; Tue, 16 May 2017 21:59:13 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 16 May 2017 21:59:13 -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=ydqmLvrEH39M7zFfiL yeXOOGrh2LHfcv0QgAUVazoJE=; b=fh3mykuISPsaIXzUb7+v3oY9SWwJe2nWVo tqcKo6abDWYSj0D9Z+Cpg9vAoy0zcFSkgr7PMPpK4wbgdY5SvkkPuf50/aM74UNi btbnY9rJeVeXvmfqZMYh20w8y3gC4pYcx2uWxf07SzcqxL6IUm0LIUOBoFTi1mex SoC2kKaELRsSvzz9imZ7H7uG5aTOVfO29HbYRbOdCb3bwd8yYZ8UszWrKgtrkRxA kv0xTSGOCCzKZqidAim4Ez+rxKp84yivTYUv5v66f59ulQfVHleUmMNYUJlxkKq3 bc9cuk4+2bZIv0fX6tadl7peQzjL0DraTPcUuESg+W8B/BeUuqfA== 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=ydqmLvrEH39M7zFfiLyeXOOGrh2LHfcv0QgAUVazoJE=; b=YblBvxUg R8yLscuiCbPhNFbA2uwnT1NjUWg1dR41YpLYqshQWBSgbVMrhmJWm4uyYvRhfnee BRZw9vWa9MYsHa3/pRto7oVh6/u2kgHV/iYmAOqGOL0g8jkCO9OkGN/Or7dsVygY nd2X5Yid/GhaWMJZw7jFQv2AJqcIT3TQBVCM3L5Xxe9OoVvq5ToZ4105piM4lxYe /+1qY43cNtnj1XRtlL60fkcgU5kwhH8CT2g1Jr+cWv78tfz6LcUpje1v80p48YFV CJO0z7VrUWG/TlfOzp6kdUU1nvuqhnpBfGGMDX/aEenWl0CN6+a73IaB2b8zo9h4 IKwtTsLddtqC7g== X-ME-Sender: X-Sasl-enc: jRHleEMPtJe0kOKRCRe3hilkdGKE4xIswJroOFWmdX9n 1494986353 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2407C7E046; Tue, 16 May 2017 21:59:13 -0400 (EDT) To: Christer Holmberg , Emil Ivov References: <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> Cc: Taylor Brandstetter , "ice@ietf.org" From: Peter Saint-Andre Message-ID: Date: Tue, 16 May 2017 19:59:12 -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] holes in the matrix (Was: 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, 17 May 2017 02:03:14 -0000 Thanks, Christer. On 5/16/17 5:04 AM, Christer Holmberg wrote: > Hi, > > I¹ve created a pull request, which ensures that multiple connectivity > checks won¹t be triggered at the same time. > > https://github.com/ice-wg/rfc5245bis/pull/33 > > > (Note that the only case when, for a given foundation, there will be no > pair in the Waiting/In-Progress state, is when a check for that foundation > has failed.) > > Regards, > > Christer > > > > On 04/05/17 21:59, "Emil Ivov" wrote: > >> In all fairness I find that text rather hard to follow. It's >> definitely clearer in 5245. I am curious what the reason for changing >> it was? >> >> And to answer your question: yes, performing multiple transactions at >> the same time directly breaks pacing. >> >> Emil >> >> On Thu, May 4, 2017 at 1:40 PM, Christer Holmberg >> wrote: >>> Hi, >>> >>> >>> >>> Related to the text below, note that it may actually trigger multiple >>> checks >>> simultaneously (normally only a single check is triggered whenever Ta >>> fires). Are we ok with that? If not, I guess we would have to select the >>> pair with the highest priority. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Taylor Brandstetter >>> Sent: 04 May 2017 18:18 >>> To: Emil Ivov >>> Cc: Peter Saint-Andre ; ice@ietf.org >>> Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of >>> draft-ietf-ice-trickle-08.txt) >>> >>> >>> >>> We could optimize for this by adding a second go at the end where all >>> the >>> failed foundations are given another attempt. >>> >>> >>> >>> This already happens with ICEbis, though: >>> >>> >>> >>> Whenever Ta fires, the agent will perform a check for a candidate >>> >>> pair within the selected CHECK LIST as follows: ... >>> >>> >>> >>> o If there is no candidate pair in the Waiting state, and if there >>> >>> are one or more pairs in the Frozen state, for each pair in the >>> Frozen state the the agent checks the foundation associated with >>> the pair. For a given foundation, if there is no pair (in any >>> CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress >>> state, the agent performs a connectivity check on the pair and >>> puts the pair state to In-Prograss. >>> >>> >>> >>> That's why I don't see the need for trickle ICE to do anything special >>> with >>> Failed candidate pairs. It's already guaranteed that failed foundations >>> will >>> be tried eventually, so what's gained by unfreezing these pairs earlier? >>> >>> >>> >>> >>> >>> >>> >>> On Thu, May 4, 2017 at 8:40 AM, Emil Ivov wrote: >>> >>> >>> >>> On 5/4/17 9:00 AM, Taylor Brandstetter wrote: >>> >>> That's not always necessarily true, since the state may go to Failed due >>> to reasons other than a timeout. >>> >>> >>> Yes, indeed. That could happen and the reason would be something like a >>> transport error or an ICMP port unreachable. We could optimize for this >>> by >>> adding a second go at the end where all the failed foundations are given >>> another attempt. >>> >>> This wouldn't be trivial to write up and I am reluctant to do it >>> because: >>> >>> 1. it adds complexity to both the specification and implementations for >>> low >>> value: you only save one time slot per pair. You don't even have to >>> worry >>> about retransmissions. >>> 2. the timeout case is arguably significantly more common >>> >>> One alternative that I would find acceptable is to simply scratch the >>> entire >>> foundation if the first pair there fails. I think that would work fine >>> and >>> it would be simple to write up but I know people on this list feel >>> strongly >>> about trying every pair and I get that point of view too. >>> >>> It would be unfortunate if this rule >>> resulted in more time slots given to a foundation that doesn't work, and >>> less to a foundation that does. >>> >>> >>> I don't believe this statement is accurate. You may end up giving slots >>> in >>> the wrong order but I don't see how you could give more to the >>> non-working >>> and less to the working. >>> >>> Emil >>> >>> It also seems odd that there's no >>> equivalent condition in ICEbis; every other condition has a parallel of >>> some sort. >>> >>> >>> >>> >>> On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre >> > wrote: >>> >>> On 5/3/17 10:45 AM, Taylor Brandstetter wrote: >>> > I am not sure I follow. Why is this not preserved? State >>> changes >>> > themselves happen as they do in 5245bis. Trickle only defines >>> what >>> > happens with newly added candidates and for the case you >>> mention >>> we >>> > have this: >>> > >>> > 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). >>> > >>> > Which translates to exactly what you have in the quotes above. >>> > >>> > What's bothering you about it? >>> > >>> > >>> > I think we're on the same page, just mis-communicating. My email >>> quoted >>> > at the start of this thread was talking about version 08; the >>> problem >>> is >>> > fixed in version 09. The only thing that concerns me about >>> version 09 >>> is >>> > the "or Failed" part >>> > (see: >>> https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA >>> >>> ). >>> >>> Emil posted in this thread about that yesterday. His explanation >>> was: >>> >>> The fact that the state has moved to Failed is indication that >>> enough time has been spent waiting on this, so unfreezing the >>> following pairs for that foundation isn't going to penalize ICE >>> processing as a whole. >>> >>> Does that ring true to you, and if so do you think we need to add >>> explanatory text to that effect? >>> >>> Peter >>> From nobody Wed May 17 22:34: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 0FF0A12EB9F for ; Wed, 17 May 2017 22:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hx0RUp2GO09f for ; Wed, 17 May 2017 22:34:55 -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 B5A601298A1 for ; Wed, 17 May 2017 22:30:03 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id v27so26242641qtg.2 for ; Wed, 17 May 2017 22:30:03 -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=DGpDS8vDznuiOqEaYaojg7iQXVvJPw5mGf/GLEJB1DA=; b=c27XmmESISXW2+PqDg9em/JFYtdz550gzHmNrvkyrixPmus4Aq8+4NQPFYdozGRC27 2EoaD4f7INx+WS1Qp1HwTvTxqfhPB9tNk21a6bEEKaStIxKFyDn1TfepeyeUYBcLKUtJ vIioWEzJjqOMkHfKNpq6Jd3V+RwY0jv91hHQxWGS4rpMNdSd9w1Q3+9qfSjTwi9A0cdu 8jy39LpOa/wcI8Hx+kgyWKlOkcXHq3b96JYwF2yDCdl8604rrEzrMvBaegD2FS7FNxz+ 1yD9X1T7UasPu8VhdoIjRjMdXGmB/SPBPptoAaqvFbM/Y9IwbshDNIddMJFeb16kNv5d nuCQ== 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=DGpDS8vDznuiOqEaYaojg7iQXVvJPw5mGf/GLEJB1DA=; b=pWQPHUzUc7ihEDyiXDvmKzSk1l+SxGoNhPyBBOyk4jdDXIVi4YFASPyEiuVW02bc0N JOG50ZD8MmjBB6Ew0KF7AFGp7Vn426SDyE2oZdpzw4tR40AOfJh2gVF9P9yAN/KNtals uwgxO+x4oZFhiwvA0zLNEH3nAf1+IoQZmlMQwVWhE2yorqQ5FozyLluG+m/EmqmPmlmp 2aiQycSsaNsFfWLPJI7sUmgruSiLGxi8DXVFtzBYfjlVXBax/w8uj0RJ/HBDDZVWmNjo PMZ6HWm3Ij/U/o15EldgGgMctDhoBYkT2nZxHcB/HrSoAoIpzBAsks+8mpp2L3V0zZBs PIIg== X-Gm-Message-State: AODbwcDyLRausxbjbGoOCEwa34cmfsOmuYfGER1yZBMc7Kg2xwlFpnYi Ynwj4sHMI+z6+X/JSD7jRjsgbWaIBThQVsE= X-Received: by 10.237.62.12 with SMTP id l12mr2396718qtf.20.1495085402656; Wed, 17 May 2017 22:30:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.61 with HTTP; Wed, 17 May 2017 22:30:02 -0700 (PDT) In-Reply-To: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> References: <51afcdf1-fc64-49c7-0953-3a4d3bdf22b4@stpeter.im> From: Taylor Brandstetter Date: Wed, 17 May 2017 22:30:02 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="001a1140e70055f13d054fc5b2d9" 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: Thu, 18 May 2017 05:34:57 -0000 --001a1140e70055f13d054fc5b2d9 Content-Type: text/plain; charset="UTF-8" I took a look at version 10, which still says: Therefore a Trickle ICE agent needs to 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). I still don't see how this is true. If it is, I can't find where this independently monitored state is used. So I think this sentence and the rest of the paragraph should be removed. Also, while looking for where it's referenced, I noticed that Section 10 still mentions a check list in an "Active" state, when it should say "Running". 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 > > --001a1140e70055f13d054fc5b2d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I took a look at
Therefore a Trickle I= CE agent needs to monitor whether a check list is active or frozen independ= ently of the state of the candidate pairs in the check list (since there mi= ght not be any pairs yet).

I still don't see how this is true. If it is, I can't find whe=
re this independently monitored state is used. So I think this sentence and=
 the rest of the paragraph should be removed.

Also, while looking for where it's referenced, I notic=
ed that Section 10 still mentions a check list in an "Active" sta=
te, when it should say "Running".

On Mon, Apr 10, 2017 at = 1:05 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:56 PM, Taylor B= randstetter 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


--001a1140e70055f13d054fc5b2d9-- From nobody Thu May 18 09:41:04 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 0B2F612EBBB for ; Thu, 18 May 2017 09:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 gEMwgXeIGh5e for ; Thu, 18 May 2017 09:40:57 -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 2EC081273B1 for ; Thu, 18 May 2017 09:33:31 -0700 (PDT) X-AuditID: c1b4fb2d-1e1ff70000000d37-6f-591dccd8b9a4 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.F1.03383.8DCCD195; Thu, 18 May 2017 18:33:29 +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; Thu, 18 May 2017 18:33:27 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ice@ietf.org" CC: Peter Thatcher Thread-Topic: ICE at IETF 99 Thread-Index: AQHSz/R6Ttd3mBBG+E65gel1IDLJmQ== Date: Thu, 18 May 2017 16:33:27 +0000 Message-ID: <5917F365-E4D0-4A6B-9595-28B586BC3F10@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <86BAF8B42564A84E9B205425F01E32D1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7ru7NM7KRBlPeKFt8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CV8bJhBWPBHKaKr7e8GhhvMHYxcnBICJhIHDyk 08XIxSEkcIRRYtXujUwQzhJGicOt3exdjJwcbAL2EpPXfGQEsUUEFCVmtjxjBrGZBTQl7p9c CFYjLCAucfTeHbChIgIyEj3nnSHK9SQ+//vLBGKzCKhKTP9+DqyVF2jk/cbnbCA2o4CYxPdT a5ggRopL3HoyH8yWEBCQWLLnPDOELSrx8vE/VghbSWLR7c9Q9XoSN6ZOYYOwrSW+9K5mhbC1 JZYtfA21S1Di5MwnLBMYRWYhWTELSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kbFealFmcnFx fp5eXmrJJkZgfBzc8lt3B+Pq146HGAU4GJV4eGO2yUYKsSaWFVfmHmKU4GBWEuG9cgAoxJuS WFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUA6NPXpP/MQn9taLa yktZb5dXbzTt8ky/VixgMV1deburFVugkqSNkuDvN0ffLrM/5OT9wvJ4cNZL+y87uR9daQ+s /7n3p5Pjl+OKjrlqz13FzxqFdBSd3f/n2aZ55lcntWcqWTVdUuJ/rDhJ3mjT3vLl/eITD3Ob 3bMKPjDt8jnLpS/F7xztmKXEUpyRaKjFXFScCABZoY67iwIAAA== Archived-At: Subject: [Ice] ICE at IETF 99 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, 18 May 2017 16:41:02 -0000 Hi all, We are planning to ask for a slot for the ICE WG in the Prague IETF meeting= to address Trickle ICE and ICE-bis (soon to be started) WGLC comments. If = you think we should discuss other topics too, please let us know as soon as= possible. Thanks, Ari & Peter= From nobody Fri May 19 02:12:31 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 28078128DF2 for ; Fri, 19 May 2017 02:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9gL1cUZ35_x for ; Fri, 19 May 2017 02:12:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82066129410 for ; Fri, 19 May 2017 02:05:30 -0700 (PDT) X-AuditID: c1b4fb30-4163b9a0000007db-bd-591eb5582ca9 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.A0.02011.855BE195; Fri, 19 May 2017 11:05:28 +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; Fri, 19 May 2017 11:05:27 +0200 From: Christer Holmberg To: Christer Holmberg , Emil Ivov CC: "ice@ietf.org" , Peter Saint-Andre , Taylor Brandstetter Thread-Topic: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt) Thread-Index: AQHSw44yG+8l/JxG+UWcffU9JI4fXaHhs50AgAAA74CAAATFgIAAAP4AgAAyNoCAAL/dgIAABFoAgACc0ICAAMdwAIAAG/YAgAAKWwCAAEgEgP//5UeAgBKK9oCABJXNgA== Date: Fri, 19 May 2017 09:05:26 +0000 Message-ID: References: <3e160644-d14f-7740-684a-cdc41c227c17@stpeter.im> <4d37002a-d9b5-ee21-0fe5-8be6a0cdf176@jitsi.org> <72fef87c-1637-d7f4-bafd-e8e523158aae@jitsi.org> <7594FB04B1934943A5C02806D1A2204B4CB93375@ESESSMB109.ericsson.se> In-Reply-To: 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.17] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7um7EVrlIg0VLtCwur3jIarFm5wQW i28Xai2O7elndmDxWLCp1GPJkp9MHv/fBHrM3fOCOYAlissmJTUnsyy1SN8ugStj5bsdjAXP vCpe/L7I3MD4waOLkZNDQsBEYvf/DjYQW0jgCKPErweyXYxcQPYSRon1i/uZuxg5ONgELCS6 /2mDmCICoRIrDmiDlDMLlEnMPreYDSQsLJAg0THDFyQsIpAoseriJUaQKSICkxgl9tz9BTae RUBVorvlNzOIzStgLfF/YSsjxKpeTomp//cwgiQ4BWwk5h9eBVbEKCAm8f3UGiaIZeISt57M Z4K4WUBiyZ7zzBC2qMTLx/9YQWxRAT2Jff++gh0kIaAosbxfDqJVS+LLj31sELa1xMXmdawQ tqLElO6H7BD3CEqcnPmEZQKj+Cwk22YhaZ+FpH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpM Li7Oz9PLSy3ZxAiMxoNbfhvsYHz53PEQowAHoxIPb8M8uUgh1sSy4srcQ4wSHMxKIrziYkAh 3pTEyqrUovz4otKc1OJDjNIcLErivI77LkQICaQnlqRmp6YWpBbBZJk4OKUaGFckqJam2kQk d/8R953+ZLpRY+jKbykJuuITP58QfPLa/V13waPrWVwTt3Iu8pR6n74s5HmX3c5olhTtXxu7 RI8vevU6i/HTd/OJ/oyPdn6w9eVKlfzRlDd347amdZMOL2HYNcu1oOv5QfGyeMu7tpknZpxV dmuW/7Sn9HHG8qka5YK9wvcFpyqxFGckGmoxFxUnAgAlsnD2wgIAAA== Archived-At: Subject: Re: [Ice] holes in the matrix (Was: 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: Fri, 19 May 2017 09:12:29 -0000 SGksDQoNCkJhc2VkIG9uIGEgY29tbWVudCBmcm9tIFRheWxvciwgSSBoYXZlIGFkZGVkIGEgZmxv dyBjaGFydCB0aGF0IGlsbHVzdHJhdGVzDQp0aGUgcHJvY2VkdXJlcy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQpPbiAxNi8wNS8xNyAxNDowNCwgIkljZSBvbiBiZWhhbGYgb2YgQ2hyaXN0 ZXIgSG9sbWJlcmciDQo8aWNlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5JqfZ2ZSBjcmVhdGVk IGEgcHVsbCByZXF1ZXN0LCB3aGljaCBlbnN1cmVzIHRoYXQgbXVsdGlwbGUgY29ubmVjdGl2aXR5 DQo+Y2hlY2tzIHdvbqn2dCBiZSB0cmlnZ2VyZWQgYXQgdGhlIHNhbWUgdGltZS4NCj4NCj5odHRw czovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC8zMw0KPg0KPg0KPihOb3RlIHRo YXQgdGhlIG9ubHkgY2FzZSB3aGVuLCBmb3IgYSBnaXZlbiBmb3VuZGF0aW9uLCB0aGVyZSB3aWxs IGJlIG5vDQo+cGFpciBpbiB0aGUgV2FpdGluZy9Jbi1Qcm9ncmVzcyBzdGF0ZSwgaXMgd2hlbiBh IGNoZWNrIGZvciB0aGF0IGZvdW5kYXRpb24NCj5oYXMgZmFpbGVkLikNCj4NCj5SZWdhcmRzLA0K Pg0KPkNocmlzdGVyDQo+DQo+DQo+DQo+T24gMDQvMDUvMTcgMjE6NTksICJFbWlsIEl2b3YiIDxl bWNob0BqaXRzaS5vcmc+IHdyb3RlOg0KPg0KPj5JbiBhbGwgZmFpcm5lc3MgSSBmaW5kIHRoYXQg dGV4dCByYXRoZXIgaGFyZCB0byBmb2xsb3cuIEl0J3MNCj4+ZGVmaW5pdGVseSBjbGVhcmVyIGlu IDUyNDUuIEkgYW0gY3VyaW91cyB3aGF0IHRoZSByZWFzb24gZm9yIGNoYW5naW5nDQo+Pml0IHdh cz8NCj4+DQo+PkFuZCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbjogeWVzLCBwZXJmb3JtaW5nIG11 bHRpcGxlIHRyYW5zYWN0aW9ucyBhdA0KPj50aGUgc2FtZSB0aW1lIGRpcmVjdGx5IGJyZWFrcyBw YWNpbmcuDQo+Pg0KPj5FbWlsDQo+Pg0KPj5PbiBUaHUsIE1heSA0LCAyMDE3IGF0IDE6NDAgUE0s IENocmlzdGVyIEhvbG1iZXJnDQo+PjxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdy b3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFJlbGF0ZWQgdG8gdGhlIHRleHQgYmVs b3csIG5vdGUgdGhhdCBpdCBtYXkgYWN0dWFsbHkgdHJpZ2dlciBtdWx0aXBsZQ0KPj4+Y2hlY2tz DQo+Pj4gc2ltdWx0YW5lb3VzbHkgKG5vcm1hbGx5IG9ubHkgYSBzaW5nbGUgY2hlY2sgaXMgdHJp Z2dlcmVkIHdoZW5ldmVyIFRhDQo+Pj4gZmlyZXMpLiBBcmUgd2Ugb2sgd2l0aCB0aGF0PyBJZiBu b3QsIEkgZ3Vlc3Mgd2Ugd291bGQgaGF2ZSB0byBzZWxlY3QNCj4+PnRoZQ0KPj4+IHBhaXIgd2l0 aCB0aGUgaGlnaGVzdCBwcmlvcml0eS4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+ DQo+Pj4NCj4+Pg0KPj4+IENocmlzdGVyDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gRnJvbTogSWNlIFtt YWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUYXlsb3INCj4+PkJyYW5k c3RldHRlcg0KPj4+IFNlbnQ6IDA0IE1heSAyMDE3IDE4OjE4DQo+Pj4gVG86IEVtaWwgSXZvdiA8 ZW1jaG9Aaml0c2kub3JnPg0KPj4+IENjOiBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBl dGVyLmltPjsgaWNlQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtJY2VdIGhvbGVzIGluIHRo ZSBtYXRyaXggKFdhczogVGF5bG9yJ3MgcmV2aWV3IG9mDQo+Pj4gZHJhZnQtaWV0Zi1pY2UtdHJp Y2tsZS0wOC50eHQpDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gV2UgY291bGQgb3B0aW1pemUgZm9yIHRo aXMgYnkgYWRkaW5nIGEgc2Vjb25kIGdvIGF0IHRoZSBlbmQgd2hlcmUgYWxsDQo+Pj50aGUNCj4+ PiBmYWlsZWQgZm91bmRhdGlvbnMgYXJlIGdpdmVuIGFub3RoZXIgYXR0ZW1wdC4NCj4+Pg0KPj4+ DQo+Pj4NCj4+PiBUaGlzIGFscmVhZHkgaGFwcGVucyB3aXRoIElDRWJpcywgdGhvdWdoOg0KPj4+ DQo+Pj4NCj4+Pg0KPj4+ICAgIFdoZW5ldmVyIFRhIGZpcmVzLCB0aGUgYWdlbnQgd2lsbCBwZXJm b3JtIGEgY2hlY2sgZm9yIGEgY2FuZGlkYXRlDQo+Pj4NCj4+PiAgICBwYWlyIHdpdGhpbiB0aGUg c2VsZWN0ZWQgQ0hFQ0sgTElTVCBhcyBmb2xsb3dzOiAuLi4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAg ICBvICBJZiB0aGVyZSBpcyBubyBjYW5kaWRhdGUgcGFpciBpbiB0aGUgV2FpdGluZyBzdGF0ZSwg YW5kIGlmIHRoZXJlDQo+Pj4NCj4+PiAgICAgICBhcmUgb25lIG9yIG1vcmUgcGFpcnMgaW4gdGhl IEZyb3plbiBzdGF0ZSwgZm9yIGVhY2ggcGFpciBpbiB0aGUNCj4+PiAgICAgICBGcm96ZW4gc3Rh dGUgdGhlIHRoZSBhZ2VudCBjaGVja3MgdGhlIGZvdW5kYXRpb24gYXNzb2NpYXRlZCB3aXRoDQo+ Pj4gICAgICAgdGhlIHBhaXIuICBGb3IgYSBnaXZlbiBmb3VuZGF0aW9uLCBpZiB0aGVyZSBpcyBu byBwYWlyIChpbiBhbnkNCj4+PiAgICAgICBDSEVDSyBMSVNUIGluIHRoZSBDSEVDSyBMSVNUIFNF VCkgaW4gdGhlIFdhaXRpbmcgb3IgSW4tUHJvZ3Jlc3MNCj4+PiAgICAgICBzdGF0ZSwgdGhlIGFn ZW50IHBlcmZvcm1zIGEgY29ubmVjdGl2aXR5IGNoZWNrIG9uIHRoZSBwYWlyIGFuZA0KPj4+ICAg ICAgIHB1dHMgdGhlIHBhaXIgc3RhdGUgdG8gSW4tUHJvZ3Jhc3MuDQo+Pj4NCj4+Pg0KPj4+DQo+ Pj4gVGhhdCdzIHdoeSBJIGRvbid0IHNlZSB0aGUgbmVlZCBmb3IgdHJpY2tsZSBJQ0UgdG8gZG8g YW55dGhpbmcgc3BlY2lhbA0KPj4+d2l0aA0KPj4+IEZhaWxlZCBjYW5kaWRhdGUgcGFpcnMuIEl0 J3MgYWxyZWFkeSBndWFyYW50ZWVkIHRoYXQgZmFpbGVkIGZvdW5kYXRpb25zDQo+Pj53aWxsDQo+ Pj4gYmUgdHJpZWQgZXZlbnR1YWxseSwgc28gd2hhdCdzIGdhaW5lZCBieSB1bmZyZWV6aW5nIHRo ZXNlIHBhaXJzDQo+Pj5lYXJsaWVyPw0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ DQo+Pj4gT24gVGh1LCBNYXkgNCwgMjAxNyBhdCA4OjQwIEFNLCBFbWlsIEl2b3YgPGVtY2hvQGpp dHNpLm9yZz4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gNS80LzE3IDk6MDAgQU0sIFRh eWxvciBCcmFuZHN0ZXR0ZXIgd3JvdGU6DQo+Pj4NCj4+PiBUaGF0J3Mgbm90IGFsd2F5cyBuZWNl c3NhcmlseSB0cnVlLCBzaW5jZSB0aGUgc3RhdGUgbWF5IGdvIHRvIEZhaWxlZA0KPj4+ZHVlDQo+ Pj4gdG8gcmVhc29ucyBvdGhlciB0aGFuIGEgdGltZW91dC4NCj4+Pg0KPj4+DQo+Pj4gWWVzLCBp bmRlZWQuIFRoYXQgY291bGQgaGFwcGVuIGFuZCB0aGUgcmVhc29uIHdvdWxkIGJlIHNvbWV0aGlu ZyBsaWtlIGENCj4+PiB0cmFuc3BvcnQgZXJyb3Igb3IgYW4gSUNNUCBwb3J0IHVucmVhY2hhYmxl LiBXZSBjb3VsZCBvcHRpbWl6ZSBmb3IgdGhpcw0KPj4+YnkNCj4+PiBhZGRpbmcgYSBzZWNvbmQg Z28gYXQgdGhlIGVuZCB3aGVyZSBhbGwgdGhlIGZhaWxlZCBmb3VuZGF0aW9ucyBhcmUNCj4+Pmdp dmVuDQo+Pj4gYW5vdGhlciBhdHRlbXB0Lg0KPj4+DQo+Pj4gVGhpcyB3b3VsZG4ndCBiZSB0cml2 aWFsIHRvIHdyaXRlIHVwIGFuZCBJIGFtIHJlbHVjdGFudCB0byBkbyBpdA0KPj4+YmVjYXVzZToN Cj4+Pg0KPj4+IDEuIGl0IGFkZHMgY29tcGxleGl0eSB0byBib3RoIHRoZSBzcGVjaWZpY2F0aW9u IGFuZCBpbXBsZW1lbnRhdGlvbnMgZm9yDQo+Pj5sb3cNCj4+PiB2YWx1ZTogeW91IG9ubHkgc2F2 ZSBvbmUgdGltZSBzbG90IHBlciBwYWlyLiBZb3UgZG9uJ3QgZXZlbiBoYXZlIHRvDQo+Pj53b3Jy eQ0KPj4+IGFib3V0IHJldHJhbnNtaXNzaW9ucy4NCj4+PiAyLiB0aGUgdGltZW91dCBjYXNlIGlz IGFyZ3VhYmx5IHNpZ25pZmljYW50bHkgbW9yZSBjb21tb24NCj4+Pg0KPj4+IE9uZSBhbHRlcm5h dGl2ZSB0aGF0IEkgd291bGQgZmluZCBhY2NlcHRhYmxlIGlzIHRvIHNpbXBseSBzY3JhdGNoIHRo ZQ0KPj4+ZW50aXJlDQo+Pj4gZm91bmRhdGlvbiBpZiB0aGUgZmlyc3QgcGFpciB0aGVyZSBmYWls cy4gSSB0aGluayB0aGF0IHdvdWxkIHdvcmsgZmluZQ0KPj4+YW5kDQo+Pj4gaXQgd291bGQgYmUg c2ltcGxlIHRvIHdyaXRlIHVwIGJ1dCBJIGtub3cgcGVvcGxlIG9uIHRoaXMgbGlzdCBmZWVsDQo+ Pj5zdHJvbmdseQ0KPj4+IGFib3V0IHRyeWluZyBldmVyeSBwYWlyIGFuZCBJIGdldCB0aGF0IHBv aW50IG9mIHZpZXcgdG9vLg0KPj4+DQo+Pj4gSXQgd291bGQgYmUgdW5mb3J0dW5hdGUgaWYgdGhp cyBydWxlDQo+Pj4gcmVzdWx0ZWQgaW4gbW9yZSB0aW1lIHNsb3RzIGdpdmVuIHRvIGEgZm91bmRh dGlvbiB0aGF0IGRvZXNuJ3Qgd29yaywNCj4+PmFuZA0KPj4+IGxlc3MgdG8gYSBmb3VuZGF0aW9u IHRoYXQgZG9lcy4NCj4+Pg0KPj4+DQo+Pj4gSSBkb24ndCBiZWxpZXZlIHRoaXMgc3RhdGVtZW50 IGlzIGFjY3VyYXRlLiBZb3UgbWF5IGVuZCB1cCBnaXZpbmcgc2xvdHMNCj4+PmluDQo+Pj4gdGhl IHdyb25nIG9yZGVyIGJ1dCBJIGRvbid0IHNlZSBob3cgeW91IGNvdWxkIGdpdmUgbW9yZSB0byB0 aGUNCj4+Pm5vbi13b3JraW5nDQo+Pj4gYW5kIGxlc3MgdG8gdGhlIHdvcmtpbmcuDQo+Pj4NCj4+ PiBFbWlsDQo+Pj4NCj4+PiBJdCBhbHNvIHNlZW1zIG9kZCB0aGF0IHRoZXJlJ3Mgbm8NCj4+PiBl cXVpdmFsZW50IGNvbmRpdGlvbiBpbiBJQ0ViaXM7IGV2ZXJ5IG90aGVyIGNvbmRpdGlvbiBoYXMg YSBwYXJhbGxlbCBvZg0KPj4+IHNvbWUgc29ydC4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9u IFdlZCwgTWF5IDMsIDIwMTcgYXQgNzowNiBQTSwgUGV0ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJA c3RwZXRlci5pbQ0KPj4+IDxtYWlsdG86c3RwZXRlckBzdHBldGVyLmltPj4gd3JvdGU6DQo+Pj4N Cj4+PiAgICAgT24gNS8zLzE3IDEwOjQ1IEFNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIHdyb3RlOg0K Pj4+ICAgICA+ICAgICBJIGFtIG5vdCBzdXJlIEkgZm9sbG93LiBXaHkgaXMgdGhpcyBub3QgcHJl c2VydmVkPyBTdGF0ZQ0KPj4+Y2hhbmdlcw0KPj4+ICAgICA+ICAgICB0aGVtc2VsdmVzIGhhcHBl biBhcyB0aGV5IGRvIGluIDUyNDViaXMuIFRyaWNrbGUgb25seSBkZWZpbmVzDQo+Pj53aGF0DQo+ Pj4gICAgID4gICAgIGhhcHBlbnMgd2l0aCBuZXdseSBhZGRlZCBjYW5kaWRhdGVzIGFuZCBmb3Ig dGhlIGNhc2UgeW91DQo+Pj5tZW50aW9uDQo+Pj4gd2UNCj4+PiAgICAgPiAgICAgaGF2ZSB0aGlz Og0KPj4+ICAgICA+DQo+Pj4gICAgID4gICAgICAgIENhc2UgMzogSWYgdGhlcmUgaXMgYXQgbGVh c3Qgb25lIHBhaXIgaW4gdGhpcyBjb2x1bW4gYWJvdmUNCj4+PnRoZQ0KPj4+IHJvdyBvZg0KPj4+ ICAgICA+ICAgICAgICB0aGUgbmV3bHkgZm9ybWVkIHBhaXIgd2hvc2Ugc3RhdGUgaXMgZWl0aGVy IFN1Y2NlZWRlZCBvcg0KPj4+IEZhaWxlZCwgc2V0DQo+Pj4gICAgID4gICAgICAgIHRoZSBzdGF0 ZSB0byBXYWl0aW5nIChlLmcuLCB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlIGlmIHRoZQ0KPj4+cGFp cg0KPj4+IGluDQo+Pj4gICAgID4gICAgICAgIGNvbHVtbiA1LCByb3cgMSBzdWNjZWVkZWQgYW5k IHR3byBuZXdseSBmb3JtZWQgcGFpcnMgd2VyZQ0KPj4+IHBsYWNlZCBpbg0KPj4+ICAgICA+ICAg ICAgICBjb2x1bW4gNSwgcm93cyAzIGFuZCA0KS4NCj4+PiAgICAgPg0KPj4+ICAgICA+ICAgICBX aGljaCB0cmFuc2xhdGVzIHRvIGV4YWN0bHkgd2hhdCB5b3UgaGF2ZSBpbiB0aGUgcXVvdGVzDQo+ Pj5hYm92ZS4NCj4+PiAgICAgPg0KPj4+ICAgICA+ICAgICBXaGF0J3MgYm90aGVyaW5nIHlvdSBh Ym91dCBpdD8NCj4+PiAgICAgPg0KPj4+ICAgICA+DQo+Pj4gICAgID4gSSB0aGluayB3ZSdyZSBv biB0aGUgc2FtZSBwYWdlLCBqdXN0IG1pcy1jb21tdW5pY2F0aW5nLiBNeSBlbWFpbA0KPj4+IHF1 b3RlZA0KPj4+ICAgICA+IGF0IHRoZSBzdGFydCBvZiB0aGlzIHRocmVhZCB3YXMgdGFsa2luZyBh Ym91dCB2ZXJzaW9uIDA4OyB0aGUNCj4+PnByb2JsZW0NCj4+PiBpcw0KPj4+ICAgICA+IGZpeGVk IGluIHZlcnNpb24gMDkuIFRoZSBvbmx5IHRoaW5nIHRoYXQgY29uY2VybnMgbWUgYWJvdXQNCj4+ PnZlcnNpb24gMDkNCj4+PiBpcw0KPj4+ICAgICA+IHRoZSAib3IgRmFpbGVkIiBwYXJ0DQo+Pj4g ICAgID4gKHNlZToNCj4+PiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lj ZS82b0RmNnlOYW5DZ2pqMXlIWEUzaWRsbW9ieUENCj4+PiANCj4+PjxodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL2ljZS82b0RmNnlOYW5DZ2pqMXlIWEUzaWRsbW9ieUE+KQ0K Pj4+Lg0KPj4+DQo+Pj4gICAgIEVtaWwgcG9zdGVkIGluIHRoaXMgdGhyZWFkIGFib3V0IHRoYXQg eWVzdGVyZGF5LiBIaXMgZXhwbGFuYXRpb24NCj4+PndhczoNCj4+Pg0KPj4+ICAgICAgICBUaGUg ZmFjdCB0aGF0IHRoZSBzdGF0ZSBoYXMgbW92ZWQgdG8gRmFpbGVkIGlzIGluZGljYXRpb24gdGhh dA0KPj4+ICAgICAgICBlbm91Z2ggdGltZSBoYXMgYmVlbiBzcGVudCB3YWl0aW5nIG9uIHRoaXMs IHNvIHVuZnJlZXppbmcgdGhlDQo+Pj4gICAgICAgIGZvbGxvd2luZyBwYWlycyBmb3IgdGhhdCBm b3VuZGF0aW9uIGlzbid0IGdvaW5nIHRvIHBlbmFsaXplIElDRQ0KPj4+ICAgICAgICBwcm9jZXNz aW5nIGFzIGEgd2hvbGUuDQo+Pj4NCj4+PiAgICAgRG9lcyB0aGF0IHJpbmcgdHJ1ZSB0byB5b3Us IGFuZCBpZiBzbyBkbyB5b3UgdGhpbmsgd2UgbmVlZCB0byBhZGQNCj4+PiAgICAgZXhwbGFuYXRv cnkgdGV4dCB0byB0aGF0IGVmZmVjdD8NCj4+Pg0KPj4+ICAgICBQZXRlcg0KPj4+DQo+Pj4NCj4+ PiAtLQ0KPj4+IGh0dHBzOi8vaml0c2kub3JnDQo+Pj4NCj4+Pg0KPj4NCj4+DQo+Pg0KPj4tLSAN Cj4+aHR0cHM6Ly9qaXRzaS5vcmcNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPkljZSBtYWlsaW5nIGxpc3QNCj5JY2VAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQo= From nobody Wed May 24 09:43:15 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 9BD9E12EB49; Wed, 24 May 2017 09:43:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Meeting Session Request Tool To: Cc: ari.keranen@ericsson.com, ben@nostrum.com, ice-chairs@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149564419354.28511.16631612294145601727.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 09:43:13 -0700 Archived-At: Subject: [Ice] ice - New Meeting Session Request for IETF 99 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: Wed, 24 May 2017 16:43:14 -0000 A new meeting session request has just been submitted by Ari Keranen, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keränen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm quic Second Priority: perc httpbis rmcat netvc sipbrandy stir Third Priority: ace 6lo lwig clue xrblock sipcore cbor People who must be present: Ben Campbell Ari Keranen Peter Thatcher Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu May 25 04:43:58 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 36CF41294E0; Thu, 25 May 2017 04:43:56 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149571263618.8596.4389107734364589475@ietfa.amsl.com> Date: Thu, 25 May 2017 04:43:56 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-11.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, 25 May 2017 11:43:56 -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-11.txt Pages : 32 Date : 2017-05-25 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-11 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 May 25 14:52:06 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 C89EF129AA3 for ; Thu, 25 May 2017 14:52:04 -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 ydAgqy8eKgrm for ; Thu, 25 May 2017 14:52:03 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 3E58F1294A6 for ; Thu, 25 May 2017 14:52:03 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l18so296749906oig.2 for ; Thu, 25 May 2017 14:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HG27u7QT//DUXHl5TQAebYaxG1fXIc6/h/rI2WByhhI=; b=QyO/q7Zjydb0M/24iTfzRIjCJVic52qteQiLPIflJ3pxLvnjqdu8PIfp7qGp3NH+tW wxNiTJDj3/EcTiIPfUG1zsQZTwHw4Qo6oyCFQJzqEf51XrrjlyHbd5SyRJW3o7R/Amvo dNxnDT7DZvV6jJduf01Hp8N/ToSULU6bpotM7Svx8pBI4bp57fr2s8QVPzytAmSTBDZM J/Ga4sb0kLemsCss5XXT92MWE+oP3Qv88EcwH2RzTMOSMKcCzjLu2exX6miqr9LlKbnn K2R9zejV44yqxRQgZjd1cYkfUDIcqV5Za+MQskO/QRJVLlOCo0W+QeWFAJrQ8J+r3FzV 5kzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HG27u7QT//DUXHl5TQAebYaxG1fXIc6/h/rI2WByhhI=; b=Sb/Cg3TyWJR0eUQWpSAoJG4ZSuvJkjG9I+WtQuel6tBnOdh0BL9zTiAULNgUDKF9k2 GFuWEwBE/7gTOkzY5uZDQl9B6O2rDlOA9+RnUFStGg1qec45tNiowEk/QDo5oyRAOcMF 1ggV8TvUSj88f6TKJ6gSIT0uM66H2H+7JgcVFkd5MlMaZM60WGs/aoJjEnlWBXRcjpXw mV9WtmrEBADV9nq9/OU9//UtDSOyXiybzrM0RqI4r0lOMbJK6EeUe5NrOJfDZEA6ywJG kRI/CXtG1DadbbpJrUnVEOuCAivifhVrwxWWlnv476OugI4mwWvPM4saRiUU2S6AABrO AAig== X-Gm-Message-State: AODbwcBGuMqI5q5N0cAI0p9/fc1sX72QJF2rfDIlsi9/X0ATv5IA4z5u oaMH0vAVL9IMANlKkje+KBxcLJReoKWtgOU= X-Received: by 10.202.75.202 with SMTP id y193mr20748364oia.224.1495749122358; Thu, 25 May 2017 14:52:02 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Thu, 25 May 2017 21:51:51 +0000 Message-ID: To: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a11c17dae1cedd70550603ba9" Archived-At: Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 25 May 2017 21:52:05 -0000 --001a11c17dae1cedd70550603ba9 Content-Type: text/plain; charset="UTF-8" We are starting a 2-week Working Group Last Call for Trickle ICE: https://tools.ietf.org/html/draft-ietf-ice-trickle-11 Please review the draft and provide any comments you may have on the document by June 9, 2017. Comments should be sent to the document authors and to the ICE WG list. If you review the document but do not have any comments, please send a note to that effect as well. --001a11c17dae1cedd70550603ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= We are starting a 2-week Working Group Last Call for Trickle ICE:

=C2=A0

https://tools.ietf.org/html/draft-ietf-ice-trickle= -11


=C2=A0Please review the draft and provide any comments you may have on the docum= ent by June 9, 2017.

=C2=A0

<= span style=3D"font-size:10pt;font-family:Arial;color:rgb(33,33,33);vertical= -align:baseline;white-space:pre-wrap">Comments should be sent to the docume= nt authors and to the ICE WG list. If you review the document but do not ha= ve any comments, please send a note to that effect as well.


--001a11c17dae1cedd70550603ba9-- From nobody Fri May 26 03:26:35 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 31C1F129417 for ; Fri, 26 May 2017 03:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 uDz_YSCL6c_I for ; Fri, 26 May 2017 03:26:32 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 43106126C22 for ; Fri, 26 May 2017 03:26:32 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id w10so7596552oif.0 for ; Fri, 26 May 2017 03:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NMMFB7ZQB36/j5t0UqkZdbX5w0lhAIIcEC1diSYQPos=; b=Q6mcA7EKeQBsF8ggLsX1jQPg8fQohwWJyYkxmFPCa+FlZZ34rL0wblxX2oLoqceA// xIirHjEZDog0crlXWTaZZVo7aPeDCHVxL2N/WLz7HqP5c0V5Bn1+cr7LQBJLIPkZPwMX 4dlPmmRrzjtL/ctVWPLCoBXlXDkSA9kUNlSh5Zc27kBV/UKetZVGfVa5M78G4L519od6 wvf5V8rL+YYP9MdcIO47J9FE6IavGlcc6+imPIsj7Ce6bENsA5GlJslIJuQKb8MPEg+s pK4LMgpuf3BvMYcWSeOjuqO3Rc1Nd1NA+wIAh31wbt3IhIZZRuzm9l0c+nKhhXEsBGUS guog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NMMFB7ZQB36/j5t0UqkZdbX5w0lhAIIcEC1diSYQPos=; b=oVsoD6+KVopolNGG4dDw7vcd8xNXbp22w9tvBa/+LVlZ7JzFnv1ZwvngBwWp1VZJx5 QbDSRjwEjB1oEcBQizd4mzijBjzlpDgPhEamHK9lhE5JBX9YlHsqVV4iU83O3DI73LWm ckpxav/1VNWpOG44yAK9zb8e8qHmALZXtpid8gKPpeOSCGF0AATKI+vdft7y/Jl3JpEa yE09gp89oGK59IRVfZRTpV1u3/ggLOTvjXUzK/w3+ZFaQkjGdnxZTWNV/hX5c8Pf+P8i huWIz8shXaMb1GpYqNYG+NJBjMN/R1MfMK629/hpNNkC/sd1ew5fFNugNRJ9x4Ul3Vw/ gIPg== X-Gm-Message-State: AODbwcBpBT9BsvyYLfdFTRm0nwRzYgqj5I1iRd3mteqmNrtleW1sPPsV 2n79odhwoU9GJKTxB3wTaEBXpL5NBNr8Qe4= X-Received: by 10.157.10.43 with SMTP id 40mr632932otg.7.1495794391176; Fri, 26 May 2017 03:26:31 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Fri, 26 May 2017 10:26:19 +0000 Message-ID: To: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1135989458362905506ac516" Archived-At: Subject: [Ice] Peter's review of ICEbis 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, 26 May 2017 10:26:34 -0000 --001a1135989458362905506ac516 Content-Type: text/plain; charset="UTF-8" I have read through ICEbis (which took a very long time because it is very long) and have the following questions and comments: - If we remove lower-priority candidate pairs across check lists, what happens if a certain check list is starved because all of its candidate pairs are lower priority? One option might be to say the limit is per check list. Another is to recognize that it might happen but live with it. - The spec says it's only defined for one TURN server and one STUN server but then it says what to do when more than one TURN server or STUN server is used. I'm guessing we should remove the part about one TURN server rather than the other way around. - Why do we nominate by putting the valid pair in the triggered check queue? Why not just say "send a binding request"? In particular reason? Do we *want* it to be delayed if there are many things in the front of the queue? - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. Would it make sense to define a check list as representing a single component of a single media stream rather than multiple components? That would make the rules and states around check lists much more simple. - Should we keep this "send another candidate exchange when you're Complete" thing? It looks like it's just there to let signaling servers learn something, which I think should be out of scope for this document. Let a SIP document specify that. - Why can't a lite agent start an ICE restart or remove a media stream? Seems like it would make sense for it to be able to, but the spec says it can't. - Since we won't have aggressive nomination, do we still need the "three-second rule" for when candidates can be freed? - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? Why not just say that some candidate pairs are valid. Why have this list of them? Seems like we could remove the concept. - The concept of using a Data Indication for a keepalive seems outdated. In RTCWEB, consent freshness requires the use of binding requests, not data indications. Should we change this? - The one example in the doc uses aggressive nomination, which no longer exists. - What does the phrase "through good box and software security on TURN servers." mean? - Do we still need all the UNASF stuff? - Do our "changes from 5245" section need to be updated? Lastly, while reading through it I found things that could be removed or moved or reworded along with grammar and style fixes. Rather than listing all of them here, I made a PR that has all of them: https://github.com/ice-wg/rfc5245bis/pull/35/files It's kind of big, but I think it's substantial improvement to clarity and readability (else why would I spend the time on it?). --001a1135989458362905506ac516 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read through ICEbis (which took a very long time be= cause it is very long) and have the following questions and comments:
<= br>
-=C2=A0If we remove lower-priority candidate pairs across che= ck lists, what happens if a certain check list is starved because all of it= s candidate pairs are lower priority?=C2=A0 One option might be to say the = limit is per check list.=C2=A0 Another is to recognize that it might happen= but live with it.

- The spec says it's only d= efined for one TURN server and one STUN server but then it says what to do = when more than one TURN server or STUN server is used.=C2=A0 I'm guessi= ng we should remove the part about one TURN server rather than the other wa= y around.

- Why do we nominate by putting the vali= d pair in the triggered check queue?=C2=A0 Why not just say "send a bi= nding request"?=C2=A0 In particular reason?=C2=A0 Do we *want* it to b= e delayed if there are many things in the front of the queue?
- Much of the spec is much more complicated than it otherwise w= ould be because a media stream has more than one component.=C2=A0 Would it = make sense to define a check list as representing a single component of a s= ingle media stream rather than multiple components?=C2=A0 That would make t= he rules and states around check lists much more simple.=C2=A0
- Should we keep this "send another candidate exchange wh= en you're Complete" thing?=C2=A0 It looks like it's just there= to let signaling servers learn something, which I think should be out of s= cope for this document.=C2=A0 Let a SIP document specify that. =C2=A0
=

- Why can't a lite agent start an ICE restart or re= move a media stream?=C2=A0 Seems like it would make sense for it to be able= to, but the spec says it can't.

- Since we wo= n't have aggressive nomination, do we still need the "three-second= rule" for when candidates can be freed?

- Wh= y do we model valid candidate pairs as a separate list of separate candidat= es from the normal check list?=C2=A0 Why not just say that some candidate p= airs are valid.=C2=A0 Why have this list of them? =C2=A0 =C2=A0Seems like w= e could remove the concept.

- The concept of using= a Data Indication for a keepalive seems outdated.=C2=A0 In RTCWEB, consent= freshness requires the use of binding requests, not data indications. =C2= =A0 =C2=A0Should we change this?

- The one example= in the doc uses aggressive nomination, which no longer exists.
<= br>
- What does the phrase "through good box and software se= curity on TURN servers." mean?

-=C2=A0Do we s= till need all the UNASF stuff?

-=C2=A0Do our "= ;changes from 5245" section need to be updated?


Lastly, while reading through it I found things that coul= d be removed or moved or reworded along with grammar and style fixes.=C2=A0= Rather than listing all of them here, I made a PR that has all of them:

=

It's kind of big, but I think it's substantial = improvement to clarity and readability (else why would I spend the time on = it?).

--001a1135989458362905506ac516-- From nobody Fri May 26 03:51:43 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 274BE127337; Fri, 26 May 2017 03:51:33 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149579589308.8693.9579778296035480021@ietfa.amsl.com> Date: Fri, 26 May 2017 03:51:33 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-10.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: Fri, 26 May 2017 10:51:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Christer Holmberg Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-10.txt Pages : 96 Date : 2017-05-26 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 26 03:55: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 A637F129C53 for ; Fri, 26 May 2017 03:55:13 -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 eAzyRn-WwRw5 for ; Fri, 26 May 2017 03:55:12 -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 76AE9127337 for ; Fri, 26 May 2017 03:55:12 -0700 (PDT) X-AuditID: c1b4fb25-377ff700000055fe-f2-5928098ea55f Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.18.22014.E8908295; Fri, 26 May 2017 12:55:10 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Fri, 26 May 2017 12:55:09 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Draft new version: draft-ietf-ice-rfc5245bis-10 Thread-Index: AQHS1g6KDlPU6U9E50uf6H2kLmvhEQ== Date: Fri, 26 May 2017 10:55: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.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D54DE5A81D2E3christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7mW4fp0akwYSpphbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvj8acb7AVnuSv2HrzC2MD4nbOLkZNDQsBE4szrMyxdjFwcQgJH GCU2TutmB0kICSxmlHi8I7OLkYODTcBCovufNkhYREBRYmbLM2YQWxgo/PLoMjaIuK3EsoVN rBC2nsTPg//BbBYBVYn/b3eBjeQVsJZYt+8oE4jNKCAm8f3UGjCbWUBc4taT+UwQ9whILNlz nhnCFpV4+fgfK8gJokAz3+33hAgrSnx8tY8RojVB4v7kXSwQ4wUlTs58wjKBUWgWkqmzkJTN QlIGETeQeH9uPjOErQ30wWsoW19i45ezjLOANjMDXb2jKx1ZyQJGjlWMosWpxUm56UbGeqlF mcnFxfl5enmpJZsYgTFycMtv1R2Ml984HmIU4GBU4uHV+aYeKcSaWFZcmXuIUYKDWUmEdymH RqQQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKEBNITS1KzU1MLUotgskwcnFINjCUvTeXm +YUs+j15C9+nK9avefd9WLrSz/lMf8MuZ4dXeyeuWJEs6/H36RfFtBVvmm0K5lnnmyc/c2dd uWb5v4NOYZfvT/wisqh2chvDu4SA/A3FHy59a4oIf5Sc/mfV22tLJB+07zjfn6YlO/1uBIuc s03JqvOFAfpfAm0K10x3zH5x71CbpKcSS3FGoqEWc1FxIgChL+z0jQIAAA== Archived-At: Subject: [Ice] Draft new version: draft-ietf-ice-rfc5245bis-10 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, 26 May 2017 10:55:13 -0000 --_000_D54DE5A81D2E3christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-10) of draft-5245bis. The main changes are in section 5.1.4.2., where we=92ve tried to make the p= rocedures easier to understand. A big Thank You to Taylor B for commenting = on my original PR, and based on that putting together a better one :) Regards, Christer --_000_D54DE5A81D2E3christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <09302697324B194186D1786A242A459A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-10) of draft-5245bis.

The main changes are in section 5.1.4.2., where we=92ve tried to = make the procedures easier to understand. A big Thank You to Taylor B for c= ommenting on my original PR, and based on that putting together a better on= e :)

Regards,

Christer
--_000_D54DE5A81D2E3christerholmbergericssoncom_-- From nobody Fri May 26 04:07:56 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 90311126B71 for ; Fri, 26 May 2017 04:07:54 -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 gJ5EkPLuAPuw for ; Fri, 26 May 2017 04:07:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8BF129C56 for ; Fri, 26 May 2017 04:07:52 -0700 (PDT) X-AuditID: c1b4fb30-4163b9a0000007db-d7-59280c86e482 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.6E.02011.68C08295; Fri, 26 May 2017 13:07:51 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Fri, 26 May 2017 13:07:50 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] WGLC for draft-ietf-ice-trickle-11 Thread-Index: AQHS1aEoCJEGRi2hKUGJbvJFoAhTGKIGh8+A Date: Fri, 26 May 2017 11:07:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D54DE8081D2F3christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7hG47j0akweOFPBbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBl7F03m7Hgg3rFpqN/mBsY+5S7GDk5JARMJJYe n8kGYgsJHGGU6Ogz6GLkArIXM0o0fznG2sXIwcEmYCHR/U8bpEZEwENi85vlYPXCAqYSG2c9 Z4aIm0nMXX6FCcI2kvj18jobSCuLgKpEy6d4kDCvgLXEgw2/oVYFSDQ8bWMBsTkFAiWeHugH sxkFxCS+n1oDNoZZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B/YZaICehLv9ntChJUkfmy4xALR miAx8XMfO8RaQYmTM5+wTGAUmYVk6iwkZbOQlEHEDSTen5vPDGFrSyxb+BrK1pfY+OUsI4Rt LbH+6TxWZDULGDlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG2cEtvw12ML587niIUYCD UYmHV+ebeqQQa2JZcWXuIUYJDmYlEV5bbo1IId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryO+y5E CAmkJ5akZqemFqQWwWSZODilGhgXrttm/WVNR0aUhbtRUumd5btmFS7vLp/2pi3it9FLziOZ Klf3p+7SiIjKM+I87PfrdWHtjmsi1zemv6042MK5/UDufznB6itT7e89Of97+f+IqRN2azSd uX2y7BOzth3jFcGz+WaJbWt1y4T5f36Qu+H6cqph+Mdvs8xyt87k8V89M/L8tT8flViKMxIN tZiLihMB8o+3064CAAA= Archived-At: Subject: Re: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 26 May 2017 11:07:54 -0000 --_000_D54DE8081D2F3christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I haven=92t read the draft in detail yet, but a general comment: As the draft is making references to sections in draft-5245bis, please note= that some of the section numbers have changed, so you may want to double c= heck that the references are still correct. Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Friday 26 May 2017 at 00:51 To: "ice@ietf.org" > Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 We are starting a 2-week Working Group Last Call for Trickle ICE: https://tools.ietf.org/html/draft-ietf-ice-trickle-11 Please review the draft and provide any comments you may have on the docum= ent by June 9, 2017. Comments should be sent to the document authors and to the ICE WG list. If = you review the document but do not have any comments, please send a note to= that effect as well. --_000_D54DE8081D2F3christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5AC630AB549E0143B051223EC331C170@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I haven=92t read the draft in detail yet, but a general comment:

As the draft is making references to sections in draft-5245bis, please= note that some of the section numbers have changed, so you may want to dou= ble check that the references are still correct.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of "pthatcher@google.com" <pthatcher@google.com>
Date: Friday 26 May 2017 at 00:51 To: "ice@ietf.org" <ice@ietf.= org>
Subject: [Ice] WGLC for draft-ietf-= ice-trickle-11

We are starting a 2-week Working Group Last Call for Trickle= ICE:

 

https://tools.ietf.org= /html/draft-ietf-ice-trickle-11


 Please review the draft and provide any comments you m= ay have on the document by June 9, 2017.

 

Comments should be sent to the docum= ent authors and to the ICE WG list. If you review the document but do not h= ave any comments, please send a note to that effect as well.


--_000_D54DE8081D2F3christerholmbergericssoncom_-- From nobody Fri May 26 04:16:54 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 4F6AD129405 for ; Fri, 26 May 2017 04:16:53 -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 5WPNy6YLZ5Uz for ; Fri, 26 May 2017 04:16:51 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E01126B71 for ; Fri, 26 May 2017 04:16:51 -0700 (PDT) X-AuditID: c1b4fb30-039ff700000007db-25-59280ea10fed Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.70.02011.1AE08295; Fri, 26 May 2017 13:16:49 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Fri, 26 May 2017 13:16:48 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis Thread-Index: AQHS1gqP7riO5+DZ+0SriWSS8FKh1aIGiX8A Importance: high X-Priority: 1 Date: Fri, 26 May 2017 11:16:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D54DEA571D2FCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2J7iO5CPo1Ig9UndCy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKONG2lblgp2dF/77ljA2M52y6GDk5JARMJObP v8QGYgsJHGGUmHLRCsJezCixdH14FyMHB5uAhUT3P22QsIiAh8TmN8vByoUFtCU23VzGBFIi IqAjcX53MESJkcTx+0/ASjgFBCR+tc9igdjEKzFl7kl2EJtFQFXi+fkrYK28AtYSmyY4QSwN kPj5rpsVojVQ4uyK6cwgNqOAmMT3U2uYQGxmAXGJW0/mM0GMFJBYsuc8M4QtKvHy8T9WkJGi AnoS7/Z7QoSVJH5suMQC0ZogsXv1BDCbV0BQ4uTMJywTGMVmIZk6C0nZLCRlEHEDiffn5jND 2NoSyxa+hrL1JTZ+OcsIYVtLLN72jAVZzQJGjlWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsY gRF5cMtvgx2ML587HmIU4GBU4uHV+aYeKcSaWFZcmXuIUYKDWUmEN4JXI1KINyWxsiq1KD++ qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUwWSYOTqkGxnrV3/6Pj1918JKydGPo+XxM om6r6qF0rSNS0yy3/rWKqlpzNHueVQmnWWxrwyeeI++PM01+apFrm3aL2c0z3NPc78nKJZsL tJ9MnrVc+4n4r3MW+rdjjBe/lrKWKW+dKuC0em+sy4lpUZWTl7ybfzTu/xTHzJkGDzK4bteV KSstuXSO9/H3hUosxRmJhlrMRcWJANuUNaPEAgAA Archived-At: Subject: Re: [Ice] Peter's review of ICEbis 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, 26 May 2017 11:16:53 -0000 --_000_D54DEA571D2FCchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, To anyone who is going to comment on Peter's e-mail: I suggest using SEPARA= TE THREADS for each issue (please indicate in the subject what the thread i= s about) =96 otherwise we are going to end up in a big mess. Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Friday 26 May 2017 at 13:26 To: "ice@ietf.org" > Subject: [Ice] Peter's review of ICEbis I have read through ICEbis (which took a very long time because it is very = long) and have the following questions and comments: - If we remove lower-priority candidate pairs across check lists, what happ= ens if a certain check list is starved because all of its candidate pairs a= re lower priority? One option might be to say the limit is per check list.= Another is to recognize that it might happen but live with it. - The spec says it's only defined for one TURN server and one STUN server b= ut then it says what to do when more than one TURN server or STUN server is= used. I'm guessing we should remove the part about one TURN server rather= than the other way around. - Why do we nominate by putting the valid pair in the triggered check queue= ? Why not just say "send a binding request"? In particular reason? Do we= *want* it to be delayed if there are many things in the front of the queue= ? - Much of the spec is much more complicated than it otherwise would be beca= use a media stream has more than one component. Would it make sense to def= ine a check list as representing a single component of a single media strea= m rather than multiple components? That would make the rules and states ar= ound check lists much more simple. - Should we keep this "send another candidate exchange when you're Complete= " thing? It looks like it's just there to let signaling servers learn some= thing, which I think should be out of scope for this document. Let a SIP d= ocument specify that. - Why can't a lite agent start an ICE restart or remove a media stream? Se= ems like it would make sense for it to be able to, but the spec says it can= 't. - Since we won't have aggressive nomination, do we still need the "three-se= cond rule" for when candidates can be freed? - Why do we model valid candidate pairs as a separate list of separate cand= idates from the normal check list? Why not just say that some candidate pa= irs are valid. Why have this list of them? Seems like we could remove t= he concept. - The concept of using a Data Indication for a keepalive seems outdated. I= n RTCWEB, consent freshness requires the use of binding requests, not data = indications. Should we change this? - The one example in the doc uses aggressive nomination, which no longer ex= ists. - What does the phrase "through good box and software security on TURN serv= ers." mean? - Do we still need all the UNASF stuff? - Do our "changes from 5245" section need to be updated? Lastly, while reading through it I found things that could be removed or mo= ved or reworded along with grammar and style fixes. Rather than listing al= l of them here, I made a PR that has all of them: https://github.com/ice-wg/rfc5245bis/pull/35/files It's kind of big, but I think it's substantial improvement to clarity and r= eadability (else why would I spend the time on it?). --_000_D54DEA571D2FCchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0727DBF34192794EA6B73922B1E9A34D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

To anyone who is going to comment on Peter's e-mail: I suggest using S= EPARATE THREADS for each issue (please indicate in the subject what the thr= ead is about) =96 otherwise we are going to end up in a big mess.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of "pthatcher@google.com" <pthatcher@google.com>
Date: Friday 26 May 2017 at 13:26 To: "ice@ietf.org" <ice@ietf.= org>
Subject: [Ice] Peter's review of IC= Ebis

I have read through ICEbis (which took a very long time be= cause it is very long) and have the following questions and comments:

- If we remove lower-priority candidate pairs across check lists,= what happens if a certain check list is starved because all of its candida= te pairs are lower priority?  One option might be to say the limit is = per check list.  Another is to recognize that it might happen but live with it.

- The spec says it's only defined for one TURN server and one STUN ser= ver but then it says what to do when more than one TURN server or STUN serv= er is used.  I'm guessing we should remove the part about one TURN ser= ver rather than the other way around.

- Why do we nominate by putting the valid pair in the triggered check = queue?  Why not just say "send a binding request"?  In = particular reason?  Do we *want* it to be delayed if there are many th= ings in the front of the queue?

- Much of the spec is much more complicated than it otherwise would be= because a media stream has more than one component.  Would it make se= nse to define a check list as representing a single component of a single m= edia stream rather than multiple components?  That would make the rules and states around check lists much more simple.&= nbsp;

- Should we keep this "send another candidate exchange when you'r= e Complete" thing?  It looks like it's just there to let signalin= g servers learn something, which I think should be out of scope for this do= cument.  Let a SIP document specify that.  

- Why can't a lite agent start an ICE restart or remove a media stream= ?  Seems like it would make sense for it to be able to, but the spec s= ays it can't.

- Since we won't have aggressive nomination, do we still need the &quo= t;three-second rule" for when candidates can be freed?

- Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list?  Why not just say that some ca= ndidate pairs are valid.  Why have this list of them?    See= ms like we could remove the concept.

- The concept of using a Data Indication for a keepalive seems outdate= d.  In RTCWEB, consent freshness requires the use of binding requests,= not data indications.    Should we change this?

- The one example in the doc uses aggressive nomination, which no long= er exists.

- What does the phrase "through good box and software security on= TURN servers." mean?

- Do we still need all the UNASF stuff?

- Do our "changes from 5245" section need to be updated= ?


Lastly, while reading through it I found things that could be removed = or moved or reworded along with grammar and style fixes.  Rather than = listing all of them here, I made a PR that has all of them:


It's kind of big, but I think it's substantial improvement to clarity = and readability (else why would I spend the time on it?).

 --_000_D54DEA571D2FCchristerholmbergericssoncom_-- From nobody Fri May 26 13:19:16 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 E93A1129422 for ; Fri, 26 May 2017 13:19:14 -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 BFXZkqGl-mVh for ; Fri, 26 May 2017 13:19:13 -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 168B8124281 for ; Fri, 26 May 2017 13:19:12 -0700 (PDT) X-AuditID: c1b4fb25-377ff700000055fe-63-59288dbde958 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.98.22014.DBD88295; Fri, 26 May 2017 22:19:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0339.000; Fri, 26 May 2017 22:19:09 +0200 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Christer Holmberg CC: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] WGLC for draft-ietf-ice-trickle-11 Thread-Index: AQHS1aEorC+thamAbkmYuxvE0ssLJqIGU9WAgACaCgA= Date: Fri, 26 May 2017 20:19:08 +0000 Message-ID: <178D0285-A6CA-4DDA-B155-C2261A713286@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C1FEBB02A11904D91C6B0F4731E881D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7k+7+Xo1Ig+0HWS2+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK+H73NlvBE+6KGxufsTcw7uHsYuTkkBAwkZjf sJKti5GLQ0jgCKPEpb0nWEESQgKLGSUmHpUEsdkEHCVOPVwLFhcRMJO4/rmXCcRmFvCQ+LKl kR3EFhYwldg46zkzTM3c5VeYIGwriRvvXwH1cnCwCKhKnN5QChLmFbCXeNr0kQliVROjxLY7 eiA2p4CNxLV1qxlBbEYBMYnvp9ZArRKXuPVkPhPEzQISS/acZ4awRSVePv7HCmErSSy6/Rmq 3kDi/bn5zBC2tcTdP3dYIGxtiWULXzND3CAocXLmE5YJjGKzkKyYhaR9FpL2WUjaZyFpX8DI uopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMKIObvmtuoPx8hvHQ4wCHIxKPLz+dRqRQqyJ ZcWVuYcYJTiYlUR4tVWAQrwpiZVVqUX58UWlOanFhxilOViUxHkd912IEBJITyxJzU5NLUgt gskycXBKNTDmL09fvP1ulodJ0vQQ66z2Oyrm7G6btp/s1JiVK+R5zFRVa2O2gcQjvwmsXXou SyTkDl6SXTFr5p9Pv4wCTZU+TchjtHO4fZQvvZthaeGyVecvvJ9zKOX3L9bHv6Y5TUveG9Qa t6pJNemSdFCU4+V9ht+NNwmoLkhpZ14V3LRiYlbxBF5LjV4lluKMREMt5qLiRABXef5rpAIA AA== Archived-At: Subject: Re: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 26 May 2017 20:19:15 -0000 Hi Christer, Good point. I did one round of cross checking section numbers when I did my= review and authors updated those that I found in the latest (-11) version.= But it's good if someone else can check if we missed something. Cheers, Ari > On 26 May 2017, at 14:07, Christer Holmberg wrote: >=20 > Hi, >=20 > I haven=92t read the draft in detail yet, but a general comment: >=20 > As the draft is making references to sections in draft-5245bis, please no= te that some of the section numbers have changed, so you may want to double= check that the references are still correct. >=20 > Regards, >=20 > Christer >=20 > From: Ice on behalf of "pthatcher@google.com" > Date: Friday 26 May 2017 at 00:51 > To: "ice@ietf.org" > Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 >=20 > We are starting a 2-week Working Group Last Call for Trickle ICE: > =20 > https://tools.ietf.org/html/draft-ietf-ice-trickle-11 >=20 > =20 > Please review the draft and provide any comments you may have on the docu= ment by June 9, 2017. >=20 > =20 > Comments should be sent to the document authors and to the ICE WG list. I= f you review the document but do not have any comments, please send a note > to that effect as well.=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Fri May 26 14:23:13 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 27661126CBF for ; Fri, 26 May 2017 14:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 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, 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=Sc4YrrO8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q6ULbrK7 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 Sz9f6LZxWX80 for ; Fri, 26 May 2017 14:23:10 -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 5A40B1274D2 for ; Fri, 26 May 2017 14:23:10 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 67F1120921; Fri, 26 May 2017 17:23:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 26 May 2017 17:23:09 -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=4T1YB+n57M3vlBT6Gy Jgqr/szQx9GVQxC8BAW7DFVgo=; b=Sc4YrrO8WHQngSnXRxR/gph93FiGQmcjiM gSpExQx1wxtGWHaUDunChaC4PV9lUA0ROn/brMfxiiuuY94k157nsnU/j4pg/UZA xu40OmaB4Dy//avctr6AHrPD4ZMqR5bsVXX+RLkWhYbjStWD+l8LM4N9dhX49zJO ciMkeHe2dQfAiaJZpc5HtYexSPdJq7iU4Zu99gGlz5/bcTDXodOjOev6aVVdHwP4 S8VI00WYdAgvDUYL8+hVm5g+HJ8TgjrsUJW+tPyVL8vqRkKfOWQJ8+1mPU6vkHCQ OWwaRMGj1tq6b6SMn1CkRZFQ3UN2MW5fDJRuc5GiHaiCi6y+CJ/Q== 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=4T1YB+n57M3vlBT6GyJgqr/szQx9GVQxC8BAW7DFVgo=; b=Q6ULbrK7 Jh39VHhiJKrWPYsFzPeflghyQFnr+Ob+yD/Z7ddUCBKbczFAGgtsmK/jOyh0lHiT +fXt6/iU/56AyNWF6v1mbS6NK8ZgNokPVo0BVEqt80AOyaP0gGFwHqrhaysqITvT yrsSqkiCWzUJY8YQnuuLyngaS7v9zSB4yCKpo0Mw1sTxPTYuf+hbp2b0Cn0QKBO6 oBG3DO35MmuJvCgwCxHkrWPiVf8I74Tkw2tXL99lfVT0i2XSPumFwoI9B/1pjTlv UzoF7bkUjwVbRb7FPU62V5Z1N/FZ6n9im2TlI7JxjFavfyQO4V7umKieBHJhjvQH Ow1vYSDijeGDJg== X-ME-Sender: X-Sasl-enc: OR/4M9C2IKfEH/pJTHtOoYUdYU6rvaUeo4e8DH1l7tDP 1495833789 Received: from aither.local (mobile-166-171-56-44.mycingular.net [166.171.56.44]) by mail.messagingengine.com (Postfix) with ESMTPA id D51032492A; Fri, 26 May 2017 17:23:08 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <178D0285-A6CA-4DDA-B155-C2261A713286@ericsson.com> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: Date: Fri, 26 May 2017 17:23:05 -0400 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: <178D0285-A6CA-4DDA-B155-C2261A713286@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 26 May 2017 21:23:12 -0000 If I'm correct in assuming that these documents will be progressed together, we can check the section numbers as late as AUTH48. On 5/26/17 4:19 PM, Ari Keränen wrote: > Hi Christer, > > Good point. I did one round of cross checking section numbers when I did my review and authors updated those that I found in the latest (-11) version. But it's good if someone else can check if we missed something. > > > Cheers, > Ari > >> On 26 May 2017, at 14:07, Christer Holmberg wrote: >> >> Hi, >> >> I haven’t read the draft in detail yet, but a general comment: >> >> As the draft is making references to sections in draft-5245bis, please note that some of the section numbers have changed, so you may want to double check that the references are still correct. >> >> Regards, >> >> Christer >> >> From: Ice on behalf of "pthatcher@google.com" >> Date: Friday 26 May 2017 at 00:51 >> To: "ice@ietf.org" >> Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 >> >> We are starting a 2-week Working Group Last Call for Trickle ICE: >> >> https://tools.ietf.org/html/draft-ietf-ice-trickle-11 >> >> >> Please review the draft and provide any comments you may have on the document by June 9, 2017. >> >> >> Comments should be sent to the document authors and to the ICE WG list. If you review the document but do not have any comments, please send a note >> to that effect as well. >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice From nobody Sat May 27 01:01:47 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 DA759126E64 for ; Sat, 27 May 2017 01:01:45 -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 m2Vn_iQSkTUL for ; Sat, 27 May 2017 01:01:44 -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 D7F22120721 for ; Sat, 27 May 2017 01:01:43 -0700 (PDT) X-AuditID: c1b4fb2d-1e1ff70000000d37-6a-59293264c310 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.01.03383.46239295; Sat, 27 May 2017 10:01:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Sat, 27 May 2017 10:01:40 +0200 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] WGLC for draft-ietf-ice-trickle-11 Thread-Index: AQHS1aEorC+thamAbkmYuxvE0ssLJqIGU9WAgACaCgCAABHegIAAsmyA Date: Sat, 27 May 2017 08:01:40 +0000 Message-ID: References: <178D0285-A6CA-4DDA-B155-C2261A713286@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="Windows-1252" Content-ID: <17CF7601A5F87D40B517BC8A94FFFA59@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7rm6akWakwexrnBbfLtRaHNvTz+zA 5LFkyU8mj7l7XjAHMEVx2aSk5mSWpRbp2yVwZfScnshYsECwYsHXpawNjN95uxg5OSQETCR6 u5tYuhi5OIQEjjBKzJm5ng3CWcwo0ftuNwtIFZuAo8Sph2tZQWwRAS2JS9f62LsYOTiYBRQl Xu5VAwkLC5hKbJz1nBmixExi7vIrTBC2m8Tkg7PAWlkEVCWWnD3IBmLzCthLdF88zgqx6w2j xItbe8CKOAXsJHpvrQfbyyggJvH91BqwQcwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJ xiVPWCHqDSTen5vPDGFbS6xfNhdqjrbEsoWvmSGOEJQ4OfMJywRGsVlIVsxC0j4LSfssJO2z kLQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYVwe3/Nbdwbj6teMhRgEORiUeXmNV zUgh1sSy4srcQ4wSHMxKIrx2lzQihXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliS mp2aWpBaBJNl4uCUamBMC3i3SorzLmu22CUHjz1FruL2v3TX3s06WJdt3BqgVXLPde3J0Pq/ 8YWa5swS849YKPvkrWGI3GV39fTrNP2oY1svOJ1cpbnASfy7Y1Dl+32PHAwLJexXXP9975C0 uK13Q9zizFWCO4RXx+j1PvfImcwhzZL/Yp/ussDCHz17ApcHOMhaPVJiKc5INNRiLipOBABa Nf67pwIAAA== Archived-At: Subject: Re: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 27 May 2017 08:01:46 -0000 Yes, as long as Trickle is ready to be published when ICE-bis is, they will= be most likely published at the same time. And AUTH48 would be the last ch= ance for checking. But let's try to keep the references in synch for all ma= jor reviews on the way so that reviewers can easily find the right context. Cheers, Ari > On 27 May 2017, at 00:23, Peter Saint-Andre wrote: >=20 > If I'm correct in assuming that these documents will be progressed > together, we can check the section numbers as late as AUTH48. >=20 > On 5/26/17 4:19 PM, Ari Ker=E4nen wrote: >> Hi Christer, >>=20 >> Good point. I did one round of cross checking section numbers when I did= my review and authors updated those that I found in the latest (-11) versi= on. But it's good if someone else can check if we missed something. >>=20 >>=20 >> Cheers, >> Ari >>=20 >>> On 26 May 2017, at 14:07, Christer Holmberg wrote: >>>=20 >>> Hi, >>>=20 >>> I haven=92t read the draft in detail yet, but a general comment: >>>=20 >>> As the draft is making references to sections in draft-5245bis, please = note that some of the section numbers have changed, so you may want to doub= le check that the references are still correct. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> From: Ice on behalf of "pthatcher@google.com" >>> Date: Friday 26 May 2017 at 00:51 >>> To: "ice@ietf.org" >>> Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 >>>=20 >>> We are starting a 2-week Working Group Last Call for Trickle ICE: >>>=20 >>> https://tools.ietf.org/html/draft-ietf-ice-trickle-11 >>>=20 >>>=20 >>> Please review the draft and provide any comments you may have on the do= cument by June 9, 2017. >>>=20 >>>=20 >>> Comments should be sent to the document authors and to the ICE WG list.= If you review the document but do not have any comments, please send a not= e >>> to that effect as well.=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >=20 From nobody Sat May 27 01:23:52 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 7E9E7124BFA for ; Sat, 27 May 2017 01:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxAokPBt2wru for ; Sat, 27 May 2017 01:23:48 -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 5F4FD1242F7 for ; Sat, 27 May 2017 01:23:48 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-da-5929379277e1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B6.D1.19050.29739295; Sat, 27 May 2017 10:23:46 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Sat, 27 May 2017 10:23:45 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Peter Saint-Andre" CC: "ice@ietf.org" Thread-Topic: [Ice] WGLC for draft-ietf-ice-trickle-11 Thread-Index: AQHS1aEoCJEGRi2hKUGJbvJFoAhTGKIGh8+AgABmEACAABHegIAAsmsAgAAnIZA= Date: Sat, 27 May 2017 08:23:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBCCE00@ESESSMB109.ericsson.se> References: <178D0285-A6CA-4DDA-B155-C2261A713286@ericsson.com> 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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7n+4kc81Ig+7VqhbfLtRaHNvTz+zA 5LFkyU8mj7l7XjAHMEVx2aSk5mSWpRbp2yVwZbR/fs9UcEykYvXXjYwNjOcFuhg5OCQETCRO P0voYuTkEBI4wihx/WFYFyMXkL2YUWLpyo/sIDVsAhYS3f+0QWpEBDIlvi5oZgEJMwsoSrzc qwYSFhYwlTj/7CQjRImZxNzlV5ggbD+Jfd27WUFsFgFViTUNj8HivAK+Ett/7GKBWLWISWJL 93cWkASngIPE8n/H2EFsRgExie+n1oA1MAuIS9x6Mh/MlhAQkFiy5zwzhC0q8fLxP1YIW0li 0e3PUPV6EjemTmGDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFpc nJtuZKSXWpSZXFycn6eXl1qyiREYIQe3/LbawXjwueMhRgEORiUe3hhVzUgh1sSy4srcQ4wS HMxKIrx2lzQihXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCU amAsnjgxxKlAWO1Fp8TkN2YRH09vkZ+Vom+4oe8dx+5X/2w27HZwb6wX+XN7+Q23Sp7LHvf2 8u5K8c1yV7j2v0BR+WOZyuNXkcsfKO/QXmS+MX7OjbJZ1uY/TjXeP9u1ubNnzvPUtXMnRec6 FH0IP3P51Cft3/qH9I2KFk98McH+2aOu07e4F+74pMRSnJFoqMVcVJwIAHkbgPSMAgAA Archived-At: Subject: Re: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 27 May 2017 08:23:50 -0000 Hi, > Yes, as long as Trickle is ready to be published when ICE-bis is, they wi= ll be most likely published > at the same time. And AUTH48 would be the last chance for checking. But l= et's try to keep the > references in synch for all major reviews on the way so that reviewers ca= n easily find the right context. Sure. But, note that some of the Gen-ART, IESG etc reviewers may actually f= ollow the links (at least I typically do that when I perform a Gen-ART revi= ew), in order to see what "hides behind it" :) But, I assume they will raise an issue if things look strange. Regards, Christer > On 27 May 2017, at 00:23, Peter Saint-Andre wrote: >=20 > If I'm correct in assuming that these documents will be progressed=20 > together, we can check the section numbers as late as AUTH48. >=20 > On 5/26/17 4:19 PM, Ari Ker=E4nen wrote: >> Hi Christer, >>=20 >> Good point. I did one round of cross checking section numbers when I did= my review and authors updated those that I found in the latest (-11) versi= on. But it's good if someone else can check if we missed something. >>=20 >>=20 >> Cheers, >> Ari >>=20 >>> On 26 May 2017, at 14:07, Christer Holmberg wrote: >>>=20 >>> Hi, >>>=20 >>> I haven't read the draft in detail yet, but a general comment: >>>=20 >>> As the draft is making references to sections in draft-5245bis, please = note that some of the section numbers have changed, so you may want to doub= le check that the references are still correct. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> From: Ice on behalf of "pthatcher@google.com"=20 >>> >>> Date: Friday 26 May 2017 at 00:51 >>> To: "ice@ietf.org" >>> Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 >>>=20 >>> We are starting a 2-week Working Group Last Call for Trickle ICE: >>>=20 >>> https://tools.ietf.org/html/draft-ietf-ice-trickle-11 >>>=20 >>>=20 >>> Please review the draft and provide any comments you may have on the do= cument by June 9, 2017. >>>=20 >>>=20 >>> Comments should be sent to the document authors and to the ICE WG=20 >>> list. If you review the document but do not have any comments, please s= end a note to that effect as well. >>>=20 >>>=20 >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >=20 _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice From nobody Sun May 28 23:13:24 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 E4A551292F5 for ; Sun, 28 May 2017 23:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-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 YQSI1iCo-0KT for ; Sun, 28 May 2017 23:13:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C3F128DF3 for ; Sun, 28 May 2017 23:13:21 -0700 (PDT) X-AuditID: c1b4fb30-4163b9a0000007db-15-592bbbff3a18 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.8B.02011.FFBBB295; Mon, 29 May 2017 08:13:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0339.000; Mon, 29 May 2017 08:13:19 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5) Thread-Index: AQHS2EKqcQ1YVitsS0inpnvCjV/idA== Date: Mon, 29 May 2017 06:13:19 +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.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <2AEAD88C925E9B4B82A8B7B6693687CC@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7uO7/3dqRBq8/Klh8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CVcWTCTeaCYxwVkz+1MjcwXmTrYuTkkBAwkdj8 +DNLFyMXh5DAEUaJzRe+gyWEBBYzSvx6KtTFyMHBJmAh0f1PGyQsIuAhsfnNcrASYYFkia2z NjGClIgIpEjsPVYGUaIn8eHdDHYQm0VAVeLHyeXMIDavgLXE4fevwGxGATGJ76fWMIHYzALi EreezGeCOEdAYsme88wQtqjEy8f/WEHGiwLNfLffEyKsKNH+tIERolVHYsHuT2wQtrVEV8dJ qLi2xLKFr6HWCkqcnPmEZQKjyCwk22YhaZ+FpH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpM Li7Oz9PLSy3ZxAiMjoNbfhvsYHz53PEQowAHoxIPL8d67Ugh1sSy4srcQ4wSHMxKIrxTy4FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MEZvZ+R32za/ M3SPX2HMsbxo961Vs9r6mnf5JaU8773No39zuTdXbUed0HHumKPnn74NvRa6ku1HiY/tJ9Wb Nxs3i3wVFqmr9JM0cNnx81Tuuc0PVGZZfYmakHNN9vUc+yfro057ScatDGLmvTT39q2tfFds Im/Z2d0trvyQ9l24tPvwiuaMAiWW4oxEQy3mouJEAIk6dcGKAgAA Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5) 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, 29 May 2017 06:13:23 -0000 Hi, > - If we remove lower-priority candidate pairs across check lists, what >happens if a certain check list is starved because all of its candidate >pairs are lower priority? > One option might be to say the limit is per check list. Another is to >recognise that it might happen but live with it. My understanding was always that the limit is per check list, but I agree it may not be very clear. Perhaps we could modify the text as below: In order to limit the attacks described in Section 15.4.1, an agent MUST limit the total number of connectivity checks the agent performs across all CHECK LISTs to a specific value, and this value MUST be configurable. A default of 100 is RECOMMENDED. This limit is enforced by, within each CHECK LIST, discarding the lower-priority candidate=20 pairs of that CHECK LIST, until there are less than a total of 100 candidate=20 pairs in the CHECK LIST SET. The discarding of candidate pairs SHOULD be distributed equally throughout the CHECK LISTs in the CHECK LIST SET. Regards, Christer From nobody Sun May 28 23:38:37 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 3F0E6127977 for ; Sun, 28 May 2017 23:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSMuGY_tj4ve for ; Sun, 28 May 2017 23:38:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B91C127369 for ; Sun, 28 May 2017 23:38:34 -0700 (PDT) X-AuditID: c1b4fb2d-1c9ff70000000d37-65-592bc1e575d1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.4E.03383.5E1CB295; Mon, 29 May 2017 08:38:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Mon, 29 May 2017 08:38:30 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis- Why do we nominate by putting the valid pair in the triggered check queue? (7.1.1) Thread-Index: AQHS2EYvl710MdTO5kmqLa/o+V6VaQ== Date: Mon, 29 May 2017 06:38:29 +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.4.170508 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D55198C51D37Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdVPfFQe1Ig6NtlhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBl7Hi+hr3ggHBF24/XjA2MvQJdjJwcEgImEkta 5zJ1MXJxCAkcYZSYv24PI4SzmFFizv9/QBkODjYBC4nuf9ogDSICHhKb3yxnA6kRFmhklFiy fBYjRKKJUWJxowVIvYiAnsT9R3wgJouAqkT/vFCQCl4Ba4kbN88zg9iMAmIS30+tYQKxmQXE JW49mc8EcY+AxJI9EDUSAqISLx//YwUZIwo08d1+T4iwokT70wZGiNYEiROXupggxgtKnJz5 hGUCo9AsJFNnISmbhaQMIm4g8f7cfGYIW1ti2cLXULa+xMYvZxlnAW1mBrq6rdcIWckCRo5V jKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIFRc3DLb90djKtfOx5iFOBgVOLhTVivHSnEmlhW XJl7iFGCg1lJhHdqOVCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+CxFCAumJJanZqakFqUUw WSYOTqkGxuy+577bZOXnvq14t2AqZxm7/I1ffw1++xTp9E5OSPjx648Ai9WBiqCs2Zc3Pv2b /ea+08M4ywO/3AIyVmlISLxbu/VMVvuX1Vn1iyOOCL5bIq6yi3OnQlTlAkWbnfyyCyW9tgbU Wy6x3Kt008N+n97khkg//7mZDU/2lef2HXvSvcs8s3BBoxJLcUaioRZzUXEiADHDiNyWAgAA Archived-At: Subject: Re: [Ice] Peter's review of ICEbis- Why do we nominate by putting the valid pair in the triggered check queue? (7.1.1) 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, 29 May 2017 06:38:36 -0000 --_000_D55198C51D37Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > - Why do we nominate by putting the valid pair in the triggered check que= ue? Why not just say "send a binding request"? In particular reason? > Do we *want* it to be delayed if there are many things in the front of th= e queue? I wonder whether the reason is to maintain the pacing among the CHECK LISTs= , i.e., to make sure that the nomination request transaction for CHECK LIST= X is not initiated at the same time as a connectivity check transaction fo= r CHECK LIST Y? But, even if we put the pair in the TRIGGERED CHECK LIST, we need to make s= ure it becomes the top-most pair in the list, because we don=92t want to te= st other pairs that may still be i the list. Regards, Christer --_000_D55198C51D37Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

> - Why do we nominate by putting the valid pair in the triggered c= heck queue?  Why not just say "send a binding request"? = ; In particular reason? 
> Do we *want* it to be delayed if there are many things in the fro= nt of the queue?

I wonder whether the reason is to maintain the pacing among the CHECK = LISTs, i.e., to make sure that the nomination request transaction for CHECK= LIST X is not initiated at the same time as a connectivity check transacti= on for CHECK LIST Y?

But, even if we put the pair in the TRIGGERED CHECK LIST, we need to m= ake sure it becomes the top-most pair in the list, because we don=92t want = to test other pairs that may still be i the list.

Regards,

Christer

--_000_D55198C51D37Dchristerholmbergericssoncom_-- From nobody Sun May 28 23:44: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 85520126BF0 for ; Sun, 28 May 2017 23:44:34 -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 lYtZmWNzq9iP for ; Sun, 28 May 2017 23:44:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4F41200B9 for ; Sun, 28 May 2017 23:44:33 -0700 (PDT) X-AuditID: c1b4fb30-039ff700000007db-e0-592bc34c20fa Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.D1.02011.C43CB295; Mon, 29 May 2017 08:44:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Mon, 29 May 2017 08:44:29 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. Thread-Index: AQHS2EcFiI1CctLCKk6poKZrQK4FhA== Date: Mon, 29 May 2017 06:44:29 +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.4.170508 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D5519E2D1D3ADchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdV9f/sHakwZJJ2hbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPJ71lrXgj1DFxU9zWBsYn/N3MXJySAiYSBw7 OZW5i5GLQ0jgCKPE3AOPmSCcxYwSkzdvAspwcLAJWEh0/9MGaRAR8JDY/GY5G0iNsMAqRokd U0+DdYsIrGaUeH/5KitElZ7Ex4PPwWwWAVWJa9M3sYIM4hWwlriwJwokzCggJvH91BomEJtZ QFzi1pP5TBAXCUgs2XOeGcIWlXj5+B9YqyjQyHf7PSHCihLtTxsYIVoTJPb82g5m8woISpyc +YRlAqPQLCRTZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriVcn7jMhq1nAyLGK UbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzB2Dm75bbCD8eVzx0OMAhyMSjy8HOu1I4VYE8uK K3MPMUpwMCuJ8E4tBwrxpiRWVqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgm y8TBKdXAuKP4SOJFf6WCiHRls6cGU33FN/Q03/pjXNG6TrFY8mH+Ob/DUc9tmllaijYubDgY KajI4PkghsNy6zkj+Y2RPPwPV5z8uiKnQUn5UIJPqNqRJUw+Nik33Bct9dr2rtlWRfPFEUmJ 2f/0f/x6/82UR9nCPU4wqLW/vOuweIhno/s6RT9TPnUlluKMREMt5qLiRAATdh2emQIAAA== Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. 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, 29 May 2017 06:44:34 -0000 --_000_D5519E2D1D3ADchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > - Much of the spec is much more complicated than it otherwise would be be= cause a media stream has more than one component. Would it make sense > to define a check list as representing a single component of a single med= ia stream rather than multiple components? That would make the rules and s= tates around check lists much more simple. I have been thinking the same thing :) However, in that case I think we need to talk about certain media streams b= eing =93dependent" on each other, and that checks for both streams (e.g., o= ne RTP stream and one RTCP stream) must succeed in order to the streams to = be used (unless BUNDLE is used, of course). Regards, Christer --_000_D5519E2D1D3ADchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

> - Much of the spec is much more complicated than it otherwise wou= ld be because a media stream has more than one component.  Would it ma= ke sense
> to define a check list as representing a single component of a si= ngle media stream rather than multiple components?  That would make th= e rules and states around check lists much more simple. 

I have been thinking the same thing :)

However, in that case I think we need to talk about certain media stre= ams being =93dependent" on each other, and that checks for both stream= s (e.g., one RTP stream and one RTCP stream) must succeed in order to the s= treams to be used (unless BUNDLE is used, of course).

Regards,

Christer
--_000_D5519E2D1D3ADchristerholmbergericssoncom_-- From nobody Sun May 28 23:50:07 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 1A8A8124217 for ; Sun, 28 May 2017 23:50:06 -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 PvemQUiE96Xn for ; Sun, 28 May 2017 23:50:04 -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 7E9921200B9 for ; Sun, 28 May 2017 23:50:04 -0700 (PDT) X-AuditID: c1b4fb3a-31fff70000004a6a-00-592bc49abf7d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BB.AE.19050.A94CB295; Mon, 29 May 2017 08:50:02 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Mon, 29 May 2017 08:50:02 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? Thread-Index: AQHS2EfLSJWiXi6t0kqXcQwCFgzNtw== Date: Mon, 29 May 2017 06:50:01 +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.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D5519FD01D3BCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdTHfWEe1IgyOfrSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKuPwho2CrTMX6hxOYGhibJLoYOTkkBEwkFlxp ZgKxhQSOMEpM6zXpYuQCshczSjRP+MDexcjBwSZgIdH9TxukRkTAQ2Lzm+VsIDXCAnMZJa5/ 3cMM4ogIzGOU+L18FjNElZ7E31MPwGwWAVWJr1vfsYLYvALWEt93/gCzGQXEJL6fWgO2mVlA XOLWk/lMEBcJSCzZc54ZwhaVePn4HyvIEaJAM9/t94QIK0pcnb6cCSTMLJAg0bzCBGK6oMTJ mU9YJjAKzUIydBZC1SwkVRAlBhLvz81nhrC1JZYtfA1l60ts/HKWEcIGuvnyURQ1Cxg5VjGK FqcWF+emGxnppRZlJhcX5+fp5aWWbGIERs3BLb+tdjAefO54iFGAg1GJh7d0vXakEGtiWXFl 7iFGCQ5mJRHeqeVAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZ ODilGhgtfyllhL9zaPv1piApZk+xV+2Jq5zO4cZh0ToRm/TEFxxSsmfk5Fs1jf/GFq3rTc05 y/5Mczp0KLBJpaDy8Ofy/5LJAnpqt5TV54XN3HY4v6dWbo3M/CDxI5ZsVQddm51SHzzkf/Py e7RUvfSP9A7ut0ZlmSayjz8dYptW/yfAtrvnsvilXCWW4oxEQy3mouJEAIIlcyKWAgAA Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? 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, 29 May 2017 06:50:06 -0000 --_000_D5519FD01D3BCchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > - Why do we model valid candidate pairs as a separate list of separate ca= ndidates from the normal check list? > Why not just say that some candidate pairs are valid. Why have this list= of them? Seems like we could remove the concept. This is related to an e-mail I sent some time ago, where I asked whether we= really need all states etc, and even suggested we could remove some of it.= However, I then decided not to do it, because it could end up in a real me= ss. But, related to your question, when I had a look at it I was thinking that = =93VALID=94 could just be a candidate pair state value, rather than a separ= ate list. Regards, Christer --_000_D5519FD01D3BCchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list? 
> Why not just say t= hat some candidate pairs are valid.  Why have this list of them?  = ;  Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =93VALID=94 could just be a candidate pair state value, rather than a = separate list.

Regards,

Christer



 --_000_D5519FD01D3BCchristerholmbergericssoncom_-- From nobody Mon May 29 00:02: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 7EA67126BF0 for ; Mon, 29 May 2017 00:02: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 ULXpLHYQBNfQ for ; Mon, 29 May 2017 00:02:24 -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 8FB211200F1 for ; Mon, 29 May 2017 00:02:24 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-a2-592bc77e1ce8 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.B1.19050.E77CB295; Mon, 29 May 2017 09:02:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Mon, 29 May 2017 09:02:23 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? Thread-Index: AQHS2EmEkwjXZ0qDuEqc4q1ImlfI2w== Date: Mon, 29 May 2017 07:02:22 +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.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D551A2851D3C7christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9SrfuuHakwZLfFhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBltC87xlJwjr/i/5qN7A2My3m7GDk5JARMJJaf nsfYxcjFISRwhFHi850OZpCEkMBiRol18+W7GDk42AQsJLr/aYOERQQ8JDa/Wc4GYgsLlEms +HqZFSJeLrFyBoytJ3Hs2ENGEJtFQFWic8YLFhCbV8Ba4vLeVrA4o4CYxPdTa5hAbGYBcYlb T+YzQdwjILFkz3lmCFtU4uXjf6wgJ4gCzXy33xMirCjx8dU+RojWBInW2/eYIcYLSpyc+YRl AqPQLCRTZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxrif5Hi1HULGDkWMUoWpxa XJybbmSkl1qUmVxcnJ+nl5dasokRGDcHt/y22sF48LnjIUYBDkYlHt7S9dqRQqyJZcWVuYcY JTiYlUR4hY4BhXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCU amAMPDXba93EWdMOvjza/+Vrhsb0w+X+0+uUu+o/G1ryTdtul7djTaIVz6f1n+OX8l1yu8mW xfnaZ9aMC7xr7jxvMkyp4ctd/di8dJ2y2KvUXq/DnNqH/nlaJ4v7HmFe8/N0kbHsFfcH886V N014VurqfeHEhvDzU5bHHtj5qjZRQfvepdVXLQ7GK7EUZyQaajEXFScCAKVxr6qXAgAA Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? 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, 29 May 2017 07:02:26 -0000 --_000_D551A2851D3C7christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > - Why can't a lite agent start an ICE restart or remove a media stream? = Seems like it would make sense for it to be able to, but the spec says it c= an't. Technically, I guess a lite agent COULD start an ICE restart. But, what wou= ld be the trigger? A lite agent doesn=92t send STUN requests etc. Regards, Christer --_000_D551A2851D3C7christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3B4324D631758A4C88E5A098A0A38329@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> - Why can't a lite agent start an ICE restart or remove a media stream= ?  Seems like it would make sense for it to be able to, but the spec s= ays it can't.

Technically, I guess a lite agent COULD start an ICE restart. But, wha= t would be the trigger? A lite agent doesn=92t send STUN requests etc.

Regards,

Christer

 --_000_D551A2851D3C7christerholmbergericssoncom_-- From nobody Mon May 29 00:08:56 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 7FF481293D9 for ; Mon, 29 May 2017 00:08:53 -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 k0PUcReqtAbO for ; Mon, 29 May 2017 00:08:52 -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 084991200F1 for ; Mon, 29 May 2017 00:08:51 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-06-592bc9028ec6 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.B6.22014.209CB295; Mon, 29 May 2017 09:08:50 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Mon, 29 May 2017 09:08:48 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments Thread-Index: AQHS2EpqeILDrRQvU0WPGJuXgYYlAQ== Date: Mon, 29 May 2017 07:08:47 +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.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D551A3B41D3D4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbE9SpfppHakwYrDIhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPH3YwliwR6Fi/9mZ7A2ML6S6GDk5JARMJD4u m8HexcjFISRwhFFi+7yjjBDOYkaJhZPPsnUxcnCwCVhIdP/TBmkQEfCQ2PxmORuILSyQIPH7 YCc7RDxR4tq+A0wQtp7E4rfrwOIsAqoSkyZ8BLN5BawlJr5oZASxGQXEJL6fWgNWzywgLnHr yXwmiIMEJJbsOc8MYYtKvHz8jxXkBFGgme/2e0KEFSU+vtrHCNGaIPFj3XtGiPGCEidnPmGZ wCg0C8nUWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAY6hea4nT954yI6tZwMixilG0OLU4 KTfdyFgvtSgzubg4P08vL7VkEyMwcg5u+a26g/HyG8dDjAIcjEo8vPLrtSOFWBPLiitzDzFK cDArifAKHQMK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnV wMjaKnW6qIvhWWzjkStrwxqTb0Qem3Hn3OxTKew/8z4/dzFsYG2J3Mk9+67ywnXC0749fvl9 2h71Ps+NFotKPiW7WBnNbvq30/Hk2doLxW1iaiWqexL6XhjsPt3SYat/Prra7mHl249/045t vCAjOdG/5lpARPX3eVNbVLMjLVfVrS9+L3X1YL0SS3FGoqEWc1FxIgB+gzJVmAIAAA== Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments 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, 29 May 2017 07:08:53 -0000 --_000_D551A3B41D3D4christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, > - The spec says it's only defined for one TURN server and one STUN server= but then it says what to do when more than one TURN server or STUN server = is used. I'm guessing we should remove the part about one TURN server rath= er than the other way around. > - Since we won't have aggressive nomination, do we still need the "three-= second rule" for when candidates can be freed? > - The concept of using a Data Indication for a keepalive seems outdated. = In RTCWEB, consent freshness requires the use of binding requests, not dat= a indications. Should we change this? > - What does the phrase "through good box and software security on TURN se= rvers." mean? > - Do we still need all the UNASF stuff? I have currently no input on the comments above. > - Should we keep this "send another candidate exchange when you're Comple= te" thing? It looks like it's just there to > let signaling servers learn something, which I think should be out of sco= pe for this document. Let a SIP document specify that. Where is this text? > - The one example in the doc uses aggressive nomination, which no longer = exists. We need to fix that. > - Do our "changes from 5245" section need to be updated? Yes... Regards, Christer --_000_D551A3B41D3D4christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <165001D6650BC4419DCDFCDEF676F666@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> - The spec says it's only defined for one TURN server and one STU= N server but then it says what to do when more than one TURN server or STUN= server is used.  I'm guessing we should remove the part about one TUR= N server rather than the other way around.
> - Since we won't have aggressive nomination, do we still need the= "three-second rule" for when candidates can be freed?
> - The concept of using a Data Indication for a keepalive seems ou= tdated.  In RTCWEB, consent freshness requires the use of binding requ= ests, not data indications.    Should we change this?
> - What does the phrase "through good box and software securi= ty on TURN servers." mean?
> - Do we still need all the UNASF stuff?

I have currently no input on the comments above.

> - Should we keep this "send another candidate exchange when = you're Complete" thing?  It looks like it's just there to 
> let signaling servers learn something, which I think should be ou= t of scope for this document.  Let a SIP document specify that.  =

Where is this text?

> - The one example in the doc uses aggressive nomination, which no= longer exists.

We need to fix that.

> - Do our "changes from 5245" section need to be up= dated?

Yes...

Regards,

Christer


 --_000_D551A3B41D3D4christerholmbergericssoncom_-- From nobody Mon May 29 05:17:23 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 49DBA129541 for ; Mon, 29 May 2017 05:17:22 -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 Q240j-bIZlIX for ; Mon, 29 May 2017 05:17:21 -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 37347127137 for ; Mon, 29 May 2017 05:17:21 -0700 (PDT) X-AuditID: c1b4fb2d-1c9ff70000000d37-19-592c114c2243 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.3F.03383.C411C295; Mon, 29 May 2017 14:17:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Mon, 29 May 2017 14:17:16 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: trickle-11: Unfreezing of candidate pairs on connectivity check success Thread-Index: AQHS2HWCMmjBMkzGv0yuMV3+mLKe5g== Date: Mon, 29 May 2017 12:17:16 +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.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7lK6/oE6kQVsXt8W3C7UOjB5Llvxk CmCM4rJJSc3JLEst0rdL4MroXPCMpWA9R8W0iR8YGxgPsHUxcnJICJhIfL//jrGLkYtDSOAI o8SVb1eZIJzFjBJrLsxm7mLk4GATsJDo/qcN0iAioCgxs+UZM4gtLBAksfj8EhaIeLjEzBN9 7BC2nsTHbfvAalgEVCWeL/7HCmLzClhL/N5xG2wxo4CYxPdTa5hAbGYBcYlbT+YzQRwkILFk z3lmCFtU4uVjkF4ODlGgme/2e4KYEgJKEtO2pkF06kncmDqFDcK2lng26wSUrS2xbOFrZoit ghInZz5hmcAoMgvJsllI2mchaZ+FpH0WkvYFjKyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2 MQKj4eCW37o7GFe/djzEKMDBqMTD28eoEynEmlhWXJl7iFGCg1lJhPf2Y+1IId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhhjNJm2+syt/ptx/POFuRvm JErtkFsyh3G1RUzS62+CvbUWfs+8nlWnnru4SPMEy0YNsckJGj4vI4Mi1iwu5gw216w7U7Nj janS+W2ziyr+Ks7Zf1D9/wStR3u0WAsk9QsC/DeGz313ttm7+eXyK4G7y9t85905bKx5S9VA bn124cSojNmdIQZKLMUZiYZazEXFiQDhKgDlggIAAA== Archived-At: Subject: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success 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, 29 May 2017 12:17:22 -0000 Hi, We may have discussed this before, but as it still exists in draft-trickle-11 I will comment on it: Section 8.1.1. contains the following text: "Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis]), for each pair that enters the Succeeded state (denoted here by "S"), 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).=B2 First, I believe the 5245bis section to reference is 6.2.5.3.3. Second, according to the text in section 6.2.5.3.3 of 5245bis, *all* pairs for *all* streams (for a given foundation) are unfrozen once the checked pair succeeds - not only pairs for the same stream. "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." Regards, Christer From nobody Mon May 29 18:35:52 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 F0F99129B44 for ; Mon, 29 May 2017 18:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03H0mhilhKvM for ; Mon, 29 May 2017 18:35:49 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 CBE46126CF6 for ; Mon, 29 May 2017 18:35:49 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 9so57187729pfj.1 for ; Mon, 29 May 2017 18:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qlArWxmCUySuI7JcaSkBly2aftTiOL2LvSD859HV34E=; b=RZFkBl394vcl30eQIKIOGuOnEXbIExpQQlhQJUTViUenXHJgqZpGnn+dG2qpp4zw4g xDjy92jc2phRc0WUce5/I2XPUOFSNeygnIc7XMD4RavdY2UwPV24yq9YX4Lrbxnd/4yK /ZYD1o8lgdByOJBJw1LaEDRVBMiqGpA9v6+zwWzRwoUC2cAYQZ17w3DCd/vCgGk/XKGv qAhC8Et2j+T++MEMzOYWePB2LyjhE3BqG4Co2pLMypCb0e6zHiKM8rooplLja3ChtY6l 2UExYVELk743dFB7FmCR9aqQbQmr/fyZiBKnJnpDptf5kcuD0LhojAd4RH540qL0D5a8 s9sw== 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=qlArWxmCUySuI7JcaSkBly2aftTiOL2LvSD859HV34E=; b=q98rAjF4+A/VzYjVFFyhxWhxaY5ev9SUdB0vSj//+IbozC/eVU8xoxdjE1pGVKMgsb +CcGb14oASZbOj/Zm56zfPD9ss/DXqrigiKjrSEzRbxHbJd7tj700Rzq827B5fSxEss2 TTY5ZthDZK2hAace0wTGiKDHylkCCnbDIh2tfOM2rycD5osA3mxRh0AbxNQbr+2SaX6a P43IWTLSTaYUNIdSTOn8ZrDBvrOoecR7KcC86c9gvTFqG4P9OydEWEx/Wh5SZGRzOusG U3J8RsLd5EOUUrO9j3BLD3OlikGllIqdBla6b72kYHRlmG6hAEaeoFDrV9yzphY/EBvE NTpg== X-Gm-Message-State: AODbwcA5yqaiR1r3FkGtPX1vgizzmWWAfNfCDh10obo8rEXNBzzvOoC7 AuESNGSdHXI19Ti3MZk= X-Received: by 10.98.207.132 with SMTP id b126mr20562654pfg.167.1496108149012; Mon, 29 May 2017 18:35:49 -0700 (PDT) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id y20sm15794895pfb.93.2017.05.29.18.35.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 18:35:48 -0700 (PDT) Received: by mail-pf0-f179.google.com with SMTP id m17so57098682pfg.3 for ; Mon, 29 May 2017 18:35:47 -0700 (PDT) X-Received: by 10.84.141.36 with SMTP id 33mr77327305plu.99.1496108147778; Mon, 29 May 2017 18:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Mon, 29 May 2017 18:35:47 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Mon, 29 May 2017 21:35:47 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Peter Thatcher , "ice@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11a720b1ad8e0550b3d27b" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? 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, 30 May 2017 01:35:51 -0000 --94eb2c11a720b1ad8e0550b3d27b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 29, 2017 at 3:02 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > - Why can't a lite agent start an ICE restart or remove a media stream? > Seems like it would make sense for it to be able to, but the spec says it > can't. > > Technically, I guess a lite agent COULD start an ICE restart. But, what > would be the trigger? A lite agent doesn=E2=80=99t send STUN requests etc= . > > Lite agent must be able to initiate ICE restart or things will break. Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-lite end point to another. In this case, 3pcc controller will send an empty re-Invite to an ICE-lite end point, to which it must respond with a new ufrag value. This will initiate an ICE restart on the full ICE end point where 3pcc will forwards the SDP received from ICE-lite endpoint, which should cause full ICE endpoint to start collecting new candidates and run connectivity checks to the ICE-lite end point. Regards, _____________ Roman Shpount --94eb2c11a720b1ad8e0550b3d27b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, May 29, 2017 at 3:0= 2 AM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
Hi,

> - Why can't a lite agent start an ICE restart or remove a media st= ream?=C2=A0 Seems like it would make sense for it to be able to, but the sp= ec says it can't.

Technically, I guess a lite agent COULD start an ICE restart. But, wha= t would be the trigger? A lite agent doesn=E2=80=99t send STUN requests etc= .


Lite agent must be ab= le to initiate ICE restart or things will break. Consider a 3pcc scenario w= here a re-INVITE moves the call from one ICE-lite end point to another. In = this case, 3pcc controller will send an empty re-Invite to an ICE-lite end = point, to which it must respond with a new ufrag value. This will initiate = an ICE restart on the full ICE end point where 3pcc will forwards the SDP r= eceived from ICE-lite endpoint, which should cause full ICE endpoint to sta= rt collecting new candidates and run connectivity checks to the ICE-lite en= d point.

Regards,
_____________
Roman Shpount
=C2=A0
<= /div>
--94eb2c11a720b1ad8e0550b3d27b-- From nobody Tue May 30 07:03:23 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 B76EE12940F for ; Tue, 30 May 2017 07:03:21 -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=unavailable 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 0pEvuMLMmMIk for ; Tue, 30 May 2017 07:03:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7EDD126C25 for ; Tue, 30 May 2017 06:56:28 -0700 (PDT) X-AuditID: c1b4fb30-4163b9a0000007db-d0-592d7a0a7643 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BF.E1.02011.A0A7D295; Tue, 30 May 2017 15:56:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Tue, 30 May 2017 15:56:27 +0200 From: Christer Holmberg To: Roman Shpount CC: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? Thread-Index: AQHS2OUS2o6Dy/2G+E2qAmGsup74daIM+cYA Date: Tue, 30 May 2017 13:56:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D55355761D573christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7tC5XlW6kQdcqbYtvF2otri1/zWox 48JUZgdmjwWbSj2WLPnJ5HFrSkEAcxSXTUpqTmZZapG+XQJXRufMBYwF5ywr3vWcY2pgbDXs YuTgkBAwkTh8w6qLkYtDSOAIo8T+tx8YIZzFjBKtt9+xghSxCVhIdP/T7mLk5BARUJX4+30y E4jNLOAh8WVLIzuILSxQKrFv2SRGiJoyiZU7nrNB2EYSV0+vZQGxWYB6Gx5eBYvzClhLbH19 igViVxOjxOSHu5lBEpwCgRJ/Jq0HK2IUEJP4fmoN1DJxiVtP5oPZEgICEkv2nGeGsEUlXj7+ B3anqICexLv9nhBhJYkfGy6xQLQmSHz9cBtqr6DEyZlPWCYwis5CMnUWkrJZSMog4gYS78/N Z4awtSWWLXwNZetLbPxylhHCtpa4fGoGE7KaBYwcqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJL NjECY/Lglt8GOxhfPnc8xCjAwajEw3syVTdSiDWxrLgy9xCjBAezkghvVTlQiDclsbIqtSg/ vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsY2P6HVf7ReMd/KZOY9+NBY 7fN+SYeXT65Me3/p11Hens8aMjoLPTLO+MvVWemEGT5u1Gf+7PX8a/P3awdeZqwQ1T65Lf/u 5iuTm4Qzllc1rBc0PfKmprTHL2nLu8Kfip/zi7Zvfn6y0ip/S9b2V9fd562ofCJSqbXi5FJ1 nnuqSzS91pwW+8auxFKckWioxVxUnAgAOcTi38UCAAA= Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? 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, 30 May 2017 14:03:22 -0000 --_000_D55355761D573christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The draft contains the following text in section 7.2.1: "The lite implementation will never itself determine that ICE processing has failed for a media stream; rather, the full peer will make that determination and then remove or restart the failed media stream as part of subsequent candidate exchange process." But, the way I read it, it=92s more about determining ICE failure. Is there= any text actually preventing an lite implementation from doing a restart? = I can=92t find such text anywhere. In any case, it would probably be a good idea to modify the text, and/or cl= arify that an lite agent is allowed to trigger a restart. Regards, Christer From: Roman Shpount > Date: Tuesday 30 May 2017 at 04:35 To: Christer Holmberg > Cc: "pthatcher@google.com" >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start = an ICE restart or remove a media stream? On Mon, May 29, 2017 at 3:02 AM, Christer Holmberg > wrote: Hi, > - Why can't a lite agent start an ICE restart or remove a media stream? = Seems like it would make sense for it to be able to, but the spec says it c= an't. Technically, I guess a lite agent COULD start an ICE restart. But, what wou= ld be the trigger? A lite agent doesn=92t send STUN requests etc. Lite agent must be able to initiate ICE restart or things will break. Consi= der a 3pcc scenario where a re-INVITE moves the call from one ICE-lite end = point to another. In this case, 3pcc controller will send an empty re-Invit= e to an ICE-lite end point, to which it must respond with a new ufrag value= . This will initiate an ICE restart on the full ICE end point where 3pcc wi= ll forwards the SDP received from ICE-lite endpoint, which should cause ful= l ICE endpoint to start collecting new candidates and run connectivity chec= ks to the ICE-lite end point. Regards, _____________ Roman Shpount --_000_D55355761D573christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <010C6CCC7822E44EA95E83C6B1D3D0B3@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

The draft contains the following text in section 7.2.1:
   "The lite implementation w=
ill never itself determine that ICE
   processing has failed for a media stream; rather, the full peer will
   make that determination and then remove or restart the failed media
   stream as part of subsequent candidate exchange process."
But, the way I read it, it=92s more about determining ICE failure. Is = there any text actually preventing an lite implementation from doing a rest= art? I can=92t find such text anywhere.

In any case, it would probably be a good idea to modify the text, and/= or clarify that an lite agent is allowed to trigger a restart.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 30 May 2017 at 04:35<= br> To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "pthatcher@google.com" <pthatcher@google.com>, "ice@ietf.org" <ice@ietf= .org>
Subject: Re: [Ice] Peter's review o= f ICEbis - Why can't a lite agent start an ICE restart or remove a media st= ream?


On Mon, May 29, 2017 at 3:02 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

> - Why can't a lite agent start an ICE restart or remove a media stream= ?  Seems like it would make sense for it to be able to, but the spec s= ays it can't.

Technically, I guess a lite agent COULD start an ICE restart. But, wha= t would be the trigger? A lite agent doesn=92t send STUN requests etc.


Lite agent must be able to initiate ICE restart or things will break. = Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-lite= end point to another. In this case, 3pcc controller will send an empty re-= Invite to an ICE-lite end point, to which it must respond with a new ufrag value. This will initiate an ICE= restart on the full ICE end point where 3pcc will forwards the SDP receive= d from ICE-lite endpoint, which should cause full ICE endpoint to start col= lecting new candidates and run connectivity checks to the ICE-lite end point.

Regards,
_____________
Roman Shpount
 
 --_000_D55355761D573christerholmbergericssoncom_-- From nobody Wed May 31 17:39: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 5080F129A8D for ; Wed, 31 May 2017 17:39:39 -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 M1InyN0xDAlQ for ; Wed, 31 May 2017 17:39:37 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 2E54A126C23 for ; Wed, 31 May 2017 17:39:37 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id o65so11551560oif.1 for ; Wed, 31 May 2017 17:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CgUJTG69Br778ozsgg9E+rPZMaqEOoC815AtO+fbUn8=; b=OHD5WuggQ0KnhOR+2DKN9RMQWmega8UH72MVQWAypE6gakOZermjXV3eMMmOG2g6tX bqOCNlV1dnqSGgRhPttBdYXrtKNCStIWQOjij9xz/9R5P3cNVTO8OzEQudgHhfjLpyCm 4/63h7BdzUqsQgSqMW5eypUVcNha7XJdnkWaabkus4TRheO/hPD6DGDKRpJal+TZvuSw cI3M+1HBp6QtqSE9n6WsRddp0vJTe6MglxAUY5a9KRhC6S2lO6YQM/tisd6cbZa940Lz DMAq9cW6NFGa2Y0iZhs9w+vsS9CYxMi13BYVwAMVViNwjGW1HyaB3mqZvhuegeLbj1cg TkCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CgUJTG69Br778ozsgg9E+rPZMaqEOoC815AtO+fbUn8=; b=RM0vKr2xF+KfjOIH8gxkNaSwmW8MPK9F3fYNnvp6ODRI3oALT86LR3oihcQEQEUCQD /ukW3HLEvvFKykLaFnPEtnGeeMFGcqD1UiI6IPIrnJBaKzxrtjANrZu4Sp2Z7asWsUtY Qyj/SGd11wJ6xmUbVblxfnFesfLPljt3M7N+VOCZBLjyTgwk62adpqHUM1mLEa9hJtYZ h/GqB66qfK1JN7WvhYl5cco51tPLwO81xwDs3j4KgVdjjWtXmykrGGGe3eNch3QJc2He UxuKMW3ZCjOy9LRoHuPUIKZ8pme67lNCeFfREvYfEjXPYhVnd9eDU7vtBlajMfv1ssNu vTsQ== X-Gm-Message-State: AODbwcCmdLWghKVda3vpIgMh5jVk6AQl0djs+VzMz4aTA46RMSeEsKDs Jm294rpGgSWnMtl1L8tHJ2JHSR6hm2gd X-Received: by 10.157.27.208 with SMTP id v16mr12118495otv.103.1496277576476; Wed, 31 May 2017 17:39:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 00:39:25 +0000 Message-ID: To: Christer Holmberg , Roman Shpount Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1141481a6ec8a80550db4540" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? 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, 01 Jun 2017 00:39:39 -0000 --001a1141481a6ec8a80550db4540 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "The lite implementation will never itself determine that ICE processing has failed for a media stream ... rather, the full peer will mak= e that determination and ... restart" sounds to me like "Full will restart; lite will not restart". However, if you're right and it realy means "Full may restart because of failure; lite may restart for other reasons", then I agree we should perhaps reword it to make it clear that the lite side can restart. Why would a lite side restart? Well, if it's a client->server situation (a common use case for ICE lite), the server may be failing over to another server with a different IP address. Rather than wait for the client to notice, it can signal it to the client. Now you may say "then let the server signal to the client to signal the ICE restart". But not only is that silly, but it also highlights the fact that this is really out of scope for ICEbis to define and that ICEbis should leave it to the using/signaling protocol to define. I think we should just say in ICEbis something like "the using protocol defines how ICE restarts are triggered" and that's about it. On Tue, May 30, 2017 at 6:56 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The draft contains the following text in section 7.2.1: > > "The lite implementation will never itself determine that ICE > processing has failed for a media stream; rather, the full peer will > make that determination and then remove or restart the failed media > stream as part of subsequent candidate exchange process." > > But, the way I read it, it=E2=80=99s more about determining ICE failure. = Is there > any text actually preventing an lite implementation from doing a restart?= I > can=E2=80=99t find such text anywhere. > > In any case, it would probably be a good idea to modify the text, and/or > clarify that an lite agent is allowed to trigger a restart. > > Regards, > > Christer > > From: Roman Shpount > Date: Tuesday 30 May 2017 at 04:35 > To: Christer Holmberg > Cc: "pthatcher@google.com" , "ice@ietf.org" < > ice@ietf.org> > Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent > start an ICE restart or remove a media stream? > > > On Mon, May 29, 2017 at 3:02 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> > - Why can't a lite agent start an ICE restart or remove a media >> stream? Seems like it would make sense for it to be able to, but the sp= ec >> says it can't. >> >> Technically, I guess a lite agent COULD start an ICE restart. But, what >> would be the trigger? A lite agent doesn=E2=80=99t send STUN requests et= c. >> >> > Lite agent must be able to initiate ICE restart or things will break. > Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-li= te > end point to another. In this case, 3pcc controller will send an empty > re-Invite to an ICE-lite end point, to which it must respond with a new > ufrag value. This will initiate an ICE restart on the full ICE end point > where 3pcc will forwards the SDP received from ICE-lite endpoint, which > should cause full ICE endpoint to start collecting new candidates and run > connectivity checks to the ICE-lite end point. > > Regards, > _____________ > Roman Shpount > > --001a1141481a6ec8a80550db4540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"= The lite implementation will never itself determine that ICE
 processing has failed fo= r a media stream ... rather, the full peer will make that determination and ... restart" sounds to me like "Full will restart; lite will not rest= art".

However, if y= ou're right and it realy means "Full may restart because of failur= e; lite may restart for other reasons", then I agree we should perhaps= reword it to make it clear that the lite side can restart.
<= div>
Why would a lite sid= e restart? Well, if it's a client->server situation (a common use c= ase for ICE lite), the server may be failing over to another server with a = different IP address. Rather than wait for the client to notice, it can si= gnal it to the client.

Now you may say = "then let the server signal to the client to signal the ICE restart&qu= ot;.=C2=A0 But not only is that silly, but it also highlights the fact that= this is really out of scope for ICEbis to define and that ICEbis should le= ave it to the using/signaling protocol to define. =C2=A0

I think we should just say in ICEbis something like "the using = protocol defines how ICE restarts are triggered" and that's about = it.





On Tue, May 30, 2017 at 6:56 AM Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:
Hi,

The draft contains the following text in section 7.2.1:
   "The lite implementation will never itself determine th=
at ICE
   processing has failed for a media stream; rather, the full peer will
   make that determination and then remove or restart the failed media
   stream as part of subsequent candidate exchange process."
But, the way I read it, it=E2=80=99s more about determining ICE failur= e. Is there any text actually preventing an lite implementation from doing = a restart? I can=E2=80=99t find such text anywhere.

In any case, it would probably be a good idea to modify the text, and/= or clarify that an lite agent is allowed to trigger a restart.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 30 May 2017 at 04:35<= br> To: Christer Holmberg <christer.holmb= erg@ericsson.com>
Cc: "pthatcher@google.com" <pthatcher@google.com= >, "ice@ietf.org<= /a>" <ice@ietf.or= g>
Subject: Re: [Ice] Peter's revi= ew of ICEbis - Why can't a lite agent start an ICE restart or remove a = media stream?


On Mon, May 29, 2017 at 3:02 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

> - Why can't a lite agent start an ICE restart or remove a media st= ream?=C2=A0 Seems like it would make sense for it to be able to, but the sp= ec says it can't.

Technically, I guess a lite agent COULD start an ICE restart. But, wha= t would be the trigger? A lite agent doesn=E2=80=99t send STUN requests etc= .


Lite agent must be able to initiate ICE restart or things will break. = Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-lite= end point to another. In this case, 3pcc controller will send an empty re-= Invite to an ICE-lite end point, to which it must respond with a new ufrag value. This will initiate an ICE= restart on the full ICE end point where 3pcc will forwards the SDP receive= d from ICE-lite endpoint, which should cause full ICE endpoint to start col= lecting new candidates and run connectivity checks to the ICE-lite end point.

Regards,
_____________
Roman Shpount
=C2=A0
--001a1141481a6ec8a80550db4540-- From nobody Wed May 31 18:08:06 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 AFF181294A4 for ; Wed, 31 May 2017 18:08:04 -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 NgoeFF7Ogn-X for ; Wed, 31 May 2017 18:07:57 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 BCB7112941D for ; Wed, 31 May 2017 18:07:57 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id o65so12080721oif.1 for ; Wed, 31 May 2017 18:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fvNW7nIwFgACNETTOo7lcsy8z5eaX30rIq8UXXU1T8A=; b=RtIrPIU8kOiAjiPWzNbpm3dmXcSIXXasa4U9q8KvsgZwFxW6D4rPC+sxHwohqaBytR /OfgOz92LeNPukuLeWXlsfLVhpOG6UH4DUmJRnpMyKG8UA60GcMlgqtE7ir5LsornV2a fECFistPil8yDXsmj8P59A9tmG+CYI15vYed1qGioQ5XxzL7wfQlvwxX+K7HRfkxFf5k r9GEiH49Cf/tslx6HM6Olliu4alNJrwxCy0lUTt1PF6DI0Ld8xPfYGGK3JmWHuycM2nh Qmc78StRMNXaSt17c0jown40dJC/0ogn6KObl2mSIGwqc0W/eMJAUCy7SN0n0PeTViLG BuaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fvNW7nIwFgACNETTOo7lcsy8z5eaX30rIq8UXXU1T8A=; b=p7TnDmloeu8caCkd8uiP72crPG7Onpp9VBMMlcmP0JK8SIpdWicLEINLexWkgvJf5F ZtvCCNpHTnRhP1LgCZ5S2F4sK9uWFYaoeTJAkVb0D0Cf0bA76ZeSYO/VqAuORwOLqVeY G42Q1bUgIbdHGbybAMKyxh0E8EhmWwdsBaMuoKXAC5RlHQ855qQkDvfnwMipfBosYtwR fwFtyvIfU82P6jWtSCEI7sKIvGrZyNOPPstr3aJzydyaDdtOxIx2q8qIVrxVGscYWx7y uNcM8ghmDqJzoSr2ik8mOxjVVZtKD1DiZH1izM8LtqHLn3eUXOBNa+yvL0C270rJxs80 cDsg== X-Gm-Message-State: AODbwcDlQgt2rR7sjh7aZ3HuRRPwVuQ8AXJ5LRE6+MgqjkauUW5ChIYd UIG/HjqKlrgghcYRz2zk96FLA1JLqjUCGaM= X-Received: by 10.202.197.205 with SMTP id v196mr11358404oif.37.1496279277117; Wed, 31 May 2017 18:07:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 01:07:46 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113e22b8cc7c830550dbaa25" Archived-At: Subject: Re: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success 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, 01 Jun 2017 01:08:05 -0000 --001a113e22b8cc7c830550dbaa25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm a little confused about the second point. It seems like the text is saying to unfreeze the pairs with the same foundation in all check lists, and that sounds correct to me. Are you saying it shouldn't unfreeze across all check lists? On Mon, May 29, 2017 at 5:17 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > We may have discussed this before, but as it still exists in > draft-trickle-11 I will comment on it: > > Section 8.1.1. contains the following text: > > "Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis]= ), > for each pair that enters the Succeeded state (denoted here by > "S"), > 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 th= e > agent will unfreeze the pair in column 1, row 2).=C2=B2 > > > First, I believe the 5245bis section to reference is 6.2.5.3.3. > > Second, according to the text in section 6.2.5.3.3 of 5245bis, *all* pair= s > for *all* streams (for a given foundation) are unfrozen once the checked > pair succeeds - not only pairs for the same stream. > > "The success of the connectivity check might also cause the state > of > other candidate pairs to change. The ICE agent MUST set the stat= es > for all other Frozen candidate pairs (in each CHECK LIST in the > CHECK > LIST SET) with the same foundation to Waiting." > > > Regards, > > Christer > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a113e22b8cc7c830550dbaa25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm a little confused about the second point.=C2=A0 It= seems like the text is saying to unfreeze the pairs with the same foundati= on in all check lists, and that sounds correct to me.=C2=A0 Are you saying = it shouldn't unfreeze across all check lists? =C2=A0

On Mon, May 29, 2017 at 5:17 AM Christer= Holmberg <christer.ho= lmberg@ericsson.com> wrote:
= Hi,

We may have discussed this before, but as it still exists in
draft-trickle-11 I will comment on it:

Section 8.1.1. contains the following text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Then, as the checks proceed (see Section = 6.2.5.4 of [rfc5245bis]),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for each pair that enters the Succeeded state (= denoted here by "S"),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the agent will unfreeze all pairs for the same = media stream and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 foundation (e.g., if the pair in column 1, row = 1 succeeds then the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 agent will unfreeze the pair in column 1, row 2= ).=C2=B2


First, I believe the 5245bis section to reference is 6.2.5.3.3.

Second, according to the text in section 6.2.5.3.3 of 5245bis, *all* pairs<= br> for *all* streams (for a given foundation) are unfrozen once the checked pair succeeds - not only pairs for the same stream.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The success of the connectivity check mig= ht also cause the state of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other candidate pairs to change.=C2=A0 The ICE = agent MUST set the states
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all other Frozen candidate pairs (in each C= HECK LIST in the CHECK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LIST SET) with the same foundation to Waiting.&= quot;


Regards,

Christer

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--001a113e22b8cc7c830550dbaa25-- From nobody Wed May 31 18:13: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 D20271294A4 for ; Wed, 31 May 2017 18:13:34 -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 OflXMELNLEzs for ; Wed, 31 May 2017 18:13:33 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCB912948F for ; Wed, 31 May 2017 18:13:33 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id h4so36883760oib.3 for ; Wed, 31 May 2017 18:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4zeHvOStASsoewEbEMMRy5TO4ZUJ9KH1UumBYClEQDs=; b=I1vpydRiwNo3FiabPRV6FzHWnrJ0P1Z6wJcAwUPxj/qPNtplIojCZWaXZT0mnd9x26 VbjJFvRWmzmKz1JQ23VWsFnunIhqOzJN5kb2iqumdiC/8KHaMVjVLXNyWztiOsMHMaks i2RXph4jzyEhO3Tm87Ji+CO/9sq6R0M4rBbipXuhH3TJSdo9l9sGFZdPongtzP0lTPM4 jg8jzQSPkSwArXQW/tYRYHAfe30NiMpNZRQRo1SBcKdspDWAbVZwpwF8lDUQVj/LvisD V/YELv4/axVSEYwOq3pwg3YIq/YU7Vd4yMu4AGtkdBRVQuDJ4X24+CJGRLGzFaGfFYrp AzTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4zeHvOStASsoewEbEMMRy5TO4ZUJ9KH1UumBYClEQDs=; b=d3UYoTFxdBYuI2yqdewzoSUTGR9Qq7fmbTdmS9zQLmMoDyYYDMUxmtKLzNNnpq5urT bt5JxTeEJD/hl3Ake32CzRyMIIalqz5OTmXRPUONZ9b8yBo+ZCf3O6jkqyPjFBNRYmvZ ATJ2O5f0X6ymG1fPPbYVsmWoNjP9NH2xGQi0o0x2mWEjDIly1axmMTxqWSvPerpQ7pzS PWjAgeCjJtukPEhFB84PR8LMypBiAjbVyV99pURs1Ye2bQtspazN9Ial+0uHv7ai1SgD L174zbHNKwb5GrYiK2F2EfmpiaEml2wkmvzPzRLeJoUsZzv4wKHlSqxjTzF8cGSWsoa0 2Lpg== X-Gm-Message-State: AODbwcDMrdE9ex7QszcEkInoQ4pXOQVyqyu9SWFK8oIy24YQmv+3UuOZ pBOyL97AafG1Eealae808XrcBAeDkP9C X-Received: by 10.202.82.23 with SMTP id g23mr11551239oib.217.1496279612587; Wed, 31 May 2017 18:13:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 01:13:22 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113d77cccb5b2a0550dbbe9e" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5) 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, 01 Jun 2017 01:13:35 -0000 --001a113d77cccb5b2a0550dbbe9e Content-Type: text/plain; charset="UTF-8" So basically add that it should be evenly distributed to avoid starving one check list? That sounds good to me. Just make sure you don't have 101 check lists :). On Sun, May 28, 2017 at 11:13 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > - If we remove lower-priority candidate pairs across check lists, what > >happens if a certain check list is starved because all of its candidate > >pairs are lower priority? > > One option might be to say the limit is per check list. Another is to > >recognise that it might happen but live with it. > > My understanding was always that the limit is per check list, but I agree > it may not be very clear. > > Perhaps we could modify the text as below: > > In order to limit the attacks described in Section 15.4.1, an agent > MUST limit the total number of connectivity checks the agent performs > across all CHECK LISTs to a specific value, and this value MUST be > configurable. A default of 100 is RECOMMENDED. This limit is > enforced by, within each CHECK LIST, discarding the lower-priority > candidate > pairs of that CHECK LIST, until there are less than a total of 100 > candidate > pairs in the CHECK LIST SET. The discarding of candidate pairs SHOULD be > distributed equally throughout the CHECK LISTs in the CHECK LIST SET. > > > Regards, > > Christer > > > --001a113d77cccb5b2a0550dbbe9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So basically add that it should be evenly distributed to a= void starving one check list? =C2=A0

That sounds good to= me.=C2=A0 Just make sure you don't have 101 check lists :).

On Sun, May 28, 2017 at 11= :13 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

> - If we remove lower-priority candidate pairs across check lists, what=
>happens if a certain check list is starved because all of its candidate=
>pairs are lower priority?
> One option might be to say the limit is per check list.=C2=A0 Another = is to
>recognise that it might happen but live with it.

My understanding was always that the limit is per check list, but I agree it may not be very clear.

Perhaps we could modify the text as below:

=C2=A0 =C2=A0In order to limit the attacks described in Section 15.4.1, an = agent
=C2=A0 =C2=A0MUST limit the total number of connectivity checks the agent p= erforms
=C2=A0 =C2=A0across all CHECK LISTs to a specific value, and this value MUS= T be
=C2=A0 =C2=A0configurable. A default of 100 is RECOMMENDED.=C2=A0 This limi= t is
=C2=A0 =C2=A0enforced by, within each CHECK LIST, discarding the lower-prio= rity
candidate
=C2=A0 =C2=A0pairs of that CHECK LIST, until there are less than a total of= 100
candidate
=C2=A0 =C2=A0pairs in the CHECK LIST SET. The discarding of candidate pairs= SHOULD be
=C2=A0 =C2=A0distributed equally throughout the CHECK LISTs in the CHECK LI= ST SET.


Regards,

Christer


--001a113d77cccb5b2a0550dbbe9e-- From nobody Wed May 31 18:15: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 804DA1296B0 for ; Wed, 31 May 2017 18:15:55 -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 R7pm3v4siRG7 for ; Wed, 31 May 2017 18:15:52 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D53129666 for ; Wed, 31 May 2017 18:15:51 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id o65so12228534oif.1 for ; Wed, 31 May 2017 18:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RpO24NKSuupqzUNpL23ypZ8EqzwCJld3k9oyBTK7RnU=; b=P14lvKUe2t9JQplO86ST9l9APigYpJgfWGjCZgt59ACrbI7irrxO6nUxop0es1AnR7 mD9SM0UUIHhjEjwZvI/wD1kOwOKVAYWhKdjtdneNROILUJckKy5c2feZRt1Cq2FCIwFP NUWj5hkcQL4UAWXOqSdojwLov5xXkpTJEj9pITw6Xb4Z62LmBARqE0npw9WQlQJiNgiP i4lpOGxdI2y0uOdMgsEAUSNj/e6rRCCYv6lfY38gw3iwojIIadGnF6CkpMTVFmXxby9j lCfyPpqPv66JOPr+Go8KmuyNq4mulWPKvkaJe0qPGIbroFt0S1LIiK/AtdD9Dt8DdX1h xeFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RpO24NKSuupqzUNpL23ypZ8EqzwCJld3k9oyBTK7RnU=; b=pOycPtLg9SG7xeaJhKfIt9c8hbMUgu4HSzYOkV2vqapUvqCtaOD2TdHyf/DLs1Tw/1 AIaUzA5VJUBnl7HDlCvLVmf2kmdNfDYBIjFXhAEtGls2torLjKi+rmF1Uqa2I2rC0MmL mP86Cou+HAkv+Wbg5mf+5WMkRyLzpW/TCkZqKIKhmuzRBwexdxT2Q1aRMBiBZxwMwcZw rdhyavQ9/CxOnkFcRiRX84gN72p4EtCV3K3kbEQ8McPLfXsiP0uKCoAwFLiSsKfrBldw 0QlsTxV2fcpSbu+82BiC2t5MY6h1iyf5KPnJBvb+KSuQaQ4QpwDX9Jr8YVr51gAxFhqd Pn5w== X-Gm-Message-State: AODbwcCP+CPdWK+n468HK2cgNSccWjYuNS+V8fFyoVkDnzqRmh0P/EzM v6w5WVE8Dn/tVKAW0y4fD2aDOd9G+5apk78= X-Received: by 10.157.17.144 with SMTP id v16mr8357878otf.209.1496279750713; Wed, 31 May 2017 18:15:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 01:15:40 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1922a40700760550dbc7fc" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis- Why do we nominate by putting the valid pair in the triggered check queue? (7.1.1) 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, 01 Jun 2017 01:15:55 -0000 --94eb2c1922a40700760550dbc7fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The pacing rules are clear that they apply to all checks. I don't think we need to over-specify the algorithm for doing so. And I don't think we need to be over-specific about when the nominating check sent either. Let the agent/implementation decide. On Sun, May 28, 2017 at 11:38 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > - Why do we nominate by putting the valid pair in the triggered check > queue? Why not just say "send a binding request"? In particular reason? > > Do we *want* it to be delayed if there are many things in the front of > the queue? > > I wonder whether the reason is to maintain the pacing among the CHECK > LISTs, i.e., to make sure that the nomination request transaction for CHE= CK > LIST X is not initiated at the same time as a connectivity check > transaction for CHECK LIST Y? > > But, even if we put the pair in the TRIGGERED CHECK LIST, we need to make > sure it becomes the top-most pair in the list, because we don=E2=80=99t w= ant to > test other pairs that may still be i the list. > > Regards, > > Christer > > --94eb2c1922a40700760550dbc7fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The pacing rules are clear that they apply to all checks.= =C2=A0 I don't think we need to over-specify the algorithm for doing so= . =C2=A0 And I don't think we need to be over-specific about when the n= ominating check sent either.=C2=A0 Let the agent/implementation decide.
On Sun, May 28, 2017 at 1= 1:38 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

> - Why do we nominate by putting the valid pair in the triggered c= heck queue?=C2=A0 Why not just say "send a binding request"?=C2= =A0 In particular reason?=C2=A0
> Do we *want* it to be delayed if there are many things in the fro= nt of the queue?

I wonder whether the reason is to maintain the pacing among the CHECK = LISTs, i.e., to make sure that the nomination request transaction for CHECK= LIST X is not initiated at the same time as a connectivity check transacti= on for CHECK LIST Y?

But, even if we put the pair in the TRIGGERED CHECK LIST, we need to m= ake sure it becomes the top-most pair in the list, because we don=E2=80=99t= want to test other pairs that may still be i the list.

Regards,

Christer

--94eb2c1922a40700760550dbc7fc-- From nobody Wed May 31 18:19: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 9654F1294A2 for ; Wed, 31 May 2017 18:19:00 -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 56W33arQN7ZA for ; Wed, 31 May 2017 18:18:59 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783CC129443 for ; Wed, 31 May 2017 18:18:59 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h4so36985534oib.3 for ; Wed, 31 May 2017 18:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6WwohfsW62LKI42J0lWGFzgbZ4AHJ0YddqJ02dtUmrQ=; b=oAnuXeX/syVE4B2kWlrX0o/4B4zs4FPdsbA1IuWb7EdtN0+n0dcyhMO6ktIPisT3q/ kSHuzOqSSAFseWSUh3w8ymfFlZRxpR0+QHZKqCBRCovjslw4Youehhx6c8v/9AZa7gG+ x1abM42Sq3NLD9JXcOBhTzdyA/wgOQ/BBtb41+X4/p6fSuVIun/hv4MLrpFkSRlcTTYk kGAFLRubzpyjGppHJTqe1BGjYdaTJ1LBuFzJjI/T9oLHCbbZ65mKpMIDGSQFIifm9ZIl dLZqEidPzPIh3IUjQC4thAahZlsV4+ZJyHj+NvjEhxFTLZi68GQ9Cqfz0K9+k1hbgicr IOXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6WwohfsW62LKI42J0lWGFzgbZ4AHJ0YddqJ02dtUmrQ=; b=gnaqqELNVdF25Ya8m57Bmt94sJF2HVgbHxsWqAEAo0ukEhmAHmU6GOr1S0qvwBkMsk qOXfPJzTX0uUILOW5spPzx8ycC5+o8eMGMCXIVxyBgNmtJmBfNryNt+lzW5P/4/Z4Aa8 PWpgoFmYHRzGxAo2O/gW0aiDCYiEbjede2Or3RAJLCmB7Z5tLG/vB2SLnm3Hf4PgUCnt dGfICZetI2mzplSenUD3Wbxu19zK82jf0FPwlPCsMHCWC0PYjMo/jMhqXqCA8br5mcCQ fbKJaGS9bjiW0Sje+ckEl9TLq/57e4XtVS2d7HHVFWQaI9gfVK9GpW1nwKS+SoGwhW3D 3qzw== X-Gm-Message-State: AODbwcAml7B5FRasKjmWPVnRZZBTLDRVddA7zxVsGG0MzFyiw2LEbry3 caaSb1qbf6Rv+SzG5/UdC/KbF++1Y2J1 X-Received: by 10.202.85.13 with SMTP id j13mr12899904oib.90.1496279938757; Wed, 31 May 2017 18:18:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 01:18:48 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113d30083c43050550dbd298" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. 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, 01 Jun 2017 01:19:00 -0000 --001a113d30083c43050550dbd298 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it's OK if we completely special case this... special case. Just say something like "ancient endpoints which do silly things like not multiplex RTCP and RTP over the same media stream will use two media streams and in this case the streams are not useful unless both succeed". What else is there to say? On Sun, May 28, 2017 at 11:44 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > - Much of the spec is much more complicated than it otherwise would be > because a media stream has more than one component. Would it make sense > > to define a check list as representing a single component of a single > media stream rather than multiple components? That would make the rules > and states around check lists much more simple. > > I have been thinking the same thing :) > > However, in that case I think we need to talk about certain media streams > being =E2=80=9Cdependent" on each other, and that checks for both streams= (e.g., > one RTP stream and one RTCP stream) must succeed in order to the streams = to > be used (unless BUNDLE is used, of course). > > Regards, > > Christer > --001a113d30083c43050550dbd298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it's OK if we completely special case this... = special case.=C2=A0 Just say something like "ancient endpoints which d= o silly things like not multiplex RTCP and RTP over the same media stream w= ill use two media streams and in this case the streams are not useful unles= s both succeed". =C2=A0

What else is there to say?<= /div>

On Sun, May 28, = 2017 at 11:44 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

> - Much of the spec is much more complicated than it otherwise wou= ld be because a media stream has more than one component.=C2=A0 Would it ma= ke sense
> to define a check list as representing a single component of a si= ngle media stream rather than multiple components?=C2=A0 That would make th= e rules and states around check lists much more simple.=C2=A0

I have been thinking the same thing :)

However, in that case I think we need to talk about certain media stre= ams being =E2=80=9Cdependent" on each other, and that checks for both = streams (e.g., one RTP stream and one RTCP stream) must succeed in order to= the streams to be used (unless BUNDLE is used, of course).

Regards,

Christer
--001a113d30083c43050550dbd298-- From nobody Wed May 31 18:21: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 99D91129AA0 for ; Wed, 31 May 2017 18:21:01 -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 WEl5gx9SyAyz for ; Wed, 31 May 2017 18:21:00 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407AA1294A2 for ; Wed, 31 May 2017 18:21:00 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id w10so37114601oif.0 for ; Wed, 31 May 2017 18:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XwZ7yC+h6rXgWB2cTXOj/NSZzyzx9KIYztPUs4kqYFc=; b=ssxy5yFcPqUfQXh1kDNVI42y39pAwQNV2SuYS+bh0m5cd/7Wm9jbv5eBZnbnUlH2W9 hsGro/Xv3IHymH3Qbdtx/YrUc+oSaIHfnHBT5o6/KtH9sUGRDk+R55zk78t/ZRjmxMtE i0+IeBlpWWFSqUjCbc4njnkYylTcSjbyak1v8qu3nnEWXDfABJDwy4dVQTpYXrxO0xGv aLsBNfxiB0Mch3O8Sg3LG2OGvGpGsVPA8mNoS+k0neTQ0YKlTxR6suUTvB+czYymrl/n T/e52niQxf84q3cZquSwEiGUSaQNaiVw9hHhyAlX0d2MI/1IhAk+Anf+JjWHGnGoL+Rf p2Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XwZ7yC+h6rXgWB2cTXOj/NSZzyzx9KIYztPUs4kqYFc=; b=B/ENNklv5hXpUG3PigPcuZ7otltwflsPQu2drUh90BVOXNL0z3x9wzKQLooJk5xauz d1Skzd0EAgOwBsTsemoKz13vg7uCzXKytTSl0tjYrDWIDDueYUv+JflGM67jAnPOg4at JgOugdFhmlJgdIGPhtQr45xiARZq4mIfqU4Gi/pbwdj/nnDBd3r9NrsCbOYmgieGWyPr wMlG/fvWmJTyn0QAb6ZpJ/LVeR/Xq4g/NGAyiYT30J/ukUE4KbV86HW0u4zk1SkW+xGq kwlxGOk7lTER4U5EuvEIUWW3fGirlwSznhw9F/u8cfjyttu3BLj09dVtTpdA6gNrm44+ bJtQ== X-Gm-Message-State: AODbwcCvyxOsjUjAaSBSC4Fk26o2wwswnJAsD5dfW7nEc6RpYjqNRtlQ HShV9zC4UXjSUR/qwrDjpMEYCWaIZiRW X-Received: by 10.157.41.204 with SMTP id g12mr1662931otd.7.1496280059625; Wed, 31 May 2017 18:20:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 01:20:49 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113dd774708a960550dbd951" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? 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, 01 Jun 2017 01:21:02 -0000 --001a113dd774708a960550dbd951 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What's the different between "valid" and "succeeded"? On Sun, May 28, 2017 at 11:50 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > - Why do we model valid candidate pairs as a separate list of separate > candidates from the normal check list? > > Why not just say that some candidate pairs are valid. Why have this > list of them? Seems like we could remove the concept. > > This is related to an e-mail I sent some time ago, where I asked whether > we really need all states etc, and even suggested we could remove some of > it. However, I then decided not to do it, because it could end up in a re= al > mess. > > But, related to your question, when I had a look at it I was thinking tha= t > =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value, rathe= r than a separate > list. > > Regards, > > Christer > > > > --001a113dd774708a960550dbd951 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's the different between "valid" and &qu= ot;succeeded"? =C2=A0


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <= christer.holmberg@ericsso= n.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list?=C2=A0
>=C2=A0Why not just say tha= t some candidate pairs are valid.=C2=A0 Why have this list of them? =C2=A0 = =C2=A0Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value, ra= ther than a separate list.

Regards,

Christer
--001a113dd774708a960550dbd951-- From nobody Wed May 31 18:25:47 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 4682C129ADD for ; Wed, 31 May 2017 18:25:46 -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 tYplpMHOq0GZ for ; Wed, 31 May 2017 18:25:44 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897D2129666 for ; Wed, 31 May 2017 18:25:44 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id o65so12409222oif.1 for ; Wed, 31 May 2017 18:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pxF+xUfvpPz02IwNy5SheW9XyY+Y2Vm+1MvP2GKCYQg=; b=hSBcb6gFG0imaYpQxCIBPRD+yHeySiK9QO3Kp819oMxZMfBXyzWcuNT0X2k0elW/QG Xxm8JcZociPfEf1eZxdWFpPHvafat3H0Bei3YQxfyYAzhJmhYsyPRdquoeng5Z9sCmyI ETEuZQDWHbsmejRQU7K0kx9wp/j2DxoGRRgvDEp4rjkX+0gcyziiRQKYq+Bdke1W8fih xoPGUOs1/7cSwQnbP3SjypqeIvoTkkkuruos892xdWdcKiehQ40ltq23eLv6UWJZZYvm w2NDEnkvldCfb+Qrsb6+ikP5pSbwe+O4mwdJUBHILzB+upS12jxBO4VZXHSn7CiwxHKs 3vtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pxF+xUfvpPz02IwNy5SheW9XyY+Y2Vm+1MvP2GKCYQg=; b=NuuCVBkp9hYNrEeS70WM+s95OXk47Ipj5QrdLq5eyfHnkZ1UP/b3qhORjtYr6NOcEk UMyrT/LzpcU+BHcC8h+5Vokmj3S4T0PSnYuPWHRdD0ioMMfjfPjJL3unwaMRQSHC0pzn YCdx07Mpg0S6+9rpB4tw7O7znPSCi86BV8W14MZp9KnkDTUAGkW0uoWvbUiymTc/h8m3 FyM1oGYx9/3PQXJRNX1O6Ang67x4fqOQEfHF1fDmJ/DvBYIdi0j/0jbU9kFt6QOoygf1 2OfjEhc8n5Fl0NmPSMgUYju0EATL96eZPDLjznCPyhB3Q5n56xEsRf4YdrBNFl3/WuWG R4mA== X-Gm-Message-State: AODbwcCif0dgQPrM67C1jAzjyw6MoI6VszEJ2cLbDD642impk3jjM3U+ WDMqdnz0k6sghzbzu+1z0sJROiFM8/dF X-Received: by 10.202.206.193 with SMTP id e184mr12762955oig.91.1496280343867; Wed, 31 May 2017 18:25:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 01 Jun 2017 01:25:33 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113d2e7261f3ee0550dbea0f" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments 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, 01 Jun 2017 01:25:46 -0000 --001a113d2e7261f3ee0550dbea0f Content-Type: text/plain; charset="UTF-8" On Mon, May 29, 2017 at 12:08 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > - The spec says it's only defined for one TURN server and one STUN > server but then it says what to do when more than one TURN server or STUN > server is used. I'm guessing we should remove the part about one TURN > server rather than the other way around. > > - Since we won't have aggressive nomination, do we still need the > "three-second rule" for when candidates can be freed? > > - The concept of using a Data Indication for a keepalive seems > outdated. In RTCWEB, consent freshness requires the use of binding > requests, not data indications. Should we change this? > > - What does the phrase "through good box and software security on TURN > servers." mean? > > - Do we still need all the UNASF stuff? > > I have currently no input on the comments above. > > > - Should we keep this "send another candidate exchange when you're > Complete" thing? It looks like it's just there to > > let signaling servers learn something, which I think should be out of > scope for this document. Let a SIP document specify that. > > Where is this text? > Search for "updated candidate". It's referred to about 4 times. It might only be for the case where one media stream fails and is thus removed. Or it might also be for peer reflexive candidates. I'm just not sure why it's in this doc at all and not in a using protocol doc. > > > - The one example in the doc uses aggressive nomination, which no longer > exists. > > We need to fix that. > > > - Do our "changes from 5245" section need to be updated? > > Yes... > > Regards, > > Christer > > > --001a113d2e7261f3ee0550dbea0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , May 29, 2017 at 12:08 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

> - The spec says it's only defined for one TURN server and one= STUN server but then it says what to do when more than one TURN server or = STUN server is used.=C2=A0 I'm guessing we should remove the part about= one TURN server rather than the other way around.
> - Since we won't have aggressive nomination, do we still need= the "three-second rule" for when candidates can be freed?
> - The concept of using a Data Indication for a keepalive seems ou= tdated.=C2=A0 In RTCWEB, consent freshness requires the use of binding requ= ests, not data indications. =C2=A0 =C2=A0Should we change this?
> - What does the phrase "through good box and software securi= ty on TURN servers." mean?
> -=C2=A0Do we still need all the UNASF stuff?

I have currently no input on the comments above.

> - Should we keep this "send another candidate exchange when = you're Complete" thing?=C2=A0 It looks like it's just there to= =C2=A0
> let signaling servers learn something, which I think should be ou= t of scope for this document.=C2=A0 Let a SIP document specify that. =C2=A0=

Where is this text?
Search for "updated c= andidate".=C2=A0 It's referred to about 4 times.=C2=A0 It might on= ly be for the case where one media stream fails and is thus removed.=C2=A0 = Or it might also be for peer reflexive candidates. =C2=A0
=
I'm just not sure why it's in this doc at all an= d not in a using protocol doc.
=C2=A0

> - The one example in the doc uses aggressive nomination, which no= longer exists.

We need to fix that.

> -=C2=A0Do our "changes from 5245" section need to be up= dated?

Yes...

Regards,

Christer
--001a113d2e7261f3ee0550dbea0f-- From nobody Wed May 31 23:21:10 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 CCEE912EB2E for ; Wed, 31 May 2017 23:21:01 -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 PNWZtNeTcbkT for ; Wed, 31 May 2017 23:21:00 -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 E6EEA12EB2D for ; Wed, 31 May 2017 23:20:59 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-f9-592fb249d970 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.41.03383.942BF295; Thu, 1 Jun 2017 08:20:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 08:18:45 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? Thread-Index: AQHS2EfLSJWiXi6t0kqXcQwCFgzNt6IPGIOAgACHTIA= Date: Thu, 1 Jun 2017 06:18:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D5558DBC1D6D4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7iq7nJv1Ig+MvLC2+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK+Lu9gbXggmnF3inXGRsY7+l1MXJySAiYSMzc dIipi5GLQ0jgCKPE/ol9zBDOIkaJjSfXsnUxcnCwCVhIdP/TBmkQEfCQ2PxmORtIjbDAXEaJ 61/3gDWICMxjlPi9fBYzRJWVRM+ZfSwgNouAisTs19eZQAbxClhL/D0KViIk0MQoMeOuEYjN KRAo8WjzESYQm1FATOL7qTVgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1aQkaICehLv9ntC hJUkfmy4xALRmiDx8dUGsFZeAUGJkzOfsExgFJmFZOosJGWzkJRBxA0k3p+bzwxha0ssW/ga ytaX2PjlLOMsoM3MQM88fSaCrGQBI8cqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMBIO7jl t+4OxtWvHQ8xCnAwKvHwWi/VjxRiTSwrrsw9xCjBwawkwstXCRTiTUmsrEotyo8vKs1JLT7E KM3BoiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qBMUGjWXrL0f326wyPFajHWoXPnX+Q1yag 8LCvosRjk99G909ytS/vPzhRfKfWtl8b+3izWEO5Snw/l+TGF2aEiu9cs8j3z+eutLwF51zZ 1blPOCkILvl79r7Nxg+Hqti7ipbPutBjdW+FZt1l/nnuDLmJzP9+HYt5/SSAI8fSISwpY6NQ dfFhJZbijERDLeai4kQA6145I7ACAAA= Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? 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, 01 Jun 2017 06:21:02 -0000 --_000_D5558DBC1D6D4christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I need to take one step back. Keep in mind that pairs in the VALID LIST do not necessarily exist in any C= HECK LIST. See section 6.2.5.3.2. Regards, Christer From: "pthatcher@google.com" > Date: Thursday 1 June 2017 at 04:20 To: Christer Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candida= te pairs as a separate list of separate candidates from the normal check li= st? What's the different between "valid" and "succeeded"? On Sun, May 28, 2017 at 11:50 PM Christer Holmberg > wrote: Hi, > - Why do we model valid candidate pairs as a separate list of separate ca= ndidates from the normal check list? > Why not just say that some candidate pairs are valid. Why have this list= of them? Seems like we could remove the concept. This is related to an e-mail I sent some time ago, where I asked whether we= really need all states etc, and even suggested we could remove some of it.= However, I then decided not to do it, because it could end up in a real me= ss. But, related to your question, when I had a look at it I was thinking that = =93VALID=94 could just be a candidate pair state value, rather than a separ= ate list. Regards, Christer --_000_D5558DBC1D6D4christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <15EB6DDBB2AC654D86B449A0612949BD@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section 6.2.5.3.2.

Regards,=

Christer=

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's review o= f ICEbis - Why do we model valid candidate pairs as a separate list of sepa= rate candidates from the normal check list?

What's the different between "valid" and "s= ucceeded"?  


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list? 
> Why not just say = that some candidate pairs are valid.  Why have this list of them? &nbs= p;  Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =93VALID=94 could just be a candidate pair state value, rather than a = separate list.

Regards,

Christer



 --_000_D5558DBC1D6D4christerholmbergericssoncom_-- From nobody Wed May 31 23:25:04 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 AF68212EB38 for ; Wed, 31 May 2017 23:25:02 -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 fserp-ujpebd for ; Wed, 31 May 2017 23:25:01 -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 15E6F12EB2A for ; Wed, 31 May 2017 23:25:00 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-50-592fb33a1370 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.D6.22014.A33BF295; Thu, 1 Jun 2017 08:24:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 08:22:52 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. Thread-Index: AQHS2EcFiI1CctLCKk6poKZrQK4FhKIPF/UAgACJAQA= Date: Thu, 1 Jun 2017 06:22:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D5558E4E1D6D9christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7k67VZv1IgwvvrSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK2Ncxh63gk27Fhm8JDYw71LoYOTkkBEwkLi7u Z+li5OIQEjjCKDHxxg12CGcRo8Sp34uYuxg5ONgELCS6/2mDNIgIeEhsfrOcDaRGWGAVo8SO qaeZQRwRgdWMEu8vX2WFqLKSuD/1AwuIzSKgIvFk2R52EJtXwFriWM9rqHVNjBIHfy9gA0lw CgRKdB56BdbAKCAm8f3UGiYQm1lAXOLWk/lMELcKSCzZc54ZwhaVePn4HyvIdaICehLv9ntC hJUkfmy4xALRmiCxYcYrNoi9ghInZz5hmcAoMgvJ1FlIymYhKYOIG0i8PzefGcLWlli28DWU rS+x8ctZRgjbWuLNsw8oahYwcqxiFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIy2g1t+q+5g vPzG8RCjAAejEg/vwyX6kUKsiWXFlbmHGCU4mJVEePkqgUK8KYmVValF+fFFpTmpxYcYpTlY lMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwJoUevOZ1S+EAby7Py62mv25O/Pv35rGqzDln 4k5Vv1h7sdaHUbdRRi2jpEKNz41zzcK/T+Rr9TjWbl4jm1DJ6X70w8P5R9kad/tKZemofu9W uJP6rOjXndcMHuXMC5xMmDe8NEhlWha85zavKL+ssHzQciPDm6V/1APPHHOPOfV/7cdNJ3xM lViKMxINtZiLihMBXu8YkrICAAA= Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. 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, 01 Jun 2017 06:25:03 -0000 --_000_D5558E4E1D6D9christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >I think it's OK if we completely special case this... special case. Just = say something like "ancient endpoints which do silly things like not multip= lex RTCP and RTP >over the same media stream will use two media streams and in this case the= streams are not useful unless both succeed". > >What else is there to say? Currently section 6.2.5.4 says the following: "If there is a valid pair for each component in the VALID LIST, the state of the check list is set to Succeeded." Now, if we REMOVE (I assume that is what you are suggesting?) the whole com= ponent concept that text would obviously go away. But, at the same time we = remove the requirement to have a valid RTCP- and RTP pair in order for a CH= ECK LIST state to be set to Succeeded. Regards, Christer On Sun, May 28, 2017 at 11:44 PM Christer Holmberg > wrote: Hi, > - Much of the spec is much more complicated than it otherwise would be be= cause a media stream has more than one component. Would it make sense > to define a check list as representing a single component of a single med= ia stream rather than multiple components? That would make the rules and s= tates around check lists much more simple. I have been thinking the same thing :) However, in that case I think we need to talk about certain media streams b= eing =93dependent" on each other, and that checks for both streams (e.g., o= ne RTP stream and one RTCP stream) must succeed in order to the streams to = be used (unless BUNDLE is used, of course). Regards, Christer --_000_D5558E4E1D6D9christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <78A389BF0D5F294A8473A6B8B2ED0BD9@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>I think it's OK if we completely special case this... = special case.  Just say something like "ancient endpoints which d= o silly things like not multiplex RTCP and RTP
>over the same media stream will use two media streams and in this = case the streams are not useful unless both succeed".  
>
>What else is there to say?

Currently section 6.2.5.4 says the following:
   "If there is a valid pair =
for each component in the
   VALID LIST, the state of the check list is set to Succeeded."
Now, if we=
 REMOVE (I assume that is what you are suggesting?) the whole component con=
cept that text would obviously go away. But, at the same time we remove the=
 requirement to have a valid RTCP- and RTP pair in order for a CHECK LIST s=
tate to be set to Succeeded.

Regards,

Christer



On Sun, May 28, 2017 at 11:44 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

> - Much of the spec is much more complicated than it otherwise wou= ld be because a media stream has more than one component.  Would it ma= ke sense
> to define a check list as representing a single component of a si= ngle media stream rather than multiple components?  That would make th= e rules and states around check lists much more simple. 

I have been thinking the same thing :)

However, in that case I think we need to talk about certain media stre= ams being =93dependent" on each other, and that checks for both stream= s (e.g., one RTP stream and one RTCP stream) must succeed in order to the s= treams to be used (unless BUNDLE is used, of course).

Regards,

Christer
 --_000_D5558E4E1D6D9christerholmbergericssoncom_-- From nobody Wed May 31 23:32:10 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 6C986127B60 for ; Wed, 31 May 2017 23:32:08 -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 x4mTFGKlXrzd for ; Wed, 31 May 2017 23:32:07 -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 E1B85124E15 for ; Wed, 31 May 2017 23:32:06 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-c5-592fb4e55d5e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.E4.03383.5E4BF295; Thu, 1 Jun 2017 08:32:05 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 08:27:45 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis- Why do we nominate by putting the valid pair in the triggered check queue? (7.1.1) Thread-Index: AQHS2EYvl710MdTO5kmqLa/o+V6VaaIPFxYAgACLPgA= Date: Thu, 1 Jun 2017 06:27:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D5558F481D6E1christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7iu7TLfqRBudfi1p8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CVsff3K+aCP5oV535fZWpgvK7UxcjJISFgIrFt yVzWLkYuDiGBI4wS/fNa2CCcRYwSd/tOs3cxcnCwCVhIdP/TBmkQEfCQ2PxmOViNsEAjo8SS 5bMYIRJNjBKLGy0gbCuJE9saWUFsFgEViSU/17OB2LwC1hK7L25ghlgAVN/97h0zSIJTIFDi 6sa5YDajgJjE91NrmEBsZgFxiVtP5jNBnCogsWTPeWYIW1Ti5eN/rCDHiQroSbzb7wkRVpS4 On05VGuCxMITF6D2CkqcnPmEZQKjyCwkU2chKZuFpAwibiDx/tx8ZghbW2LZwtdQtr7Exi9n GSFsa4nJDx+xI6tZwMixilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMw2g5u+a27g3H1a8dD jAIcjEo8vNZL9SOFWBPLiitzDzFKcDArifDyVQKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zrs uxAhJJCeWJKanZpakFoEk2Xi4JRqYFzO9PF5w+SUw90vxCYsWzpLY/4Wi51bltqmai0+6atQ XpLP51eRXXRocqbg/NfnL87Q/vvt4HGWrQWXzE5nHPFInfvE1CGcYXOHxNcAtzsnjvVvqF67 WfiOgvZU65RrzZHVAs+t/74JXVfpI6h1ce2ZM+dFo//w/pVba/Utu83F+WawynyGl/xKLMUZ iYZazEXFiQDCbu2NsgIAAA== Archived-At: Subject: Re: [Ice] Peter's review of ICEbis- Why do we nominate by putting the valid pair in the triggered check queue? (7.1.1) 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, 01 Jun 2017 06:32:08 -0000 --_000_D5558F481D6E1christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >The pacing rules are clear that they apply to all checks. The question is whether we, for a given CHECK LIST, want to trigger a new c= onnectivity check transaction (no matter whether it=92s for nomination or n= ot) only when Ta fires and that CHECK LIST is selected. If we allow the implementation to send the nomination request =93whenever i= t wants=94 there is always a chance that Ta fires for another CHECK LIST at= the same time. Having said that, if the connectivity check transaction already exists, and= the only thing the agent does is setting the nomination flag, it=92s not a= new transaction, and it could be done at any time=85 Regards, Christer I don't think we need to over-specify the algorithm for doing so. And I= don't think we need to be over-specific about when the nominating check se= nt either. Let the agent/implementation decide. On Sun, May 28, 2017 at 11:38 PM Christer Holmberg > wrote: Hi, > - Why do we nominate by putting the valid pair in the triggered check que= ue? Why not just say "send a binding request"? In particular reason? > Do we *want* it to be delayed if there are many things in the front of th= e queue? I wonder whether the reason is to maintain the pacing among the CHECK LISTs= , i.e., to make sure that the nomination request transaction for CHECK LIST= X is not initiated at the same time as a connectivity check transaction fo= r CHECK LIST Y? But, even if we put the pair in the TRIGGERED CHECK LIST, we need to make s= ure it becomes the top-most pair in the list, because we don=92t want to te= st other pairs that may still be i the list. Regards, Christer --_000_D5558F481D6E1christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>The pacing rules are clear that they apply to all chec= ks.

The question is whether we, for a given CHECK LIST, want to trigger a = new connectivity check transaction (no matter whether it=92s for nomination= or not) only when Ta fires and that CHECK LIST is selected.

If we allow the implementation to send the nomination request =93whene= ver it wants=94 there is always a chance that Ta fires for another CHECK LI= ST at the same time.

Having said that, if the connectivity check transaction already exists= , and the only thing the agent does is setting the nomination flag, it=92s = not a new transaction, and it could be done at any time=85

Regards,

Christer



  I don't think we need to over-specify the algorithm= for doing so.   And I don't think we need to be over-specific about w= hen the nominating check sent either.  Let the agent/implementation de= cide.

On Sun, May 28, 2017 at 11:38 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

> - Why do we nominate by putting the valid pair in the triggered c= heck queue?  Why not just say "send a binding request"? = ; In particular reason? 
> Do we *want* it to be delayed if there are many things in the fro= nt of the queue?

I wonder whether the reason is to maintain the pacing among the CHECK = LISTs, i.e., to make sure that the nomination request transaction for CHECK= LIST X is not initiated at the same time as a connectivity check transacti= on for CHECK LIST Y?

But, even if we put the pair in the TRIGGERED CHECK LIST, we need to m= ake sure it becomes the top-most pair in the list, because we don=92t want = to test other pairs that may still be i the list.

Regards,

Christer

 --_000_D5558F481D6E1christerholmbergericssoncom_-- From nobody Wed May 31 23:44:02 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 486CD1294E1 for ; Wed, 31 May 2017 23:44:01 -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 6nqIb4gss_w9 for ; Wed, 31 May 2017 23:43:59 -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 753D1127B60 for ; Wed, 31 May 2017 23:43:59 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-17-592fb7ad9c1d Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.F9.19050.DA7BF295; Thu, 1 Jun 2017 08:43:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 08:41:41 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5) Thread-Index: AQHS2EKqcQ1YVitsS0inpnvCjV/idKIPFnkAgACPxwA= Date: Thu, 1 Jun 2017 06:41:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D55591181D6FBchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7n+7a7fqRBle7DSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK+LN5P1NBh0ZF49fVrA2MHxS6GDk5JARMJKZ2 fmACsYUEjjBKvN4V1MXIBWQvYpRY0fWasYuRg4NNwEKi+582SI2IgIfE5jfL2UBsYYFkia2z NoGViAikSOw9VgZRYiUx+/EEsJEsAioSG95uASvnFbCWODxpGdSqJkaJj2d9QWxOgUCJzf+n gMUZBcQkvp9aA2YzC4hL3HoynwniTAGJJXvOM0PYohIvH/9jBVkrKqAn8W6/J0RYUeLq9OVQ rQkSv2f+Y4RYKyhxcuYTlgmMIrOQTJ2FpGwWkjKIuIHE+3PzmSFsbYllC19D2foSG7+cZYSw rSX6V/ewIKtZwMixilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwyg5u+W21g/Hgc8dDjAIc jEo8vDpL9SOFWBPLiitzDzFKcDArifDyVQKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zrsuxAh JJCeWJKanZpakFoEk2Xi4JRqYJzpYZ9nq/W0W77TKu9G3Sku5v2yy6fmPbis8eHhM93i7r9v /zOf3cUsePL2fma5a4teTPCVe3E9+ku1+BLeVqXH8yb+PC/Loxg4s8SuMZvbzlop51DGn4a6 d309kff+ZPB5L1qacvVezuT7tYeXqzNyHkxnCfaT4mlrq1RMaW15IeP4+H87qxJLcUaioRZz UXEiAGqPw/WuAgAA Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5) 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, 01 Jun 2017 06:44:01 -0000 --_000_D55591181D6FBchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >So basically add that it should be evenly distributed to avoid starving on= e check list? Correct. >That sounds good to me. Just make sure you don't have 101 check lists :). In normal cases I guess we=92d be nowhere near 100, but note that if we hav= e separate check lists for RTP and RTCP (see your other e-mail) we are talk= ing about 50 RTP/RTCP (non-mused) flows =96 which still is a very big numbe= r. Regards, Christer On Sun, May 28, 2017 at 11:13 PM Christer Holmberg > wrote: Hi, > - If we remove lower-priority candidate pairs across check lists, what >happens if a certain check list is starved because all of its candidate >pairs are lower priority? > One option might be to say the limit is per check list. Another is to >recognise that it might happen but live with it. My understanding was always that the limit is per check list, but I agree it may not be very clear. Perhaps we could modify the text as below: In order to limit the attacks described in Section 15.4.1, an agent MUST limit the total number of connectivity checks the agent performs across all CHECK LISTs to a specific value, and this value MUST be configurable. A default of 100 is RECOMMENDED. This limit is enforced by, within each CHECK LIST, discarding the lower-priority candidate pairs of that CHECK LIST, until there are less than a total of 100 candidate pairs in the CHECK LIST SET. The discarding of candidate pairs SHOULD be distributed equally throughout the CHECK LISTs in the CHECK LIST SET. Regards, Christer --_000_D55591181D6FBchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8B56BF42F17DC04DAF478FF69EEB6E68@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>So basically add that it should be evenly distributed = to avoid starving one check list?  

Correct.

>That sounds good to me.  Just make sure you don't have 101 ch= eck lists :).

In normal cases I guess we=92d be nowhere near 100, but note that if w= e have separate check lists for RTP and RTCP (see your other e-mail) we are= talking about 50 RTP/RTCP (non-mused) flows =96 which still is a very big = number.

Regards,

Christer






On Sun, May 28, 2017 at 11:13 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

> - If we remove lower-priority candidate pairs across check lists, what=
>happens if a certain check list is starved because all of its candidate=
>pairs are lower priority?
> One option might be to say the limit is per check list.  Another = is to
>recognise that it might happen but live with it.

My understanding was always that the limit is per check list, but I agree it may not be very clear.

Perhaps we could modify the text as below:

   In order to limit the attacks described in Section 15.4.1, an = agent
   MUST limit the total number of connectivity checks the agent p= erforms
   across all CHECK LISTs to a specific value, and this value MUS= T be
   configurable. A default of 100 is RECOMMENDED.  This limi= t is
   enforced by, within each CHECK LIST, discarding the lower-prio= rity
candidate
   pairs of that CHECK LIST, until there are less than a total of= 100
candidate
   pairs in the CHECK LIST SET. The discarding of candidate pairs= SHOULD be
   distributed equally throughout the CHECK LISTs in the CHECK LI= ST SET.


Regards,

Christer


 --_000_D55591181D6FBchristerholmbergericssoncom_-- From nobody Wed May 31 23:50: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 A2DAD1271DF for ; Wed, 31 May 2017 23:50:00 -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 gLC5niyY_Pn9 for ; Wed, 31 May 2017 23:49:59 -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 BBAB1126D46 for ; Wed, 31 May 2017 23:49:58 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-24-592fb9141444 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 47.2A.03383.419BF295; Thu, 1 Jun 2017 08:49:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 08:48:09 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success Thread-Index: AQHS2HWCMmjBMkzGv0yuMV3+mLKe5qIPFIMAgACTJgA= Date: Thu, 1 Jun 2017 06:48:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D555936B1D723christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7oq7oTv1Igy+reSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKuD9nBXvBPLuKzbOmsTQw7rbpYuTkkBAwkZj9 ahMriC0kcIRRYvdVuy5GLiB7EaPEla4lzF2MHBxsAhYS3f+0QWpEBDwkNr9ZzgZiCwvESOw4 PYkRIh4r8XrnbzYI20qiYfJ5sDiLgIrE9MW3mEFsXgFriSM3l7BBzG9ilGjbuBxsPqdAoMSR SUYgNYwCYhLfT61hArGZBcQlbj2ZzwRxp4DEkj3nmSFsUYmXj/+xgrSKCuhJvNvvCRFWlPj4 ah8jRGuCxMLTvxkh1gpKnJz5hGUCo8gsJFNnISmbhaQMIq4l8eXHPjYIW1FiSvdD9llA25gF NCXePKyFCFtLPLy+hhFZyQJGjlWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF2cMtv3R2M q187HmIU4GBU4uG1XqofKcSaWFZcmXuIUYKDWUmEl68SKMSbklhZlVqUH19UmpNafIhRmoNF SZzXYd+FCCGB9MSS1OzU1ILUIpgsEwenVAMjW5CHEVfC4Wvyp/3y6i5vK0mx79jduKBkig+j 6mEup+3/2yxz9sx6Kanxd9phxZCqtvhby5fFx4lcS337/vDVr0zT36mneU+4rfiVcbnK+nV1 ZkL9cWe3/Gta8Wfn8WVPHBiPT3vBn7U8SVU8Wyd/89SNJfoCM+vMgz0qk2WYRfg8ox6Uif1R YinOSDTUYi4qTgQAhfjCgq4CAAA= Archived-At: Subject: Re: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success 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, 01 Jun 2017 06:50:00 -0000 --_000_D555936B1D723christerholmbergericssoncom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNCj4gSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHRoZSBzZWNvbmQgcG9pbnQuICBJ dCBzZWVtcyBsaWtlIHRoZSB0ZXh0IGlzIHNheWluZyB0byB1bmZyZWV6ZSB0aGUgcGFpcnMgd2l0 aCB0aGUgc2FtZSBmb3VuZGF0aW9uIGluIGFsbCBjaGVjayBsaXN0cywgYW5kIHRoYXQgc291bmRz IGNvcnJlY3QgdG8gbWUuDQoNClRoYXQgaXMgd2hhdCBpdCBzaG91bGQgc2F5IDopDQoNCkJ1dCB0 aGUgdGV4dCBzYXlzIKGwZm9yIHRoZSBTQU1FIG1lZGlhIHN0cmVhbSBhbmQgZm91bmRhdGlvbqGx LiBJdCBzaG91bGQgc2F5IKGwZm9yIEFMTCBtZWRpYSBzdHJlYW1zIHdpdGggdGhlIHNhbWUgZm91 bmRhdGlvbqGxLg0KDQpBbHNvLCBpbiBGaWd1cmUgMyBvbmx5IG0yIGlzIHNldCB0byBXLiBtMyBh bmQgbTQgc2hvdWxkIGFsc28gYmUgc2V0IHRvIFcuDQoNCk5vdywgaW4gRmlndXJlIDQgbTMgYW5k IG00IEFSRSBzZXQgdG8gVywgc28gbWF5YmUgbXkgaXNzdWUgaXMgdGhhdCBJIGRvbqGvdCByZWFs bHkgc2VlIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gRmlndXJlIDMgYW5kIDQuIENvdWxkbid0IEZp Z3VyZSAzIGJlIHJlbW92ZWQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KDQoN Cg0KT24gTW9uLCBNYXkgMjksIDIwMTcgYXQgNToxNyBBTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpXZSBtYXkgaGF2ZSBkaXNjdXNzZWQgdGhpcyBiZWZv cmUsIGJ1dCBhcyBpdCBzdGlsbCBleGlzdHMgaW4NCmRyYWZ0LXRyaWNrbGUtMTEgSSB3aWxsIGNv bW1lbnQgb24gaXQ6DQoNClNlY3Rpb24gOC4xLjEuIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgdGV4 dDoNCg0KICAgICAgICAiVGhlbiwgYXMgdGhlIGNoZWNrcyBwcm9jZWVkIChzZWUgU2VjdGlvbiA2 LjIuNS40IG9mIFtyZmM1MjQ1YmlzXSksDQogICAgICAgIGZvciBlYWNoIHBhaXIgdGhhdCBlbnRl cnMgdGhlIFN1Y2NlZWRlZCBzdGF0ZSAoZGVub3RlZCBoZXJlIGJ5ICJTIiksDQogICAgICAgIHRo ZSBhZ2VudCB3aWxsIHVuZnJlZXplIGFsbCBwYWlycyBmb3IgdGhlIHNhbWUgbWVkaWEgc3RyZWFt IGFuZA0KICAgICAgICBmb3VuZGF0aW9uIChlLmcuLCBpZiB0aGUgcGFpciBpbiBjb2x1bW4gMSwg cm93IDEgc3VjY2VlZHMgdGhlbiB0aGUNCiAgICAgICAgYWdlbnQgd2lsbCB1bmZyZWV6ZSB0aGUg cGFpciBpbiBjb2x1bW4gMSwgcm93IDIpLqn3DQoNCg0KRmlyc3QsIEkgYmVsaWV2ZSB0aGUgNTI0 NWJpcyBzZWN0aW9uIHRvIHJlZmVyZW5jZSBpcyA2LjIuNS4zLjMuDQoNClNlY29uZCwgYWNjb3Jk aW5nIHRvIHRoZSB0ZXh0IGluIHNlY3Rpb24gNi4yLjUuMy4zIG9mIDUyNDViaXMsICphbGwqIHBh aXJzDQpmb3IgKmFsbCogc3RyZWFtcyAoZm9yIGEgZ2l2ZW4gZm91bmRhdGlvbikgYXJlIHVuZnJv emVuIG9uY2UgdGhlIGNoZWNrZWQNCnBhaXIgc3VjY2VlZHMgLSBub3Qgb25seSBwYWlycyBmb3Ig dGhlIHNhbWUgc3RyZWFtLg0KDQogICAgICAgICJUaGUgc3VjY2VzcyBvZiB0aGUgY29ubmVjdGl2 aXR5IGNoZWNrIG1pZ2h0IGFsc28gY2F1c2UgdGhlIHN0YXRlIG9mDQogICAgICAgIG90aGVyIGNh bmRpZGF0ZSBwYWlycyB0byBjaGFuZ2UuICBUaGUgSUNFIGFnZW50IE1VU1Qgc2V0IHRoZSBzdGF0 ZXMNCiAgICAgICAgZm9yIGFsbCBvdGhlciBGcm96ZW4gY2FuZGlkYXRlIHBhaXJzIChpbiBlYWNo IENIRUNLIExJU1QgaW4gdGhlIENIRUNLDQogICAgICAgIExJU1QgU0VUKSB3aXRoIHRoZSBzYW1l IGZvdW5kYXRpb24gdG8gV2FpdGluZy4iDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5n IGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg== --_000_D555936B1D723christerholmbergericssoncom_ Content-Type: text/html; charset="euc-kr" Content-ID: <7927E1DEF57CE249B4C8CB13E25F24B0@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGksPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jmd0OyBJJ20gYSBsaXR0bGUgY29uZnVzZWQgYWJv dXQgdGhlIHNlY29uZCBwb2ludC4mbmJzcDsgSXQgc2VlbXMgbGlrZSB0aGUgdGV4dCBpcyBzYXlp bmcgdG8gdW5mcmVlemUgdGhlIHBhaXJzIHdpdGggdGhlIHNhbWUgZm91bmRhdGlvbiBpbiBhbGwg Y2hlY2sgbGlzdHMsIGFuZCB0aGF0IHNvdW5kcyBjb3JyZWN0IHRvIG1lLiZuYnNwOzwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYXQgaXMg d2hhdCBpdCBzaG91bGQgc2F5IDopPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CdXQg dGhlIHRleHQgc2F5cyChsGZvciB0aGUgU0FNRSBtZWRpYSBzdHJlYW0gYW5kIGZvdW5kYXRpb26h sS4gSXQgc2hvdWxkIHNheSChsGZvciBBTEwgbWVkaWEgc3RyZWFtcyB3aXRoIHRoZSBzYW1lIGZv dW5kYXRpb26hsS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc28sIGluIEZpZ3Vy ZSAzIG9ubHkgbTIgaXMgc2V0IHRvIFcuIG0zIGFuZCBtNCBzaG91bGQgYWxzbyBiZSBzZXQgdG8g Vy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdywgaW4gRmlndXJlIDQgbTMgYW5k IG00IDxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPkFSRTwvc3Bhbj4mbmJzcDtzZXQg dG8gVywgc28gbWF5YmUgbXkgaXNzdWUgaXMgdGhhdCBJIGRvbqGvdCByZWFsbHkgc2VlIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gRmlndXJlIDMgYW5kIDQuIENvdWxkbid0IEZpZ3VyZSAzIGJlIHJl bW92ZWQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hyaXN0ZXI8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+PGJyPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciI+T24gTW9uLCBNYXkgMjksIDIwMTcg YXQgNToxNyBBTSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NCkhpLDxicj4NCjxicj4NCldlIG1heSBoYXZlIGRpc2N1c3NlZCB0aGlz IGJlZm9yZSwgYnV0IGFzIGl0IHN0aWxsIGV4aXN0cyBpbjxicj4NCmRyYWZ0LXRyaWNrbGUtMTEg SSB3aWxsIGNvbW1lbnQgb24gaXQ6PGJyPg0KPGJyPg0KU2VjdGlvbiA4LjEuMS4gY29udGFpbnMg dGhlIGZvbGxvd2luZyB0ZXh0Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmcXVvdDtUaGVuLCBhcyB0aGUgY2hlY2tzIHByb2NlZWQgKHNlZSBTZWN0aW9uIDYuMi41LjQg b2YgW3JmYzUyNDViaXNdKSw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9yIGVh Y2ggcGFpciB0aGF0IGVudGVycyB0aGUgU3VjY2VlZGVkIHN0YXRlIChkZW5vdGVkIGhlcmUgYnkg JnF1b3Q7UyZxdW90OyksPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBhZ2Vu dCB3aWxsIHVuZnJlZXplIGFsbCBwYWlycyBmb3IgdGhlIHNhbWUgbWVkaWEgc3RyZWFtIGFuZDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3VuZGF0aW9uIChlLmcuLCBpZiB0aGUg cGFpciBpbiBjb2x1bW4gMSwgcm93IDEgc3VjY2VlZHMgdGhlbiB0aGU8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgYWdlbnQgd2lsbCB1bmZyZWV6ZSB0aGUgcGFpciBpbiBjb2x1bW4g MSwgcm93IDIpLqn3PGJyPg0KPGJyPg0KPGJyPg0KRmlyc3QsIEkgYmVsaWV2ZSB0aGUgNTI0NWJp cyBzZWN0aW9uIHRvIHJlZmVyZW5jZSBpcyA2LjIuNS4zLjMuPGJyPg0KPGJyPg0KU2Vjb25kLCBh Y2NvcmRpbmcgdG8gdGhlIHRleHQgaW4gc2VjdGlvbiA2LjIuNS4zLjMgb2YgNTI0NWJpcywgKmFs bCogcGFpcnM8YnI+DQpmb3IgKmFsbCogc3RyZWFtcyAoZm9yIGEgZ2l2ZW4gZm91bmRhdGlvbikg YXJlIHVuZnJvemVuIG9uY2UgdGhlIGNoZWNrZWQ8YnI+DQpwYWlyIHN1Y2NlZWRzIC0gbm90IG9u bHkgcGFpcnMgZm9yIHRoZSBzYW1lIHN0cmVhbS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJnF1b3Q7VGhlIHN1Y2Nlc3Mgb2YgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayBt aWdodCBhbHNvIGNhdXNlIHRoZSBzdGF0ZSBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBvdGhlciBjYW5kaWRhdGUgcGFpcnMgdG8gY2hhbmdlLiZuYnNwOyBUaGUgSUNFIGFnZW50 IE1VU1Qgc2V0IHRoZSBzdGF0ZXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9y IGFsbCBvdGhlciBGcm96ZW4gY2FuZGlkYXRlIHBhaXJzIChpbiBlYWNoIENIRUNLIExJU1QgaW4g dGhlIENIRUNLPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExJU1QgU0VUKSB3aXRo IHRoZSBzYW1lIGZvdW5kYXRpb24gdG8gV2FpdGluZy4mcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQpS ZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkljZUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ljZSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pY2U8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D555936B1D723christerholmbergericssoncom_-- From nobody Wed May 31 23:55:56 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 0122C129B56 for ; Wed, 31 May 2017 23:55:53 -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 qdKUufovILU9 for ; Wed, 31 May 2017 23:55:51 -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 9120B1294D8 for ; Wed, 31 May 2017 23:55:50 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-76-592fba748650 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.DF.22014.47ABF295; Thu, 1 Jun 2017 08:55:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 08:55:30 +0200 From: Christer Holmberg To: Peter Thatcher , Roman Shpount CC: "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? Thread-Index: AQHS2OUS2o6Dy/2G+E2qAmGsup74daIM+cYAgAIR8oCAAJ0hAA== Date: Thu, 1 Jun 2017 06:55:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D55595021D73Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7vW7JLv1Ig3dnLC2+Xai1uLb8NavF jAtTmR2YPRZsKvVYsuQnk8etKQUBzFFcNimpOZllqUX6dglcGd874guuJ1Scf+HQwHgmqIuR k0NCwETiy50tLF2MXBxCAkcYJX6/X80G4SxilGg/0snaxcjBwSZgIdH9TxukQUTAR+LR3UeM IGFmAUWJl3vVQMLCAqUS+5ZNYoQoKZNYueM5G4TtJPFswzk2kHIWARWJvd8LQExeAWuJO+tc IBb9ZpR4PHEGO0g5p0CgxINjX8FsRgExie+n1jCB2MwC4hK3nsxngjhZQGLJnvPMELaoxMvH /8COFBXQk3i33xPElBBQkpi2NQ2iM0Hi0+GNrCA2r4CgxMmZT1gmMIrOQjJ0FpKyWUjKIOIG Eu/PzWeGsLUlli18DWXrS2z8cpYRwraW2NT+kw1ZzQJGjlWMosWpxUm56UbGeqlFmcnFxfl5 enmpJZsYgZF4cMtv1R2Ml984HmIU4GBU4uF9uEQ/Uog1say4MvcQowQHs5IIL18lUIg3JbGy KrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWpRTBZJg5OqQZGe8cKk7W9Ye5KVx/P /Pz9s6eU08GIqAnzAvhVv7iaRB687lzfzcywte3wni59D++9iXWFy6cImUk+OJP8uEZ469kV 5VprpB1mez5Tt8m/cK39//0ZMXUOm9ybEm4m6v2tm3B72gTD3Ol8L/f8uVBVtH2l+LKr6984 aD5S3db2Z72Y3q57Ij3KSizFGYmGWsxFxYkAHXt9u8ACAAA= Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream? 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, 01 Jun 2017 06:55:53 -0000 --_000_D55595021D73Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >"The lite implementation will never itself determine that ICE >processing has failed for a media stream ... >rather, the full peer will >= make that determination and ... restart" sounds >to me like "Full will rest= art; lite will not restart". > > However, if you're right and it realy means "Full may restart because of = failure; lite may restart for other reasons", then I agree we should perhap= s > reword it to make it clear that the lite side can restart. I agree. >Why would a lite side restart? Well, if it's a client->server situation (a= common use case for ICE lite), the server may be failing over to another s= erver with a different IP address. Rather than wait for >the client to noti= ce, it can signal it to the client. > >Now you may say "then let the server signal to the client to signal the IC= E restart". But not only is that silly, but it also highlights the fact th= at this is really out of scope for ICEbis to define and that ICEbis should = leave it to the using/signaling protocol to define. > >I think we should just say in ICEbis something like "the using protocol de= fines how ICE restarts are triggered" and that's about it. I=92ll think of some text. Regards, Christer On Tue, May 30, 2017 at 6:56 AM Christer Holmberg > wrote: Hi, The draft contains the following text in section 7.2.1: "The lite implementation will never itself determine that ICE processing has failed for a media stream; rather, the full peer will make that determination and then remove or restart the failed media stream as part of subsequent candidate exchange process." But, the way I read it, it=92s more about determining ICE failure. Is there= any text actually preventing an lite implementation from doing a restart? = I can=92t find such text anywhere. In any case, it would probably be a good idea to modify the text, and/or cl= arify that an lite agent is allowed to trigger a restart. Regards, Christer From: Roman Shpount > Date: Tuesday 30 May 2017 at 04:35 To: Christer Holmberg > Cc: "pthatcher@google.com" >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start = an ICE restart or remove a media stream? On Mon, May 29, 2017 at 3:02 AM, Christer Holmberg > wrote: Hi, > - Why can't a lite agent start an ICE restart or remove a media stream? = Seems like it would make sense for it to be able to, but the spec says it c= an't. Technically, I guess a lite agent COULD start an ICE restart. But, what wou= ld be the trigger? A lite agent doesn=92t send STUN requests etc. Lite agent must be able to initiate ICE restart or things will break. Consi= der a 3pcc scenario where a re-INVITE moves the call from one ICE-lite end = point to another. In this case, 3pcc controller will send an empty re-Invit= e to an ICE-lite end point, to which it must respond with a new ufrag value= . This will initiate an ICE restart on the full ICE end point where 3pcc wi= ll forwards the SDP received from ICE-lite endpoint, which should cause ful= l ICE endpoint to start collecting new candidates and run connectivity chec= ks to the ICE-lite end point. Regards, _____________ Roman Shpount --_000_D55595021D73Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>"The lite implementation will never itself determine that ICE
>processing h= as failed for a media stream ... >rather, the = full peer will >make that de= termination and = ... restart"= ; sounds >to me like "Full will restart; lite will not restart".
>
> However, if you're right and = it realy means "Full may restart because of failure; lite may restart = for other reasons", then I agree we should perhaps > reword it to make it clear that the lite side can restart.

I agree.

>Why would a li= te side restart? Well, if it's a client->server situation (a common use = case for ICE lite), the server may be failing over to another server with a= different IP address. Rather than wait for >the client to notice, it can signal it to the client.
>
>Now you may say "then let the server signal to the client to = signal the ICE restart".  But not only is that silly, but it also= highlights the fact that this is really out of scope for ICEbis to define = and that ICEbis should leave it to the using/signaling protocol to define.  
>
>I think we should just say in ICEbis something like "the usin= g protocol defines how ICE restarts are triggered" and that's about it= .

I=92ll think of some text.

Regards,

Christer





On Tue, May 30, 2017 at 6:56 AM Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:
Hi,

The draft contains the following text in section 7.2.1:
   "The lite implementation will never itself determine th=
at ICE
   processing has failed for a media stream; rather, the full peer will
   make that determination and then remove or restart the failed media
   stream as part of subsequent candidate exchange process."
But, the way I read it, it=92s more about determining ICE failure. Is = there any text actually preventing an lite implementation from doing a rest= art? I can=92t find such text anywhere.

In any case, it would probably be a good idea to modify the text, and/= or clarify that an lite agent is allowed to trigger a restart.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 30 May 2017 at 04:35<= br> To: Christer Holmberg <christer.holmb= erg@ericsson.com>
Cc: "pthatcher@google.com" <pthatcher@google.com= >, "ice@ietf.org<= /a>" <ice@ietf.org>=
Subject: Re: [Ice] Peter's review o= f ICEbis - Why can't a lite agent start an ICE restart or remove a media st= ream?


On Mon, May 29, 2017 at 3:02 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

> - Why can't a lite agent start an ICE restart or remove a media stream= ?  Seems like it would make sense for it to be able to, but the spec s= ays it can't.

Technically, I guess a lite agent COULD start an ICE restart. But, wha= t would be the trigger? A lite agent doesn=92t send STUN requests etc.


Lite agent must be able to initiate ICE restart or things will break. = Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-lite= end point to another. In this case, 3pcc controller will send an empty re-= Invite to an ICE-lite end point, to which it must respond with a new ufrag value. This will initiate an ICE= restart on the full ICE end point where 3pcc will forwards the SDP receive= d from ICE-lite endpoint, which should cause full ICE endpoint to start col= lecting new candidates and run connectivity checks to the ICE-lite end point.

Regards,
_____________
Roman Shpount
 
 --_000_D55595021D73Fchristerholmbergericssoncom_--