Re: [MMUSIC] Review of draft-ietf-mmusic-trickle-ice-02

Brandon Williams <brandon.williams@akamai.com> Fri, 23 October 2015 16:17 UTC

Return-Path: <brandon.williams@akamai.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC201A6FC7 for <mmusic@ietfa.amsl.com>; Fri, 23 Oct 2015 09:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 qBekWXf716KA for <mmusic@ietfa.amsl.com>; Fri, 23 Oct 2015 09:17:39 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9C1A6FC5 for <mmusic@ietf.org>; Fri, 23 Oct 2015 09:17:39 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BD05343351F; Fri, 23 Oct 2015 16:17:38 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A6C30433514; Fri, 23 Oct 2015 16:17:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445617058; bh=mq2BsJLheLcRj4a5QNkh/jgKjzanecMzrunZ8K4Wo6s=; l=1795; h=To:References:From:Date:In-Reply-To:From; b=qYefKFGUZj1itwqmDxVhDNktbqzgfAAN9IjY8+DoLCjtBNavQ/FQH2uiQXJspUnLg L50HfnV97M1LVH9GshtQbre7HnfTLbAGI9sIbGNZxOFTYCy6/QqYPkxpKvuzMUG577 TYvPLM4vR3RpKhNDM8zuAzr+Zyua+7iuJ5pITAGw=
Received: from [172.28.113.245] (bowill.kendall.corp.akamai.com [172.28.113.245]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9E0362055; Fri, 23 Oct 2015 16:17:38 +0000 (GMT)
To: Peter Saint-Andre - &yet <peter@andyet.net>, mmusic@ietf.org, draft-ietf-mmusic-trickle-ice@tools.ietf.org
References: <55E8A14B.5080305@akamai.com> <561F1C2A.5090008@andyet.net> <561FB305.30001@akamai.com> <562530C9.3010004@andyet.net>
From: Brandon Williams <brandon.williams@akamai.com>
Message-ID: <562A5DA2.4040104@akamai.com>
Date: Fri, 23 Oct 2015 12:17:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <562530C9.3010004@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/5bXEQaoyfAiah3J-4ekuTqSu3KM>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-trickle-ice-02
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2015 16:17:40 -0000

Having an empty checklist doesn't seem problematic to me. My comment was 
just that the purpose of creating an empty checklist is unclear to me 
from the text. Empty checklists won't happen with Vanilla ICE, so a 
potential implementer might need a little more detail about why they are 
created and what to do with them while they remain empty.

--Brandon

On 10/19/2015 02:04 PM, Peter Saint-Andre - &yet wrote:
> On 10/15/15 8:07 AM, Brandon Williams wrote:
>> On 10/14/2015 11:23 PM, Peter Saint-Andre - &yet wrote:
>>>> s 6.2
>>>> It's unclear to me why it's useful to monitor Active/Frozen state for
>>>> check lists with no remote and/or local candidates.
>>>
>>> Does §6.2 actually say that?
>>>
>>>> What is actually
>>>> being monitored in? Or is this just meant to indicate than an empty
>>>> checklist MUST/SHOULD be treated as frozen for the purpose of the
>>>> frozen
>>>> candidates algorithm?
>>
>> I was referring to this text from section 6.2:
>>
>>     Obviously in
>>     order for candidate pairing to be possible, it would be necessary
>>     that both the offer and the answer contained candidates.  If this was
>>     not the case agents will still create the check lists (so that their
>>     Active/Frozen state could be monitored and updated) but they will
>>     only populate them once they actually have the candidate pairs.
>>
>> This does seem to indicate that empty checklists might be created for
>> the purpose Active/Frozen state monitoring.
>
> Yes, it does. The assumption seems to be that candidate pairs will be
> forthcoming and that the user agents won't do any checking until the
> checklist is non-empty. Does that seem to be problematic?
>
> Peter
>
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.