Subject: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE

From: Brandon Williams <[email-masked]>
Date: Fri, 29 Aug 2014 14:49:54 -0400

Hi all,

In working through some relay server selection issues with a customer, 
we began discussing some corner cases related to server redirection via 
the TRY-ALTERNATE error response for allocate requests. We also 
discussed the impact on call setup time. I'd like to get some feedback 
from the list on the issue.

Here's the basic problem. For a 3rd party TURN service that uses DNS to 
select from among multiple candidate relay servers, the location of the 
requester will often be determined using the source IP address of the 
DNS request. This will typically be the client's configured DNS server, 
not the client itself. Some public DNS servers support end-user 
identification in the DNS request, but it's not common and it requires a 
trust relationship between the client's DNS server and the relay 
provider's DNS server. There are two problems (at least) with this approach:

   1. The DNS server is not geolocated with the client, so a bad relay
      is returned.

   2. The DNS server is shared by multiple clients, making it more
      difficult to load balance the clients across multiple relays.

Each of these can be resolved by sending a TRY-ALTERNATE error to the 
client on the allocate request, but this also has some issues, mostly 
relating to call setup time.

Even one redirection can noticeably extend call setup delays. If the 
initial relay server selection is horrible (e.g. because the DNS server 
is located very far away from the client), this is worth the tradeoff, 
but in cases where the initial selection is suboptimal but still 
reasonable, it may be preferable to continue call setup using the 
initial relay server selection while waiting for the new relay 
allocation. If there is some bad luck and the client receives multiple 
TRY-ALTERNATE error responses, the negative impact on call setup could 
be quite substantial.

So, similar to the case described in the peer-specific redirection I.D., 
in some cases, it may be useful for the client to indicate to the server 
whether it would like performance-based redirection and also what type 
of response (success or error) it would like to receive in that case. 
What I am discussing with this customer is the idea of using the 
CHECK-ALTERNATE attribute defined in the peer-specific redirection draft 
for allocate requests. The value for the attribute would be one of: 
noredirect, senderror, or sendsuccess. This would allow the client to 
optimize call setup and also to mitigate the risk of redirection loops.

Is anyone else interested in this idea? I.e. would it be worthwhile for 
me to write up a short I.D.? Does anyone have ideas for a better way to 
handle the same problem that I should consider instead?

Thanks,
--Brandon

PS: I know that at least the geolocation problem could be mostly 
resolved using anycast addresses. Experience suggests that anycast 
addresses are unsuitable for broad deployments with lots of POPs, 
frequently preventing deployments in some areas due to management 
burden. They usually require the use of fallback to unicast, and so 
become an optimization, not a full solution.

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 31 Aug 2014 04:20:57 +0000

Hi Brandon,

Please see inline 

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Saturday, August 30, 2014 12:20 AM
> To: [email-masked]
> Subject: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-
> ALTERNATE
> 
> Hi all,
> 
> In working through some relay server selection issues with a customer, we
> began discussing some corner cases related to server redirection via the TRY-
> ALTERNATE error response for allocate requests. We also discussed the
> impact on call setup time. I'd like to get some feedback from the list on the
> issue.
> 
> requester will often be determined using the source IP address of the DNS
> request. This will typically be the client's configured DNS server, not the client
> itself. Some public DNS servers support end-user identification in the DNS
> request, but it's not common and it requires a trust relationship between the
> client's DNS server and the relay provider's DNS server. 

Few questions
1) Is trust relationship mandatory ? 
I don't see any such discussion in http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01#section-9
2) Is end-user identification required or just detecting user's geolocation sufficient ? 
The reason for the question is in CDN, identifying user's geolocation is sufficient for DNS based redirection (http://tools.ietf.org/html/rfc7336#section-2.1.1)
3)If Google/OpenDNS public DNS servers already support edns-client-subnet then what is the problem ?

> There are two
> problems (at least) with this approach:
> 
> Each of these can be resolved by sending a TRY-ALTERNATE error to the client
> on the allocate request, but this also has some issues, mostly relating to call
> setup time.

Is it mandatory for the endpoints in the Enterprise network to use the 3rd party TURN service ?
I mean if firewall is configured to permit media sessions to any external peer only through the 3rd party TURN service, it may help if client only advertises relayed candidates. 
This way ICE can be concluded faster.

> 
> Even one redirection can noticeably extend call setup delays. 

It will be useful if you can share the numbers on the call setup delay noticed.

> If the initial
> relay server selection is horrible (e.g. because the DNS server is located very
> far away from the client), this is worth the tradeoff, but in cases where the
> initial selection is suboptimal but still reasonable, it may be preferable to
> continue call setup using the initial relay server selection while waiting for the
> new relay allocation. 

So the idea is that the client will trigger ICE restart later using the new relay allocation.

> If there is some bad luck and the client receives multiple
> TRY-ALTERNATE error responses, the negative impact on call setup could be
> quite substantial.
> 
> So, similar to the case described in the peer-specific redirection I.D., in some
> cases, it may be useful for the client to indicate to the server whether it
> would like performance-based redirection and also what type of response
> (success or error) it would like to receive in that case.
> What I am discussing with this customer is the idea of using the CHECK-
> ALTERNATE attribute defined in the peer-specific redirection draft for
> allocate requests. The value for the attribute would be one of:
> noredirect, senderror, or sendsuccess. This would allow the client to optimize
> call setup and also to mitigate the risk of redirection loops.
> 
> Is anyone else interested in this idea? 

Yes, once you convince that there is a problem :)

Cheers,
-Tiru

> I.e. would it be worthwhile for me to
> write up a short I.D.? Does anyone have ideas for a better way to handle the
> same problem that I should consider instead?
> 
> Thanks,
> --Brandon
> 
> PS: I know that at least the geolocation problem could be mostly resolved
> using anycast addresses. Experience suggests that anycast addresses are
> unsuitable for broad deployments with lots of POPs, frequently preventing
> deployments in some areas due to management burden. They usually
> require the use of fallback to unicast, and so become an optimization, not a
> full solution.
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram