Subject: RE: [MMUSIC] Q about ICE redraft

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

Many thanks for taking the time to respond. The information was very
helpful.

Simon

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: 25 July 2006 16:48
To: Hughes, Simon (Simon)
Cc: [email-masked]
Subject: Re: [MMUSIC] Q about ICE redraft

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:

> 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

-- 
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