Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

Flemming Andreasen <fandreas@cisco.com> Fri, 29 June 2018 13:21 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACC2130E86; Fri, 29 Jun 2018 06:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WXnn4z6reR9P; Fri, 29 Jun 2018 06:21:55 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB6F130E5B; Fri, 29 Jun 2018 06:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10848; q=dns/txt; s=iport; t=1530278515; x=1531488115; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=s2+ct6ZMEt09lroCVL0uUrUg+G3zSDyDTmpVJPsM+Pc=; b=TiK1cjkAFniX9Yk0GheWeudLaKbrYi391CsVV4Ofc32j/u1jZbneR/rD DfHJkuKhi2pb2gHf2PYSsXm+OM47dC65EbAu0BmK3xR7fxACaFgsOnJG3 mdUM/Flq3691TT6JZ8dKC+iCPellxOvnEFrNKEN3uEDkXaPN6FiSxnpxt Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQDBMTZb/5JdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYMbLmJ/KIN5lEKBXSp1hzmHZ4cGCxgBCoQDRgKDISE4FAECAQECAQECbRwMhTcBAQEDAQEhSwsQCxgjBwICIQYwBgEMBgIBAReDBQGBZwMIDQ+sYIIcH4Q8gjoNgS6BHwWIbYFWP4EPJ4IzNYJWQgEBAgGBPQEBgx+CVQKMTYxLKwmGBIYMgwUGiA+FQoouT4cAgVghgVJNIxU7gmmCIxcRiEiFWiMwAQEBjk+COQEB
X-IronPort-AV: E=Sophos;i="5.51,285,1526342400"; d="scan'208,217";a="417166635"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2018 13:21:54 +0000
Received: from [10.118.10.23] (rtp-fandreas-2-8816.cisco.com [10.118.10.23]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w5TDLriZ008782; Fri, 29 Jun 2018 13:21:53 GMT
To: Ben Campbell <ben@nostrum.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Adam Roach <adam@nostrum.com>, mmusic-chairs@ietf.org, mmusic WG <mmusic@ietf.org>, Roman Shpount <roman@telurix.com>, Thomas Stach <thomass.stach@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-mmusic-trickle-ice-sip@ietf.org
References: <152276622276.14060.4683526444260158304.idtracker@ietfa.amsl.com> <de37b547-e278-4fa5-b28e-70298a414843@gmail.com> <4A9014B4-102A-4894-BA41-1DA49A662D8B@kuehlewind.net> <fb95e318-50b3-fb42-f94a-c78e124af651@gmail.com> <D9BF2D39-0B51-4697-A5F1-5801916F543D@kuehlewind.net> <a702e5b6-c540-77f9-1f08-08d5a5e1feed@gmail.com> <b1d7c7fa-eea5-ae8a-4a10-b7d5f58d6353@nostrum.com> <0a05813f-21ac-43ba-9caa-fa4dc1000914@cisco.com> <CBA18047-8484-44D3-97A0-465D2441EE0E@nostrum.com> <b7cba717-f611-b7ff-6a59-2cc1de1b117a@gmail.com> <CAD5OKxujrAqk-wKkg5ASvRHM0_0NE12z+Np_J98=aBQhVzNcJA@mail.gmail.com> <53a79cff-8bd9-b676-d534-0aca57ce43fe@cisco.com> <2fa03c8a-3a71-e77e-a76c-d78890b51df3@gmail.com> <CAD5OKxsaeOiv=wNKa-F_kZBBW48BVner7kk8=zbM5+MZbGkPMw@mail.gmail.com> <93422207-c1bd-481b-000b-be000c6e2730@nostrum.com> <A2855A45-1741-4BAA-AE6C-9BF539967C00@nostrum.com> <CAKKJt-faDpbfdOx4GepNcHtFC=dUVRKfJ1Xs3N+SxGUTqEkzqA@mail.gmail.com> <6A08DB61-30F7-4CC3-BA97-7D917E64FD73@nostrum.com>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <95b96c38-cd86-eaf5-9d69-0aa7331eb42e@cisco.com>
Date: Fri, 29 Jun 2018 09:21:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <6A08DB61-30F7-4CC3-BA97-7D917E64FD73@nostrum.com>
Content-Type: multipart/alternative; boundary="------------B04B873B3E4AC18D589436F4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/hI2uuLN1dTn1GmFOU6UedmUd02M>
Subject: Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.26
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, 29 Jun 2018 13:21:59 -0000

Did we finalize on this - does the latest version of the document (-18) 
address the comments ?

Thanks

-- Flemming


On 6/2/18 1:00 AM, Ben Campbell wrote:
> Understood, and I think I knew that. I called out her name in hopes she notices it when digging out from under the pile of mail that will certainly await her when she returns. :-)
>
> Ben.
>
>> On Jun 1, 2018, at 6:45 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>>
>> My co-AD is off the net this week - she is back on next week, I believe.
>>
>> Silence is not a reflection of AD response to the proposed text.
>>
>> Spencer
>>
>> On Fri, Jun 1, 2018, 16:29 Ben Campbell <ben@nostrum.com> wrote:
>> +1.
>>
>> Mirja: does Roman’s proposed text (below) work for you?
>>
>> Thanks!
>>
>> Ben.
>>
>>> On May 31, 2018, at 2:37 PM, Adam Roach <adam@nostrum.com> wrote:
>>>
>>> Of the solutions proposed so far, this is the one I like the most. Thanks, Roman.
>>>
>>> /a
>>>
>>> On 5/31/18 2:11 PM, Roman Shpount wrote:
>>>> Thomas,
>>>>
>>>> One slight correction:
>>>>
>>>> "Implementors MUST aggregate ICE candidates in case that unreliable transport protocol such as UDP is used. A Trickle ICE agent MUST NOT have more than one INFO request pending at any one time.
>>>> When INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in  RFC3261 section 17.1.2.1."
>>>>
>>>> Regards,
>>>>
>>>> _____________
>>>> Roman Shpount
>>>>
>>>> On Thu, May 31, 2018 at 3:06 PM, Thomas Stach <thomass.stach@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'd be also OK with Roman's Proposal and go ahead with the following text:
>>>>
>>>> "Implementors MUST aggregate ICE candidates in
>>>> case that UDP is used as transport protocol.
>>>> A Trickle ICE agent MUST NOT have
>>>> more than one INFO request pending at any one time.
>>>> When INFO messages are sent over an unreliable transport,
>>>> they are retransmitted according to the rules specified in
>>>> RFC3261 section 17.1.2.1."
>>>>
>>>> I hope that this text is also acceptable for the WG and  our ADs.
>>>> Thanks
>>>>
>>>> Thomas
>>>>
>>>>
>>>> On 2018-05-31 16:28, Flemming Andreasen wrote:
>>>>> Hi
>>>>>
>>>>> Did we reach a conclusion on this thread ? If not, what do we need to move it forward ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Flemming
>>>>>
>>>>> On 5/22/18 5:11 PM, Roman Shpount wrote:
>>>>>> On Tue, May 22, 2018 at 4:07 PM, Thomas Stach <thomass.stach@gmail.com> wrote:
>>>>>> E.g. something like:
>>>>>>
>>>>>> "Implementors MUST aggregate ICE candidates in
>>>>>> case that UDP is used as transport protocol.
>>>>>> It is RECOMMENDED that Trickle ICE implementations
>>>>>> implement a way to estimate the round-trip time (RTT)
>>>>>> and send only one INFO request per estimated RTT.
>>>>>> If the RTT is unknown, a Trickle ICE agent MUST NOT have
>>>>>> more than one INFO request pending at any one time.
>>>>>> In case of re-transmissions a Trickle-ICE agent needs to adhere to the default SIP
>>>>>> retransmission schedule resulting in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc."
>>>>>>
>>>>>>
>>>>>> I think it should be enough to require that a Trickle ICE agent MUST NOT have more than one INFO request pending at any one time. Requiring only one request in progress will also deal with remote proxy or client overload more gracefully. RTT is likely not a right measure here since INFO message can traverse multiple proxies and RTT would need to include transport delays between the proxies as well as proxy processing delay.
>>>>>>
>>>>>> Also, there is no need to specify how normal SIP re-transmission works, especially as it can be interpreted that you disallow modification of SIP timer values when trickle ICE is used or modify RFC 3261 in some way. I think it would be better simply state that when INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in rfc3261 section 17.1.2.1 (https://tools.ietf.org/html/rfc3261#section-17.1.2.1).
>>>>>>
>>>>>> Finally, is it allowed to cancel (stop transmitting) the current INFO request with ICE candidates and start a new INFO request with new candidate set if new candidate is discovered while INFO message is being transmitted? My assumption is that it is not allowed.
>>>>>>
>>>>>> Regards,
>>>>>> _____________
>>>>>> Roman Shpount
>>>>>>
>>>>>>
>>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic