[MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip-00

[Eric Rescorla <ekr at networkresonance.com>]

Jonathan,


I just finished reading draft-rosenberg-mmusic-ice-nonsip-00. Comments
below.


GENERAL COMMENTS
While I think that a generic version of ICE is a good idea, I'm not
really that enamored with two of the high-level choices you've made,
namely, to subset ICE and to define a specific encoding for the
parameters. I'll take these in turn.
 
1. Subsetting ICE
If I'm a guy who has an ICE stack, the last thing I want to
do is to have *two* ICE stacks. So, everywhere you say stuff
like:

   In addition, the rules in Section
   4.1.1.3 MUST be ignored; instead, each candidate MUST have a unique
   foundation, assigned arbitrarily by the client.

or:

   o  ICE defines an algorithm called the Frozen algorithm.  This
      algorithm exists to speed up completion of ICE in cases where
      multiple candidates share similar properties.  For example, when
      an audio and video candidate are on the same host IP address.
      Since NICE only supports a single candidate and a single
      component, the use cases for the Frozen algorithm diminish
      significantly.  Furthermore, the Frozen algorithm is entirely
      about speed and is not as much an issue for more general non-real
      tiem protocols .  Thus, this algorithm is not used by NICE.  It
      falls out by using the algorithm defined in ICE, but by setting
      each foundation to a unique value.

I get serious heartburn. 

Current ICE was designed to handle a bunch of complicated cases,
but it's quite capable of handling the simple cases as well,
simply by restricting the environment it operates in 
(e.g., only one media stream). So, you shouldn't be telling
us stuff here that contradicts things in ICE.

Now, it may well be true that in these restricted environments
you can get away with not implementing specific pieces of 
ICE, or implementing simpler versions of the algorithm,
but those are implementation hints and should be relegated to
some non-normative appendix for people who are only implementing
NICE (though I must say I have no idea why you would want
to encourage that).

Instead of describing this as a subset, I would describe this as
a restricted set of *inputs* to ICE, which has the result that
only some of the full ICE functionality is exercised, but that
your full ICE stack works fine with those inputs.


2. Specific Encoding
I don't see the value of providing a specific encoding for
the NICE parameters. Every protocol that uses ICE is going
to have its own encoding style. Why should they have to
shove in some RFC-822 parser just because that's what you
like? Far better to describe the abstract data that needs
to be transmitted.



TECHNICAL COMMENTS
S 4.
I'm not sure why it's a good idea to only allow one stream.
Here and later you seem to be assuming that real-time = SIP,
but why should that be true?

S 11.
Maybe I'm missing something, but I don't see why regular
nomination is required here. In what case does Aggressive
lead to inconsistencies?

-Ekr










_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic