Subject: [MMUSIC] ICE 15: Triggered check clarification

From: Benny Prijono <[email-masked]>
Date: Tue, 03 Apr 2007 18:44:31 +0100

Hi,

I'd like to propose clarification for triggered check. Please see
Section 7.2.1.4.  Triggered Checks for reference.

Background 1)

"
  Next, the agent constructs a pair whose local candidate is equal to
  the transport address on which the STUN request was received, and
  ..
"

A typical application doesn't normally have access on the
destination address of an incoming packet (it only has access to
source address), so in the situation where a base address is 
associated with more than one candidates (for example, host and 
server reflexive), it wouldn't be possible to find which local 
candidate to choose.

Background 2)

"
  This pair is then looked up in the check list.  There can be one of
  several outcomes:
  o  If the pair is not already on the check list:

     *  The pair is inserted into the check list based on its
        priority
"

A pair might not be found in the checklist because it might have
been pruned, so inserting a new pair here might just add an
unnecessary check.

I propose to clarify the local candidate finding process when 
handling triggered check by modifying the text to something like this:

"
Next, the agent constructs a pair of a local candidate and a
remote candidate which address is equal to the source transport
address where the request came from (which may be peer-reflexive
remote candidate that was just learned).  The local candidate
is selected by searching in the checklist, starting from the
highest priority, for a local candidate which base address is
equal to the transport address where the request is received.
"

Comments?

  -benny

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Apr 2007 08:15:20 -0400

inline.

Benny Prijono wrote:

> source address), so in the situation where a base address is associated 
> with more than one candidates (for example, host and server reflexive), 
> it wouldn't be possible to find which local candidate to choose.

Sure, though it would know the IP address and port of the local socket 
when it had initially bound to it. So you wouldn't need to make this 
determination dynamically when a packet is received.

> been pruned, so inserting a new pair here might just add an

It would not have been pruned. The pruning will remove pairs whose local 
candidates have the same base. THis is done by replacing the local 
candidate with its base and then removing redundancies. THis means that 
every pair in the check list has a local candidate that is either host 
or relayed - never server reflexive. For triggerered checks, the local 
candidate will always be host or relayed, and so it will never have been 
one that was pruned.

> 
> I propose to clarify the local candidate finding process when handling 
> triggered check by modifying the text to something like this:
> 
> 
> "

I disagree with this change, per above.

-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: Benny Prijono <[email-masked]>
Date: Thu, 05 Apr 2007 14:04:10 +0100

Thanks for the reply, Jonathan. Please see my comments inline.

Jonathan Rosenberg wrote:
>> associated with more than one candidates (for example, host and server 
>> reflexive), it wouldn't be possible to find which local candidate to 
>> choose.
> 

Yeah, I just realized this. Basically I've got my implementation 
"wrong" and I create one socket for one component instead of one per 
candidate, that's why I couldn't figure out which candidate to 
choose when an incoming request arrives.

I said "wrong", because I think I can make my implementation work 
too. Let me argue about this on another thread.

> candidate will always be host or relayed, and so it will never have been 

I disagree that local checklist can never have (local) server 
reflexive candidate. In my implementation, if STUN is configured in 
the agent, I put server reflexive candidate type preference to have 
larger value then host candidate type, so it will appear first in 
the checklist than the host. Because of this, it's the checks with 
local host candidates that will be pruned.

The reason why I put srflx type with higher preference value is for 
optimization reason. If STUN is configured, then most likely the 
agent will communicate with other agent over Internet, so server 
reflexive candidate will likely to be used. Putting srflx with 
higher type on this case will make ICE complete faster.

But anyway this is not related to the original question. The current 
text is fine.

thanks,
  -benny

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Apr 2007 09:25:14 -0400

inline.

Benny Prijono wrote:

>> It would not have been pruned. The pruning will remove pairs whose 
>> local candidates have the same base. THis is done by replacing the 
>> local candidate with its base and then removing redundancies. THis 
>> means that every pair in the check list has a local candidate that is 
>> either host or relayed - never server reflexive. For triggerered 
>> checks, the local candidate will always be host or relayed, and so it 
>> will never have been one that was pruned.
> 
> 
> I disagree that local checklist can never have (local) server reflexive 
> candidate. In my implementation, if STUN is configured in the agent, I 
> put server reflexive candidate type preference to have larger value then 
> host candidate type, so it will appear first in the checklist than the 
> host. Because of this, it's the checks with local host candidates that 
> will be pruned.

Sure, but the check lists always have the local candidate replaced with 
its base. So if it was server reflexive, it would be replaced by its 
corresponding host candidate. So, irregardless of priority, there is 
NEVER a check on the check list whose local candidate is server reflexive.

-Jonathan R.

---

From: Benny Prijono <[email-masked]>
Date: Thu, 05 Apr 2007 15:42:35 +0100

> NEVER a check on the check list whose local candidate is server reflexive.

Ah right, it seems that I misunderstood this phrase in 5.7.5 Pruning 
the Pairs:

   For each pair where the local candidate is server reflexive, the
   server reflexive candidate MUST be replaced by its base.

Silly as it is, I thought base means the base address, not the host 
candidate representing this base address. Never mind, my mistake.

Thanks,
  -benny