[MMUSIC] Comments on draft-ietf-mmusic-trickle-ice-01

Rajmohan Banavi <rajmohanbanavi@gmail.com> Thu, 18 September 2014 06:33 UTC

Return-Path: <rajmohanbanavi@gmail.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 3E1A41A701F for <mmusic@ietfa.amsl.com>; Wed, 17 Sep 2014 23:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 xokaQgVRrtcW for <mmusic@ietfa.amsl.com>; Wed, 17 Sep 2014 23:33:27 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA701A701B for <mmusic@ietf.org>; Wed, 17 Sep 2014 23:33:25 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id c11so499426lbj.9 for <mmusic@ietf.org>; Wed, 17 Sep 2014 23:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rkt3SVwbtYvTiFy0TT2ZC94iCKGV9sDaFxq6FyF1xEg=; b=t3TgkHbFhLCaABjzyCPvgp1H2dKJlJcM49tOVJacT0O+z2tl4l3zBVIdlTTE2R3gFD 9h3xlXauql2fiCJDfmjEVVMnnAI010Ut537gwIzEsK8j7p/HXp1LxysFrZSi4SZDM77i l/b1hxMWnEb4xRikI0dkRCkhtgG+gd1RQHXOquTcrmOjQYEwl2hE46glCKC6Vue9LTNL Zub+b0hxUT834YimvAdPmnBwz7TrHpOaX6N70/EhzKBCPUdVulqv+DPZhsw2PoouOA6q j05IXH//VJlKcdIfrKFBj7/DF0QZFmbkMDAFBULA+iL/HDo62c1KQqJ2PQqGb4pvQ2dZ 5iKg==
MIME-Version: 1.0
X-Received: by 10.112.62.200 with SMTP id a8mr2073522lbs.34.1411022003599; Wed, 17 Sep 2014 23:33:23 -0700 (PDT)
Received: by 10.152.210.103 with HTTP; Wed, 17 Sep 2014 23:33:23 -0700 (PDT)
Date: Thu, 18 Sep 2014 12:03:23 +0530
Message-ID: <CAJWm+fGZtZDyQ1bDiSrvdnez7_hJh28d6r5nW+uORrnJu6018Q@mail.gmail.com>
From: Rajmohan Banavi <rajmohanbanavi@gmail.com>
To: mmusic@ietf.org
Content-Type: multipart/alternative; boundary=001a11c3c5a04b7d770503512978
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DxHkUlsE7lRwz45IljTGcwE9NDs
Cc: draft-ietf-mmusic-trickle-ice@tools.ietf.org
Subject: [MMUSIC] Comments on draft-ietf-mmusic-trickle-ice-01
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: <http://www.ietf.org/mail-archive/web/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: Thu, 18 Sep 2014 06:33:29 -0000

Comments on draft-ietf-mmusic-trickle-ice-01


   - "Sec 4 Determining Support for Trickle ICE" - "According to [RFC5245]
   every time an agent supporting trickle ICE generates an offer or an
   answer,".

Need to be reworded as RFC 5245 has no idea of trickle

"According to [RFC5245] every time an agent supporting an extension
generates an offer or answer, it must include an identification token in
the ice-options attribute. Accordingly, an agent supporting trickle ICE
must include the "trickle" token in the ice-options attribute."


   - Trivial typo in sec 1 Introduction.  "gathering, candidates" --->
    "gathering candidates".



   -  Sec 5 Paragraph 5: Fallback must be to Half Trickle rather than
   vanilla ICE

Prior to actually sending an initial offer, agents MAY verify if the
remote party supports trickle ICE, where such mechanisms actually

exist.  If absence of such support is confirmed agents MUST fall back

to using vanilla ICE or abandon the entire session.

If it is not possible to determine if the remote party support trickle ice,
then the agent must make use of Half Trickle mechanism described in sec
4.1.


   - Sec 8.1 "Check List and Timer State Updates" - there is something
   wrong here in this paragraph. Why would a vanilla ICE agent set the state
   of a check list to Failed if the pairs in the check list are in succeeded
   state (bullet 1)? Further, it says that "if the following two conditions
   are satisfied". Is it either one of the two conditions? Good idea to
   provide a reference to RFC 5245 (sec 7.1.3.3), since we are describing the
   operation of vanilla ICE.



   - Trivial type. Sec 9.3 - "Announcing End of Candidates". Duplication of
   sentence



   - During implementation, one of the issues that surfaced was regarding
   the check list timer. RFC 5245 Sec 5.8 "Scheduling Checks" mentions that if
   there is no such pair, "Terminate the timer for that check list". This is
   obviously not going to work with trickled ice candidates as the candidate
   pairs list will keep filling up incrementally. So for trickled ice, the
   conditions for stopping of the check list timer must be changed. Probably
   the checklist timer must not be stopped until the checklist moves to
   completed or Failed state.


Cheers,
Rajmohan