Subject: [MMUSIC] Re: Problem with Pairing Peer-Reflexive Candidates in ICE

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

Wow, nice work in figuring out a scenario that manifests this problem.
Its a pretty complicated configuration.

Let us remember that ICE actually works in this situation; it will
result in media successfully going between clients. It just happens to
use the STUN relay when it could have gone directly if, as you suggest,
ICE had tried to pair the peer reflexive candidate with every other 
candidate. So, its a question of whether we want to optimize every 
possible use case.

Its worth noting as well that an optimal path would have been used if 
the nat supported hairpinning. Consequently, as behave compliant nats 
get deployed this use case goes away.

So, I am very reluctant to have ICE pair peer reflexive transport 
addresses with all others. As you point out, this will add even more 
checks to an already busy check process. Worse still, I think its a 
non-trivial jump in complexity for a protocol which is already pretty 
complicated.

Consequently, I'm inclined to leave well-enough alone and not try to 
optimize this case.

Thanks,
Jonathan R.

Philip Matthews wrote:

> Currently, the ICE specification states that a peer-reflexive candidate
> is ONLY paired with the remote candidate that was involved in
> discovering it. However, Eric and I have discovered an example where
> this results in an optimal communication path NOT being discovered
> (and where the optimal path WOULD be discovered if peer-reflexive
> candidates were paired with other candidates).
> 
> We briefly summarize the example below. Full details can be found at
>   www.magma.ca/~philip_matthews/Peer-Reflexive-Pairing-Problem.pdf
> 
> Consider the following network. Here the candidates are indicated with
> stars (*) and labeled L1, L2, etc.
> 
>         +-------------+                  +------------+
>         | STUN Server |                  | STUN/TURN  |
>         |      S      |              R5  * Server ST  |
>         +-------------+                  +------------+
> 
>              L2                               R4
>           +----*-----------------------------*------+
>           |               NAT  N                    |
>           +-----------------------------------------+
> 
>                                             +------------+
>                                             | STUN/TURN  |
>                                         R3  * Server STR |
>                                             +------------+
> 
>          L1R3                            R1L1R3     R2
> +------*-+                                   +*----*--+
> | NAT NL |                                   | NAT NR |
> +--------+                                   +--------+
> 
>    /\                                            /\
>   /  * L1                                       /  * R1
>  /  L \                                        /  R \
> +------+                                      +------+
> 
> 
> Both L and R get internet access from a provider that NATs its
> entire network using NAT N. NAT N is almost BEHAVE-compliant,
> but does not support hairpinning.
> L is a home phone whose owner has purchased a simple NAT which
> happens to be BEHAVE-compliant. L came pre-configured to use
> STUN server S.
> R is a corporate phone. R is behind a symmetric NAT NR
> (= address-and-port-dependent mapping, address-and-port-dependent
> filtering). R is configured to use two STUN/TURN servers:
> server ST has a public IP address, while server STR is located
> inside the ISP's network.
> 
> During the initial gathering of candidates phase, L learns only
> L1 and L2. It does NOT learn a server-reflexive candidate on NL
> because L is not configured to use a STUN server that could give it
> that information.
> 
> But, as the connectivity checks proceed, L and R learn a peer-reflexive
> candidate for L on NL. This peer-reflexive candidate is learned while
> checking candidate pair (L1, R3), and thus the rules
> of [ICE-08] say that the peer-reflexive candidate is named L1R3 and
> it is paired only with R3, which is the candidate that helped find it.
> 
> HOWEVER, if the rules of ICE were changed to pair this new candidate
> with R1 as well, then the connectivity checks for (L1R3, R1) would find
> a second peer-reflexive candidate, which would be named R1L1R3.
> This would then give rise to the pair (L1R3, R1L1R3), which is the
> optimal path.
> 
> 
> 
> The obvious fix for this problem is to pair native peer-reflexive  
> candidates
> with *ALL* remote candidates, not just the one that was involved in
> discovering it. However, this fix has the side effect of almost doubling
> the number of candidate pairs (from 10 to 18) -- a huge increase with
> corresponding increase in messaging. It may be that it is sufficient
> to pair the peer-reflexive candidate with just certain other candidates.
> This needs more investigation.
> 
> - Philip
> 

-- 
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

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

---

From: Philip Matthews <[email-masked]>
Date: Sat, 8 Jul 2006 11:00:20 -0400

Thanks for the complement. It did take a bit of thinking to come up with
this example. The main question we asked
I suspect there is a simpler example that also shows up this problem
-- perhaps a situation with a multi-homed user agent.

Regarding the issue of hairpinning. You are correct that if NAT N  
supported
hairpinning, then a different path would be discovered. This would still
not be optimal, but it would be better than the TURN server path.

We deliberately stated that NAT N did not support hairpinning because  
that
shows up a DIFFERENT problem -- namely that the optimal path would never
get discovered because the re-offer happens too soon. In other words,
in some cases, low-priority paths can lead to the discovery of peer- 
reflexive
candidates which lead to the discovery of high-priority paths, so  
killing off
low-priority checks using timer Tws may be a bad idea.
(We didn't say this in our original e-mail because we are still  
investigating
this issue and it just obscured the main point -- namely the need to  
pair
peer-reflexive candidates with more than one remote candidate).

- Philip

On 7-Jul-06, at 16:23 , Jonathan Rosenberg wrote:

> Its worth noting as well that an optimal path would have been used  
> if the nat supported hairpinning. Consequently, as behave compliant  
> nats get deployed this use case goes away.
>
> addresses with all others. As you point out, this will add even  
> more checks to an already busy check process. Worse still, I think  
> its a non-trivial jump in complexity for a protocol which is  
> already pretty complicated.
>
> Consequently, I'm inclined to leave well-enough alone and not try  
> to optimize this case.
>
> Thanks,
> Jonathan R.
>
>
>
> Philip Matthews wrote:
>

---

From: Philip Matthews <[email-masked]>
Date: Sat, 8 Jul 2006 11:43:21 -0400

The discussion on a different thread about the ordering rules in ICE
caused Eric and I to look again at the detailed example we worked out
about the peer-reflexive pairing problem.

In the process, we discovered that we got the ordering of the  
candidate pairs wrong.

Luckily, correcting this error didn't invalidate the example. It just  
causes the
checks to be done in a slightly different order.

We have posted a corrected version of the example at
    www.magma.ca/~philip_matthews

It should be noted that the detailed message flow in this example is  
worked using
the check rules of ICE-08 (which was the current version at the time  
the example
was originally done). ICE-09 suppresses some of these checks, so that  
the actual
message flow under ICE-09 will be slightly different, but the basic  
pattern is still
the same, and the problem still exists.

- Philip