Subject: [MMUSIC] Re: Comments/questions on draft-ietf-mmusic-ice-00

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Mar 2004 16:36:38 -0500

sorry for the multi-week delay in responding, Mary. Answers inline.

Mary Barnes wrote:

> 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.  

I commented on this in response to Charlie Clemmer's note a week or so back.

> 
> 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.

If the critieria is "minimize relays", which it is as you point out 
above, VPNs introduce a relay.

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

Fixed.

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

Fixed.

> 
> 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?  

Yes. Fixed.

Thanks for your comments,
Jonathan R.

-- 
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

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

---

From: "Charlie Clemmer" <[email-masked]>
Date: Tue, 2 Mar 2004 18:18:08 -0600

Jonathan,

Following-up on your second response to Mary (relevant part of the response
quoted below), I think you hit the nail on the head regarding the discussion
point. It seems to me that ICE potentially brings alot of value as a
solution, and the implementation potentially seems to lend itself to the
flexibility to either minimize relays or to pick a preferred interface type
based on a given implementation.

I might have documented this in my last response, but my main concern comes
from the scenario where two teleworkers for a particular enterprise have a
VPN connection established to their employer, and then attempt to make a
VoIP call between each other (for instance). There is a certain level of
expectation, I feel, that in such a scenario, the enterprise would prefer to
have that voice session traverse the VPN cloud if for no other reason than
out of security concerns. If this VoIP session were SIP based, the
corporation might prefer that the entire SIP session stay on the VPN so that
any additional SIP interaction between the two users such as instant
messaging or collaboration activities can also be encrypted by the VPN.

If the argument is that VPN technology inherently adds relays, I would agree
with that view, but only in the context that because the VPN is providing a
tunnel between two endpoints, it makes it harder for ICE or any other client
side selection algorithm to correctly quantify the number of "relays"
encountered when going over a given VPN connection. Given one teleworker
connected back to an enterprise over a VPN communicating with another
corporate user inside the company's security perimeter, its possible that
there are no extra relays added to the route. However, the same argument
could be made for many IPv6 implementations which depend on implicit and
explicit tunneling mechanisms in order to provide a cohesive v6 environment
over a predominately v4 infrastructure.

I don't think any one view of "minimize relays" or "maximize security" is
going to be a home run for all implementations, but I do think it would be
useful to have some discussion on whether this implementation decision
should be something configurable by the end user, and is so, what the
possible best case default behavior should be for prioritizing transport
interfaces would be.

Regards,
Charlie Clemmer

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2004 3:37 PM
To: Barnes, Mary [NGC:B622:EXCH]
Cc: [email-masked]'
Subject: [MMUSIC] Re: Comments/questions on draft-ietf-mmusic-ice-00

Mary Barnes wrote:
[snip]