[Tsv-art] TSV-ART Last Call review for draft-ietf-mmusic-trickle-ice-sip
Joerg Ott <ott@in.tum.de> Fri, 26 January 2018 11:09 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 5ABF712D960; Fri, 26 Jan 2018 03:09:09 -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 QObDHtrkqFMi; Fri, 26 Jan 2018 03:09:07 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DEA12D779; Fri, 26 Jan 2018 03:09:03 -0800 (PST)
Received: by mail.in.tum.de (Postfix, from userid 107) id 3C6BE1C2A44; Fri, 26 Jan 2018 12:09:01 +0100 (CET)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id D381F1C2A3D; Fri, 26 Jan 2018 12:08:55 +0100 (CET) (Extended-Queue-bit tech_lpwgd@fff.in.tum.de)
To: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, tsv-art@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <a68e66dc-8822-06d8-79a0-aa1bc7f9fdbf@in.tum.de>
Date: Fri, 26 Jan 2018 19:09:18 +0800
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
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/rUrheaRgbBIZXJF8RvuQbpZHj2w>
Subject: [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, 26 Jan 2018 11:09:09 -0000
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. 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? 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 -> ??? Best, Jörg