Subject: Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?

From: Varun Singh <[email-masked]>
Date: Thu, 31 Jul 2014 13:58:00 +0300

On Tue, Jul 29, 2014 at 7:24 PM, Tirumaleswar Reddy (tireddy)
<[email-masked]> wrote:
>> -----Original Message-----
>> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
>> Sent: Tuesday, July 29, 2014 6:13 PM
>> To: Justin Uberti; Jonathan Lennox
>> Cc: [email-masked]
>> Subject: Re: [tram] Comment on draft-williams-peer-redirect-01: might it not
>> converge?
>>
>> Le 2014-07-28 20:56, Justin Uberti a écrit :
>> > I agree this is a real problem - while A' might be a better match for
>> > B, A might be better for B', just due to internet routing oddities. So
>> > you could end up switching ad nauseam.
>>
>> Agreed.
>>
>> > Also:
>> > 2) Ted's point that "closer" doesn't always mean "better" - A often
>> > won't have the information to know for sure that A' is better for B.
>>
>> I don't think that the problem is that it won't work: we know from Akamai's
>> example that it can work. What Ted asked, as I understand it, is for the next
>> draft revision to describe the knowledge that is required in order to be able to
>> perform the kind of server selection for which the draft defines signaling.
>>
>> > 3) The general mechanism is unlikely to produce the desired results,
>> > because the ALTERNATE-SERVER will typically arrive after gathering has
>> > completed - and thus you need to do an ICE restart to actually use the
>> > new TURN server. Since the timing of ALTERNATE-SERVER will be
>> > different for both a and b, it will be difficult to get this properly synchronized.
>> >
>> > If we could do a synchronized restart though, one could treat the
>> > ALTERNATE-SERVER from the original TURN server as a suggestion, and
>> > then during the restart, allocate candidates from both. Then, using
>> > the actual RTTs that are observed amongst the permutations (A->B,
>> > A->B', A'->B, A'->B'), the CONTROLLING side can determine the best path to
>> use.
>>
>> Would be nice if we had an ICE-RTT draft that we could point to... ;)
>
> MPRTP already uses RTT and other path characteristics to load balance the media stream across different interfaces, it may help to look into the work they have already done.
>

As Jonathan pointed out, RTT can be calculated from the STUN
transactions messages. but the endpoint may also want to prefer a less
lossy path. This too may be calculated using STUN retransmissions or
counting the numbe of RTOs.
It may not matter when there is only one interface, but when choosing
between multiple interfaces/paths (3G, WLAN, etc.) to a TURN server.

Since this proposal is about redirecting the peer to a different TURN
server, the redirecting server probably already knows the throughput
or the capacity of the new TURN server and took that into
consideration before redirecting the peers.

MPRTP is slightly different because it does not know the throughputs
of each path before hand and needs to send data on those paths to make
appropriate load balancing decisions. (it may of course learn some
metrics from processing connectivity checks).

Cheers,
Varun

> -Tiru
>
>>
>> Simon
>>
>> _______________________________________________
>> tram mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Varun Singh <[email-masked]>
Date: Thu, 31 Jul 2014 14:04:04 +0300

On Wed, Jul 30, 2014 at 10:10 AM, Justin Uberti <[email-masked]> wrote:
> On Tue, Jul 29, 2014 at 11:40 PM, Tirumaleswar Reddy (tireddy)
>> > The one thing we need to do is update ICE to allow the CONTROLLING side
>> > to make dynamic decisions about which pair to use, instead of being forced
>> > to use PRIORITY (which is what 5245 says).
>>
>> The dynamic decision of changing priority in certain scenarios  should be
>> confined to an interface. For example when cost saving is taken into account
>> in multi-interface scenario, candidates from an interface which offers least
>> cost would have higher priority than candidates from other interfaces.
>
>
> Least cost is one policy that the application could choose. I don't think it
> should be the only one.
>

Assuming cost meant monetary cost, apart from dollar costs, it can be
energy costs, latency vs throughput trade-off, or something else altogether.
So agree the monetary cost shouldn't be the only policy. I suppose the
application, user and/or the system knows these policies better.

Cheers,
Varun