Subject: [MMUSIC] Comments on draft-roach-mmusic-pof-pan-02

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2014 18:40:39 -0500

I was asked to re-review pof-pan. Here are my current thoughts about 
this draft. I'm only focusing on fundamentals here - I think it is 
premature to worry about nits at this stage.

My overall feeling about this is that it introduces a lot of new 
machinery. The primary motivation for all of this is to avoid glare and 
hence the need to carry out the glare backoff/retry mechanism of 3261 
that can be slow. (Minimum time before starting to retry is a random 
value between zero and two seconds. So in some cases it may be necessary 
to suffer a two second delay!)

So a fundamental question is whether the gain justifies all the added 
machinery. (Especially since the machinery doesn't avoid glare in all 
cases. The glare algorithms still must be implemented and used.)

* A radical alternative:

Rather than figuring out how to negotiate individual streams in order to 
minimize the occurrence of glare, I wonder if it might be better to work 
on optimizing glare handling so that it can be handled more quickly.

Having said that, here are some comments on the draft as it is:

* Section 3 says:

    ... (3) all partial
    offers and partial answers are sent using a technique that guarantees
    in-order and reliable delivery.

I'm concerned that this requirement is a radical departure for O/A, and 
will severely limit applicability.

Then:

    If the new stream needs to be added to an existing group, it does so
    by using the "a=in-group" attribute defined in
    [I-D.roach-mmusic-groupid], indicating the ID of a group that has
    already been established within the session.  If the new stream needs
    to be added to a new group, then such a group may be created by
    adding an "a=in-group" attribute that contains a group ID that is not
    yet present in the session.  In both cases, the session-level
    membership of the group is semantically updated to reflect the new
    member of the group (and, if necessary, the creation of a new group).

A couple of issues with the above:

- when adding to an existing bundle group, there is no specification
   of where the new mid is added in the mid list. I suppose the
   intent is that they be added to the end. Maybe it doesn't matter
   as long as all grouped m-lines are required to have the same address.

- when creating a new group, I see no guarantee that both sides won't
   choose the same new group ID. What happens then is unclear.

* Section 3.2 says:

    If the recipient of a partial offer that contains an existing MID has
    also sent a partial offer to change that exact same stream, and
    neither the received nor the sent partial offer contains a port
    number of zero, then a legitimate glare condition has arisen.  Normal
    glare recovery procedures -- e.g., using a tie-breaker token or a
    back-off timer -- must be engaged to resolve the conflict.

Is the intent to fall back to a full O/A? Or is it to define glare 
handling using pof/pan?

If the intent is a full O/A, then how does that occur? Both sides will 
detect this same condition. If they each immediately try to send an 
offer, there is a high likelihood of glare on the full O/A too. But now 
the cost is higher than if the initial attempt had been a full offer. 
One possibility is that both sides should behave as if the glare had 
just occurred on a full O/A, so that the glare retry algorithm is 
started immediately.

* Section 5.2:

The following is in this section:

    ... Finally, the implementation
    evaluates whether the changes it needs to make can be performed
    exclusively using the values present in a media section, without any
    modifications necessary to session-level values (except for the sess-
    version value on the session-level o= line).

This fails to call out an exception for use of a=group... for which you 
have a special mechanism. (This is sort of a nit.)

* Section 5.5:

This procedure makes me very uncomfortable. While I'm not *sure* there 
is a problem, it feels like there can be. some concerns that come to 
mind are:

- if more than one partial offer is quarantined, ISTM that the order 
they are brought out of quarantine will impact the order of mids in the 
full SDP. Will it be deterministic on both sides?

- for that matter, even when not quarantined, isn't there still a 
problem this way?

- what if some a partial offer has changes or removals, and also has 
additions. Are the changes an removals processed immediately and only 
the additions quarantined? Or is the whole partial offer quarantined? 
(Seems like it could make a difference.)

In general this mechanism seems "fragile".

	Thanks,
	Paul