Subject: [MMUSIC] Comments on ICE-15

From: Philip Matthews <[email-masked]>
Date: Fri, 20 Apr 2007 11:02:12 -0400

Here are some comments on ICE-15.

*) When there are multiple check lists, there is nothing that  
requires that the various check timers
     be spaced out. As it currently stands, all the check timers  
could expire at the same time.
     I suggest creating just one check timer, and serve round-robin- 
ing between the check lists.

*) I think the document needs to be more explicit about how the  
transport addresses of an
     incoming binding request gets matched to a candidate pair. There  
is text scattered through
    sections 7.2.1.3, and .4 and .5 which is vague and confusing.  
Moreover, it doesn't make the
    point that none of this can be done until the offerer receives  
the answer.
     I think a new section needs to be inserted between sections  
7.2.1.2 and 7.2.1.3.
     This section would say roughly
     - The processing at this point pauses until an answer is  
received from the far end.
        Then once un-paused ...
     - The destination transport address is matched to a local
        candidate using the local UFRAG in the received binding request.
     - The source transport address is matched to a remote candidate  
using the remote UFRAG.
        If there is no such candidate, a new peer-reflexive candidate  
is created.
    This would replace the vague text in the next few sections that  
talk about determining the
    candidate pair and the remote password, etc.

*) The text says:
               o  If there is at least one nominated pair in the  
valid list for a
                  media stream and the state of the check list is  
Running:
                      *  The agent MUST remove all Waiting and Frozen  
pairs in the check
                         list for the same component as the nominated  
pairs for that
                         media stream
    Do we remove ALL checks, or just checks of lower priority? In  
aggressive nomination mode,
    the latter seems to be the better choice, since it gives the  
chance for higher priority checks
    to find a better path, which seems to be in the spirit of  
aggressive nomination.

*) Not long afterwards it says:
              o  Once there is at least one nominated pair in the  
valid list for
                 every component of at least one media stream and the  
state of the
                 check list is Running:
                      *  The agent MUST change the state of  
processing for its check
                         list for that media stream to Completed.
     What about checks that are currently "in-progress"? Do these  
continue to run?
     It seems in keeping with "aggressive nomination" to have them  
continue, but
     it seems weird to consider the check list to be "Completed" (and  
even weirder
     to think of ICE as being "Completed", which is what happens if  
this is the only
     check list).

*) Most of the presentation in the document assumes a single offerer  
and single answerer.
     However, we know that SIP supports forking, and thus ICE must  
support an offer being
     delivered to multiple answerers, and there are occasional hints  
about this in the document.
     It would be nice if this was clearly stated early on. I am  
worried that we have not paid
     enough attention to this case.

- Philip

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 16:45:51 -0400

Thanks for the comments. Responses inline.

Philip Matthews wrote:

> *) When there are multiple check lists, there is nothing that  requires 
> that the various check timers
>     be spaced out. As it currently stands, all the check timers  could 
> expire at the same time.
>     I suggest creating just one check timer, and serve round-robin- ing 
> between the check lists.

I don't want to require that; the reason is that in distributed systems 
where the audio, video and call control pieces are in different 
boxes/agents, this kind of tight coordination of timers is hard. I'd 
rather say that,"care should be taken to roughly space out these 
timers". In a single box solution, you could round-robin, randomize or 
whatever. In a distributed system it'd probably be more or less 
randomized anyway.

>     incoming binding request gets matched to a candidate pair. There  is 
> text scattered through
>    point that none of this can be done until the offerer receives  the 
> answer.

Actually, 7.2 is quite explicit about this. It says:

It is possible (and in fact
    very likely) that an offeror will receive a Binding Request prior to
    receiving the answer from its peer.  If this happens, the agent MUST
    generate a response (including computation of the mapped address as
    described in Section 7.2.1.2.  Once the answer is received, it MUST
    proceed with the remaining steps required, namely Section 7.2.1.3,

Rosenberg              Expires September 27, 2007              [Page 43]

Internet-Draft                     ICE                        March 2007

    Section 7.2.1.4, and Section 7.2.1.5 for full implementations.  In
    cases where multiple STUN requests are received before the answer,
    this may cause several triggered notifications to all be sent at the
    same time,

>     I think a new section needs to be inserted between sections  7.2.1.2 
> and 7.2.1.3.
>     - The processing at this point pauses until an answer is  received 
> from the far end.
>        Then once un-paused ...

No - matching is always done based on IP/port. Never on ufrags. THose 
will typically be the same for all candidates.

>        If there is no such candidate, a new peer-reflexive candidate  is 
> created.
>    This would replace the vague text in the next few sections that  talk 
> about determining the

None of the text seems vague to me. Can you please point to specific 
places where you find it unclear?

> 
> *) The text says:
>               o  If there is at least one nominated pair in the  valid 
> list for a
>                  media stream and the state of the check list is  Running:
>    the latter seems to be the better choice, since it gives the  chance 
> for higher priority checks
>    to find a better path, which seems to be in the spirit of  aggressive 
> nomination.

THe text talks about removing *WAITING* and *FROZEN* checks. This, by 
definition, are not checks that have not yet begun. This means that, you 
don't need to wait for them to complete. They never started.

>              o  Once there is at least one nominated pair in the  valid 
> list for
>                      *  The agent MUST change the state of  processing 
> for its check
>     to think of ICE as being "Completed", which is what happens if  this 
> is the only
>     check list).

THe previous bullet list would also apply; these top level if statements 
are not if..else; they are just if(). I'll clarify that. WHat it means 
is that you will stop transmissions on lower priority in progress 
checks. It is a bit misleading to claim ICE is completed; though it will 
be definitively true for regular nomination. For aggressive; there is a 
race here that you might flip selected pairs a couple of times while 
stabilizing. However you cannot tell which mode an entity is in and so 
there is no way to add another state. Anyway the desired behavior is 
right as currently specified.

>     It would be nice if this was clearly stated early on. I am  worried 
> that we have not paid

I added a paragraph in section 6, mentioned that you'll proceed with 
each offer/answer pair independently:

<t>
When ICE is used with SIP, forking may result in a single offer
generating a multiplicity of answers. In that each, ICE proceeds
completely in parallel and independently for each answer, treating the
combination of its offer and each answer as an independent
offer/answer exchange, with its own set of pairs, check lists, states,
and so on. The only case in which processing of one pair impacts
another is freeing of candidates, discussed below in <xref 
target="sec-XXX"/>.
</t>

The only interaction I'm aware of across branches is freeing of turn or 
stun candidates. THis is because everywhere in ICE talks about 
operations on PAIRS and not on individual candidates, except there. But 
if you see something please advise.

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: Philip Matthews <[email-masked]>
Date: Fri, 27 Apr 2007 14:35:49 -0400

On 26-Apr-07, at 16:45 , Jonathan Rosenberg wrote:

>>     I suggest creating just one check timer, and serve round- 
>> robin- ing between the check lists.
>
> I don't want to require that; the reason is that in distributed  
> systems where the audio, video and call control pieces are in  
> different boxes/agents, this kind of tight coordination of timers  
> is hard. I'd rather say that,"care should be taken to roughly space  
> out these timers". In a single box solution, you could round-robin,  
> randomize or whatever. In a distributed system it'd probably be  
> more or less randomized anyway.

I am OK with saying "care should be taken to roughly space out these  
timers".

>>     incoming binding request gets matched to a candidate pair.  
>> There  is text scattered through
> No - matching is always done based on IP/port. Never on ufrags.  
> THose will typically be the same for all candidates.

To be more precise, this is what I think happens:
a) Using the local UFRAG in the received binding request, locate the  
set of candidates with that UFRAG. These candidates will all be  
associated with the same offer.
b) With the IP and port in the received binding request, select the  
subset of (a) that has this address and port as its base.
The result will be a set of candidates that all share the same ufrag  
and base, and thus share the same password. These candidates will all  
have been sent is the same offer and be associated with a single  
media stream.
Use this tuple (local base, local ufrag, local password) in sections  
7.2.1.3, 7.2.1.4, and 7.2.1.5.

>>     - The source transport address is matched to a remote  
>> candidate  using the remote UFRAG.
>>        If there is no such candidate, a new peer-reflexive  
>> candidate  is created.
>>    This would replace the vague text in the next few sections  
>> that  talk about determining the
> None of the text seems vague to me. Can you please point to  
> specific places where you find it unclear?

My concern was over the text in section 7.2.1.4 that read:

    If a triggered check is to be generated, it is constructed and
    processed as described in Section 7.1.1.  These procedures require
    the agent to know the transport address, username fragment and
    password for the peer.  The username fragment for the remote
    candidate is equal to the part after the colon of the USERNAME in  
the
    Binding Request that was just received.  Using that username
    fragment, the agent can check the SDP messages received from its  
peer
    (there may be more than one in cases of forking), and find this
    username fragment.  The corresponding password is then  
selected.  ...

I was thinking that this section could be replaced with: use the  
ufrag, password, and base determined above.

>>                      *  The agent MUST remove all Waiting and  
>> Frozen  pairs in the check
>>                         list for the same component as the  
>> nominated  pairs for that
>>                         media stream
> THe text talks about removing *WAITING* and *FROZEN* checks. This,  
> by definition, are not checks that have not yet begun. This means  
> that, you don't need to wait for them to complete. They never started.

This is a topic we have discussed before. Due to triggered checks and  
other things, with Aggressive Nomination, lower-priority checks can  
complete before higher priority checks even start. So the question  
is: Do we try to improve the quality of the path found by Aggressive  
Nomination by allowing these higher-priority checks to run, or is  
Aggressive Nomination totally optimized towards finishing as fast as  
possible?

With Regular Nomination, which is more focused on path quality, these  
higher-priority checks WILL be allowed to run, and thus a higher- 
quality path will be found it it exists.

- Philip