Subject: Re: [MMUSIC] ICE-15 WGLC Comments

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2007 15:36:45 -0400

Thanks for the comments. Responses inline.

Kevin Johns wrote:

> Jonathan,
>  
> Please find my comments on ICE-15 below for your consideration. I tried 
> to avoid nit picking, hopefully I was successful. I did not include any 
> editorial issues I found (spaces in the middle of words, missing closing 
> parenthesis, etc.) as I figure those will be caught by the editor before 
> publication. If you want them I will gladly forward.
>  
> Let me know if you have any questions.
>  
> Kevin
>  
>  
> 
> Section 2.4 (Frozen Candidate)
> 
> 1^st paragraph, 1^st sentence at the end of the parenthetical statement 
> – 'each of which has to work for the media stream as a whole to be work' 
> I think 'be' should be deleted

fixed

> 
>  
> 
> Section 4.2 (Lite Implementation)
> 
> Per my previous email this section is unclear as to whether a lite 
> implementation can include multiple candidates. Given my understanding 
> that it cannot, I think removing the first sentence of the last 
> paragraph would help clarify the section.

This is now allowed per list discussion.

> 
>  
> 
> Section 5.7.2 Computing Pair Priority and Ordering Pairs
> 
> The formula ends with (O>A?1:0) but the text after the formula defines 
> it as (O-P>A-P?1:0). The formula should probably be updated to align 
> with the textual description.

Bug, fixed.

> 
>  
> 
> Also, given the procedures in section 5.8 (performing periodic checks) 
> rely on the pair priority to determine the next pair to unfreeze are we 
> sure that the pair priority will results in pairs with the lower 
> component ID being checked first? Meaning if we have two component IDs 
> we want to check all the pairs for component ID 1 first before starting 
> any checks for component ID 2 pairs in order to get the optimizations 
> ICE provides by using the info learned from component ID 1 to quickly 
> find the best valid pair for component ID 2.

If you follow this formula:

priority = (2^24)*(type preference) +
            (2^8)*(local preference) +
            (2^0)*(256 - component ID)

then definitely yes.

The frozen algorithm also has a 'fallback' in cases where somehow we 
didn't unfreeze something. If there are pairs in the check list that are 
Frozen but none are Waiting, we take the highest priority Frozen 
candidate and use it.

> 
>  
> 
> Section 5.7.4 (computing states)
> 
> 2^nd paragraph after step 2 indicates there are two states but three are 
> actually defined (running, completed, and failed).

fixed

> 
>  
> 
> Sections 7.1.1.1 (PRIORITY and USE-CANDIDATE) and 7.1.1.2 
> (ICE-CONTROLLED AND ICE-CONTROLLING)
> 
> Both sections discuss the ICE defined STUN attributes. It would be 
> helpful to provide a reference back to their respective sections where 
> they are defined (18.5)

done

> 
>  
> 
> Section 8.1.1 (Regular Nomination)
> 
> The 2^nd paragraph discusses repeating the check with the USE-CANDIDATE 
> flag set. There is no discussion as to how the agent behaves if this 
> check is lost for some reason. While unlikely, it is possible that this 
> check could be lost in the network and would need to be retransmitted. 
> It might be worth while to provide some guidance on this scenario.

I think this can be left to implementation approach. If this happens 
something bad has happened that is uncrecoverable.

> 
>  
> 
> I read section 9.2.1.1 (detecting ICE restarts) and 9.2.2 (procedures 
> for full implementations) to be contradictory. 9.2.1.1 states that if 
> ICE is restarting for a media stream the agent MUST change the 
> a=ice-ufrag and a=ice-pwd attributes in the answer. However, 9.2.2 
> states the username fragments, password, and implementation level MUST 
> remain the same as previously. If an agent needs to change one of these 
> it MUST restart ICE for that media stream by generating an offer; ICE 
> cannot be restarted in an answer. I am I miss-reading these two 
> sub-sections?

Good catch. 9.2.2 is meaning to say that unless there is an ICE restart, 
you need to keep these the same. In other words, you can't cause a 
restart in an answer.

> 
>  
> 
> Section 12.1.1 (offer in INVITE)
> 
> The 2^nd paragraph discusses a mechanism for ensuring reliable delivery 
> of a response. However, if the target of the response is an ICE-lite 
> implementation it will never send a stun request and the agent is forced 
> to keep retransmitting its response needlessly. Would it make sense to 
> call this out, or let it be as it will resolve once the agent sends the 
> 200 OK?

Actually this is a really good point. I spent a lot of time thinking 
about this.

There are a few alternatives here:

1. let the retransmissions happen, possibly adjusting the retransmit 
count down in this case

2. allow ICE to proceed without actually even sending an answer in a 1xx 
- it is actually possible and would sometimes work (see below)

3. require PRACK everywhere

At first I was leaning towards #2. But there is another related issue 
which is that there are going to be middleboxes and firewalls that are 
expecting to see a 18x with SDP in order to open pinholes and even let 
the ICE checks complete themselves. We really want the 18x for their 
benefit.

SO I think the answer is #1, but adjusting the retransmit count down (to 
say, 4).

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