Subject: [clue] comments to framework 09 - simultaneous sets

From: Roberta Presta <[email-masked]>
Date: Wed, 27 Feb 2013 19:47:09 +0100

Hi all,

sorry for boring you always with the same things :)

When I read Section 6.3 "Simultaneous Transmission Set Constraint", I 
noticed a couple of things:

1) the only motivation that has been provided to justify the definition 
of simultaneous sets is the fact that captures generated from the same 
device cannot be sent simultaneously. However, there can be other 
motivations behind the need of expressing simultaneity constraints 
(leaving resource constraints handled by encoding groups and other stuff 
such as max-encoding- and so on).
Citing Andy Pepperel in 
http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, 
simultaneous sets can be used by MCUs that might not want to be obliged 
to provide some capture simultaneously, in order to avoid overloading.
I think that these other motivations should be explicitely mentioned in 
the framework document to explain that simultaneity limitations may not 
be due only to physical constraints.

2)  Copying from the document:  "Simultaneous transmission sets are 
expressed as sets of the Media Captures that could physically be 
transmitted at the same time (though it may not make sense to do so). "
Does it mean that even if there is a large set of captures able to be 
sent simultaneously, it may not make sense, from the consumer's 
perspective, to receive them all together? Maybe rewording is needed here.

3) Again, on the design (and definition) of the simultaneous sets.

Simultaneous sets, as defined in the framework, are *all* the groups of 
*captures* that can be sent together.
The consumer presumably has to check if the set of captures he wants is 
fully *included* in almost one of the listed ones.
If not, he has to re-structure the configure to fit simultaneity 
constraints expressed by the provider.
(Is that the expected behavior of the consumer?)

I was thinking that each set can be expressed also in terms of capture 
scene entries, or capture scene as a whole, for example:
1) CSE1, CSE2, CS3, VC1, CS5
2) CSE1, CSE4, CS3, VC1, CS5
....
Where CSE* identifies a capture scene entry, and CS* identifies a 
capture scene.
That can allow to make simultaneous sets more synthetic by exploiting 
the capture aggregates the framework envisions. It can be particularly 
useful to MCUs that want to offer just subsets of the complete list of 
capture scenes they receive from multiple contributors.

4) Some further reasoning.

In some cases it can be more efficient to express only mutual exclusion 
constraints.
We could discuss about envisioning a section of information named 
"simultaneity constraints" that can include a list of simultaneous sets 
and a list of mutual exclusion conditions to be checked on the 
consumer's side.
For example, if a media provider offers many captures, and has only 4 
mutual exclusion conditions, instead of listing all the possible 
simultaneous sets, he can just provide the 4 mutual exclusion conditions 
to the consumer.

Another alternative is also Christer Holmberg's proposal in 
http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, where 
simultaneity constraints are logical conditions that the consumer has to 
verify before issuing a configure to the provider.
The example was:

"(CSE-X AND CSE-Y) OR CSE-Z.

This means that the provider can provide CSE-X and CSE Y
(and all captures associated with CSE-X and CSE-Y) simultaneously,
or that the provider can provide CSE-Z (and all captures associated with 
CSE-Z)."

Do you think we should stuck on the framework solution or also consider 
the aforementioned alternatives?
I promise I stop thinking about it!

RP

-- 
Roberta Presta, Ph.D. Student
Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione (DIETI)
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 Feb 2013 15:00:35 +1100

Hello Roberta,

Please see my comments below.

Regards, Christian

On 28/02/2013 5:47 AM, Roberta Presta wrote:
> 1) the only motivation that has been provided to justify the 
> definition of simultaneous sets is the fact that captures generated 
> from the same device cannot be sent simultaneously. However, there can 
> be other motivations behind the need of expressing simultaneity 
> constraints (leaving resource constraints handled by encoding groups 
> and other stuff such as max-encoding- and so on).
> Citing Andy Pepperel in 
> simultaneous sets can be used by MCUs that might not want to be 
> obliged to provide some capture simultaneously, in order to avoid 
> overloading.
> I think that these other motivations should be explicitely mentioned 
> in the framework document to explain that simultaneity limitations may 
> not be due only to physical constraints.
[CNG] I agree that there could be several difference reasons why the 
Advertiser might indicate that there is a simultaneity limitations. It 
could also relate to scene composition issues, i.e. if a movable device 
is capturing different regions in the advertised captures. Think would a 
device physical constraint rather than a transmission physical 
constraint. I think the main thing is that the reason to send a 
simultaneity constraint is not limited.

> perspective, to receive them all together? Maybe rewording is needed 
[CNG] Do we need the text "(though it may not make sense to do so)"? If 
the consumer chooses a "strange" set of captures then it should make 
sense to it. It may not make sense to an Advertiser. Also do we need 
"physically", i.e. is it sufficient to say "...that could be transmitted 
at the same time."

> Simultaneous sets, as defined in the framework, are *all* the groups 
> of *captures* that can be sent together.
> The consumer presumably has to check if the set of captures he wants 
> is fully *included* in almost one of the listed ones.
[CNG] I'm not sure what you mean by "in almost one of the listed ones." 
I think the intention is that the selected captures firstly meet a 
"capture scene entry" and then the "simultaneous set" if they don't. If 
the consumer can't get a match then I guess there would be a failure. 
Maybe we need an additional error in Paul K's signalling document for a 
Configure message? i.e. "Unable to select captures due to local constraints"

> capture scenes they receive from multiple contributors.
[CNG] My understanding is that a CSE is under a capture scene? I'm not 
sure how the above examples relate to that.

> In some cases it can be more efficient to express only mutual 
> exclusion constraints.
> "simultaneity constraints" that can include a list of simultaneous 
> sets and a list of mutual exclusion conditions to be checked on the 
> consumer's side.
> simultaneous sets, he can just provide the 4 mutual exclusion 
> conditions to the consumer.
[CNG] There's probably a thesis for someone to study whether inclusion 
or exclusion is best. I guess the tradeoff of less signalling data is 
possibly more processing to determine whether the Consumers choice fits.
> simultaneity constraints are logical conditions that the consumer has 
> to verify before issuing a configure to the provider.
> The example was:
>

> or that the provider can provide CSE-Z (and all captures associated 
> with CSE-Z)."
[CNG] I'm for keeping things simple and assuming "or". If we define 
robust version/extension mechanisms if we find its a issue we could 
enhance CLUE by having more extension syntax.
>
> Do you think we should stuck on the framework solution or also 
> consider the aforementioned alternatives?
[CNG] Don't stop thinking about it. It's good that its being questioned, 
that leads to a better protocol.

---

From: Roberta Presta <[email-masked]>
Date: Thu, 28 Feb 2013 13:04:49 +0100

Hi Christian,

I reply below.

Il 28/02/2013 05:00, Christian Groves ha scritto:
>> from the same device cannot be sent simultaneously. However, there 
>> can be other motivations behind the need of expressing simultaneity 
>> in the framework document to explain that simultaneity limitations 
>> may not be due only to physical constraints.
> could also relate to scene composition issues, i.e. if a movable 
> device is capturing different regions in the advertised captures. 
> Think would a device physical constraint rather than a transmission 
> physical constraint. I think the main thing is that the reason to send 
> a simultaneity constraint is not limited.
>
>>
> [CNG] Do we need the text "(though it may not make sense to do so)"? 
> If the consumer chooses a "strange" set of captures then it should 
> make sense to it. It may not make sense to an Advertiser. Also do we 
> need "physically", i.e. is it sufficient to say "...that could be 
> transmitted at the same time."
>
[RP] +1
> [CNG] I'm not sure what you mean by "in almost one of the listed ones." 
[RP]
Let's suppose there are two advertised simultaneous sets:
1) VC1, VC2, VC5
2) VC1, VC2, VC6
The consumer must verify that the list of captures he desires is fully 
included at least or in set (1) or in set (2).
For example, if the consumer's desired list of captures is, for example, 
(VC1, VC2), or (VC1, VC2, VC5), then the check is verified.
If the consumer's desired list of captures is (VC1, VC2, VC5, VC6) the 
check is not verified.
I'm just applying what is actually stated in the framework up to now.

> "capture scene entry" and then the "simultaneous set" if they don't.

[RP] What I have understood by reading the framework document is 
slightly different.
Capture scene entries are defined as set of captures that can be sent 
simultaneously, so there is no doubt about it.
Nonetheless, if simultaneity constraints are present in an 
advertisement, the consumer must verify that his capture selection fits 
such constraints.
If simultaneity constraints are *present*, the only case in which they 
can be skipped is the one where the consumer chooses only one capture 
scene entry (i.e., a set of captures listed in the same capture scene 
entry), or captures belonging to the same capture scene entry.
If the consumer selects more than one capture scene entry, and 
simultaneity constraints are present, they should be checked. Indeed, 
captures belonging to different scene entries could not be able to be 
sent simultaneously.

> If the consumer can't get a match then I guess there would be a 
> failure. Maybe we need an additional error in Paul K's signalling 
> document for a Configure message? i.e. "Unable to select captures due 
> to local constraints"
>
>>
>> I was thinking that each set can be expressed also in terms of 
>> capture scene entries, or capture scene as a whole, for example:
>> the capture aggregates the framework envisions. It can be 
>> particularly useful to MCUs that want to offer just subsets of the 
>> complete list of capture scenes they receive from multiple contributors.
[RP] I try to explain what I have in mind by providing a couple of examples.

Suppose we have three capture scenes:
1) CSA made by three scene entries: CSE1_A, CSE2_A, CSE3_A
2) CSB made by three scene entries: CSE1_B, CSE2_B, CSE3_B
3) CSC made by three scene entries: CSE1_C, CSE2_C, CSE3_C
Suppose that each capture scene entry is made of three captures ==> we 
have 27 captures.

Suppose that I want to offer OR (CSA and CSB) OR (CSA and CSC). I can 
provide two simultaneous sets:
- CSA, CSB
- CSA, CSC
without listing all the captures for each alternative.

Let's make another example. Suppose that CSE1_A and CSE2_A are not 
compatible because of physical constraints.
If I want to express just such a limitation, by applying the philosophy 
of the current framework document, I should list two sets:
- all captures in CSB, all captures in CSC, all captures in CSE3_A, and 
all captures in CSE1_A
- all captures in CSB, all captures in CSC, all captures in CSE3_A, and 
all captures in CSE2_A
My proposal is, instead of listing all the captures, using capture scene 
identifiers and capture scene entry identifiers, and building 
simultaneous sets as:
- CSB, CSC, CSE3_A, CSE1_A
- CSB, CSC, CSE3_A, CSE2_A

>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, 
>> where simultaneity constraints are logical conditions that the 
>> consumer has to verify before issuing a configure to the provider.
>> The example was:
>>
> [CNG] Don't stop thinking about it. It's good that its being 
> questioned, that leads to a better protocol.
>>
>> RP
>>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 01 Mar 2013 10:17:04 +1100

Hello Roberta,

Please see below.

Regards, Christian

..snip
> For example, if the consumer's desired list of captures is, for 
> example, (VC1, VC2), or (VC1, VC2, VC5), then the check is verified.
[CNG] OK that's my understanding also.

> advertisement, the consumer must verify that his capture selection 
> fits such constraints.
[CNG] I think we have the same understanding.
>>> That can allow to make simultaneous sets more synthetic by 
>>> exploiting the capture aggregates the framework envisions. It can be 
>> [CNG] My understanding is that a CSE is under a capture scene? I'm 
>> not sure how the above examples relate to that.
>>
[CNG] OK

> If I want to express just such a limitation, by applying the 
> philosophy of the current framework document, I should list two sets:
> - all captures in CSB, all captures in CSC, all captures in CSE3_A, 
> and all captures in CSE1_A
> - all captures in CSB, all captures in CSC, all captures in CSE3_A, 
> and all captures in CSE2_A
> My proposal is, instead of listing all the captures, using capture 
> scene identifiers and capture scene entry identifiers, and building 
> simultaneous sets as:
[CNG] OK. Sounds reasonable. Are you proposing to still keep individual 
captures in the STS? i.e. VC1, VC2. If so we may have to scope these to 
a CSE/CS because you can use the same captureID in different CSEs. It 
may get confusing it we don't?
..snip