Subject: Re: [MMUSIC] Comments on ICE version 06

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Mar 2006 14:41:34 -0500

inline.

zuo bf wrote:

> Hi,
>   First thanks for the great work. Then i'd like to give out the points 
> at which i am not clear.
> 
> 1. Should all components in a candidate are in the same realm or are 
> derived using a same way ?

Not sure what you mean by 'realm' here. All components in a candidate 
are derived in the same way, yes. That is, they are all with stun, or 
turn, or local.

> And Does the derived transport address need to compare with every 
> available transport addresses ?
> 
>  From the draft and example you give, i think you mean it's same, but I 
> got confused here. In page14,
> there is no explicit require for that, and the candidate comparison just 
> compare transport address with
> transport address in another candidate, there is the point, as we 
> compare candidate in this way, why
> the process for getting a peer-derived candidate different, in that 
> process we restrict that the derived address
> doesn't equal any available transport addresses (even they have 
> different component id), but isn't there a
> chance that two candidate have partial same transport addresses ? 
> Consider the scenario below :
> (This is a strange scenario, but i think it could be used for demo)
>                                Phy1
> |--------- | R1 |--------------------------------| R2 |
> |          --------                                -------
> |             |                                       |
> |          -------                                 -------
> |          | H1 |                                | H2 |
> |          -------                                 -------
> |             |                                       |
> |          -------                                 -------
> |----------| R3 |--------------------------------| R4 |
>            -------           Phy2              -------
> H1 and H2 are both in two realms, and a candidate comprised of two realm 
> address may pass the STUN connection
> check, and even more there could a route H1-->R1--->R3----->R4----->H2,  
> and if this route is better than the H1--->R1-->
> R2--->H2 one, and better than the H1--->R3--->R4---->H2 because of some 
> factor like bandwith, then the desired candidate
> can be comprised of two realm addresses, in that situation there is a 
> chance of collision with the peer derive procedure:
> More clearly, assume Phy1 is an IPv4 network, Phy2 is an IPv6 network, 
> H1 and H2 are dual stack clients but not capable of
> conversion between IPv4 and IPv6. So the initial candidate list before 
> any peer-derived one added could be:
> candidate1: H1_IPv4_transport_addr_1 H1_IPv6_transport_addr_2
> candidate2: H1_IPv4_transport_addr_1 H1_IPv4_transport_addr_2
> candidate3: H1_IPv6_transport_addr_1 H1_IPv6_transport_addr_2
> We know routes H1-->R1--->R3----->R4----->H2 and H1--->R3--->R4---->H2 
> are good for the two component respectively, so we want a
> derived candidate4:R3_IPv6_transport_addr_1 H1_IPv6_transport_addr_2, 
> but because H1_IPv6_transport_addr_2 already exists
> in several candidates,  and this address can't trigger the add action 
> for it to be added to the newly created candidate.

The draft does not consider this case. A candidate is meant to be 
homogeneous in its usage of a transport address between components. The 
idea is that components are tightly coupled things and you WANT them to 
go the same way. Older drafts had them more decoupled and we ended up 
with topologies like you describe, and it was considered a bug. If you 
look at RTP and RTCP, which is the main thing we are all worrying about, 
  since RTCP is used to measure RTT for the RTP packets, it needs to 
take the same path to be useful.

> 
> 2. De-allocation of resources
> 
> This is just a riminder, in page 39 there is
> 
>    5.  If the removed candidate was a TURN-derived candidate, the agent
>        SHOULD de-allocate its transport addresses from the TURN server.
> 
> 
> But because there is a possibility of proxy forking, so an offer/answer exchange
> within a single dialog doesn't mean that the TURN-derived candidate won't be used
> by other early dialogs or so.

Right. Good point. I have clarified this in the -07.

> 
> 3. When receive an update offer, why not trust the other agent ?

I dont understand what you mean here.

> 
> 
> Also page 39, Receiving the Offer and Sending an Answer
> 
> Why not choose the a=remote-candidate directly, unless the offer is not sent for
> just promoting one candidate to active, otherwise the pair that the offer indicate
> 
> through m/c line and a=remote-candidate Should be the most desired one, and because of the
> peer-derive process when there's symmetric NAT exist, the undesirable candidate pair could
> be valid ahead of the the desired one in the answer side, does that mean the answer should
> 
> use that candidate only because it hasn't received the response for the desired pair's request,
> but isn't there a 100% chance for that response to come ?

There is not a 100% chance, since nothing is 100% in todays Internet ;)

But, the idea is that the answer HAS received a packet from the offerer 
- the initial BindingRequest which caused the discovery of the new 
peer-derived address. The response that will come later will get through 
as long as the NAT is not treating UDP packets with the same 5-tuples 
differently based on the fact that one is a stun request, the other, a 
response.

The -07 draft explains the race condition this is solving more clearly. 
Its actually an extremely unlikely case, but we need to be covered.

> 
> 4. Role of offerer and answerer ?
> 
> In page 33, there is:
> 
> 
>    Recall that, for each candidate pair, one agent plays the role of
>    offerer, and the other of answerer.  For peer-derived candidates, the
>    agent that receives the STUN request and follows the processing in
> 
>    this section acts as the answerer.
> 
> If the derived pair is the desired one, and the offerer and answerer role is
> reversed, which one should send the updated offer ?

According to -06, if A sends an offer to B, and then B sends a stun 
request to A, and the response shows B a new address, that would make A 
the answerer and B the offer. Thats really ugly, since it reverses the 
roles as you point out. Worse yet, I discovered that this breaks the 
early media approach we agreed on last ietf. So, I changed this in -07. 
Now, the role of the peer-derived candidate is inherited from its 
generating candidate. Thats much easier and more consistent all around. 
It never causes role reversals.

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

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