Subject: [BEHAVE] TURN: ALTERNATE-SERVER

From: Philip Matthews <[email-masked]>
Date: Wed, 13 Feb 2008 20:23:05 -0500

TURN-06 contains the following text that describes how a TURN server  
can redirect a client to an alternate TURN server:

    When a server returns an error response, it MAY include an  
ALTERNATE-
    SERVER attribute if it has positive knowledge that the problem
    reported in the error response will not be a problem on the  
alternate
    server.  For example, a 443 response (Invalid IP Address) with an
    ALTERNATE-SERVER means that the other server is responsible for that
    IP address.  A 442 (Unsupported Transport Protocol) with this
    attribute means that the other server is known to support that
    transport protocol.  A 507 (Insufficient Capacity) means that the
    other server is known to have sufficient capacity.  Using the
    ALTERNATE-SERVER mechanism in the 507 (Insufficient Capacity)
    response can only be done if the rejecting server has definitive
    knowledge of available capacity on the target.  This will require
    some kind of state sharing mechanism between TURN servers, which is
    beyond the scope of this specification.  If a TURN server  
attempts to
    redirect to another server without knowledge of available capacity,
    it is possible that all servers are in a congested state, resulting
    in series of rejections that only serve to further increase the load
    on the system.  This can cause congestion collapse.

I now realize that there are a couple of problems with this text.  
First of all, this text applies only to the Allocate request; it  
doesn't make sense to redirect a Refresh or ChannelBind request, for  
example.

More importantly, the text says that the referring server must have  
positive knowledge that the error that causes the problem won't occur  
on the alternate server, otherwise there may be redirect loops.  
However, there are three conditions under which a redirect might be  
appropriate: 442 (Unsupported Transport Protocol), 486 (Allocation  
Quota Reached) and 507 (Insufficient Capacity) [the 443 error is  
going away now that we have adopted Cullen's proposal]. If server X  
redirects the client to server Y because of a 442 error, and server Y  
redirects the client back to server X because of a 507 error, then we  
will still have a redirect loop.

One possible fix is to require the redirecting server to have  
positive knowledge that the alternate server will not reject the  
request for ANY of the above conditions.

However, an alternate fix is to rely on new text that was added to  
draft-ietf-behave-rfc3489bis (STUN) since the words above were  
written.  That document now says:

    If the server has been redirected to a server on which
    it has already tried this request within the last five minutes, it
    MUST ignore the redirection and consider the transaction to have
    failed.  This prevents infinite ping-ponging between servers in case
    of redirection loops.

My proposal is to simply remind the TURN implementor of this (new)  
STUN requirement, and remove all the words about "positive knowledge"  
from the TURN spec.

Comments?

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 13:19:44 -0500

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?

If I don't hear anything, then the text will probably remain in  
TURN-07, but get removed in TURN-08.

- Philip

---

From: Brian Korver <[email-masked]>
Date: Wed, 20 Feb 2008 10:56:47 -0800

Philip,

When I implemented ALTERNATE-SERVER, I felt it was overly complicated  
(it didn't graft into the control flow especially easily), even though  
the concept is simple.  I vote for drop it in favor of SRV.

-brian
[email-masked]

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 21 Feb 2008 15:58:41 -0800

> 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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 22 Feb 2008 16:45:06 +0200

Le Friday 22 February 2008 01:58:41 ext Marc Petit-Huguenin, vous avez écrit :
> First example is for the clients that does not implement SRV RR.

As far as I remember, SRV is a MUST anyway, and I would not bother trying to 
support non-standard clients in a standard specification.

-- 
Rémi Denis-Courmont

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 22 Feb 2008 07:05:21 -0800

> support non-standard clients in a standard specification.

I am not suggesting to add text to support non-standard clients, I am
trying to show that there is other usages to ALTERNATE-SERVER than
load-balancing.