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

From: Brandon Williams <[email-masked]>
Date: Tue, 02 Sep 2014 15:13:50 -0400

See inline.

On 08/31/2014 12:20 AM, Tirumaleswar Reddy (tireddy) wrote:
> 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.
>>
>> 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.
>
> 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

Section 9.3 of the edns I.D. refers to limits that could be imposed by 
an authoritative nameserver to protect against problems that can result 
when false information is provided in the edns-client-subnet option. 
Requiring a trust relationship is one method used to mitigate the risks 
associated with bad use of the option.

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

End-user identification is not required.

> 3)If Google/OpenDNS public DNS servers already support edns-client-subnet then what is the problem ?
>

Not everyone uses Google/OpenDNS :-)  Many corporate environments 
require their users to use corporate nameservers, and these are often 
centrally located.

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

I'm not sure how this question relates to the DNS problem. Also, I don't 
think the question is easy to answer. There are cases where use of the 
3rd party relay could be optional, but there are also cases where its 
use is mandated by either the enterprise or the app vendor.

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

I'll try to look into that. I'm not sure if I'll be able to do it, 
though, because the numbers come from a customer, not from us. The 
delays have to do with how the connectivity information is exchanged -- 
out-of-band via a centralized address registry.

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

Yes. Something like that.

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

I'm quite confident that there's a problem, but I'm not sure that it's 
a problem that's broadly applicable.

--Brandon

> 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

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Sep 2014 10:50:14 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2014 12:44 AM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [tram] DNS-based relay selection, ALTERNATE-SERVER, and
> CHECK-ALTERNATE
> 
> See inline.
> 
> >> 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.
> >>
> >> 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.
> >
> > Few questions
> > I don't see any such discussion in
> > http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01#sec
> > tion-9
> 
> Section 9.3 of the edns I.D. refers to limits that could be imposed by an
> authoritative nameserver to protect against problems that can result when
> false information is provided in the edns-client-subnet option.

Okay.

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

Got it. It's not a problem in an Enterprise network that uses split tunneling and split DNS. 

> >> 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.
> >
> > 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.
> I'm not sure how this question relates to the DNS problem. Also, I don't think
> the question is easy to answer. There are cases where use of the 3rd party
> relay could be optional, but there are also cases where its use is mandated
> by either the enterprise or the app vendor.

Ok.

> a problem that's broadly applicable.

Agreed that it's a problem.

-Tiru