Subject: Re: [BEHAVE] TURN: Drop ALTERNATE-SERVER?

From: Philip Matthews <[email-masked]>
Date: Tue, 11 Mar 2008 15:23:29 -0400

Just a heads up that I plan to discuss the question of what we should  
do about ALTERNATE-SERVER in the TURN presentation slot at the BEHAVE  
meeting, and I am planning to recommend that we remove the ALTERNATE- 
SERVER attribute from both STUN and TURN for now.

My reasons are:
* There seems to be tentative consensus that the SRV mechanism is a  
better solution (than ALTERNATE-SERVER) for load balancing.
* Though I understand the use of this to redirect to a closer TURN  
server, I think there are other ways to achieve this that do not  
require ALTERNATE-SERVER.
* A number of people have suggested that it would be better if  
ALTERNATE-SERVER contained a domain name rather than an IP address  
and port. I agree.
So rather than to try to get consensus around the use-case, the  
proper solution to the use case, and the proper semantics of  
ALTERNATE-SERVER, I am proposing to remove it for now. This can be  
added as a future enhancement if and when necessary.

So come prepared to discuss this at BEHAVE!

- Philip

On Thu, 21-Feb-08, at 18:58 , Marc Petit-Huguenin wrote:

> Philip Matthews wrote:
>> Cullen and EKR are both suggesting that we drop the ALTERNATE-SERVER
>> mechanism from TURN. They think the mechanism adds complexity for no
>> real value. They suggest that the SRV mechanism, combined with an
>> admonition for the client to not immediately retry when an Allocate
>> transaction fails due to capacity problems, is sufficient to handle
>> load balancing
>>
>> I have recently rewritten the text on ALTERNATE-SERVER for the
>> forthcoming TURN-07. The text is simpler, but I tend to agree that it
>> does not add a lot of value.
>>
>> Could anyone who wants it speak up and explain what they want it for?
>
> The problem here is that using SRV RR is not a replacement for all the
> usages of ALTERNATE-SERVER.  I would agree 100% to remove
> ALTERNATE-SERVER if its only usage was for load balancing, but  
> there is
> other usages.  In fact I suggested multiple times that it would be  
> more
> useful to return a domain name instead of an IP address, but even with
> only one IP address returned it is still possible to do something  
> useful.
>
> I have two examples of usages:
>
> First example is for the clients that does not implement SRV RR.  In
> this case, the client contacts the TURN server at the IP address (A or
> AAAA) of the domain and the default port for TURN (let's say 3479).
> Running at this IP address/port is a simple server that queries the  
> DNS
> for the SRV RR of the domain, runs the RFC 2782 algorithm and  
> returns an
> IP address in the ALTERNATE-SERVER attribute.  Failover and priority
> will not work, but at least the requests will be balanced between the
> servers according to the weight in the SRV RR.  The client will not  
> work
> better but it has less chance to overload the servers.
>
> Second example is to redirect a client to a "closer" TURN server.  I
> explained how this could work with a domain name returned instead  
> of an
> IP address in this email:
>
> http://www.ietf.org/mail-archive/web/behave/current/msg02716.html
>
> Even without the domain name, it is possible to redirect to a closer
> server, which is better than nothing.  Note that anycast does not work
> for this example, as explained in rfc3489bis, section 7.2.
>
> So as a conclusion, I would like to keep ALTERNATE-SERVER if there is
> not a better mechanism to redirect for *other* reasons than
> load-balancing.  If ALTERNATE-SERVER is kept in its current form, I
> would suggest to add some text that strongly advise against using  
> it for
> load balancing.
>
> Thanks.
>
> -- 
> Marc Petit-Huguenin           [                                 ]
> Home: [email-masked] [RFC1855-compliant space for rent ]
> Work: [email-masked]            [                                 ]
> [                                                               ]
> _______________________________________________
> Behave mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/behave
>

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 11 Mar 2008 14:54:25 -0700

Philip Matthews wrote:
> Just a heads up that I plan to discuss the question of what we should do
> about ALTERNATE-SERVER in the TURN presentation slot at the BEHAVE
> meeting, and I am planning to recommend that we remove the
> ALTERNATE-SERVER attribute from both STUN and TURN for now.
> 
> My reasons are:
> server, I think there are other ways to achieve this that do not require
> ALTERNATE-SERVER.

You misunderstood what I said.  I never suggested that ALTERNATE-SERVER
should be kept because of this *example*.  I am just saying that there
is *other* usages to ALTERNATE-SERVER than just load balancing, and the
fact that there is alternative ways to implement my *example* does not
invalidate this.

> ALTERNATE-SERVER contained a domain name rather than an IP address and
> port. I agree.
> So rather than to try to get consensus around the use-case, the proper
> solution to the use case, and the proper semantics of ALTERNATE-SERVER,
> I am proposing to remove it for now. This can be added as a future
> enhancement if and when necessary.
> 
>> ALTERNATE-SERVER if its only usage was for load balancing, but there is
>> other usages.  In fact I suggested multiple times that it would be more
>> only one IP address returned it is still possible to do something useful.
>>
>> Running at this IP address/port is a simple server that queries the DNS
>> for the SRV RR of the domain, runs the RFC 2782 algorithm and returns an
>> servers according to the weight in the SRV RR.  The client will not work
>> explained how this could work with a domain name returned instead of an
>> would suggest to add some text that strongly advise against using it for
>> load balancing.
>>
>> Thanks.
>>

---

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Mar 2008 10:25:38 -0400

Does this mean that you are ok if we remove it?

- Philip

On Tue, 11-Mar-08, at 17:54 , Marc Petit-Huguenin wrote:

>> require
>> and
>> proper

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Mar 2008 07:34:39 -0700

> Does this mean that you are ok if we remove it?

No, I said exactly the opposite.  We should keep it because there is
other usages to ALTERNATE-SERVER than load balancing.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Mar 2008 10:46:00 -0400

OK. Then come prepared to argue for keeping it at the BEHAVE meeting  
tomorrow.

- Philip

On Wed, 12-Mar-08, at 10:34 , Marc Petit-Huguenin wrote:

>>>>> would suggest to add some text that strongly advise against  
>>>>> using it
>>>>> for
>>>>> load balancing.
>>>>>
>>>>> Thanks.
>>>>>
>
>
> -- 
> Marc Petit-Huguenin           [                                 ]

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Mar 2008 07:58:47 -0700

> OK. Then come prepared to argue for keeping it at the BEHAVE meeting

I am not attending this IETF meeting, but I'll be listening to the audio
stream.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Mar 2008 11:09:16 -0400

I know you have done some of this before, but can I ask you to  
prepare an e-mail summarizing your arguments for why we should keep  
ALTERNATE-SERVER, and briefly describe the semantics you think it  
should have, and then send it to me and the list. I will then try to  
present your position at the meeting.

My position will likely be: Let's not cover this in the base  
specification, but advance it as a TURN extension. So you should  
argue why you think it needs to be in the base specification.

- Philip

On Wed, 12-Mar-08, at 10:58 , Marc Petit-Huguenin wrote:

>>>>>>>> Could anyone who wants it speak up and explain what they  
>>>>>>>> want it
>>>>>>>> for?
>>>>>>>
>>>>>>> The problem here is that using SRV RR is not a replacement  
>>>>>>> for all
>>>>>>> the
>>>>>>> useful to return a domain name instead of an IP address, but  
>>>>>>> even
>>>>>>> with
>>>>>>> server, which is better than nothing.  Note that anycast does  
>>>>>>> not
>>>>>>> work

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Mar 2008 16:46:47 -0700

Philip Matthews wrote:
> I know you have done some of this before, but can I ask you to prepare
> an e-mail summarizing your arguments for why we should keep
> ALTERNATE-SERVER, and briefly describe the semantics you think it should
> have, and then send it to me and the list. I will then try to present
> your position at the meeting.
> 
> specification, but advance it as a TURN extension. So you should argue
> why you think it needs to be in the base specification.
> 

OK, I tried to keep it short:

1.  TURN supports the ALTERNATE-SERVER mechanism as defined in
rfc3489bis section 11 (i.e. ALTERNATE-SERVER on a 300 response).
2.  TURN does not support the ALTERNATE-SERVER on other responses than 300.

For load-balancing (or more generally resource-balancing) purposes, RFC
2782 is better than using redirection, so ALTERNATE-SERVER should not be
used for any 4xx response.  There should be some text saying that even
if 300 can be used for load balancing, it is not recommended to do so.

The reason for TURN to support 300 with ALTERNATE-SERVER is to permit to
dynamically (opposed to statically as it is done with the SRV RR)
redirect the client to another server in the same administrative domain.
  I will not repeat my previous examples because people seem to be
distracted by the examples instead of seeing the need for a general
mechanism for redirection - HTTP and SIP both have a redirection
mechanism, and nobody seems to think that it is useless.

Because some usages of redirection mandate that the client follows the
redirection, it needs to be specified in the base document, and not as
an extension.

This proposal can be improved by returning a domain name (like SIP and
HTTP) instead of an IP address, but this part can be done in an extension.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 12:53:56 -0700

Reading the minutes from meeting, it looks like we decided to keep  
ALTERNATIVE-SERVER in but rework it a bit. The use case that I found  
most convincing was Jonathan anycast use case so I hope this can can  
be explicitly mentioned when the draft gets updated so we don't forget  
about it.

Cullen <with my individual contributor hat on>