Re: [MMUSIC] Partial Offer/Partial Answer draft

[Paul Kyzivat <[e-mail]>]

On 10/17/13 12:28 PM, Adam Roach wrote:
> On 10/15/13 16:19, Paul Kyzivat wrote:
>> I believe it is valid to have multiple mid lines per media section.
>
> I don't think that's right. I'll admit that RFC5888 doesn't specifically
> talk about ordinality, but there is strong implication here that we're
> required to have a one-to-one relationship. Consider the language:
>
>     In a given
>     session description, each "m" line is identified by a token, which is
>     carried in a "mid" attribute below the "m" line.
>
> We're always talking about these things in the singular when referring
> to their use in a media section. If we need to make this constraint an
> explicit precondition for using partials, than I'm okay doing so -- but
> I don't think it's really a constraint above and beyond what's implied
> by RFC 5888 itself.

My thinking was that when grouping is being used for multiple purposes, 
each might use its own mid values.

The requirement that to use grouping at all every m-line must have a mid 
decreases the motivation to do that. And certainly a single mid is 
*sufficient*. But its hard to contemplate what all possible 
implementations might do.

Rather than *assuming* 5888 forbids multiple mids, or updating to to 
make that explicit, I think its easier to just say that you can't use 
partials if there are multiple mids for any m-line.

Even then, I don't think that 5888 requires that the mids in a 2nd offer 
must be the same, or in the same order, as in the prior offer. I don't 
think you depend on that, but it is worth keeping in mind.

>> Section 3.2:
>>
>> I don't understand the open issue. How do stream changes result in glare?
>
> I send you a partial offer to set a sendrecv stream to sendonly at the
> same time as you send me a partial offer to change that very same stream
> to inactive.

OK.

>> Section 5.2:
>>
>> The restriction to changing a *single* media section per partial offer
>> is intended? What is wrong with changing several media sections in the
>> same partial offer? (Other than increasing the possibility of glare.)
>
> That's the open issue from section 3.2. I just didn't tag it as open in
> both places -- I figured pointing it out the first time we talk about
> the issue would be enough.
>
> And, yes, it's all about glare. After all, the entire raison d'etre for
> this mechanism is glare minimization.

I guess this is just a question of whether you want to protect people 
from themselves, or give them enough rope to do good and bad things.

If multiple changes were *permitted*, then an application that wants to 
minimize the glare can restrict itself to one change per pof. Some other 
application, that has special knowledge about the usage may know that 
certain combinations of changes have low probability of glaring.

>> I'm bothered by the use of random values for the new mid values. (I
>> just hate *depending* on two random values being different.) Instead,
>> how about specifying that each end use a unique prefix. We can find
>> some method to select the prefix. E.g., userid + sessionid from the
>> o-line. (Forbid use of partial offers if those aren't unique.)
>
> Sure, we can consider alternate proposals for this. I'll point out that
> you're more likely to have a collision between {userid,sessionid} of two
> clients than you will from 202 bits of randomness (which is what is
> currently proposed). Consider that sessionid is (supposed to be) derived
> from a notion of the current time, so the chances of colliding are
> exceedingly high. Similarly, the userid for SDP is frequently a fixed
> string rather than some variable string.

Obviously some other value could be used. All we need is a unique 
designator for each end within the single session. Then all the mids can 
be derived from that. Each one doesn't need to be random.

For instance, we could call the offering end of the most recent O/A "O" 
and the answerer for that "A". And then each side could use that as a 
prefix for all new mids assigned by POFs from that side.

> Your misgivings aside, I'm pretty much in the camp that believes that
> math works, even the statistics and probability parts of it.

And I'm in the camp that never gambles.

Statistics says that even exceedingly low probability events *can* 
happen. Its ok to count on low probability events not happening if you 
are willing to accept the consequences when they do happen. Even if that 
is only expected to happen once in a trillion years, that doesn't mean 
you have to wait a trillion years for it to happen. It could be tomorrow.

> I'd be more interested in entering into a conversation about how many
> bits of randomness are acceptable. I'm pretty sure 202 is massive
> overkill. Version 4 UUIDs, for contrast, use 122 bits of randomness,
> which we would get with 20-character SDP tokens. Given their limited
> scope (just one session), we could probably get away with far less than
> this.
>
>> Section 5.3:
>>
>> I think you need to s/less than/less than or equal to/ in:
>>
>>    The agent then examines the o= line in the received partial offer.
>>    If the <sess-version> value is less than the most recently
>>    received full (non-partial) offer or answer, then the partial offer
>>    is stale and MUST be rejected.
>
> Sure. "Equal to" would only arise from a misimplemented peer, but I'm
> happy to just call it stale.

Oh. Duh. You are right. Leave as it is.

>> Steps 3 & 4:
>>
>> Deciding *when* to do this is tricky. I don't know exactly what you
>> have in mind. I do have an idea for a simpler way:
>>
>> For all partial updates following a particular O/A, order *all* the
>> added media sections by their mid value. A new O/A then freezes those
>> and starts over.
>
> That occurred to me, mostly because it allows for multiple partial
> offers to be in flight simultaneously in the same direction.
>
> What concerned me was the difficulty in dealing with such freezes
> between sending a full offer and receiving its corresponding full
> answer, since any glare that arises from that exchange requires
> unfreezing the lines, but only back to the point that was created after
> the (now second-) most recent offer/answer exchange.

I don't see the problem. After sending a full offer everything *is* 
frozen until the the answer is accepted or rejected. That's true without 
POF/PAN.

Or do you mean that you are accepting and queuing *pending* partial 
updates while waiting for the answer? But that doesn't seem like an 
issue either. Just defer assigning the mids until the POF is to be sent.

> I also didn't like the way it interacted internally with our own
> implementation, since we would have a pretty hard time re-ordering
> streams after we brought them up and running. It's not too painful to do
> this upon processing of an answer (particularly because we've already
> seen the other side's offer, and know where each line is going to end up).
>
> It's not impossible to fix, but it sure would be more complicated and
> bug-prone. I don't expect we're the only ones who would run into
> difficulty in this arena, especially since I know we share this part of
> our code with a major hardware vendor who is active in the WebRTC space.

I won't argue with this. But it does need to be traded off against the 
issue in the note. That seems to have similar problems.

	Thanks,
	Paul