Subject: [MMUSIC] ICE-10 Issue #1: Unified or Separate Checks across Media Streams

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Sep 2006 16:22:36 -0400

In ICE-10, all of the checks that need to be made across all media 
streams are done through a single unified check list. Checks on this 
check list are paced at one very 50ms. This is in contrast to previous 
versions of ICE, which described checks as being done for each media 
stream separately, at a rate of one very N*50ms, where N is the number 
of streams.

There were several reasons for this change. Perhaps the biggest was this 
concept of "Frozen" states for checks. This optimization brings a big 
performance boost for multimedia sessions. The idea is to check the 
candidates for a single media stream *first*, and then once those 
succeed, check candidates of other media streams with the same 
foundation (foundation is a new term introduced in ICE-10; it refers to 
the combination of host interface from whcih a candidate was obtained, 
along with the IP address of its stun server, and its type. The idea is 
that if two candidates share the same foundation, if one works, the 
other is likely to work too).

The other reason I made this change was that it simplifies things, I 
thought.

However, it comes with several problems:

1. it doesn't allow accelerated pacing for high bandwidth media streams,
2. it requires us to introduce a limit on the number of streams in a 
session (10 in ICE-10)
3. it doesn't readily facilitate a distributed implementation with each 
media stream being terminated on a separate physical host
4. it requires more than 32 bits to store the priority for a candidate pair

So, the proposal is to basically change it back to the way it was 
before. A check list would be constructed for each media stream, and 
checks on that media stream would be paced at one every Ta*N, where N is 
the number of streams. There is a separate question about increasing 
this pacing, which I'll discuss in a separate mail.

The optimization I described (of using the results of a check on one 
media stream for another) can still be done. Its utility in this model 
of parallel pacing is limited unless you increase the pacing for each 
media stream, which is again a separate issue (though as a preview I 
will suggest that we do that).

Comments?

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 12:58:42 -0400

This open issue was discussed on the ICE call yesterday.

There wasn't a strong consensus on it. We discussed accelerated pacing 
at length (which I'll post on separately). There were some concerns 
raised with the accelerated pacing, which I'll post on in a separate note.

That said, I still suggest defining separate check lists for each media 
stream. This at least facilitates a distributed implementation. The 
Frozen/unfrozen algorithm would still apply as described in ice-10. Even 
though you have multiple check lists, one for each media stream, all of 
the checks on each check list but the first would be in the frozen 
state. They'd be unfrozen only when checks in the first list complete.

Comments?

-Jonathan R.