Subject: [MMUSIC] comment on draft-ietf-mmusic-ice-09.txt

From: "SUNOUCHI, Yuji" <[email-masked]>
Date: Mon, 3 Jul 2006 15:15:38 +0900

I'd like to make a comment on candidate pair priority ordered list.
The current draft orders the list by  checking the minimum serial
number,
then the max serial number, but I think it should be the other way
around.
Checking th maximum serial number, then the minimum serial number.

The example on the draft in 7.5 is ordered like below.

   Order    A     A       A       B     B      B                   Max
          Cand. Cand.    Cand.  Cand. Cand.   Cand.   Max    Min   Cand.
            ID  q-value   SN      ID  q-value  SN     SN     SN     ID
   ---------------------------------------------------------------------
    1      g9g9  1.0      1     h8h8   0.3     1       1      1    h8h8
    2      8888  0.8      2     h8h8   0.3     1       2      1    h8h8
    3      g9g9  1.0      1     6565   0.2     2       2      1    g9g9
    4      g9g9  1.0      1     klkl   0.1     3       3      1    klkl
    5      8888  0.8      2     6565   0.2     2       2      2    8888
    6      8888  0.8      2     klkl   0.1     3       3      2    klkl

and the candidates would probably be something like,

 - g9g9 : local candidate
 - 8888 : server reflexive candidate
 - h8h8 : local candidate
 - 6565 : server reflexive candiate
 - klkl : relayed candidate

In the candidate pair priority list above, pair 8888:6565 which
does not use a stun relay is ordered lower than pair g9g9:klkl
which uses a stun relay.

By ordering the candidate pairs by maximum serial number first instead
of
minimum serial number first, usage of relayed candidate can be minimized
since relayed candidates should have higher serial numbers.
The list would be like this.

   Order    A     A       A       B     B      B                   Max
          Cand. Cand.    Cand.  Cand. Cand.   Cand.   Max    Min   Cand.
            ID  q-value   SN      ID  q-value  SN     SN     SN     ID
   ---------------------------------------------------------------------
    1      g9g9  1.0      1     h8h8   0.3     1       1      1    h8h8
    2      8888  0.8      2     h8h8   0.3     1       2      1    h8h8
    3      g9g9  1.0      1     6565   0.2     2       2      1    g9g9
    4      8888  0.8      2     6565   0.2     2       2      2    8888
    5      g9g9  1.0      1     klkl   0.1     3       3      1    klkl
    6      8888  0.8      2     klkl   0.1     3       3      2    klkl

Regards,
Yuji Sunouchi

---
Yuji Sunouchi<[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Eric Cooper" <[email-masked]>
Date: Fri, 7 Jul 2006 11:31:41 -0400

Hi Yuji, 

I agree that candidate pairs without relays should be prioritized over candidate pairs with relays.  I had noticed a similar problem when considering an example posed by my colleague Philip Matthews.  

I would like to propose an alternate solution, though.  I believe that ordering based upon sequence number is problematic.  It can lead to:

1) Cases where relay candidates are preferred over reflexive candidates; or
2) Cases where server-reflexive candidates are preferred over native candidates.

I think that we should give native candidates highest priority, followed by reflexive candidates, with relayed candidates getting lowest priority.  

ICE-09 proposes sorting first by the minimum sequence number of the pair (lowest min == highest priority), then sub-sorting by maximum sequence number.

I believe you are proposing to sort by the maximum sequence number first (lowest max == highest priority), then sub-sort by the minimum sequence number.

My proposal is that we should ignore the sequence numbers entirely.  Instead, the candidate pairs should be assigned a priority based upon the q-values of the candidates of the pair.  Specifically, I propose to multiple the two q-values (highest result == highest priority).  i.e, a candidate pair with q-values (0.7, 0.7) would be assigned a priority value 0.49.

As a more comprehensive example, please consider the network topology from Philip's earlier message:

         +-------------+                  +-----------+
         | STUN Server |                  | STUN/TURN |
         |      S      |              R5  * Server ST |
         +-------------+                  +-----------+

              L2                               R4
           +----*-----------------------------*------+
           |               NAT  N                    |
           +-----------------------------------------+

                                             +------------+
                                             | STUN/TURN  |
                                         R3  * Server STR |
                                             +------------+

                                                     R2
 +--------+                                   +-----*--+
 | NAT NL |                                   | NAT NR |
 +--------+                                   +--------+

    /\                                            /\
   /  * L1                                       /  * R1
  /  L \                                        /  R \
 +------+                                      +------+

Let's say that q-values assigned to the various candidates are:

L1 - 1.0         R1 - 1.0
L2 - 0.7         R2 - 0.71
                 R3 - 0.31
                 R4 - 0.7
                 R5 - 0.3

The table below shows the candidate pairs and the results of the various ordering schemes:

Cand.          Seq.           Q                          Order
Pair           Nums          Vals            Min 1st    Max 1st     Multiply
----------------------------------------------------------------------------
(L1, R1)     (1, 1)       (1.0, 1.0)            1          1           1
(L1, R2)     (1, 2)       (1.0, 0.71)           2          2           2
(L1, R3)     (1, 4)       (1.0, 0.31)           5          7           7
(L1, R4)     (1, 3)       (1.0, 0.7)            4          6           4
(L1, R5)     (1, 5)       (1.0, 0.3)            6          9           8
(L2, R1)     (2, 1)       (0.7, 1.0)            3          3           3
(L2, R2)     (2, 2)       (0.7, 0.71)           7          4           5
(L2, R3)     (2, 4)       (0.7, 0.31)           9          8           9
(L2, R4)     (2, 3)       (0.7, 0.7)            8          5           6
(L2, R5)     (2, 5)       (0.7, 0.3)            10         10          10

As you pointed out, the min-first scheme puts candidate pair (L1, R3), which involves a relayed candidate, ahead of candidate pair (L1, R4), which does not.  This more complex example also shows that the max-first scheme puts candidate pair (L2, R4), which is two server-reflexive candidates, ahead of candidate pair (L1, R4), which has a native candidate and a server-reflexive candidate.  The multiplication scheme does neither of these things, and has the added bonus of being really easy to explain.

Best Regards,

Eric Cooper.

  ----- Original Message ----- 
  From: SUNOUCHI, Yuji 
  To: [email-masked] 
  Sent: Monday, July 03, 2006 2:15 AM
  Subject: [MMUSIC] comment on draft-ietf-mmusic-ice-09.txt

     Order    A     A       A       B     B      B                   Max

   - g9g9 : local candidate

     Order    A     A       A       B     B      B                   Max

  Regards,
  Yuji Sunouchi

  ---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 16:46:14 -0400

inline.

Eric Cooper wrote:

> Hi Yuji,
>  
> I agree that candidate pairs without relays should be prioritized over 
> candidate pairs with relays.  I had noticed a similar problem when 
> considering an example posed by my colleague Philip Matthews. 
>  
> I would like to propose an alternate solution, though.  I believe that 
> ordering based upon sequence number is problematic.  It can lead to:
>  
> I think that we should give native candidates highest priority, followed 
> by reflexive candidates, with relayed candidates getting lowest priority. 
>  
> ICE-09 proposes sorting first by the minimum sequence number of the pair 
> (lowest min == highest priority), then sub-sorting by maximum sequence 
> number.
>  
> I believe you are proposing to sort by the maximum sequence number first 
> (lowest max == highest priority), then sub-sort by the minimum sequence 
> number.
>  
> My proposal is that we should ignore the sequence numbers entirely.  
> Instead, the candidate pairs should be assigned a priority based upon 
> the q-values of the candidates of the pair.  Specifically, I propose to 
> multiple the two q-values (highest result == highest priority).  i.e, a 
> candidate pair with q-values (0.7, 0.7) would be assigned a priority 
> value 0.49.

I had considered that in the initial design of ICE. However, it doesn't 
work. The problem is that q-values are ordinal, not cardinal. If you 
multiply them together as you suggest, then the resulting sequence 
depends on the cardinality, which is bad. Here is an example. Consider 
two agents L and R. L has candidates A and B, and R has candidates C and 
D. Consider the following set of q-values:

SET 1:

A: .1       C: .5
B: .2       D: .1

SET 2:

A: .98      C: .5
B: .99      D: .1

These two sets have the same relative order for candidates, but if you 
get the candidate-pair priority by multipling q-values, you get 
completely different orderings between the two sets. Thats not allowed.

We went through this with caller preferences (RFC 3841) whose design 
worked by multiplying q-values as you suggest. We had to abandon that 
for the same reason.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 16:48:33 -0400

I'll have to ponder this a bit more, but at first glance I think your 
suggestion makes sense. It depends on the objective of the maximization 
function. If its aim is to avoid relays, then I think your suggestion works.

-Jonathan R.