Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

From: Brandon Williams <[email-masked]>
Date: Mon, 09 Feb 2015 09:45:48 -0500

Sorry for the delayed feedback on this one. I've been having a little 
trouble thinking it through, mostly around the question of what type of 
guidance I think would be useful here. At this point, it's unclear to me 
whether the document should be giving any recommendations at all. But if 
not, then what purpose can it serve?

I agree with Justin that any recommendations presented in the document 
should be clear and straight-forward. If they aren't, then they will be 
difficult for an implementor to apply and end up being meaningless. That 
said, for a couple of reasons, I'm not certain that it's possible to put 
forward a strong and clear set of recommendations for server selection.

First, I think such recommendations could quickly go out-of-date as new 
mechanisms are defined to extend the procol. For example, if this 
document had been written a couple of years ago, it might not have made 
reference to return, mobility, or DTLS.

Second, I think the selection criteria could have different priorities 
for different users and/or applications, making the recommendations 
difficult to apply. For example, the goals of location privacy and 
performance could be in conflict, since a relay server more closely tied 
to the peer's network geographic location will often provide better 
performance. The same could be said for any capability not directly 
related to the relay function, since it any limitation on the candidate 
set for relay selection could result in added latency.

If it's not possible to give implementable recommendations that will 
have ongoing relevance, then what's the purpose of the document at all? 
One possibility is that it could be used to provide guidance for authors 
of other drafts, helping them to identify important areas of discussion 
relevant to new TURN mechanisms and their impact on server selection. 
This would also help reviewers to remember to ask important questions 
(e.g. "does this draft discuss the impact on location privacy?").

I've got some comment on the specifics of the draft too, but I'm not 
sure how relevant they are until I'm more confident about the intended 
purpose/goals of the draft.

--Brandon

On 01/09/2015 11:28 AM, Gonzalo Salgueiro (gsalguei) wrote:
> Thanks, Justin.  We'll collect Brandon's feedback on the draft too and the authors will deliberate on text edits and produce a new version for your review.
>
> -G
>
>
>> On Jan 8, 2015, at 5:34 PM, Justin Uberti <[email-masked]> wrote:
>>
>> At IETF 91, I promised to send feedback on this document, so here goes.
>>
>> Generally, I think many of the issues mentioned in this document are important, but the recommendations are confusing and possibly contradictory; a developer with little knowledge of TURN will have a hard time figuring out exactly what to do. Furthermore, many of the properties discussed in this document are dynamic, and should be handled by the ICE process, rather than in TURN server selection (for example, the notion of RTT as it relates to user experience).
>>
>> Therefore, I think this document should take a stronger stance and put forth explicit best practices for selection (as opposed to "things to consider"), for non-dynamic properties, and leave the decisions on dynamic properties to be resolved by ICE.
>>
>> For example, I think we should omit the text in Section 3 about what to do with non-working TURN servers, and measuring RTT. Same for Section 3.3, which also discusses RTT, and Section 3.4, which talks about multiple interfaces. This can all be handled by ICE.
>>
>> In addition, the sections on local config and location privacy are unnecessary when RETURN is used. When RETURN is used, the application can always use the app TURN server for location privacy, and the relationship between local TURN server and app TURN server is fully spelled out, so there is nothing for the application to decide on.
>>
>> This leaves only the Security, Authentication, and Mobility sections.
>>
>> For security, I think we can give some clear guidance on what applications should do. For security, I think the guidance should be to use only DTLS + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback may be contraindicated, but at this point in time, DTLS deployment isn't widespread enough to truly recommend this.
>>
>> This relates to the Authentication section - but I think any failures to authenticate the server cert should cause the TURN allocation to fail. This is just like any other misconfiguration on the TURN server - there's no reason we should even allow use of TURN servers whose cert chains don't validate. So, this section could probably be removed.
>>
>> Lastly, the Mobility section says that if "all other parameters [are] equal", a TURN server with mobility should be used. Clearly, all other parameters will not be equal (e.g. RTT), and even if they were, the client has no way to know if a server is mobility-capable a priori. So I think this recommendation ought to be removed, or perhaps turned into some sort of recommendation for TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), probably in a separate doc.
>>
>> These recommendations should reduce the size of this document and provide much clearer advice to app developers.
>> _______________________________________________
>> tram mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 18 Feb 2015 22:37:26 +0000

Hi Brandon,
Thanks for the review.

>reference to return, mobility, or DTLS.

As Justin suggests, we want the next revision to put forth explicit best
practices for server selection. For dynamic properties, leave the decision
to ICE.

>performance.

Yes, but for an application, one parameter is always more significant that
another parameter. For the case above, an application chooses location
privacy if that¹s of utmost importance.

-Prashanth

> The same could be said for any capability not directly
>> Thanks, Justin.  We'll collect Brandon's feedback on the draft too and
>>the authors will deliberate on text edits and produce a new version for
>>your review.
>>
>> -G
>>
>>
>>> Generally, I think many of the issues mentioned in this document are
>>>important, but the recommendations are confusing and possibly
>>>contradictory; a developer with little knowledge of TURN will have a
>>>hard time figuring out exactly what to do. Furthermore, many of the
>>>properties discussed in this document are dynamic, and should be
>>>handled by the ICE process, rather than in TURN server selection (for
>>>example, the notion of RTT as it relates to user experience).
>>>
>>> Therefore, I think this document should take a stronger stance and put
>>>forth explicit best practices for selection (as opposed to "things to
>>>consider"), for non-dynamic properties, and leave the decisions on
>>>dynamic properties to be resolved by ICE.
>>>
>>> For example, I think we should omit the text in Section 3 about what
>>>to do with non-working TURN servers, and measuring RTT. Same for
>>>Section 3.3, which also discusses RTT, and Section 3.4, which talks
>>>about multiple interfaces. This can all be handled by ICE.
>>>
>>> In addition, the sections on local config and location privacy are
>>>unnecessary when RETURN is used. When RETURN is used, the application
>>>can always use the app TURN server for location privacy, and the
>>>relationship between local TURN server and app TURN server is fully
>>>spelled out, so there is nothing for the application to decide on.
>>>
>>> For security, I think we can give some clear guidance on what
>>>applications should do. For security, I think the guidance should be to
>>>use only DTLS + TLS, if both are available, with fallback to UDP or TCP
>>>if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP
>>>fallback may be contraindicated, but at this point in time, DTLS
>>>deployment isn't widespread enough to truly recommend this.
>>>
>>> This relates to the Authentication section - but I think any failures
>>>to authenticate the server cert should cause the TURN allocation to
>>>fail. This is just like any other misconfiguration on the TURN server -
>>>there's no reason we should even allow use of TURN servers whose cert
>>>chains don't validate. So, this section could probably be removed.
>>>
>>> Lastly, the Mobility section says that if "all other parameters [are]
>>>equal", a TURN server with mobility should be used. Clearly, all other
>>>parameters will not be equal (e.g. RTT), and even if they were, the
>>>client has no way to know if a server is mobility-capable a priori. So
>>>I think this recommendation ought to be removed, or perhaps turned into
>>>some sort of recommendation for TURN server developers (e.g. TURN
>>>servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD
>>>support redirect), probably in a separate doc.
>>>
>>> These recommendations should reduce the size of this document and
>>>provide much clearer advice to app developers.

---

From: Brandon Williams <[email-masked]>
Date: Thu, 19 Feb 2015 10:02:16 -0500

Hi Prashanth,

I'm not certain that your responses actually address my comments. On the
one hand, you appear to agree that user priorities have a significant
impact on server selection, and you haven't responded at all to my point
about how quickly recommendations will go out of date as new mechanisms
are developed. I can certainly wait for the next draft to see what you
have in mind, but I don't clearly see what BCPs you could document that
will actually be useful to an implementer over the long term.

--Brandon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 19 Feb 2015 19:36:54 +0000

Hi Brandon,

On 2/19/15, 7:02 AM, "Brandon Williams" <[email-masked]>
wrote:

>impact on server selection,

Yes, and it’s one of the reasons we can only offer best practices and not
priorities. The final choice is always made by an application, weighing in
with its priorities.

Also, best practices are with what we know today. You’re right, there
could be new parameters that emerge in the future which we cannot account
for, in any current document. Some recommendations may be broad enough to
accommodate new parameters, but not all.

All of this may translate to implementable recommendations, or (as you
point out) may end up looking like BCP for new TURN mechanisms and their
impact on server selection.

-Prashanth

> and you haven't responded at all to my point
>are developed. 
> I can certainly wait for the next draft to see what you