Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt

From: Ari Keränen <[email-masked]>
Date: Sun, 3 Nov 2013 22:39:30 -0800

Hi,

I think the algorithm starts to make sense, but how do you envision to 
choose the "N" and should there be a negotiation mechanism that ensures 
that both endpoints choose the same N?

Cheers,
Ari (as individual)

On 8/25/13 11:42 PM, Tirumaleswar Reddy (tireddy) wrote:
> Updated the Happy Eyeballs Extension for ICE Algorithm in section 4
> of the draft based on the comments received from the WG to update the
> candidate priority such that some server-reflexive candidates have
> higher priority than some IPv6 host candidates.
>
> Comments and Suggestions are welcome.
>
> -Authors.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 4 Nov 2013 14:00:54 +0000

> -----Original Message-----
> From: Ari Keränen [mailto:[email-masked]]
> Sent: Monday, November 04, 2013 12:10 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-
> happy-eyeballs-02.txt
> 
> Hi,
> 
> that both endpoints choose the same N ?

I don't think there is any need to negotiate about "N" because it's only local prioritization of candidates. ICE agent can use Happy Eyeballs Extension for ICE algorithm independent of whether remote agent supports it or not. 

-Tiru.

---

From: Ari Keränen <[email-masked]>
Date: Mon, 4 Nov 2013 15:55:21 +0000

> I don't think there is any need to negotiate about "N" because it's only local prioritization of candidates. ICE agent can use Happy Eyeballs Extension for ICE algorithm independent of whether remo…

Have you done an exercise (or better, implementation?) on how the candidate pairs would then look like? Since ICE uses MAX/MIN sorting of the pairs (see http://tools.ietf.org/html/rfc5245#appendix-B.5) simply having high priority on the other side may not give the results you want.

Cheers,
Ari

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 6 Nov 2013 09:56:41 +0000

> Sent: Monday, November 04, 2013 9:25 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> > I don't think there is any need to negotiate about "N" because it's only
> local prioritization of candidates. ICE agent can use Happy Eyeballs Extension
> for ICE algorithm independent of whether remote agent supports it or not.
> 
> Have you done an exercise (or better, implementation?) on how the candidate
> pairs would then look like? Since ICE uses MAX/MIN sorting of the pairs (see
> http://tools.ietf.org/html/rfc5245#appendix-B.5) simply having high priority
> on the other side may not give the results you want.

MAX/MIN logic used for calculating candidate-pair priority ensures that for a particular agent, a lower-priority candidate is never used until all higher-priority candidates have been tried. So even if the remote peer does not support Happy Eyeballs Extension algorithm, the ICE agent would start ICE connectivity checks based on the local prioritization and if IPv4 ICE connectivity is received by the remote peer then it would cause Triggered Checks for IPv4 candidate-pair. Hence IPv4 candidate-pair will be tested earlier even if remote peer does not Happy Eyeballs Extension algorithm. So effectively even if just one of the end points supports the algorithm, connectivity checks are optimized and should see better results. 

-Tiru.

---

From: Ari Keränen <[email-masked]>
Date: Thu, 7 Nov 2013 01:11:31 +0000

Hi Tiru,

> MAX/MIN logic used for calculating candidate-pair priority ensures that for a particular agent, a lower-priority candidate is never used until all higher-priority candidates have been tried. So eve…

I'm afraid that still wouldn't work like that. As you said, "a lower-priority candidate is never used until all higher-priority candidates have been tried". You would not start checks based on a local high priority for an IPv4 candidate since a *pair* with that candidate would not have high priority (due to the "2^32*MIN(G,D)" part of the formula -- it's the smaller priority of the candidates that counts).

That said, I remember getting this wrong in my own implementation the first time so as I said you may want to do this exercise with real numbers and see where you end up.

Cheers,
Ari

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 12 Nov 2013 11:46:22 +0000

Hi Ari,

Please see inline 

> Sent: Thursday, November 07, 2013 6:42 AM
> Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-
> happy-eyeballs-02.txt
> 
> Hi Tiru,
> 
> > MAX/MIN logic used for calculating candidate-pair priority ensures that for
> a particular agent, a lower-priority candidate is never used until all higher-
> priority candidates have been tried. So even if the remote peer does not
> support Happy Eyeballs Extension algorithm, the ICE agent would start ICE
> connectivity checks based on the local prioritization and if IPv4 ICE
> connectivity is received by the remote peer then it would cause Triggered
> Checks for IPv4 candidate-pair. Hence IPv4 candidate-pair will be tested
> earlier even if remote peer does not Happy Eyeballs Extension algorithm. So
> effectively even if just one of the end points supports the algorithm,
> connectivity checks are optimized and should see better results.
> 
> I'm afraid that still wouldn't work like that. As you said, "a lower-priority
> candidate is never used until all higher-priority candidates have been tried".
> You would not start checks based on a local high priority for an IPv4
> candidate since a *pair* with that candidate would not have high priority (due
> to the "2^32*MIN(G,D)" part of the formula -- it's the smaller priority of the
> candidates that counts).

You are right, there is no benefit if only one endpoint supports Happy Eyeballs Extension algorithm. we will update the draft to high-light this point.

Thanks and Regards,
-Tiru.

> 
> That said, I remember getting this wrong in my own implementation the first
> time so as I said you may want to do this exercise with real numbers and see
> where you end up.
> 
> 
> Cheers,
> Ari