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

Ari Keränen <> Thu, 03 November 2011 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5DC111E80D5 for <>; Thu, 3 Nov 2011 04:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9GMzB-sull95 for <>; Thu, 3 Nov 2011 04:02:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E72E11E80A6 for <>; Thu, 3 Nov 2011 04:02:04 -0700 (PDT)
X-AuditID: c1b4fb39-b7cb2ae000001bd8-34-4eb274acc9a9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BA.A5.07128.CA472BE4; Thu, 3 Nov 2011 12:02:04 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 3 Nov 2011 12:02:03 +0100
Received: from As-MacBook-Air.local ( []) by (Postfix) with ESMTP id 103EC22ED; Thu, 3 Nov 2011 13:02:02 +0200 (EET)
Message-ID: <>
Date: Thu, 03 Nov 2011 12:02:12 +0100
From: Ari Keränen <>
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" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, General Area Review Team <>, Gonzalo Camarillo <>, "" <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mmusic-ice-tcp-15
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.