Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jul 2013 09:51:20 +0000

Hi,

I do realize that the draft does not represent the complete glare solution.

Paul has raised some issues/questions, and I also have some. I'll leave the SDP low-level ones for now, and only raise a few high-level ones.

Q1: How essential part of the unified plan is having *A* working "partial o/a" solution? TECHNICALLY, the other parts of the unified plan do not depend on having a "partial o/a" solution, but I would like to know whether people (specially the draft authors) would be willing to move ahead with unified plan even if we would not manage to specify a working "partial o/a" solution.

Q2a: When sending a partial offer, the draft says that only the m= line explicitly signaled is affected. Note, however, that you will still signal information (e.g. the SDP version value, the group:BUNDLE attribute etc) which affect the whole SDP, and if you have multiple outstanding partial offers (for different m= lines) that can cause issues.

Q2b: In addition, when using BUNDLE, modifying an m= line might implicitly modify other m= lines, and there are rules (also indicated in the draft) mandating identical SDP attribute values etc. So, if you have multiple outstanding partial offers, you may end up with all kind of different "BUNDLE collisions".

Q3: If I send a partial offer, for a given m= line, can the answer only contain that given m= line? What if the partial offer causes other m= lines to be modified?

Regards,

Christer

Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Adam Roach
Lähetetty: 17. heinäkuuta 2013 20:08
Vastaanottaja: Paul Kyzivat
Kopio: [email-masked]
Aihe: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling

On 7/17/13 11:38, Paul Kyzivat wrote:
Adam,

While I see there can be some value to extending O/A to allow for smaller critical sections, I fear that it is going to be very messy to get "right". Some messy things:

- Glare between a partial O/A and a full O/A

...is glare. Resolve as normal. For SIP, that means timers.

- Is a partial O/A permitted in a sip reINVITE? Can you have
  an offerless reINVITE where the response contains a partial offer?
  Or can these only be done in UPDATE?

No, no, and no. In SIP, the protocol machinery would not allow INVITE or UPDATE to complete concurrently in opposite directions for any amount of overlap. We aren't proposing a change to SIP state machines here, only to the offer/answer model. This necessarily means that we need to carry partial offers and partial answers in something else -- probably INFO.

- In SIP, processing of concurrent reINVITEs/UPDATEs containing
  partial SDP updates. This seems to already be a

You left this unfinished, but I *think* it was going to make the same point I did in my response above.

- How to assign version numbers to the full SDP as a result
  of partial updates

Section 3.4.1: "... the SDP version is incremented by one..."

- I'm not sure your algorithm for resolving glare when adding
  streams works in all cases. (More below on this.)

These (and ones I haven't thought of) *may* all be resolvable. But this certainly complicates the already complex O/A process - maybe to the point that many get it wrong. (I don't want to write rfc6337bis!)

My concern with the glare resolution algorithm is that for it to work both sides must realize that glare occurred. And I think there are common sequences when one side won't realize it.

I'm not saying I didn't miss it, but I did work through as many permutations as I could think of, and none of them are left out by the algorithm described in section 3.4.1.

That said, I did my analysis in the context of WebRTC, and assumed a reliable, in-order delivery channel for messages. I recognize that we don't have that for SIP, and that messages in the same direction can be reordered. I admit that this does raise some interesting scenarios that may require additional work to resolve.

I'm reluctant to buy into a scheme that depends on this without knowing it it will be implementable.

I understand your reluctance, and don't want to gloss over it. This is but one plank in the overall plan, and it represents what we think is the best (but not only) solution to this specific requirement. If the issues prove intractable, we could fall back to an alternate scheme, such as the designated-offerer I describe in draft-roach-rtcweb-glareless-add-00, or the token-passing scheme described by Ted Hardie (cf. http://www.ietf.org/mail-archive/web/rtcweb/current/msg07361.html).

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Jul 2013 13:39:15 -0500

> I do realize that the draft does not represent the complete glare 

Right, and I think it would be premature to dig into those details for 
their own sake at the moment.  So, before we go into a discussion of 
what I believe are minutiea, we need to establish whether you're asking 
because it seems like an interesting problem to work on, or if you think 
that the approach has intractable flaws that would prevent developing it 
to completion. (To be clear, even though it's not phrased as a question, 
I would expect you to indicate which of those is the case, Christer).

In the former case, I'd like to defer the discussion around what I 
believe are addressable open issues in the high-level sketch, and 
instead focus on whether the overall "partial o/a" approach satisfies 
the needs of those parties for whom glare reduction is an important goal.

> *Q1*: How essential part of the unified plan is having **A** working 
> "partial o/a" solution? TECHNICALLY, the other parts of the unified 
> plan do not depend on having a "partial o/a" solution, but I would 
> like to know whether people (specially the draft authors) would be 
> willing to move ahead with unified plan even if we would not manage to 
> specify a working "partial o/a" solution.
>

Let's back up -- you're conflating mechanism with requirement here. The 
requirement is no glare in certain use cases (adding/removing streams). 
The proposed mechanism is partial o/a. The requirement is important to 
certain key participants in the working group, so I would characterize 
having a mechanism to address it as essential.

Keeping that in mind, "having a working 'partial o/a' solution," to 
re-use your phrasing, is utterly nonessential, since it is only one way 
to skin this cat. However, like I just said, having a working story for 
glare *is* essential. We've seen others (as I explained to my response 
to Paul, earlier), and may be able to come up with yet more.

> *Q2a*: When sending a partial offer, the draft says that only the m= 
> line explicitly signaled is affected. Note, however, that you will 
> still signal information (e.g. the SDP version value, the group:BUNDLE 
> attribute etc) which affect the whole SDP, and if you have multiple 
> outstanding partial offers (for different m= lines) that can cause issues.
>
> *Q2b*: In addition, when using BUNDLE, modifying an m= line might 
> implicitly modify other m= lines, and there are rules (also indicated 
> in the draft) mandating identical SDP attribute values etc. So, if you 
> have multiple outstanding partial offers, you may end up with all kind 
> of different "BUNDLE collisions".
>
> *Q3*: If I send a partial offer, for a given m= line, can the answer 
> only contain that given m= line? What if the partial offer causes 
> other m= lines to be modified?
>

These three points are, as far as I can discern, the natural engineers' 
curiosity that leads us to want to start working on fleshing out a 
solution as soon as we understand its skeleton. I don't think it's time 
for that. I have answers for these questions, but I'm 100% certain that 
providing them would start a highly distracting, if interesting, 
conversation that would delay our nailing down the other aspects of the 
unified plan.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2013 04:52:45 +0000

Hi,

> Right, and I think it would be premature to dig into those details for their own sake at the moment.  So, before we go into a discussion of what I believe are minutiea, we 
> need to establish whether you're asking because it seems like an interesting problem to work on, or if you think that the approach has intractable flaws that would prevent 
> developing it to completion. (To be clear, even though it's not phrased as a question, I would expect you to indicate which of those is the case, Christer).

I have always thought that one of the downsides with SDP O/A is the fact that you always need to include the information for all streams when you send an Offer or Answer. Now, when you have 1 or 2 streams that is not a big issue. But, in the rtcweb context people have been talking about a much bigger number of streams, so it may become an issue.

So, I definitely think it seems like an interesting problem to work on.

I do think that there are issues with 'partial O/A'. But, as we both have said, this is not the moment to go into detailed discussions about the mechanism :)

> In the former case, I'd like to defer the discussion around what I believe are addressable open issues in the high-level sketch, and instead focus on 
> whether the overall "partial o/a" approach satisfies the needs of those parties for whom glare reduction is an important goal.
>
>> Q1: How essential part of the unified plan is having *A* working "partial o/a" solution? TECHNICALLY, the other parts of the unified plan do not depend 
>> on having a "partial o/a" solution, but I would like to know whether people (specially the draft authors) would be willing to move ahead with unified plan
>> even if we would not manage to specify a working "partial o/a" solution.
>
> Let's back up -- you're conflating mechanism with requirement here. The requirement is no glare in certain use cases (adding/removing streams).

The draft also talks about modifying streams (section 3.4.2). Are there specific modification use cases where no glare is important, or is it about being able to modify streams in general and avoid glare?

> The proposed mechanism is partial o/a.

Correct.

> The requirement is important to certain key participants in the working group, so I would characterize having a mechanism to address it as essential.

Ok.

> Keeping that in mind, "having a working 'partial o/a' solution," to re-use your phrasing, is utterly nonessential, since it is only one way to skin this cat. However, like
> I just said, having a working story for glare *is* essential. We've seen others (as I explained to my response to Paul, earlier), and may be able to come up with yet more.

So, moving ahead with unified plan basically means adopting the requirement to solve glare, but we may also look at other mechanisms?

Thanks for the clarification!

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2013 00:21:04 -0500

> The draft also talks about modifying streams (section 3.4.2). Are there specific modification use cases where no glare is important, or is it about being able to modify streams in general and avoid…

I was a matter of realizing that our design allows, with very little 
additional effort, significant reduction in the probability of glare for 
stream modification in general. As this seemed like very low hanging 
fruit, it seems to be sensible to include it as part of the design.

So, to answer you question directly: it's not driven by specific use 
cases; it's just general glare probability reduction.

> So, moving ahead with unified plan basically means adopting the 
> requirement to solve glare, but we may also look at other mechanisms?

It is my understanding that making glare impossible or nearly impossible 
for the add/remove stream case is an important requirement for any plan 
(a, b, unified, or anything else). At the moment, the proposal in the 
unified plan document is the best that the authors can come up with. I 
think we're all open to the prospect of alternate designs that achieve 
the same goal, although I would hope we don't spend too much time 
exploring the solution space.

/a