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

["Vijay K. Gurbani" <[e-mail]>]

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.

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.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/