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

Nils Ohlmeier <nohlmeier@mozilla.com> Thu, 02 May 2019 17:07 UTC

Return-Path: <nohlmeier@mozilla.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 ADCC2120605 for <ice@ietfa.amsl.com>; Thu, 2 May 2019 10:07:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArMjqrpyFOgZ for <ice@ietfa.amsl.com>; Thu, 2 May 2019 10:06:59 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 50A941205E9 for <ice@ietf.org>; Thu, 2 May 2019 10:06:59 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id c13so1354970pgt.1 for <ice@ietf.org>; Thu, 02 May 2019 10:06:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fPddByX6aKNP6F7fxVWA2TNRYh7G06tfRFEGMQtSEec=; b=fqS+pj8nvVv6nwQRJs6uVNx3va/s7PNQCY63vr15j/5SRoeI8k+nqtywWSM0sNoYqr bjefARTjYFrQqbT/ydIPHe18t5JQUfMoanOscXDx7t34qK6j54A31eWSpMAx65kx8vSl 09bl8rxHzadn6lTP8axVB8RhecZRCtyWzLLDI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fPddByX6aKNP6F7fxVWA2TNRYh7G06tfRFEGMQtSEec=; b=j+rZ35RjXhBBnz/qo4+eMFK3mPwEcufGKahzu7+vFSexNMLQFUJW0Kxir0/7ubZ6hY XAVztnjLYPskgQQn9Wzusk5jNxTvjblIFOaeCT/G8ZkT6ytHgl19x7h3lxE6y4mf+YIb HV/v8nXF3lQ8KjutliQIoMth/M5UxdAPNE5gkDPi3FeEnP4wuX1D+uGoRRoRN8oiqpt/ ttMaHQSeAgl+wnsaxJdkmerII0r0/xccMiLTDDG4qlN/GfKt/ts0EgsyrLwxpwD/kdCX 6quzhR4iw3nH5bPdJfkHVbCGOSEZTtBC1v+1byz5IjSBbBmaaN1WqoX+16z3vvD39lBa KMgA==
X-Gm-Message-State: APjAAAXYIvAnbqh4SK3WY1oPAwjxcLbf0DocyCrR+5cq5EOPYMSJksYo WR0WIHDf7E5EWJ0Yn+ZGQ7wmng==
X-Google-Smtp-Source: APXvYqzaNgX1J5K7eeGb2hyYJzE0WXrIKP05bzq5u6wja1vux8gmoJt6ao4HALkZ4Zu2Ur2B1Jgodw==
X-Received: by 2002:a63:58b:: with SMTP id 133mr5145759pgf.138.1556816818806; Thu, 02 May 2019 10:06:58 -0700 (PDT)
Received: from ?IPv6:2601:647:4600:3f31:2dab:9212:1aa4:b41a? ([2601:647:4600:3f31:2dab:9212:1aa4:b41a]) by smtp.gmail.com with ESMTPSA id b20sm42160722pff.118.2019.05.02.10.06.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 May 2019 10:06:57 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Nils Ohlmeier <nohlmeier@mozilla.com>
In-Reply-To: <156839B0-C680-4F8F-8D93-8F6B33FB8F01@ericsson.com>
Date: Thu, 02 May 2019 10:06:56 -0700
Cc: Justin Uberti <juberti@google.com>, Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0928C15F-E7F4-405B-BBBB-2ECD35BD621D@mozilla.com>
References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <CAD5OKxsMgNTQPNP4Ni72H+yD4iUeyNK+x6CSvdBApGnPTpr_vg@mail.gmail.com> <A4EC3C01-4D7D-45DF-876D-E58706F74866@ericsson.com> <CAD5OKxt8tDemkK=v4X1gjwJGLYrxcd95S7uV53_fsga6grZ_rA@mail.gmail.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <CAD5OKxvmRK8Xzu4FSRv3Lgdg-VrrufzGhjAdSmfcLLkrm-jtjw@mail.gmail.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> <CAD5OKxsgpf7Hv_nxFOZFwfNk7-_xNRzmoPTA2bZCqZo3wzudKQ@mail.gmail.com> <HE1PR07MB316172053751D307F83DE0EB933E0@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxu332E8vzdc4dt09NxXGf9Cr2izwECDAQjc7V_YDx3r5w@mail.gmail.com> <HE1PR07MB316189447ED302BEC5021946933F0@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAOJ7v-3Dv4N5j0KykxQf-gHQfvJ9x-VzbTTTcdJyfgYgcdYy5A@mail.gmail.com> <HE1PR07MB3161E4496E7BDC5FF419CCE793390@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAOJ7v-3JkrYnWpghusRytVvTn1u7OibL9J3NyVh+ia9neSyuHA@mail.gmail.com> <46390078-DE3B-456B-87AC-61AE3C3DF035@ericsson.com> <CAOJ7v-202_STNVj6nLv_0pTTuE_=jn_HJusNERv9Yj7=k=86jg@mail.gmail.com> <156839B0-C680-4F8F-8D93-8F6B33FB8F01@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/QbCx6_J3ISPePy1wJTtkWhBV0Vk>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?
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, 02 May 2019 17:07:07 -0000

>> 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).

>> 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.

>> 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.

Best
  Nils