Subject: [MMUSIC] ICE-16 possible issue

From: Guilherme Balena Versiani <[email-masked]>
Date: Thu, 12 Jul 2007 14:13:03 -0300

The section "4.1.1.3. Eliminating Redundant Candidates" states that "a 
candidate is redundant if its transport address equals another 
candidate, and its base equals the base of that other candidate".

The next section "4.1.1.4. Computing Foundations" then states that "two 
candidates MUST have the same foundation ID when all of the following 
are true: they are of the same type, their bases have the same IP, for 
server and reflexive candidates, the STUN servers used to obtain them 
have the same IP address".

Be the following scenario:

  - There are two STUN servers configured by an agent A 
(200.100.10.50:3478 and 200.100.10.51:3478);
  - The agent A have two components (RTP and RTCP);
  - The gathering process obtain the following addresses (in order):
    * component=1, transport=10.0.0.1:5004/udp, type=local;
    * component=2, transport=10.0.0.1:5005/udp, type=local;
    * component=2, transport=200.100.10.1:5005/udp, type=srflx, 
stunserver=200.100.10.50:3478;
    * component=1, transport=200.100.10.1:5004/udp, type=srflx, 
stunserver=200.100.10.51:3478;
    * component=1, transport=200.100.10.1:5004/udp, type=srflx, 
stunserver=200.100.10.50:3478;
    * component=2, transport=200.100.10.1:5005/udp, type=srflx, 
stunserver=200.100.10.51:3478;

Following the algorithm described in the section "4.1.1.3", we must 
eliminate two of the server reflexive candidates as they have the same 
mapped-address. So, by removing the redundant candidates in order 
(forward comparison), we get the new candidate list as follows:

    * component=1, transport=10.0.0.1:5004/udp, type=local;
    * component=2, transport=10.0.0.1:5005/udp, type=local;
    * component=2, transport=200.100.10.1:5005/udp, type=srflx, 
stunserver=200.100.10.50:3478;
    * component=1, transport=200.100.10.1:5004/udp, type=srflx, 
stunserver=200.100.10.51:3478;

Note that the two server reflexive candidates was obtained by two 
different STUN servers. Now I must compute the foundations, then I would 
get:

    * foundation=1, component=1, transport=10.0.0.1:5004/udp, type=local;
    * foundation=1, component=2, transport=10.0.0.1:5005/udp, type=local;
    * foundation=2, component=2, transport=200.100.10.1:5005/udp, 
type=srflx, stunserver=200.100.10.50:3478;
    * foundation=3, component=1, transport=200.100.10.1:5004/udp, 
type=srflx, stunserver=200.100.10.51:3478;

I expected to have the same foundation for the last two candidates, for 
they have the same mapped-address IP and both the STUN servers are 
located at the same network. I know it is difficult to discover if two 
STUN servers are located in the same network, so I suggest you to review 
the section "4.1.1.4" the statement "for reflexive and relayed 
candidates, the STUN servers used to obtain them have the same IP 
address". I don't know if this is an issue or it is a normal behavior of 
the algorithm, but I use these foundations to conclude the ICE 
processing (I wait for two candidate pairs with the same foundation to 
complete, for QoS purposes).

Regards,

Guilherme Balena Versiani
ComunIP S/A

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 10:05:06 -0400

What you describe is normal behavior of the algorithm. There is no way 
for ICE to know whether these STUN servers are really 'the same' and 
that their network paths towards the NAT are identical.

The problem here is that, when you eliminated the redundant candidates, 
you ended up eliminating one from one STUN server, and one from the 
other. In fact you should have eliminated both of them from the same 
STUN server.

THe spec is currently silent on WHICH candidates to eliminate when they 
are redundant. That is because the current redundancy elimination step 
happens prior to prioritization.

I suggest a simple fix is that I merely move Section 4.1.2 down after 
prioriziation, and then suggest that the least preferred candidate is 
eliminated.

-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: Guilherme Balena Versiani <[email-masked]>
Date: Fri, 20 Jul 2007 10:24:11 -0300

Just moving Section 4.1.2 down does not do the work, as there are not 
any defined order between the native candidates during Gathering.

Is there any reason to not check just the base IP address and the mapped 
IP address? I though something like "a candidate must have the same 
foundation ID when all of the following are true: they are of the same 
type, their bases have the same IP, for server and reflexive candidates, 
the transport address have the same IP". Is there any known issue 
related to this solution?

-- Guilherme Balena Versiani.

Jonathan Rosenberg wrote:
> The problem here is that, when you eliminated the redundant 
> candidates, you ended up eliminating one from one STUN server, and one 
> from the other. In fact you should have eliminated both of them from 
> the same STUN server.
>
> THe spec is currently silent on WHICH candidates to eliminate when 
> they are redundant. That is because the current redundancy elimination 
> step happens prior to prioritization.
>
>> The section "4.1.1.3. Eliminating Redundant Candidates" states that 
>> "a candidate is redundant if its transport address equals another 
>> The next section "4.1.1.4. Computing Foundations" then states that 
>> "two candidates MUST have the same foundation ID when all of the 
>> following are true: they are of the same type, their bases have the 
>> same IP, for server and reflexive candidates, the STUN servers used 
>> to obtain them have the same IP address".
>>
>> eliminate two of the server reflexive candidates as they have the 
>> same mapped-address. So, by removing the redundant candidates in 
>> order (forward comparison), we get the new candidate list as follows:
>>
>> different STUN servers. Now I must compute the foundations, then I 
>> would get:
>>
>> I expected to have the same foundation for the last two candidates, 
>> for they have the same mapped-address IP and both the STUN servers 
>> are located at the same network. I know it is difficult to discover 
>> if two STUN servers are located in the same network, so I suggest you 
>> to review the section "4.1.1.4" the statement "for reflexive and 
>> relayed candidates, the STUN servers used to obtain them have the 
>> same IP address". I don't know if this is an issue or it is a normal 
>> behavior of the algorithm, but I use these foundations to conclude 
>> the ICE processing (I wait for two candidate pairs with the same 
>> foundation to complete, for QoS purposes).
>>
>> Regards,
>>

---

From: Guilherme Balena Versiani <[email-masked]>
Date: Fri, 20 Jul 2007 10:42:59 -0300

I'm sorry. Moving the Section 4.1.2 really do the work. BTW, please 
check my question.

Guilherme Balena Versiani wrote:
> Is there any reason to not check just the base IP address and the 
> mapped IP address? I though something like "a candidate must have the 
> same foundation ID when all of the following are true: they are of the 
> same type, their bases have the same IP, for server and reflexive 
> candidates, the transport address have the same IP". Is there any 
> known issue related to this solution?
>
>> What you describe is normal behavior of the algorithm. There is no 
>> way for ICE to know whether these STUN servers are really 'the same' 
>> and that their network paths towards the NAT are identical.
>>
>> candidates, you ended up eliminating one from one STUN server, and 
>> one from the other. In fact you should have eliminated both of them 
>> from the same STUN server.
>>
>> they are redundant. That is because the current redundancy 
>> elimination step happens prior to prioritization.
>>
>>> if two STUN servers are located in the same network, so I suggest 
>>> you to review the section "4.1.1.4" the statement "for reflexive and