Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart
Justin Uberti <juberti@google.com> Wed, 10 July 2019 23:09 UTC
Return-Path: <juberti@google.com>
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 40CC9120248 for <ice@ietfa.amsl.com>; Wed, 10 Jul 2019 16:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.204
X-Spam-Level:
X-Spam-Status: No, score=-16.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 46E2bBN7eu8E for <ice@ietfa.amsl.com>; Wed, 10 Jul 2019 16:09:25 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 77097120222 for <ice@ietf.org>; Wed, 10 Jul 2019 16:09:25 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id 190so2642061vsf.9 for <ice@ietf.org>; Wed, 10 Jul 2019 16:09:25 -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=UyjD9c6j4nXPlilI5RsOZHPfb2PfWcz+LFtW8V99O9E=; b=RqMAdNTl7ZXaG7s6rqhBrMHeTW2kKWbHe4MWDk3Ya6CYQz+/ouyyhDEhaEhx+8PJHE CKhOYoT3gu/Yg5L2SMtyX2ZdfebTQht3JUgVYsrji96EGKc2Y/U7SibR6sUTCq87EZ19 ZPJkrmf0ex8oKml7Y1Ric10hmwmh8AZN9nYAYpBgvGOcfhZlvQOvkpc+G85EUpAK55RR ThUzGAaaRdAxjfmGnIrpgJlDH0JOft7694fF81FoxK8NL8w6L/fG8gH31s5Z3F3k3wbX nLnfgLW9TVPJrSj9+iwk2asn1FjNe55WjYFjSdsk/Gesk6RZJhTiPWboVAC3m6OQ93/p 7xng==
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=UyjD9c6j4nXPlilI5RsOZHPfb2PfWcz+LFtW8V99O9E=; b=DIUZ74HJyOnM8pf4K/AfcVRRBSS8COQqBND5wqFYEA4NyJ+wUz3nCWwPYanAnt82df 5D8QL227AsHgP7EkUf5wQhYHit9mK6esQeSaMjvgZ606XScIBMBVu+1K7q9A/SKlTSlz 0SqTMyCnCD9YuFS303nrdO54DYS+lTpOAVrDRq9o6Yw9upxKn9obKmVtaQhOk0jO8+Uh NXPtAvjEYaSfOV6XM63EfLmgISFb5dV681/yzOm3dKLCLqYhkWSl4+rSXVdBzxRzMpyI /t1gNL8j+s0EfuQ3EZtu2DMvav2ktmW3cdXUzgUvkLggLMqE+wk64Qg9txb2Cn/0EDFC rJ1w==
X-Gm-Message-State: APjAAAU0FimfAacBul16suvGsHuMA6x2kBwtDWxNBWmBJggvHdBl7n7P f27oIFx1Ko7HkW6LKgkkfWhyfcXHp0QnuDqjUPFlbA==
X-Google-Smtp-Source: APXvYqy18V84EukqfE5ED0tpcsSGUEVNtDjvKb+BuKgdTHeL6Hc5ko1e3azYjMklfUIk4PxGVwo3IbvXWD+FTLNi9CI=
X-Received: by 2002:a67:eb19:: with SMTP id a25mr397161vso.109.1562800163697; Wed, 10 Jul 2019 16:09:23 -0700 (PDT)
MIME-Version: 1.0
References: <AFCE8799-8865-454F-8478-81CE11E9B454@ericsson.com> <1aa5aac7-af59-4e3b-8651-18f6e6431a2d@alvestrand.no> <66678ADA-7C02-4D9D-B9D2-308873BC0125@ericsson.com> <7a829bc0-d066-a3be-b7be-9b39ce799821@alvestrand.no> <CAJrXDUHZJURLvzBYX2MGcMsrFgyOagW5=s1OSXwDmTZpsruD0A@mail.gmail.com> <VI1PR07MB3167F21EF7A1009B8EB9948B93FB0@VI1PR07MB3167.eurprd07.prod.outlook.com> <CAOJ7v-11EjJK644RCb=nASVu_vwkhOxzj4XY4JUBW+1Fr19yOA@mail.gmail.com>
In-Reply-To: <CAOJ7v-11EjJK644RCb=nASVu_vwkhOxzj4XY4JUBW+1Fr19yOA@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 10 Jul 2019 16:09:11 -0700
Message-ID: <CAOJ7v-20GcArjJ0K0ECjtM4RHXPgnx=zs15XAYDEcZjaYinYJg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Peter Thatcher <pthatcher@google.com>, Harald Alvestrand <harald@alvestrand.no>, Nils Ohlmeier <nohlmeier@mozilla.com>, Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d2f1b058d5bc444"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/hh__ZusU0uOE2XMw9JwXZRYBpcM>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 23:09:29 -0000
When writing up this text, I realized there are edge cases where you might want to discover prflx candidates even if you didn't send any candidates (e.g., you don't send any candidates, you get a single IP from the remote side, and when you check it, you get a response back from a different IP). Ergo, I think we should start the timer as soon as we have local and remote ICE credentials, regardless of whether or not we send a candidate. On Wed, Jul 3, 2019 at 9:22 PM Justin Uberti <juberti@google.com> wrote: > For #1, I don't think the proposed solution is correct. The "alternative > c)" that I proposed is to "Start the timer as soon as we have received a > remote offer or answer and have also sent a local candidate to the remote > side", which is different than what is mentioned in the OP. > > The rationale for this is: > A) we can't start ICE processing (checks) until we get a remote > offer/answer with ICE credentials > B) we can't receive an incoming check that could create a prflx candidate > unless we sent a candidate to the remote side > > Tracking this issue in https://github.com/cdh4u/draft-ice-pac/issues/12. > > For #2, I agree we should use the "max duration of a connectivity check > transaction". I think this value will work just fine in real world > scenarios. And if the timer expires before we have tested all pairs (this > can certainly happen, in the case of two hosts with no connectivity to each > other), we just resume existing ICE processing, and fail when everything > moves to the failed state (i.e., every pair has timed out). The timer is > simply there to prevent premature failures. > > Tracking in https://github.com/cdh4u/draft-ice-pac/issues/13 > > > On Wed, Jul 3, 2019 at 1:02 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> So, what timer value do people want? >> >> >> >> And, assuming the timer value is not going to be based on the number of >> streams, what do we do if the timer expires before we have tested all pairs >> for all streams? I think we need to specify that. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* Peter Thatcher <pthatcher@google.com> >> *Sent:* 02 July 2019 03:56 >> *To:* Harald Alvestrand <harald@alvestrand.no> >> *Cc:* Christer Holmberg <christer.holmberg@ericsson.com>; Justin Uberti < >> juberti@google.com>; Nils Ohlmeier <nohlmeier@mozilla.com>; Roman >> Shpount <roman@telurix.com>; ice@ietf.org >> *Subject:* Re: [Ice] ICE PAC: When to start the timer waiting for >> possible peer reflexive candidates? - discussion restart >> >> >> >> I agree. The options you present seem reasonable and I think we should >> move ahead with them. >> >> >> >> On Mon, Jun 24, 2019 at 6:20 AM Harald Alvestrand <harald@alvestrand.no> >> wrote: >> >> On 6/24/19 12:06 PM, Christer Holmberg wrote: >> >> Hi, >> >> >> >> Go for what? 😊 >> >> I was noting the month of silence, and thinking that I should encoruage a >> decision to be taken - "analysis paralysis" is not a good thing! >> >> >> >> Regarding 1), eventhough it’s not my personal preference to start the >> timer when the first offer/answer is sent, I could live with it. >> >> >> >> It's a well defined time, and is observable by the entity that has to act >> when the timer expires, so I think it is much better than "undefined". >> >> That's my requirement :-) >> >> >> >> >> >> Regarding 2), however, I would really like some input on whether the >> duration should be independent of the number of streams, components etc. >> >> I think having a single number is preferable to having a complex number >> that could change over time (for instance, if we don't reset the timer when >> adding streams, then adding or removing streams after the timer started >> will lead to hard-to-define behavior). >> >> >> >> But my main concern is that we get this stuff done and get the basic >> timer mechanism into interoperable code - having a spec to implement from >> now is better than having a spec that has had slightly more discussion, but >> no fundamental changes, 6 months from now. >> >> >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From: *Harald Alvestrand <harald@alvestrand.no> <harald@alvestrand.no> >> *Date: *Sunday, 23 June 2019 at 9.08 >> *To: *Christer Holmberg <christer.holmberg@ericsson.com> >> <christer.holmberg@ericsson.com>, Justin Uberti <juberti@google.com> >> <juberti@google.com>, Nils Ohlmeier <nohlmeier@mozilla.com> >> <nohlmeier@mozilla.com> >> *Cc: *Roman Shpount <roman@telurix.com> <roman@telurix.com>, >> "ice@ietf.org" <ice@ietf.org> <ice@ietf.org> <ice@ietf.org> >> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for >> possible peer reflexive candidates? - discussion restart >> >> >> >> On 5/28/19 1:54 PM, Christer Holmberg wrote: >> >> Hi, >> >> >> >> We need to move forward with this. >> >> >> >> There are two main questions at the moment: >> >> >> >> 1. When does an endpoint start the timer ("minimum-time-to-run-ICE" >> timer, based on previous discussions)? >> 2. What is the duration of the timer? >> >> >> >> Regarding 1), my understanding is that people suggest alternative c), >> which starts the timer when an endpoint has sent (in an offer or answer) at >> least one local candidate (or EOC). >> >> >> >> >> >> Regarding 2), it has been suggested that the duration would be the same >> as the max duration of a connectivity check transaction. Do we think that >> is enough, no matter how many media streams and components are used? >> >> >> >> Go for it. It is much better than having nothing. >> >> >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From: *Ice <ice-bounces@ietf.org> <ice-bounces@ietf.org> on behalf of >> Christer Holmberg <christer.holmberg@ericsson.com> >> <christer.holmberg@ericsson.com> >> *Date: *Friday, 3 May 2019 at 15.02 >> *To: *Justin Uberti <juberti@google.com> <juberti@google.com>, Nils >> Ohlmeier <nohlmeier@mozilla.com> <nohlmeier@mozilla.com> >> *Cc: *Roman Shpount <roman@telurix.com> <roman@telurix.com>, >> "ice@ietf.org" <ice@ietf.org> <ice@ietf.org> <ice@ietf.org> >> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for >> possible peer reflexive candidates? >> >> >> >> Hi, >> >> >> >> I don’t think there will be any interoperability issues. At the end of >> the day PAC is only about how long to wait for candidates, so the worse >> thing that can happen is than an agent declares ICE failure too early. >> >> >> >> And, no matter whether an agent knows that the peer supports PAC or not, >> it should aim at sending it’s candidates to its peer as soon as possible, >> depending on whatever local policies. The agent should not delay sending >> candidates just because it assumes that the peer will anyway wait for them. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From: *Justin Uberti <juberti@google.com> <juberti@google.com> >> *Date: *Thursday, 2 May 2019 at 22.28 >> *To: *Nils Ohlmeier <nohlmeier@mozilla.com> <nohlmeier@mozilla.com> >> *Cc: *Christer Holmberg <christer.holmberg@ericsson.com> >> <christer.holmberg@ericsson.com>, Roman Shpount <roman@telurix.com> >> <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org> <ice@ietf.org> >> <ice@ietf.org> >> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for >> possible peer reflexive candidates? >> >> >> >> >> >> >> >> On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <nohlmeier@mozilla.com> >> wrote: >> >> >> >> >> >> >> On May 2, 2019, at 12:13, Justin Uberti <juberti@google.com> wrote: >> >> >> >> >> >> >> >> On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <nohlmeier@mozilla.com> >> wrote: >> >> >> >> I do think Nils' point is important though, i.e., if we have a bad >> server it will take a very long time to decide on 'last set of candidates', >> >> which is probably not helpful. As such I think the potential positions >> we can take are: >> >> a) Start the timer as soon as we have an answer, regardless of any >> candidates. >> >> b) a) + receipt of at least one remote candidate (or remote EOC). >> (This is Nils' suggestion). >> >> c) a) + sending at least one local candidate (or local EOC). >> >> As we are mostly concerned about the remote side: 1) not providing us >> with candidates, or 2) providing us with unusable candidates or 3) >> providing us with candidates really late I don’t see how option c) would >> help in any of these scenarios. >> From my point of view we should choose either a) or b). >> >> >> >> c) is just a clarification of a), in that you can't expect to receive >> prflx candidates until you've at least provided the other side with a >> candidate, so that may be the right time for the timer to start. I don't >> feel super strongly about this though. >> >> >> >> Ok. I hadn’t looked at it from that angle. So c) being a stronger a) I >> guess it would be okay. >> >> >> >> I guess my only concern is that in Firefox we stopped doing a) because it >> caused to many problems. With that in mind would it cause interop problems >> if we leave up to the implementor to choose to implement either b) or c)? >> >> >> >> I'd be fine with that, but I'd want to describe what to watch out for. >> Can you explain a bit more? >> >> >> >> >> >> >> b) has a problem if the remote side doesn't send any candidates, which >> we want to explicitly allow. >> > >> > True. >> >> Just to make sure we are all on the same page: b) is only a problem in >> the scenario where the remote side doesn’t send any candidates but also >> does not send EOC. >> >> >> The EOC should allow agents which explicitly don’t want to provide >> candidate to get the timer started soon. >> I think that leaves us with scenarios where the remote doesn’t provide >> host candidates, and it’s reflexive or relay candidates take for ever >> because of slow servers. >> >> >> >> Correct, but we can't control which endpoints will send us an EOC or not. >> So that will always be a possibility. >> >> >> >> Fair enough. >> >> >> >> >> >> >> I tend to lean towards a) as the simplest option. >> > >> > Keep in mind that RFC 8445 is generic, so we need to to define what we >> mean by "answer". I guess it means some kind of indication that makes the >> agent assume that the remote peer has been contacted. In ice-sip-sdp we can >> then map that to an SDP answer. >> >> Good point. We basically treat the SDP answer here to be something like >> an beginning of ICE, because we don’t have an explicit signal for that. I >> think in SDP based worlds there is no need for an extra signal like that. >> Not sure if other use cases of ICE would benefit from an explicit begin >> signal. >> >> >> >> The answer in some ways is an explicit begin signal, because it contains >> the username/password information needed to start ICE checks. >> >> >> >> Yeah I didn’t see your reply before hitting send on mine. Using the >> availability sounds like a good idea as the minimum gating function/signal. >> >> >> >> Best >> >> Nils >> >> >> >> >> >> _______________________________________________ >> >> Ice mailing list >> >> Ice@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ice >> >> >> >> -- >> >> Surveillance is pervasive. Go Dark. >> >> >> >> -- >> >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >>
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Harald Alvestrand
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Harald Alvestrand
- Re: [Ice] ICE PAC: When to start the timer waitin… Peter Thatcher
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Roman Shpount
- Re: [Ice] ICE PAC: When to start the timer waitin… Justin Uberti
- Re: [Ice] ICE PAC: When to start the timer waitin… Harald Alvestrand
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Roman Shpount
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Harald Alvestrand
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Justin Uberti
- Re: [Ice] ICE PAC: When to start the timer waitin… Justin Uberti
- Re: [Ice] ICE PAC: When to start the timer waitin… Roman Shpount
- Re: [Ice] ICE PAC: When to start the timer waitin… Peter Thatcher
- Re: [Ice] ICE PAC: When to start the timer waitin… Nils Ohlmeier
- Re: [Ice] ICE PAC: When to start the timer waitin… Justin Uberti
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg
- Re: [Ice] ICE PAC: When to start the timer waitin… Justin Uberti
- Re: [Ice] ICE PAC: When to start the timer waitin… Christer Holmberg