draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations

[Worley, Dale R (Dale)]

I am starting work on a messy part of the media policy dataset
definition: Specifying the logic when a policy is applied to a
session-info, and also specifying how two policies are combined to
apply jointly to session-infos. The goal is to implement one's
intuitive expectations while introducing as few special cases as
possible.

My current analysis is:

- The primary operation is applying a session-policy to a session-info
to produce a possibly more restricted session-info. This is done by
applying the session-policy to each stream in turn, which may
"restrict" the stream (in regard to bandwidth, codecs, etc.).

- A stream may be restricted to the point that it permits no media
whatsoever. Such "null" streams are all logically equivalent,
although a null stream can be represented in many different ways.
When translated back into SDP, a null stream becomes a rejected
m= line.

- The different <stream> elements in a session-policy are effectively
ORed together, in that the policy intends to permit any stream that
conforms to *any one* of the <stream> elements. This is necessary
because e.g. a session-policy can contain one <stream> that specifies
audio media and restricts the codecs permitted for audio, and
another <stream> that specifies video media and restricts the codecs
permitted for video.

- Thus, applying a session-policy to a stream involves applying each
session-policy <stream> to the stream, and then choosing the "best"
result. In practice, we expect that the streams admitted by the
session-policy <stream> elements to be disjoint (e.g., one is for
audio, one is for video), so the result of applying any but one
<stream> will be a null stream, and the "best" result will be the
only non-null result.

- The alternative strategy of "unioning" the results of applying each
<stream> element cannot be used because it can allow the resulting
session to exceed all of the <stream> element policies. Consider
the policy

<streams>
<stream> codecs: audio/foo, bandwidth: 10 </stream>
<stream> codecs: audio/foo,audio/bar, bandwidth: 1 </stream>
</streams>

applied to the requested stream "codecs: audio/foo,audio/bar,
bandwidth: 10". The result of restricting with the first <stream>
is "codecs: audio/foo, bandwidth: 10" and the result of restricting
with the second <stream> is "codecs: audio/foo,audio/bar, bandwidth:
1". The union of the two (the "smallest" stream that contains them
both) is "codecs: audio/foo,audio/bar, bandwidth: 10", which is not
allowed by either <stream>.

- Within this context, combining two policies to form a joint policy
that enforces both their restrictions simultaneously is simple: The
resulting policy is made by "intersecting" all possible pairs of
<stream>s, one from the first policy and one from the second policy.
(Intersections that result in null policies can be dropped from the
result.)

- I haven't studied the role of the directional attributes yet, but
currently I believe that a bidirectional session-info <stream> can
be treated as an abbreviation for two session-info <stream>s, one in
each direction, and a bidirectional session-policy <stream> can be
treated similarly. Or, directionality can be treated as an
attribute with two possible values, *with identical results*.

Comments?

Dale
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Gonzalo Camarillo]

Hi Dale,

here you have my answers not only to your original email, but to the
whole section on open revision items you added to the draft.

> 1.1. Media Types
>
>
> 1.1.1. Require Registration
>
>
> In -10, all media type names that are mentioned in a MPDF are
> explicitly required to be IANA-registered. Technically, this means
> that experimental or private-use types can not be used, even in
> situations where all participants are aware of non-registered media
> types. In practice, people will go ahead and use them anyway. I am
> proposing to remove the "registered" requirement.

yes, I agree this draft does not need to put unnecessarily restrictive
requirements on the tokens to be placed in MPDF documents.

> 1.1.2. Terminology
>
> In a number of places, media types are called "MIME types". The
> latter is common usage, but it is not official, and as RFC 4288 makes
> clear, media types are independent of their use within MIME. I've
> fixed the wording of the draft in a number of places to correct this.

Perfect.

> 1.1.3. Rename the <mime-type> child of <codec>
>
> There is an element <mime-type> that is a child of the <codec>
> element that carries a media type and subtype. The natural fix would
> be to change this to <media-type>, but there is already an element of
> that name that is a child of <stream> that carries a media type
> (without subtype). I would like a name that means "media type and
> subtype", but I can't think of a short one. Suggestions?

I do not think we should spend too much time thinking of a good name for
it. Let's just call it <media-type-subtype>, for instance.

>
> 1.2. Remove reference to uaprofile.rng
>
> The Relax NG schema given in draft-ietf-sipping-media-policy-dataset
> includes "uaprofile.rng". As far as I can figure out, uaprofile.rng
> is the schema defined in draft-ietf-sipping-profile-datasets, which
> has been abandoned. So we need to remove the reference to
> uaprofile.rng. It's possible that there are things defined in that
> schema that need to be either deleted from
> draft-ietf-sipping-media-policy-dataset, or copied from the abandoned
> draft into the schema in draft-ietf-sipping-media-policy-dataset.
>
> If anyone has further information about this, please tell me.
>

Yes, although a cleanup was performed in order to get rid of the
now-abandoned draft, we may still need to finish it properly.


> 1.3. Remove <property-set>
>
> I have updated the text of draft-ietf-sipping-media-policy-dataset-11
> to consistently use "property-set" rather than sometimes using
> "property_set". However, it seems to me that the <property-set>
> element serves no use (now that sipping-profile-datasets has been
> abandoned). The draft says that each <session-info> and <session-
> policy> appears in a <property-set>, and <property-set> can contain
> more than one of each. But there seems to be no practical use for
> this grouping; the semantics of <session-info> and <session-policy>
> is completely standalone.
>
> So I am proposing eliminating the <property-set> element entirely,
> making <session-info> and <session-policy> into top-level elements.

Yes, this is part of the cleanup we referred to above.

> 1.4. Specifying Sets
>
> There are many properties for which the values are sets of primitive
> values. The current syntax for specifying sets is awkward. In
> addition, it is not permitted to specify a set containing zero
> elements. Sessions containing empty sets are not useful to write,
> but it is easy to generate them when applying a policy to a <session-
> info>. So the syntax for set values needs to be updated.

Yes, it makes sense.

> 1.5. Specifying Bandwidth Limitations
>
> Looking at the XML of draft-ietf-sipping-media-policy-dataset, I see
> this paragraph:
>
> <!--
> <t>If a b= line is present for a media stream, this line MUST be
> used to create the bandwidth elements.</t>
> -->
>
> SDP provides "b=" lines for specifying bandwidth limitations.
> Similarly, MPD provides <max-bw>, <max-session-bw>, and
> <max-stream-bw> elements, and the draft states that they are
> equivalent to various forms of the b= line. Should we require that
> when SDP is translated into MPD that the bandwidth limitations be
> translated?

Yes, it makes sense.

>
> 1.6. Rejecting a media stream
>
> In draft-ietf-sipping-media-policy-dataset-10 there is no explicit
> way to indicate that a stream has been rejected (which is needed to
> correspond to an m= line in SDP where the port number is 0).
> Implicitly, this can be done by setting the port number in the
> <local-host-port> or <remote-host-port> to 0. But that is pretty
> ugly. I propose that we introduce an attribute of the <stream>
> element to indicate that a stream has been rejected/disabled:
>
> <stream enabled="no">
>
> The default value of "enabled" would be "yes".
>
> This resolves the problem of how a policy server would modify a
> <session-info> to make it conform to a policy if one of the <stream>s
> contradicted the policy: The policy server would put enabled="no"
> onto the <stream>.
>
> For consistency, a policy server could effectively reject a proposed
> session by rejecting all of the streams within it. This would be
> slightly different than rejecting the session as a whole by returning
> an empty session-info document, <session-info/>. This distinction
> corresponds to the difference between an SDP offer/answer negotiation
> failing, and the negotiation succeeding but the answer rejecting all
> the m= lines in the SDP.

Yes, it makes sense.

>
> 1.7. The implied boolean logic of policy operations
>
> I am starting work on a messy part of the media policy dataset
> definition: Specifying the logic when a policy is applied to a
> session-info, and also specifying how two policies are combined to
> apply jointly to session-infos. The goal is to implement one's
> intuitive expectations while introducing as few special cases as
> possible.
>
> My current analysis is:
> o The primary operation is applying a session-policy to a session-
> info to produce a possibly more restricted session-info. This is
> done by applying the session-policy to each stream in turn, which
> may "restrict" the stream (in regard to bandwidth, codecs, etc.).

Yes.

> o A stream may be restricted to the point that it permits no media
> whatsoever. Such "null" streams are all logically equivalent,
> although a null stream can be represented in many different ways.
> When translated back into SDP, a null stream becomes a rejected m=
> line.

Yes.

> o The different <stream> elements in a session-policy are
> effectively ORed together, in that the policy intends to permit
> any stream that conforms to *any one* of the <stream> elements.
> This is necessary because e.g. a session-policy can contain one
> <stream> that specifies audio media and restricts the codecs
> permitted for audio, and another <stream> that specifies video
> media and restricts the codecs permitted for video.

When policies apply to different aspects (e.g., video codecs and audio
codecs), this is true. However, if different policies apply to the same
aspect, they need to be merged. And when merging the policies, the
resulting stream needs to be compliant to all policies (i.e., an AND
operation). For example, if one policy allows codecs 0 and 8 and another
only allows 8, the resulting policy is to only use codec 8. If a policy
allows only codec 0 and another policy only allows codec 8, the result
is a null session. I am not sure if this is what you are saying above
(and below in the rest of the section), though.

Thanks,

Gonzalo

> o Thus, applying a session-policy to a stream involves applying each
> session-policy <stream> to the stream, and then choosing the
> "best" result. In practice, we expect that the streams admitted
> by the session-policy <stream> elements to be disjoint (e.g., one
> is for audio, one is for video), so the result of applying any but
> one <stream> will be a null stream, and the "best" result will be
> the only non-null result.
> o The alternative strategy of "unioning" the results of applying
> each <stream> element cannot be used because it can allow the
> resulting session to exceed all of the <stream> element policies.
> Consider the policy
>
> <streams>
> <stream> codecs: audio/foo, bandwidth: 10 </stream>
> <stream> codecs: audio/foo,audio/bar, bandwidth: 1 </stream>
> </streams>
>
> applied to the requested stream "codecs: audio/foo,audio/bar,
> bandwidth: 10". The result of restricting with the first <stream>
> is "codecs: audio/foo, bandwidth: 10" and the result of
> restricting with the second <stream> is "codecs: audio/foo,audio/
> bar, bandwidth: 1". The union of the two (the "smallest" stream
> that contains them both) is "codecs: audio/foo,audio/bar,
> bandwidth: 10", which is not allowed by either <stream>.
> o Within this context, combining two policies to form a joint policy
> that enforces both their restrictions simultaneously is simple:
> The resulting policy is made by "intersecting" all possible pairs
> of <stream>s, one from the first policy and one from the second
> policy. (Intersections that result in null policies can be
> dropped from the result.)
> o I haven't studied the role of the directional attributes yet, but
> currently I believe that a bidirectional session-info <stream> can
> be treated as an abbreviation for two session-info <stream>s, one
> in each direction, and a bidirectional session-policy <stream> can
> be treated similarly. Or, directionality can be treated as an
> attribute with two possible values, *with identical results*.

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Worley, Dale R (Dale)]

Gonzalo Camarillo [***@ericsson.com] writes:
> > o The different <stream> elements in a session-policy are
> > effectively ORed together, in that the policy intends to permit
> > any stream that conforms to *any one* of the <stream> elements.
> > This is necessary because e.g. a session-policy can contain one
> > <stream> that specifies audio media and restricts the codecs
> > permitted for audio, and another <stream> that specifies video
> > media and restricts the codecs permitted for video.
>
> When policies apply to different aspects (e.g., video codecs and audio
> codecs), this is true. However, if different policies apply to the same
> aspect, they need to be merged. And when merging the policies, the
> resulting stream needs to be compliant to all policies (i.e., an AND
> operation). For example, if one policy allows codecs 0 and 8 and another
> only allows 8, the resulting policy is to only use codec 8. If a policy
> allows only codec 0 and another policy only allows codec 8, the result
> is a null session. I am not sure if this is what you are saying above
> (and below in the rest of the section), though.

I'm not sure I'm understanding you completely here. And it's possible
that we aren't talking about exactly the same thing.

Let me recap my opinion:

- When there are two <stream> elements in *one* session-policy, then
the intention is to OR the specified restrictions: a stream that
conforms to any one of the <stream> elements is premitted.

- When we "merge" *two* session-policy's, that is an AND, in that the
stream is subject to the restrictions of each session-policy
seperately.

So within one session-policy, one could have a <stream> element that
specifies the allowed audio codecs, and another <stream> element that
specifies the allowed video codecs, because an SDP stream that
conforms to *either* <stream> element would be allowed. Thus, if one
<stream> allows codec G.729 and another <stream> allows codec G.711,
then either codec could be used in a stream.

But if one is "merging" two session-policy's, an audio stream would
only be acceptable to the resulting merged session-policy if its
codecs conformed to the limitations in both original ession-policy's.
Thus, if one session-policy allows codec G.729 and the other
session-policy allows codec G.711, then no codec could be used in an
audio stream.

Dale
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Gonzalo Camarillo]

Hi Dale,

yes, we are saying the same thing.

Thanks,

Gonzalo

On 07/03/2011 11:46 PM, Worley, Dale R (Dale) wrote:
> Gonzalo Camarillo [***@ericsson.com] writes:
>>> o The different <stream> elements in a session-policy are
>>> effectively ORed together, in that the policy intends to permit
>>> any stream that conforms to *any one* of the <stream> elements.
>>> This is necessary because e.g. a session-policy can contain one
>>> <stream> that specifies audio media and restricts the codecs
>>> permitted for audio, and another <stream> that specifies video
>>> media and restricts the codecs permitted for video.
>>
>> When policies apply to different aspects (e.g., video codecs and audio
>> codecs), this is true. However, if different policies apply to the same
>> aspect, they need to be merged. And when merging the policies, the
>> resulting stream needs to be compliant to all policies (i.e., an AND
>> operation). For example, if one policy allows codecs 0 and 8 and another
>> only allows 8, the resulting policy is to only use codec 8. If a policy
>> allows only codec 0 and another policy only allows codec 8, the result
>> is a null session. I am not sure if this is what you are saying above
>> (and below in the rest of the section), though.
>
> I'm not sure I'm understanding you completely here. And it's possible
> that we aren't talking about exactly the same thing.
>
> Let me recap my opinion:
>
> - When there are two <stream> elements in *one* session-policy, then
> the intention is to OR the specified restrictions: a stream that
> conforms to any one of the <stream> elements is premitted.
>
> - When we "merge" *two* session-policy's, that is an AND, in that the
> stream is subject to the restrictions of each session-policy
> seperately.
>
> So within one session-policy, one could have a <stream> element that
> specifies the allowed audio codecs, and another <stream> element that
> specifies the allowed video codecs, because an SDP stream that
> conforms to *either* <stream> element would be allowed. Thus, if one
> <stream> allows codec G.729 and another <stream> allows codec G.711,
> then either codec could be used in a stream.
>
> But if one is "merging" two session-policy's, an audio stream would
> only be acceptable to the resulting merged session-policy if its
> codecs conformed to the limitations in both original ession-policy's.
> Thus, if one session-policy allows codec G.729 and the other
> session-policy allows codec G.711, then no codec could be used in an
> audio stream.
>
> Dale

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP