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

From: Ari Keränen <[email-masked]>
Date: Fri, 10 Jan 2014 18:00:17 +0200

Hi,

I read the latest draft and have a few questions. In Section 3 the draft 
says:

>    ICE [RFC5245] section 4.1.2 states that the formula in section
>    4.1.2.1 SHOULD be used.  Failing to do so may lead to ICE taking
>    longer to converge as the checklist no longer will be coordinated.
>    Therefore responsiveness of ICE candidate checks are improved when
>    both sides support Happy-Eyeballs, both sides have the same number of
>    candidate pairs, and both sides use the same Happy Eyeballs promotion
>    algorithm.

Do you mean the checklist is no longer coordinated (i.e., matching on 
both sides) if all those requirements aren't fulfilled? That sounds a 
bit strange but that's the impression I got from the text.

Also, if there is no coordination/signaling between the endpoints, what 
are the odds they'd end up using the same promotion algorithm?

>    If each ICE agent uses a different algorithm to promote IPv4
>    candidates, ICE connectivity checks will be as responsive as the
>    least aggressive algorithm.

What is "least aggressive algorithm"?

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 13 Jan 2014 11:46:21 +0000

On 10 Jan 2014, at 17:00 pm, Ari Keränen <[email-masked]> wrote:

> Hi,
> 
> I read the latest draft and have a few questions. In Section 3 the draft says:
> 
> Do you mean the checklist is no longer coordinated (i.e., matching on both sides) if all those requirements aren't fulfilled? That sounds a bit strange but that's the impression I got from the text.

What we tried to say was that if the two agents have different Happy Eyeball Algorithms ICE might take longer to complete.
Both Alice and Bob used the following formula to sort the checklist: After N numbers of IPv6 addresses, add M numbers of IPv4 addresses. 

   Alice(N=4, M=1)                   Bob(N=2,M=1)
1     IPv6                                     IPv6
2     IPv6                                     IPv6
3     IPv6                                     IPv4(*)
4     IPv6                                     IPv6
5     IPv4(*)                                 IPv6
6     IPv6                                     IPv4(*)
7     IPv6                                     IPv6
8     IPv6                                     IPv6
9     IPv6                                     IPv4(*)
10   IPv4(*)                                 IPv6
11   IPv6                                     IPv6
12   IPv6                                     IPv4(*)
13   IPv6                                     IPv6
14   IPv6                                     IPv6
15   IPv4(*)
16   IPv4(*)

 The initial thought was that having for example different M and N values would cause ICE to take longer to complete. But due to triggered checks different M and N values might actually speed up the ICE negotiation. 

I will update the text using this simple example algorithm, and rewrite Section 3.

> 
> Also, if there is no coordination/signaling between the endpoints, what are the odds they'd end up using the same promotion algorithm?
> 
Exactly, and that might be an advantage.. 

> What is "least aggressive algorithm”?

Good question. Regarding what the meaning was I think it was wron.

Rereading the entire draft myself. I realise it is in a pretty bad state. I will do a full rewrite focusing on:

1. Explaining the need for the draft. (Get IPv6 path a head start so we choose that, but try to minimize the delay if the path is broken)
2. Get rid of generic IP address language. We are dealing with IPv6 and IPv4. That is not going to change for a while. (Haing language as if IPv8 was just around the corner just makes it harder to read)
3. Add example algorithm as described in this mail

Thanks for the review, will submit a 05 version before next IETF. 

.-.
Pål-Erik

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 13 Jan 2014 13:39:24 +0000

Hi Ari,

>What is "least aggressive algorithm"?

Since there is no signaling between the end points, each end point could
promote IPv4 to different positions in the checklist. Based on candidate
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0), the end point that
has promoted IPv4 in the least aggressive fashion i.e. IPv4 lower in its
list when compared to the other end point, will influence the candidate
priority pairing due to (2^32*MIN(G,D)) in the formula.

Thanks,
Prashanth

>
>
>Cheers,
>Ari
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ari Keränen <[email-masked]>
Date: Fri, 24 Jan 2014 13:59:36 +0000

Hi,

The way forward you proposed sounds good. Looking forward to the updated draft. However, I didn’t really understand how is the lack of coordination and different promo algorithms an advantage?

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 28 Jan 2014 13:49:19 +0000

> The way forward you proposed sounds good. Looking forward to the updated draft. However, I didn’t really understand how is the lack of coordination and different promo algorithms an advantage?

My thought at the time was due to triggered checks it could in some cases be good to have uncoordinated checklists for IPv6 due to less NATs and other restrictive “things”. But that is clearly a bad idea. Sorry for the derailing. 

Just posted -05 version of the draft. 

Name:		draft-reddy-mmusic-ice-happy-eyeballs
Revision:	05
Title:		Happy Eyeballs Extension for ICE
Document date:	2014-01-28
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-happy-eyeballs-05.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-happy-eyeballs/
Htmlized:       http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eyeballs-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-reddy-mmusic-ice-happy-eyeballs-05

Not sure if we hit the right balance between keeping it short, but still readable without having all the ICE details fresh in memory. 

Do we ask for WG adoption, or do we need another MMUSIC session discussing this?

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Thu, 30 Jan 2014 13:34:33 +0200

Hi,

> Just posted -05 version of the draft.

Thanks! Here's a few comments on the latest version.

The abstract says:

>    This document provides guidelines on how to make ICE [RFC5245]
>    conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths
>    exist.  This will lead to more sustained IPv6 deployment as users
>    will no longer have an incentive to disable IPv6.

Out of (much of) context, especially the second sentence seems like a 
quite strong statement. I guess there could be other reasons than this 
for disabling v6, for example.

And nit: usually abstract should not contain references and open the ICE 
acronym.

>    An ICE agent can choose an algorithm or a technique of its choice to
>    ensure that the resulting check lists have a fair intermingled mix of
>    IPv4 and IPv6 address families.  Modifying the check list directly
>    can lead to uncoordinated local and remote check lists that result in
>    ICE taking longer to complete.

Not only can the tests take longer, but they can potentially also fail 
if the lists get badly out of sync since once you have made a NAT 
binding with a connectivity check packet, the check to other direction 
must come before the binding expires. But I suppose this will not be a 
problem with the proposed solution since the lists will be in sync?

>    The local and remote agent can have different algorithms for choosing
>    the type preference value without any impact on coordination between
>    the local and remote check list.

What do you mean by "without any impact on coordination"?

>    Where G is the candidate provided by the controlling agent and D the

s/candidate/priority of the candidate/

> Do we ask for WG adoption, or do we need another MMUSIC session discussing this?

Given this new approach, I think it's too early to ask for WG adoption. 
Rather we need more discussion especially here on the list and possibly 
at the meeting.

What I would find helpful for discussion is that if you could provide a 
step-by-step example of how the candidate lists are formed and 
connectivity checks done in cases where a) both support this with same 
promo algo b) both support this but with different promo algo c) only 
one endpoint supports this.

Also maybe a recommended promo algo would make sense so that there is at 
least a fair chance that both will use the same algo/values and get most 
out of this.

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 31 Jan 2014 13:44:36 +0000

On 30 Jan 2014, at 12:34 pm, Ari Keränen <[email-masked]> wrote:

> Out of (much of) context, especially the second sentence seems like a quite strong statement. I guess there could be other reasons than this for disabling v6, for example.

Agree. Sentence removed.

> 
> And nit: usually abstract should not contain references and open the ICE acronym.
> 
Fixed.

> Not only can the tests take longer, but they can potentially also fail if the lists get badly out of sync since once you have made a NAT binding with a connectivity check packet, the check to other direction must come before the binding expires. But I suppose this will not be a problem with the proposed solution since the lists will be in sync?
> 
Added failure as well to further scare the reader. :-)

And yes, the list must be kept in sync.

> What do you mean by "without any impact on coordination”?

kept in sync?

New text:

The local and remote agent can have different algorithms for choosing
the local preference value without impacting the synchronisation
between the local and remote check list.

> s/candidate/priority of the candidate/
tnx

> Given this new approach, I think it's too early to ask for WG adoption. Rather we need more discussion especially here on the list and possibly at the meeting.
> 
Ok. 

Just a bit afraid of wasting cycles if this proves to not so useful. 

> What I would find helpful for discussion is that if you could provide a step-by-step example of how the candidate lists are formed and connectivity checks done in cases where a) both support this with same promo algo b) both support this but with different promo algo c) only one endpoint supports this.
> 

As I do believe in running code, I wrote a simple implementation of the algorithm described below.

It can be downloaded from:
https://github.com/palerikm/HappyE-ICE-Test

>From README:

Compiling
===============
Run ./bootstrap to create the configure script.

then do ./configure
and
 
make

Running
===============

There are two txt files with candidates. One with local candidates where priorities needs to be calculated and a predefined remote candidate file. (Please Note parsing is crude so keep the files clean..)

the program can be run as follows:

src/icehetest 4 candidates.txt remoteCandidates.txt 

4 indicates the number of concecutive candidates if same address type allowed.

> Also maybe a recommended promo algo would make sense so that there is at least a fair chance that both will use the same algo/values and get most out of this.
> 
First shot an an algorithm:

5.  Example Algorithm for Choosing the Local Preference

   The value space for the local preference is from 0 to 65535
   inclusive.  This value space can be divided up in chunks for each IP
   address family.

   An IPv6 and IPv4 start priority must be given.  In this example IPv6
   starts at 60000 and IPv4 at 59000.  This leaves enough address space
   to further play with the values if pr interface priorities needs to
   be added.  The highest value should be given to the address family
   that should be prioritized.

        IPv6    IPv4
         Start   Start
   65535  60k     59k    58k    57k    56k    55k                    0
   +--------+------+------+------+------+------+---------------------+
   |        | IPv6 | IPv4 | IPv6 | IPv4 | IPv6 |                     |
   |        | (1)  |  (1) |  (2) |  (2) |  (3) |                     |
   +--------+------+------+------+------+------+---------------------+
             <- N->

   The local preference can be calculated by the given formula:

         local_preference = N*2*(Cn/Cmax)

   Where N is the absolute value of IPv6_start-IPv4_start.  This ensures
   a positive number even if IPv4 is the highest priority.  Cn is the
   number of current candidates of a specific IP address type and
   candidate type (HOST, SRFLX, RELAY).  Cmax is the number of allowed
   consecutive candidates of the same IP address type.

.-.
Pål-Erik