Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 11 July 2019 06:19 UTC

Return-Path: <christer.holmberg@ericsson.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 23BC81200EF for <ice@ietfa.amsl.com>; Wed, 10 Jul 2019 23:19:51 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Vy3iFZjpHqCe for <ice@ietfa.amsl.com>; Wed, 10 Jul 2019 23:19:46 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40079.outbound.protection.outlook.com [40.107.4.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E038A12008B for <ice@ietf.org>; Wed, 10 Jul 2019 23:19:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XH6+ljw1GnUwpCmSIVAzwWelnqhNGhhdyyjWcVgr2ym6afkW/S8h6gzo/KXdp7tdFRXj3LHLBuOU5Xq9D3ophsZNfkqLxXgk6R6V/k2/EuE3a8MZXjpabM3V3ZNjVm9GW/Im+/mChxJlwhIMgPyH8ZhL3GEGtanNhiQQ/8lpR+ssBVyO/Dp43h73JLeOeBxw/l/cafoOPLRetc2MWdn+iBgZ1IQ9YoRsHd97EU5SG/0z6QldYJWfUxarGMGWphwTeMovoCwxpzndPeQ6mLIvdNWwfaAQreukttW8jhScdyjmaZDaICCpJn4QUz+xx208OSPvWcv9rqStU3GNIY5TDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nJFKyLwn2ptf2Zit0KzE3aRw5gPuoSNQCKwdflTYOmo=; b=N1h3D98C9U+gxT1LCSXvDh6s5VmS3ZDG3yyE34i6Hb35kV0PsWtK8HMzx0kOBd1x4XjVgUnILd/0D38gSje/FajdrHWL5KGhKJ0WdUG5m21y0Q/tvM096GZ7yN1fBk9GM2M07DQYso3XELRzhA69M3D67KCg/TGHfZP9L6fel9fB7hrzwbrmoDeCzEYqhq1CVlw6LvGZ9jKSTKlMK3ONIW7OvEt5rm5IYYrIUmw3ogT94yw4CsT04o2hY3XDyHkEcjemG4ZyBdDmq5uwEax1rXNTe15LQzKJDNJM4Cnm9h2n/3tDdJbtw1tondaDQ9QTo8HBZSrNGuaJqzVuTOajdg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nJFKyLwn2ptf2Zit0KzE3aRw5gPuoSNQCKwdflTYOmo=; b=o/T5F+VFdn+4nQkSjMQoSOh71/yuZcnEGKALNKP6vXGtMZF3mFHRfHejLfcewyGm+Y8DOCBu8XMTtsZDi7facIW/DTpwxEgM4Zp5aD9X09iTKM2o6PG0oIWjWOSbxPcF/ez5GU8xJIoOj43EjeJw/teaSLGba4x/xD72YDtsM0I=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4444.eurprd07.prod.outlook.com (20.176.167.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 06:19:42 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 06:19:42 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Justin Uberti <juberti@google.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>
Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart
Thread-Index: AQHVFUwc5tNKLJLjCke9cDBba/EsEKao6YiAgAIHR4CAAAOSAIALwuyAgALR9zCAAIw7AIAKqOCAgACqkoA=
Date: Thu, 11 Jul 2019 06:19:41 +0000
Message-ID: <2C4A3D11-79C0-4C45-9F3E-AA4C2A9333C1@ericsson.com>
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> <CAOJ7v-20GcArjJ0K0ECjtM4RHXPgnx=zs15XAYDEcZjaYinYJg@mail.gmail.com>
In-Reply-To: <CAOJ7v-20GcArjJ0K0ECjtM4RHXPgnx=zs15XAYDEcZjaYinYJg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190609
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1c6b13ed-5fe1-4d2c-4a34-08d705c7c2ca
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4444;
x-ms-traffictypediagnostic: HE1PR07MB4444:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <HE1PR07MB44441861E7F52FB40A13F2D993F30@HE1PR07MB4444.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0095BCF226
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(396003)(346002)(366004)(376002)(199004)(189003)(51444003)(446003)(476003)(11346002)(2616005)(6246003)(5660300002)(3846002)(186003)(4326008)(58126008)(6116002)(6306002)(54906003)(6512007)(54896002)(236005)(6486002)(478600001)(99286004)(6436002)(102836004)(966005)(316002)(26005)(7736002)(66066001)(53936002)(66476007)(33656002)(53946003)(6506007)(53546011)(30864003)(486006)(76116006)(8676002)(81156014)(25786009)(64756008)(229853002)(76176011)(6916009)(66556008)(81166006)(66446008)(66946007)(71190400001)(2906002)(14454004)(5070765005)(44832011)(71200400001)(256004)(86362001)(68736007)(36756003)(14444005)(606006)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4444; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ylVlKhpZvacD2MlVlMEi+rhKNEM9PmcGtXkkcc8+kbpi3DNNYwN3lyoegmoJ2KBGmpBOnSEI2H2hiFzOQD87fs8RrPg0rKVCVfZVj9apJ25VPE+i5M074TXSSlOOdUKn1l+zvsK2lgcbusyaersnMY1y1hmK/mlFh38bJmFUW1Xrul22+AV7CUDt7PpqeVf0PeiTaRwAHfEcd4U14WoOvg4Nvgjk0Jz+qNexp/zm3MLBhZv6X3RgxuSZPAm7K/RVRPfGHOi9hZg0Gs1UPJl6QpwL8uuXRrZ4+1halaOB5ZIKc/jWjk9CwmWQRBghbz9snBL9/BwKQaUOFQYFLE0xgPYsAhfXmguLPJobj0XSv7mmduNztM0YA8xppglmFWegVv22EocSSZHmxtmucx/mUo0h8+7JGcpM6AvjzUiLco0=
Content-Type: multipart/alternative; boundary="_000_2C4A3D1179C04C459F3EAA4C2A9333C1ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c6b13ed-5fe1-4d2c-4a34-08d705c7c2ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 06:19:41.8373 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4444
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/nfgdlnngKloFuu0lrfUdwjA_RSw>
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: Thu, 11 Jul 2019 06:19:51 -0000

Hi,

What do you mean by ”single IP from the remote side”? A candidate?

Regards,

Christer

From: Justin Uberti <juberti@google.com>
Date: Thursday, 11 July 2019 at 2.09
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "pthatcher@google.com" <pthatcher@google.com>, Harald Alvestrand <harald@alvestrand.no>, Nils Ohlmeier <nohlmeier@mozilla.com>, Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

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<mailto: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<https://protect2.fireeye.com/url?k=fa812fa0-a60b0d76-fa816f3b-0cc47ad93dcc-14ecb4925c17821c&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F12>.

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<https://protect2.fireeye.com/url?k=560d1e46-0a873c90-560d5edd-0cc47ad93dcc-dad442e58bc4db30&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F13>


On Wed, Jul 3, 2019 at 1:02 PM Christer Holmberg <christer.holmberg@ericsson.com<mailto: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<mailto:pthatcher@google.com>>
Sent: 02 July 2019 03:56
To: Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>>
Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; Justin Uberti <juberti@google.com<mailto:juberti@google.com>>; Nils Ohlmeier <nohlmeier@mozilla.com<mailto:nohlmeier@mozilla.com>>; Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>; ice@ietf.org<mailto: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<mailto: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><mailto:harald@alvestrand.no>
Date: Sunday, 23 June 2019 at 9.08
To: Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>, Justin Uberti <juberti@google.com><mailto:juberti@google.com>, Nils Ohlmeier <nohlmeier@mozilla.com><mailto:nohlmeier@mozilla.com>
Cc: Roman Shpount <roman@telurix.com><mailto:roman@telurix.com>, "ice@ietf.org"<mailto:ice@ietf.org> <ice@ietf.org><mailto: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><mailto:ice-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>
Date: Friday, 3 May 2019 at 15.02
To: Justin Uberti <juberti@google.com><mailto:juberti@google.com>, Nils Ohlmeier <nohlmeier@mozilla.com><mailto:nohlmeier@mozilla.com>
Cc: Roman Shpount <roman@telurix.com><mailto:roman@telurix.com>, "ice@ietf.org"<mailto:ice@ietf.org> <ice@ietf.org><mailto: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><mailto:juberti@google.com>
Date: Thursday, 2 May 2019 at 22.28
To: Nils Ohlmeier <nohlmeier@mozilla.com><mailto:nohlmeier@mozilla.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>, Roman Shpount <roman@telurix.com><mailto:roman@telurix.com>, "ice@ietf.org"<mailto:ice@ietf.org> <ice@ietf.org><mailto: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<mailto:nohlmeier@mozilla.com>> wrote:



On May 2, 2019, at 12:13, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:



On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <nohlmeier@mozilla.com<mailto: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<mailto: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<mailto:Ice@ietf.org>
https://www.ietf.org/mailman/listinfo/ice