Re: [Tsv-art] TSV-ART Last Call review for draft-ietf-mmusic-trickle-ice-sip
Joerg Ott <ott@in.tum.de> Fri, 02 February 2018 10:24 UTC
Return-Path: <ott@in.tum.de>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0C12711E; Fri, 2 Feb 2018 02:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 rlwAg57f7-BO; Fri, 2 Feb 2018 02:24:06 -0800 (PST)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F3B12EC06; Fri, 2 Feb 2018 02:24:00 -0800 (PST)
Received: by mail.in.tum.de (Postfix, from userid 107) id 8ADEA1C2A44; Fri, 2 Feb 2018 11:23:58 +0100 (CET)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id B8D471C2A25; Fri, 2 Feb 2018 11:23:56 +0100 (CET) (Extended-Queue-bit tech_okjwo@fff.in.tum.de)
To: Thomas Stach <thomass.stach@gmail.com>, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, tsv-art@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
References: <a68e66dc-8822-06d8-79a0-aa1bc7f9fdbf@in.tum.de> <c325d057-ada3-e34c-7cab-7a04ccb4e734@gmail.com>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <3288af0e-3123-5efe-e7dd-0bbca1991af1@in.tum.de>
Date: Fri, 02 Feb 2018 11:23:59 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <c325d057-ada3-e34c-7cab-7a04ccb4e734@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/dDHnJ65V8LAklmSJbsQi0UDyRlU>
Subject: Re: [Tsv-art] TSV-ART Last Call review for draft-ietf-mmusic-trickle-ice-sip
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Feb 2018 10:24:08 -0000
Hi Thomas, thanks much -- this course of action sounds good to me. Cheers, Jörg On 01.02.18 23:47, Thomas Stach wrote: > Joerg, > > first of all apologies for the delay in responding to your review. > > Thanks for your effort. > > Responses inline > > > On 2018-01-26 12:09, Joerg Ott wrote: >> Hi, >> >> Reviewer: Jörg Ott >> Review result: Largely ready with Issues >> >> I've reviewed this document as part of TSV-ART's ongoing effort to >> review key IETF documents. These comments were written primarily for the >> transport area directors, but are copied to the document's authors for >> their information and to allow them to address any issues raised. When >> done at the time of IETF Last Call, the authors should consider this >> review together with any other last-call comments they receive. Please >> always CC tsv-art@ietf.org if you reply to or forward this review. >> >> The draft defines a how the Session Initiation Protocol (SIP) shall >> make use the incremental discovery and exchange of IP addresses as >> provided by tricke ICE; the main purpose is reducing call setup latency. >> >> The draft defines address the SIP aspects comprehensively with all >> necessary features. From a transport perspective relevant is primarily >> its use the SIP INFO method for carrying updates to the collected >> addresses to notify the respective peer that further ones can now >> be tried and inform when when the address gathering is complete. >> >> Before proceeding, I note that SIP as defined in RFC 3261 and >> referenced in the draft can use UDP as a transport (which I thought >> was deprecated at some point, but couldn't find evidence to this >> end). >> >> This means that SIP message generation may lead straight to packet >> generation on the network and thus uncontrolled generation of SIP >> INFO frames will lead to uncontrolled, potentially bursty, network >> traffic. >> >> As far as I recall, this has always been an issue with SIP INFO >> for which no pacing or congestion control was defined (this is >> in contrast to SUBCRIBE/NOTIFY, for which packages need to specify >> how to rate control notifications). >> >> The document authors are aware of this but provide, IMHO, insufficient >> guidance when they write in section 10.9: >> >> 10.9. Rate of INFO Requests >> >> A Trickle ICE Agent with many network interfaces might create a high >> rate of INFO requests if every newly detected candidate is trickled >> individually without aggregation. Implementors that are concerned >> about loss of packets in such a case might consider aggregating ICE >> candidates and sending INFOs only at some configurable intervals. >> >> Given that IP addresses may be gathered rapidly and poor implementations >> may send them one by one, implementers MUST be concerned with this and >> MUST rate limit the transmission of INFO messages. There are examples >> in other SIP specs (see SUB/NOT, for example) that provide clearer >> guidance from the authors may borrow. I acknowledge that SIP INFO >> messages are strictly unidirectional and hence one cannot map them >> naturally to determine when one was received. So the simplest way may >> be a careful pacing. But the group has probably thought more about >> this. > Ok, we will come up with stricter text and e.g. change to MUST. > With respect to pacing we would stick to our recommendation to send > INFOs only at some configurable intervals without specifying a concrete > value, > since an appropriate value would differ dependent on the specific network. >> >> If SIP runs on top of TCP, which is probably the standard way, this is >> not an issue for the network anymore, but it may remain one for SIP >> proxies and other intermediaries forwarding the SIP INFO messages. >> Also, an endpoint may not be able to tell that it has congestion >> controlled transport all the way. >> Minor notes: >> >> I found two cases, where the correct standards keywords (MUST) may >> be missing: >> >> Section 4.1.3, first paragraph on page 10 reads: >> >> If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or >> exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will >> include the "a=rtcp-mux" attribute in the initial Answer. >> >> will -> MUST? > We removed normative language at various places where we referred to > other specs based on the review of our AD Ben Campbell. > So, I will stick to "will" >> >> Section 4.4, bottom of page 19: >> >> When receiving INFO requests carrying any candidates, agents will >> therefore first identify and discard the attribute lines containing >> candidates they have already received in previous INFO requests or in >> the Offer/Answer exchange preceding them. Two candidates are >> >> Will -> ??? > needs to be a MUST. > > Thanks again for your review. > >> >> >> Best, >> Jörg >> >