Subject: [MMUSIC] Q about ICE redraft

From: "Hughes, Simon \(Simon\)" <[email-masked]>
Date: Tue, 25 Jul 2006 13:46:56 +0100

Hi

I did not attend the recent IETF Montreal meeting but I've heard that
there is to be a significant rewrite of draft-ietf-mmusic-ice-09.txt.
Would it be possible for somebody to list the important areas where
revisions are to take place ? 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Jul 2006 11:48:24 -0400

Sure.

Firstly, you can find slides at:
http://www3.ietf.org/proceedings/06jul/slides/mmusic-1.pdf
which describe this.

The essential problem is that I have gotten a bunch of solid feedback 
that ICE is just too complicated. The intro helped, but the algorithms 
are sufficiently complex at this point that it is threatening interop.

So, the idea was to make a few major changes:

1. when an agent receives a stun request with a source IP/port which 
doesn't match the candidate, ice-09 has the agent do one of two things. 
If the address/port is totally new, the agent creates a new peer derived 
candidate. If it matches a different IP/port, it feeds a state update 
into that candidate pair. In both cases, the actual pair on which the 
request was received is invalidated. Instead of doing all of this, the 
idea is to simply update the remote IP address/port of the pair on which 
the request was received. This has the same net result as the existing 
ice-09 algorithm but is way simpler to specify. It was reassuring to 
hear from Tim Moore that this is how his implementation actually behaves.

2. the draft has a lot of confusion around transport address pairs vs. 
candidate pairs. I'm going to ditch what is current called candidate 
pair, and change the name of what is currently called transport address 
pair to candidate pair, and structure everything around that. This 
should boot out a bunch of terminology and complexity.

3. I think I can further unify tcp and udp processing

The first of these three is the real big one. That should eliminate the 
entire section on peer derived candidates, how you compute and link 
them, computing these derived candidate IDs, and so on. It will also 
simplify the state machine, removing this whole miss/match bit that was 
recently added in.

Now, the tradeoff that the group has to make is this.

Philip has described, in his mail to the group here:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg04314.html

that there is a case where a peer-derived candidate would need to be 
paired with a different candidate from the one from which it was 
derived. With the simplification I propose, such a pairing could only be 
done via an explicit re-invite. I have argued that the simplification is 
worth the additional latency cost of a re-invite for covering what looks 
like a corner case. I think there was general consensus in the group 
that this tradeoff (simplifying the algorithm at the expense of 
requiring a re-invite in this corner case), was worth it.

HTH,
Jonathan R.

Hughes, Simon (Simon) wrote:

> ------------------------------------------------------------------------
> 

-- 
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 25 Jul 2006 18:20:22 +0200

Hi Jonathan,
 
Was there any outcome on the SBC case (slide #7) issue?
 
I guess case 2 is the one which has caused most discussions.
 
Regards,
 
Christer

________________________________

Lähettäjä: Jonathan Rosenberg [mailto:[email-masked]]
Lähetetty: ti 25.7.2006 17:48
Vastaanottaja: Hughes, Simon (Simon)
Kopio: [email-masked]
Aihe: Re: [MMUSIC] Q about ICE redraft

Sure.

HTH,
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 <http://www.jdrosen.net/>                          PHONE: (973) 952-5000
http://www.cisco.com <http://www.cisco.com/>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jul 2006 00:14:10 -0400

Yes. The conclusion was to basically treat the lack of a candidate for 
the m/c-line as if the peer doesn't support ICE and fallback to just 
using the addres on the m/c-line.

-Jonathan R.