Re: [Gen-art] Gen-ART review of draft-ietf-mmusic-ice-tcp-15

Ari Keränen <ari.keranen@ericsson.com> Thu, 03 November 2011 11:02 UTC

Return-Path: <ari.keranen@ericsson.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DC111E80D5 for <gen-art@ietfa.amsl.com>; Thu, 3 Nov 2011 04:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GMzB-sull95 for <gen-art@ietfa.amsl.com>; Thu, 3 Nov 2011 04:02:05 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72E11E80A6 for <gen-art@ietf.org>; Thu, 3 Nov 2011 04:02:04 -0700 (PDT)
X-AuditID: c1b4fb39-b7cb2ae000001bd8-34-4eb274acc9a9
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BA.A5.07128.CA472BE4; Thu, 3 Nov 2011 12:02:04 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 3 Nov 2011 12:02:03 +0100
Received: from As-MacBook-Air.local (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 103EC22ED; Thu, 3 Nov 2011 13:02:02 +0200 (EET)
Message-ID: <4EB274B4.80709@ericsson.com>
Date: Thu, 03 Nov 2011 12:02:12 +0100
From: Ari Keränen <ari.keranen@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
References: <4EAF17BC.6020409@bell-labs.com> <4EAF2AF5.9010003@ericsson.com> <4EB00227.8060307@bell-labs.com>
In-Reply-To: <4EB00227.8060307@bell-labs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "fandreas@cisco.com" <fandreas@cisco.com>, General Area Review Team <gen-art@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "draft-ietf-mmusic-ice-tcp@tools.ietf.org" <draft-ietf-mmusic-ice-tcp@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mmusic-ice-tcp-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2011 11:02:06 -0000

On 11/1/11 3:28 PM, Vijay K. Gurbani wrote:
> On 10/31/2011 06:10 PM, Ari Keränen wrote:
>>> - S1: The draft says, "This specification does so by following the
>>> outline of ICE itself, and calling out the additions and changes
>>> necessary in each section of ICE to support TCP candidates."
>>>
>>> Does this imply that this specification normatively updates
>>> rfc5425 (the ICE RFC)? If so, this is not reflected in the
>>> masthead for the document as "Updates: RFC 5425".
>>
>> Actually no. These additions are specific to TCP so the (UDP) ICE RFC is
>> not updated. In an effort to keep this draft reasonably compact, only
>> the delta from the RFC5245 is defined. So, when something is not defined
>> here, the behavior defined in RFC5245 is assumed.
>
> Ari: Thanks for the clarification.  In that case, I would think that
> inserting some text to the document fashioned along what you write
> above will help those folks who would read your document and assume
> normative changes to rfc5425.
>
> A small change such as this will suffice (please feel free to edit):
>
> OLD:
>     This specification does so by following the outline of ICE itself,
>     and calling out the additions and changes necessary in each section
>     of ICE to support TCP candidates.
>
> NEW:
>     This specification does so by following the outline of ICE itself,
>     and calling out the additions and changes necessary to support TCP
>     candidates in ICE.  The base behaviour of ICE [RFC5245] remains
>     unchanged except for the extensions in this document that define the
>     usage of ICE with TCP candidates.

Makes sense, we'll use that.

> One more comments; please see below.
>
>>> - S4.1, last paragraph. It says that, "TCP-based STUN transactions
>>> are paced out at one every Ta seconds." However, rfc5245 Section
>>> 16 says that, "These transactions are paced at a rate of one
>>> every Ta millisecond, ..."
>>>
>>> I suspect that in your draft, Ta refers to the same Ta as in
>>> rfc5245, so it seems to me that they should be paced one every
>>> Ta milliseconds to conform to rfc5245, no?
>>
>> This one is a bit tricky since even RFC5245 is not consistent with this
>> (e.g., section 5.8. of RFC5245 says "Ta seconds later", and section
>> 16.1. is even more vague). We chose to use "seconds" so that the
>> formulas in 16.1. of 5245 would have right units, but actually in the
>> text 5245 does use "milliseconds" more often. I'm fine either way but
>> since you found this confusing, probably the milliseconds is a better
>> choice.
>
> I believe that ms is what is intended (but the author of rfc5245 can
> always be asked for a clarification).  Here's my reasoning:
>
> The formulas of Section 16.1 are stated in terms of ms; i.e.,
> Ta = MAX(20ms, 1/sum_{i=1}^k (1/Ta_i)).  To get an authoritative answer
> from the MAX() function would require both parameters to be the
> same units.  That is, MAX(20, 3) is rather ambiguous if the first
> parameter is in terms of ms and the second in terms of second.
> On the other hand, MAX(20, 3000) is straightforward to evaluate
> since both parameters are in terms of ms.

Yeah, probably it's more clear to use ms. We'll go with that.


Thanks,
Ari