Subject: [MMUSIC] Simulcast worries: Fallback in the a=rid language

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Oct 2015 15:57:12 +0200

I'm worried about the extensibility of the constraints model in the RID
language.
Consider for instance this situation:

- A knows about a new constraint "max-goats"
- B doesn't know about it

A sends:

a=rid:1 recv max-goats=47;max-fr=50
a=rid:2 recv max-goats=22;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

This indicates that A offers two simulcast layers and is willing to
receive two.

B does not know about "max-goats". It's willing to do simulcast and obey
the FR constraint, but it has no way of knowing whether the streams it
generates will violate the goats restriction or not.

Alternatives:

1 - Toss all RIDs that it cannot parse fully
2 - Accept all send RIDs that it can promise to handle, toss all receive
RIDs that it cannot promise to restrict itself to (because it doesn't
understand the restriction).
3 - Accept all RIDs, drop constraints it does not understand.

Resulting SDP would be:

1:

a=simulcast:

doesn't look good. You're not going to simulcast today.

2:

a=simulcast:recv rid=3;4
a=rid:3 recv max-fr=20
a=rid:4 recv max-fr=10

Works for incoming simulcast to B, but the ability to simulcast to A has
been lost: Expanding the language at A has created failure modes that
lead to lost functionality.

3:

a=simulcast: recv rid=3;4 send rid=1;2
a=rid:1 send max-fr=50
a=rid:2 send max-fr=20
a=rid:3 recv max-fr=20
a=rid:4 recv max-fr=10

We keep simulcast capability, but if the goats restrictions were
important to A, it will now have to detect that capabilities were
dropped, and will have to do another offer/answer in order to prevent
itself being overrun by goats from B.

What's the USEFUL semantics to support on extensibility?

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 21 Oct 2015 08:32:12 -0700

I can think of some more alternatives:

Alternative 4.  Offer doesn't constrain max-goats until it know the
answerer supports and then does a re-offer with max-goats constrained:

offer 1:

a=rid:1 recv max-goats;max-fr=50
a=rid:2 recv max-goats;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

answer 1:

a=rid:1 send max-goats;max-fr=50
a=rid:2 send max-goats;max-fr=20
a=rid:3 recv max-goats=44;max-fr=20
a=rid:4 recv max-goats=44;max-fr=10
a=simulcast: recv rid=3;4 send rid=1;2

offer 2:

Problem: You'd probably need a re-offer for all recv lines doing this,
since all attributes are optional.

Alternative 5.  Accept all RIDs, drop constraints it does not understand,
*but remove the problematic RIDS from the simulcast line*.

Offer 1:

Answer 1:

a=rid:1 send max-fr=50
a=rid:2 send max-fr=20
a=rid:3 recv max-fr=20
a=rid:4 recv max-fr=10
a=simulcast: recv rid=3;4

Offer 2:

a=rid:1 recv max-fr=50
a=rid:2 recv max-fr=20
a=rid:3 send max-fr=20
a=rid:4 send max-fr=10

Alternative 6.  Mark constraints as optional

Offer 1:

a=rid:1 recv max-goats=47?;max-fr=50
a=rid:2 recv max-goats=22?;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

Basically, have a marker for "I'd prefer this be the max, but if you don't
support this kind of max, at least send me something".  Notice the "?".

On Wed, Oct 21, 2015 at 6:57 AM, Harald Alvestrand <[email-masked]>
wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2015 11:55:18 -0400

> I'm worried about the extensibility of the constraints model in the RID

Good catch.

> will have to do another offer/answer in order to prevent

:-)  Love it!!!

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 11:35:18 -0700

> 1 - Toss all RIDs that it cannot parse fully

This.

If you were able to handle options that didn't limit goats, then you
can add an alternative profile that doesn't include any max-goats
constraints:

a=rid:5 recv max-fr=10
a=rid:6 recv max-fr=5
a=rid:7 send max-fr=10
a=rid:8 send max-fr=5
a=simulcast: send rid=3;4,7;8 recv rid=1;2,5;6

(I've probably gotten the syntax off here, but I hope that this is clear enough.

---

From: Byron Campen <[email-masked]>
Date: Wed, 21 Oct 2015 13:41:55 -0500

> (I've probably gotten the syntax off here, but I hope that this is clear enough.
     This could work, I suppose.

Best regards,
Byron Campen

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Oct 2015 22:27:16 +0200

> (I've probably gotten the syntax off here, but I hope that this is clear enough.
But to a receiver that understands max-goats, this is a profile that
says "send me 4 simulcast streams if you feel like it", not "send me
either these two or those two".

This may be harmless, but it may be surprising.

-- 
Surveillance is pervasive. Go Dark.

---

From: Byron Campen <[email-masked]>
Date: Wed, 21 Oct 2015 15:35:19 -0500

> This may be harmless, but it may be surprising.
     a=simulcast: recv rid=1,5;2,6 send rid=3,7;4,8 means that there are 
two simulcast streams each for send and recv, and each of those may use 
one of two rids (but not both at the same time). Now, if the answerer 
doesn't remove any rids, that allows either end to switch out which rid 
it uses at will, which is pretty weird. Don't know why anyone would 
actually do this though, but it probably wouldn't cause too much havoc.

Best regards,
Byron Campen

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 21 Oct 2015 15:05:47 -0700

But if you have max-goats and max-dogs and max-cats and the answerer
supports max-dogs but not max-goats or max-cats,  how can it structure it
to offer all the combinations of what might work and what might not?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 15:23:21 -0700

On 21 October 2015 at 15:05, Peter Thatcher <[email-masked]> wrote:
> supports max-dogs but not max-goats or max-cats,  how can it structure it to
> offer all the combinations of what might work and what might not?

Yes, combinatorial explosion ensues.

My view is that we aren't likely to add enough of these extensions
that we will ever reach that explosion point.

And if enough time lapses between introduction of different things,
you can start to make assumptions about things, and do things like
bundle max-dogs and max-cats together.  Sure, the guy who understands
(not supports) only max-dogs falls back to the baseline, but as long
as you have a baseline you don't suffer too badly.

In practice, I think that this will only create a modest amount of
pressure not to extend.  I can't actually think of a downside to that.

BTW, this is a repeat of a similar discussion we had in HTTP.  There,
we settled on having parameters be ignored if not supported.  I don't
think that's feasible in this context because things like limits are
important.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Oct 2015 07:37:32 +0200

> think that's feasible in this context because things like limits are
The logic is in fact different for the two directions.

If I tell someone I'm going to stick to a limit they don't know about
(send), no harm will come from ignoring the parameter - I can stick to
the limit anyway.

If I tell someone I can't take more than X from them (recv), it's
dangerous if they ignore it, because they can overrun my limitations
through ignorance.

That tells me that:

a) we need to think more about this
b) sendrecv is a bad idea

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 09:43:59 -0500

> dangerous if they ignore it, because they can overrun my limitations

And if they don't support the simulcast mechanism at all, they'll do the 
same thing. You're asking us to solve a problem that is unrelated to the 
mechanism.

> ...

That has been well-established as the emerging consensus. If you find 
the string "sendrecv" in either draft-ietf-mmusic-sdp-simulcast-03 or 
draft-pthatcher-mmusic-rid-02 in a context other than "a=sendrecv", 
please point it out. My search turned none up.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Oct 2015 20:13:49 +0200

> same thing. You're asking us to solve a problem that is unrelated to the

I don't understand this comment.

If that (telling the other guy not to send more in a simulcast than you
want to handle) isn't the problem the mechanism was supposed to solve,
what IS the point of the mechanism?

I'm assuming that the correspondent that doesn't understand simulcast is
restricted by other attributes like a=imageattr (well, sort of), a=fmtp
and b=, so that this is regarded as a problem this mechanism doesn't
have to solve.

> please point it out. My search turned none up.

Good. It was in simulcast-02; happy to see it gone.

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 13:18:54 -0500

> and b=, so that this is regarded as a problem this mechanism doesn't

Right, and all of those still apply, even when they *do* understand 
simulcast. 
https://tools.ietf.org/html/draft-pthatcher-mmusic-rid-02#section-9

In any case, this is all kind of academic, unless you're proposing that 
we change things to work in the way you assert is broken. The current 
situation (in the spec) is that those RIDs containing restrictions that 
you don't understand are ignored. Not the restriction, the entire RID. I 
think your point that we might be able to allow the RIDs to say around 
for streams you're receiving (it doesn't matter if the far end restricts 
the stream it's sending in a way you don't understand) is a good one 
that we should probably take into account.

/a