Subject: [MMUSIC] Updated Comments/questions on draft-ietf-mmusic-ice-01

From: "Charlie Clemmer" <[email-masked]>
Date: Wed, 25 Feb 2004 14:18:54 -0600

Jonathan,

I hadn't seen any response to Mary's questions earlier in the month, but
since a new draft of ICE has been published, I thought I would compare
comments against the new draft to see if some of the original concerns were
resolved.

Echoing the concern that Mary raised in point number two, I am concerned
about the priorities assigned to the different transport address mechanisms.
For the most part, agree with the priorities cascading down from local IPv6
addresses being the highest priority, then cascading down to local IPv4,
etc; however, I'm concerned with the way VPN derived addresses in particular
are grouped in the lowest priority. Given the widespread usage of VPN
technology throughout the Enterprise segment, the potential exists where
voice traffic could take an unencrypted route rather than the available VPN
protected route that was anticipated to be used by the Enterprise admin.
Perhaps a solution to this dilemma would be to make the transport address
priorities something that can be configured by the user. If the priorities
need to be something static, I would argue that VPN should not be a low
priority transport.

I believe Mary's other points below are still valid against the new draft as
well.

Regards,
Charlie Clemmer 

-----Original Message-----
From: Barnes, Mary 
Sent: Thursday, February 05, 2004 10:10 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: [MMUSIC] Comments/questions on draft-ietf-mmusic-ice-00

Hi Jonathan,

Per my note on the SIPPING WG mailing list around your NAT scenarios draft
based on ICE, I also had a few comments on the ICE draft itself.  My primary
comments are around the prioritization of the transport addresses, with a
few minor nits also noted:

1) Page 12, section 5.3, Prioritizing the Transport Addresses.  It seems
that the effectiveness of ICE is highly dependent upon the choices of
qvalues in terms of getting the optimal path. However, the current
recommendations for the assigning priorities are fairly imprecise relative
to the overall importance of this aspect of the algorithm.  Based on the
point in the second paragraph of section 5.3,  it seems that rather than a
client having knowledge of topology, with ICE, the client is now configured
with these relative priorities reflected in the qvalues, which are an
indirect reflection of the network configuration.  So, it seems that it
might be useful to either be more prescriptive on what priorities would give
the most desireable results for particular configarations (eg per the
scenarios document) or to determine a formula or equation by which the
priorities SHOULD be defined, including factors such as the number of
intermediaries, etc.  At a minimum, some examples in this document would be
useful, perhaps just bringing in a snippet or 2 from the scenarios draft.  

2) Page 12, section 5.3,  Why is it that you would want the local addresses
obtained from VPN interfaces to be lowest priority?    It would seem that
there are some cases where you might want that to be a higher priority.

3) Page 17, section 5.7, 3rd sentence, "...it SHOULD just sent..." should be
"...it SHOULD just send...".

4) Page 18, section 5.8, OPEN ISSUE: "doesnt" should be "doesn't"

5) Page 34, Reference [4] RFC 3261, since the qvalue in the alt-attibute is
from RFC 3261, shouldn't this be a normative reference?  

Regards,
Mary H. Barnes
[email-masked]
972-684-5432

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 15:35:41 -0500

Firstly, I have to apologize that I have not responded to her comments 
yet; responses are pending, I'm just swamped.

Indeed, unfortunately the ICE revision has virtually no changes from the 
previous rev. I realized I would not be able to do anything substantive 
before IETF, so I put in a rev just to more or less refresh the expiry 
timer.

To answer this specific question, priority allocation is definitely a 
big question. Indeed, there are multiple criteria one might use to 
assign a priority. I have prioritized them based on usage of relays. In 
conversations I had with others, the comment was that ideally true 
latency through each path would determine priority; a route through a 
relay might actually yield lower latencies. You are basically proposing 
that security characteristics might be another way of defining priorities.

To a large degree, the viability of ICE is not strongly dependent on a 
standardized choice of priorities. ICE functions as long as there exists 
a default poitn of contact which always works; selection of alternates 
that do better can be based on differing policies. As such, I would be 
amenable to text which allowed for local determination of priorities, 
and included discussion of the various axes that might be used in 
defining such a policy.

Thanks,
Jonathan R.

Charlie Clemmer wrote:

> comments against the new draft to see if some of the original concerns 
> were resolved.
> 
> about the priorities assigned to the different transport address 
> mechanisms. For the most part, agree with the priorities cascading down 
> from local IPv6 addresses being the highest priority, then cascading 
> down to local IPv4, etc; however, I'm concerned with the way VPN derived 
> addresses in particular are grouped in the lowest priority. Given the 
> widespread usage of VPN technology throughout the Enterprise segment, 
> the potential exists where voice traffic could take an unencrypted route 
> rather than the available VPN protected route that was anticipated to be 
> used by the Enterprise admin. Perhaps a solution to this dilemma would 
> be to make the transport address priorities something that can be 
> configured by the user. If the priorities need to be something static, I 
> would argue that VPN should not be a low priority transport.
> 
> I believe Mary's other points below are still valid against the new 
> draft as well.
> 
> Regards,
> Charlie Clemmer
> 
> Per my note on the SIPPING WG mailing list around your NAT scenarios 
> draft based on ICE, I also had a few comments on the ICE draft itself.  
> My primary comments are around the prioritization of the transport 
> addresses, with a few minor nits also noted:
> 
> recommendations for the assigning priorities are fairly imprecise 
> relative to the overall importance of this aspect of the algorithm.  
> Based on the point in the second paragraph of section 5.3,  it seems 
> that rather than a client having knowledge of topology, with ICE, the 
> client is now configured with these relative priorities reflected in the 
> qvalues, which are an indirect reflection of the network configuration.  
> So, it seems that it might be useful to either be more prescriptive on 
> what priorities would give the most desireable results for particular 
> configarations (eg per the scenarios document) or to determine a formula 
> or equation by which the priorities SHOULD be defined, including factors 
> such as the number of intermediaries, etc.  At a minimum, some examples 
> in this document would be useful, perhaps just bringing in a snippet or 
> 2 from the scenarios draft. 
> 
> 3) Page 17, section 5.7, 3rd sentence, "...it SHOULD just sent..." 
> should be "...it SHOULD just send...".
> 
> 5) Page 34, Reference [4] RFC 3261, since the qvalue in the alt-attibute 
> is from RFC 3261, shouldn't this be a normative reference? 
> 
> Regards,
> Mary H. Barnes

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com