Subject: Re: [MMUSIC] unified plan glareless atomicity improvement

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 10:51:09 -0400

On Jul 31, 2013, at 12:42 PM, Paul Kyzivat <[email-masked]> wrote:

> I don't understand how sendonly and recvonly reduce glare.
> If I offer a sendonly m-line, it still must be answered. And subsequently an offer for that m-line can come from either side, possibly producing glare.
> 
> ISTM that you should offer a sendrecv m-line iff you intend a bidirectional flow, where the two sides are related, will have common properties and lifetimes.
> 
> There is still a problem if both sides want a bidirectional flow, but aren't agreed on who should initiate it. In that case they both might offer and glare. And there there remains the question of whether they recognize this as glare, rather than thinking they need both flows.

My understanding is the concept isn't such that there isn't an offer going in both directions - there is an offer going in both directions.  But if the two offers don't "collide" in the things they change, then it's not a glare, and instead they can just accept the offer they each receive as an answer.

So in the direction attribute case, if you send a=sendonly and the other side sent a=recvonly, there is no collision - each side can just treat the offer as an answer.  Likewise if you both send "a=sendrecv", or both send "a=inactive".

We can even define rock-paper-scissor rules, as was done for when a stream is removed and changed at the same time (in that case removal trumps changing).  For example, we can make it so that an "a=inactive" trumps all other directions; so regardless of what direction attribute you sent, if you receive an "a=inactive", that's the new state.

We could even define a lookup table for it, like this:

Sent Offer  Rcvd Offer      Local state
--------------------------------------
sendrecv    sendrecv        sendrecv
sendrecv    sendonly        recvonly
sendrecv    recvonly        sendonly
sendrecv    inactive        inactive
sendonly    sendrecv        sendonly
sendonly    sendonly        inactive
sendonly    recvonly        sendonly
sendonly    inactive        inactive
recvonly    sendrecv        recvonly
recvonly    sendonly        recvonly
recvonly    recvonly        inactive
recvonly    inactive        inactive
inactive    sendrecv        inactive
inactive    sendonly        inactive
inactive    recvonly        inactive
inactive    inactive        inactive

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 15:01:35 +0000

So, you are basically saying that both endpoints can send partial offers for the SAME m- line, WITHOUT "triggering" glare, if there is no "state collision"???

My understanding of the UP (unified plan) was that you would still get glare if both endpoints simultaneously send a partial offer for the same m- line.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Paul Kyzivat [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [MMUSIC] unified plan glareless atomicity improvement

-hadriel

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Aug 2013 23:25:27 +0200

> My understanding is the concept isn't such that there isn't an offer going in both directions - there is an offer going in both directions.  But if the two offers don't "collide" in the things they…

That isn't my understanding. My understanding was that the intent was to 
reduce the probability that there will be concurrent offers from both 
sides for the same subset of the SDP.

> So in the direction attribute case, if you send a=sendonly and the other side sent a=recvonly, there is no collision - each side can just treat the offer as an answer.  Likewise if you both send "a…

Assume that we did an initial full O/A, and m-line#1 sendonly for X and 
recvonly for Y.

Subsequently, one side, or the other, or both, may wish to make a change 
to the media section headed by m-line#1. For instance, one side may wish 
to change the codec list - perhaps drop one of the PTs from the initial 
O/A, or add a new one.

If both sides attempt this then there is still glare. One can't assume 
that one side won't ever have need to do this.

> We can even define rock-paper-scissor rules, as was done for when a stream is removed and changed at the same time (in that case removal trumps changing).  For example, we can make it so that an "a…

Having one side change the directionality is just one of the multitude 
of changes that might come up. It probably isn't the most significant 
one. The likelihood if it will be reduced if sendrecv is never used.

> Sent Offer  Rcvd Offer      Local state

If nothing else was changed, then there could be some advantage to this 
in reducing glare. But it doesn't help with changing anything else about 
the media section. And while similar rules might be worked out for some 
of those things, I think it will be hard. (Similar in scale and 
complexity to draft-nandakumar-mmusic-sdp-mux-attributes.)

I think it is probably true that using sendonly and recvonly when adding 
*new* m-lines may work out better than using sendrecv and counting on 
the other side to pair the reverse direction. But even then it will only 
matter with certain usage scenarios.

IMO the key to using sendrecv is not to avoid it entirely, but rather to 
figure out when it makes sense. I think that is when you *want* "fate 
sharing" between the paired streams.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 17:58:11 -0400

On Aug 5, 2013, at 5:25 PM, Paul Kyzivat <[email-masked]> wrote:

> That isn't my understanding. My understanding was that the intent was to reduce the probability that there will be concurrent offers from both sides for the same subset of the SDP.

Huh.  Yup you could be right.  Heck if I know - I'm only going by what I thought Martin said at the mic in the meeting.  I thought he said it would be useful to reduce glare if all that changed was direction attribute on both sides. (like you both hit "hold" or "un-hold" whatever)  But I could easily be misunderstanding what he said.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 18:00:52 -0400

> My understanding of the UP (unified plan) was that you would still get glare if both endpoints simultaneously send a partial offer for the same m- line. 

Currently in the UP draft, that's true.  I thought Martin's point at the mic was we could do a bit better for specific attribute changes, such as direction, of the same m-line.  Or I could be reading something into his words that he didn't intend.

I eagerly await his email to enlighten us. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 18:45:24 -0400

On Aug 5, 2013, at 5:25 PM, Paul Kyzivat <[email-masked]> wrote:

> Having one side change the directionality is just one of the multitude of changes that might come up. It probably isn't the most significant one. The likelihood if it will be reduced if sendrecv is never used.

Afaict in *SIP* the most common causes of glare are (1) transport addr:port changes and (2) directionality attribute changes.  Usually early in calls, like in the first few seconds; sometimes in the middle of calls, if both sides press a hold button at the same time for example.[1]

But yeah since the use-case that drove UP is basically hangouts, Martin probably did mean something completely unrelated to what I was thinking.

-hadriel
[1] It's hard to generalize them into "most common causes", because there're plenty of other cases too; and probably different people see different cases more/less frequently.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 22:55:30 +0000

Hi,

If you use separate m- lines per media direction, there MAY be a smaller risk that both endpoints try to modify the same m- line. Maybe that is what he was talking about :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Hadriel Kaplan
Lähetetty: 6. elokuuta 2013 1:45
Vastaanottaja: Paul Kyzivat
Kopio: [email-masked]
Aihe: Re: [MMUSIC] unified plan glareless atomicity improvement

-hadriel

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Aug 2013 07:44:07 +0200

> If you use separate m- lines per media direction, there MAY be a smaller risk that both endpoints try to modify the same m- line. Maybe that is what he was talking about :)

That's actually all I was suggesting.  But the wild speculation that
ensued was quite interesting nonetheless.

I believe that most of what has been said on this thread is also true.
 Yes, you can probably reduce glare further by defining some specific
rules (reject beats any other change, etc...).  Yes, you can devise
rules for other stuff.  Yes, it's probably not worth it for a lot of
those things anyway.  Yes, changing parameters that affect multiple
m-lines, like transport parameters, is probably going to cause
unavoidable wide-scale glare.  Etc..

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 13:29:28 -0400

> unavoidable wide-scale glare.  Etc..

Huh.  Well my idea was much better... sure, it may not provide any value, benefit, or fix any problem... but it's a way cooler idea. ;)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Aug 2013 12:55:27 -0500

> Huh.  Well my idea was much better... sure, it may not provide any value, benefit, or fix any problem... but it's a way cooler idea. ;)

Yeah, maybe -- but I think we want to keep this relatively simple. More 
directly: we need to be careful to evaluate what incremental gains added 
complexity gets us over a simpler mechanism. I think the scheme you 
outlined is out in the "diminishing returns" part of the solution space.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 16:14:09 -0400

On Aug 7, 2013, at 1:55 PM, Adam Roach <[email-masked]> wrote:

> Yeah, maybe -- but I think we want to keep this relatively simple. More directly: we need to be careful to evaluate what incremental gains added complexity gets us over a simpler mechanism. I think the scheme you outlined is out in the "diminishing returns" part of the solution space.

Dude, it was a joke.  Apparently not a funny one, though. :(

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 20:37:57 +0000

Hadriel, your jokes work much better during f2f meetings, because part of the joke telling is that you first laugh at your joke yourself, before anyone else :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Hadriel Kaplan
Lähetetty: 7. elokuuta 2013 23:14
Vastaanottaja: Adam Roach
Kopio: [email-masked] (E-mail)
Aihe: Re: [MMUSIC] unified plan glareless atomicity improvement

-hadriel

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Aug 2013 22:58:12 +0000

On Jul 31, 2013, at 6:16 AM, Martin Thomson <[email-masked]> wrote:

> I think that the only guidance needed is something like:
> "Implementations MAY choose to exclusively use m-lines with a=sendonly
> or a=recvonly in order to further reduce the probably of encountering
> glare."

that can't be the default for non bundle lines or it won't work with existing stuff which was the whole point of this. It's not clear it helps reduce glare in general.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2013 00:27:27 +0100

> that can't be the default for non bundle lines or it won't work with existing stuff which was the whole point of this. It's not clear it helps reduce glare in general.

You are somewhat correct.  I'm sure that it will "work" for some value
of "work", but that might not correspond with anything useful.

I was operating under the assumption that partial offers/answers
wouldn't reach old stuff.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 01:43:50 +0200

> wouldn't reach old stuff.

Well, when we hear others assert such things in other contexts we give 
them a very hard time, and tell them that in spite of all their best 
intentions things will leak.

E.g., private network addresses, asserted identity.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2013 01:23:43 +0100

On 14 August 2013 00:43, Paul Kyzivat <[email-masked]> wrote:
> Well, when we hear others assert such things in other contexts we give them
> a very hard time, and tell them that in spite of all their best intentions
> things will leak.

This is an interesting point, but I'm not sure if it's relevant
without knowing more about how people intend to standardize the use of
these things.  If you send them in SIP INVITE messages, then I'm
willing to entertain the discussion about leakage - we have to worry
at that point.

Until that happens, I will regard these partial thingies as square
pegs and SIP as a round hole.  And, while I expect that someone will
come along with a hammer shortly, allow me at least that brief time to
avoid worrying about these sorts of crazy things.

--Martin