Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 9 Sep 2014 03:15:00 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Tuesday, September 09, 2014 2:44 AM
> To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); [email-masked]
> Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-
> mobility-01.txt
> 
> On 09/08/2014 12:48 PM, Tirumaleswar Reddy (tireddy) wrote:
> [snip]
> >>>> Change in service provider can be one of the most significant
> >>>> factors influencing connection quality, because the peering
> >>>> relationships between providers are so important. If the peering
> >>>> relationships for the new provider are distinctly different than
> >>>> the peering relationships for the previous, that could be enough to
> >>>> make the relay
> >> server a very bad choice in some cases.
> >>>
> >>> 1) how will peer-redirect work in this case ?
> >>>       Are you assuming that the relay server provided by both the
> >>> service
> >> providers have some tie-up for peer-redirect to be used ?
> >>
> >> Performance-based redirection (or really any use of try-alternate)
> >> assumes that the relay servers have some sort of tie-up, even though
> >> it might be quite loose.
> >
> > I thought they are tightly coupled (operated by the same vendor)
> >
> 
> It would be a tight coupling in the Akamai use case today, but I've got no idea
> what we might see in the future.
> 
> >> The one sending try-alternate has to have some way to know what the
> >> reasonable candidates are.
> >>
> >> That said, I'm not suggesting peer-redirect via a
> >> channelbind/permission response. I'm suggesting redirection via the
> >> refresh response. It would work something like this:
> >>
> >>      * Client changes IP address and sends refresh with mobility ticket.
> >>
> >>      * Relay sends refresh response with new mobility ticket and
> >>        alternate server attribute.
> >>
> >>      * Client continues to use relay with established session while at
> >>        the same time setting up a new allocation and channel via the
> >>        provided alternate server.
> >>
> >>      * After the new allocation and channel are set up, the client can
> >>        shift the flow to the new relay.
> >>
> >> It's pretty similar to the peer redirect case, except that it would
> >> potentially impact all existing p2p flows.
> >
> > Got it, I think the above mechanism should be explained in peer-redirect
> draft and not in TURN Mobility draft.
> 
> I'm not describing peer-redirect here. I'm describing a scenario that's
> specifically associated with use of mobility tickets. If there is no specified way
> to drive the client to shift to another relay, then the only option for a relay
> server like the one I describe is to issue an error respond to the mobility
> ticket, breaking the session. Maybe that's OK, since that's what would have
> happened without mobility support. That having been said, if I end up writing
> a bit broader draft that discusses use of ALTERNATE-SERVER in general, what
> I'm describing could fit in well there.

Yup, broader draft that discusses use of ALTERNATE-SERVER in general will help.
 
> 
> >
> >>
> >>> 2)If let's say the client is using application provided TURN server
> >>> or third
> >> party provided TURN server  and the client moves from 3G to Wifi or
> >> vice- versa.
> >>>       Is there a need for peer-redirect in this case ?
> >>
> >> Do you mean there would be a case where the client uses an app
> >> provided relay when on 3G and a 3rd party relay when on wifi (or vice
> versa)?
> >
> > No, I meant the TURN client uses the same application provided relay
> server in both 3G and Wifi networks.
> > My question - Is there need for peer-redirect amongst the application
> provided TURN servers in this scenario ?
> 
> The utility of peer-redirection depends upon the relay server distribution.
> The same is true for redirection of almost any sort, I think. It doesn't really
> matter who provides the relay server capacity (whether the app provider or a
> 3rd party). The more centralized the relay capacity, the lower the likelihood
> that redirection will be required or even helpful.

Agreed.

-Tiru

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