Subject: [Sipping] Conclusion for merging

From: Volker Hilt <[email-masked]>
Date: Wed, 04 Apr 2007 11:10:12 -0400

One of the remaining issues for config and policy data sets is whether 
merging of data sets is needed or not.

A UA can receive data sets from multiple different sources (local 
network provider, device provider and SIP service provider) and needs to 
combine these sets into a single data set it can work with. In 
principle, the following strategies exist for enable this:

1. For each property, define exactly one source that can set this 
property. For example, define that codec usage can only be set by the 
local network provider.
-> It seems impossible to assign each property to exactly one source. 
For example, if codec usage is assigned to the local network provider, 
it can never be part of the user profile.

2. Define an order of precedence between sources so that, for example, 
local profile overrides user profile and user profile overrides device 
profile.
-> This also does not seem to be practical. For example, a single codec 
setting in the local profile would override all codec settings in the 
user profile. Thus, the effects of the user profile would depend on 
whether or not there is a local profile.

3. Define rules for each property that specify how data from different 
sources is merged. Ideally, there are a small number of common rules 
that can be referred to for each property. Examples: use the lowest 
number for the allowed bandwidth, disable codecs if they are disallowed 
in a data set.
-> This approach seems feasible, however, it requires the implementation 
of multiple merging rules.

The current drafts uses option 3. Are there any concerns, comments, 
thoughts on using this approach? Are we missing something?

Thanks!

Volker

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Apr 2007 11:58:10 -0400

I'm concerned about complexity and predictability. As soon as you  
allow merging or overriding, things can change mid-call if  
configuration data suddenly becomes available or changes (by  
notification).

While theoretically, multiple providers can provide input for many of  
the parameters, I think it would be worthwhile to look at the likely  
scenarios. For that, it would be helpful to have a more complete list  
of likely configuration parameters. I actually see restricting codecs  
as a somewhat unlikely configuration option, except for the most  
paranoid corporations.

On Apr 4, 2007, at 11:10 AM, Volker Hilt wrote:

> One of the remaining issues for config and policy data sets is  
> whether merging of data sets is needed or not.
>
> network provider, device provider and SIP service provider) and  
> needs to combine these sets into a single data set it can work  
> with. In principle, the following strategies exist for enable this:
>
> property. For example, define that codec usage can only be set by  
> the local network provider.
> -> It seems impossible to assign each property to exactly one  
> source. For example, if codec usage is assigned to the local  
> network provider, it can never be part of the user profile.
>
> 2. Define an order of precedence between sources so that, for  
> example, local profile overrides user profile and user profile  
> overrides device profile.
> -> This also does not seem to be practical. For example, a single  
> codec setting in the local profile would override all codec  
> settings in the user profile. Thus, the effects of the user profile  
> would depend on whether or not there is a local profile.
>
> 3. Define rules for each property that specify how data from  
> different sources is merged. Ideally, there are a small number of  
> common rules that can be referred to for each property. Examples:  
> use the lowest number for the allowed bandwidth, disable codecs if  
> they are disallowed in a data set.
> -> This approach seems feasible, however, it requires the  
> implementation of multiple merging rules.
>

---

From: Volker Hilt <[email-masked]>
Date: Wed, 04 Apr 2007 21:40:57 -0400

Henning Schulzrinne wrote:
> I'm concerned about complexity and predictability. As soon as you allow
> merging or overriding, things can change mid-call if configuration data 
> suddenly becomes available or changes (by notification).
> 
I'm not sure if this is specific to merging. Even if there is only one 
source for profiles, this source may suddenly update config data 
mid-call through a notify.

> scenarios. For that, it would be helpful to have a more complete list of 
> likely configuration parameters. I actually see restricting codecs as a 
> somewhat unlikely configuration option, except for the most paranoid 
> corporations.
> 
I think there are other examples as well in which it seems hard to 
assign a parameter to a specific provider. For example, a local provider 
as well as a SIP provider might want to restrict the use of video (both 
for different reasons). Or both providers may want to add a media 
intermediary. Or both want to restrict the bandwidth available for a 
session. Nevertheless, there might be parameters that can be assigned to 
a specific source. In this case, instead of specifying a merging rule, 
we might say that it can only come from a local/SIP/device provider.

The following drafts contain an initial list of configuration parameters 
for different areas:
- draft-petrie-sipping-profile-datasets-04.txt
- draft-petrie-sipping-sip-dataset-02.txt
- draft-petrie-sipping-identity-dataset-01.txt
- draft-petrie-sipping-voip-features-dataset-01.txt
- draft-ietf-sipping-media-policy-dataset-03

Thanks,

Volker

>> network provider, device provider and SIP service provider) and needs 
>> to combine these sets into a single data set it can work with. In 
>> codec setting in the local profile would override all codec settings 
>> in the user profile. Thus, the effects of the user profile would 
>> depend on whether or not there is a local profile.
>>
>> number for the allowed bandwidth, disable codecs if they are 
>> disallowed in a data set.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 14 Apr 2007 22:04:14 -0700

There is a third option which I have always been a fan of - basically  
do 1 below but then in the places where you do want two things, lets  
say, both local and network can set a max_bandwidth, well you have  
two things one call local_max_bandwidth and one called  
network_max_bandwidth. They are both separate fields and the  
application knows what to do with them.

This approach seems simple to understand, specify, and implement and  
even with the limitations of this approach, it is still easy to meet  
all the use cases people have proposed.

Cullen <with my individual hat on>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Apr 2007 10:10:57 -0400

On Apr 15, 2007, at 1:04 AM, Cullen Jennings wrote:

>
> There is a third option which I have always been a fan of -  
> basically do 1 below but then in the places where you do want two  
> things, lets say, both local and network can set a max_bandwidth,  
> well you have two things one call local_max_bandwidth and one  
> called network_max_bandwidth. They are both separate fields and the  

Since the application has to obey a single bandwidth limit, the  
application still has to decide that either local_max_bandwidth  
overrides network_max_bandwidth or the result is min(local_,  
network_). If you want predictable behavior, you presumably need to  
standardize which it is.

Thus, I don't see how this addresses the problem at hand.

>
> This approach seems simple to understand, specify, and implement  
> and even with the limitations of this approach, it is still easy to  
> meet all the use cases people have proposed.
>
>> settings in the user profile. Thus, the effects of the user  
>> profile would depend on whether or not there is a local profile.
>>
>> The current drafts uses option 3. Are there any concerns,  
>> comments, thoughts on using this approach? Are we missing something?
>>
>> Thanks!
>>
>> Volker
>>
>>
>>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 15 Apr 2007 07:18:09 -0700

Depending on the application, there are several generic criteria, such
as:

- Bandwidth,
- Latency,
- Number of IP routing hops (less chance for sudden non-transitivity and
routing flaps).

A network distance metric based on the above provides more flexibility
to the application. Some usage scenarios would be helpful here: Do I use
video or voice only, other apps beside voice? What about a conference or
chat room with widely distributed members?

Such choices should be left IMHO to the application in the endpoints and
just define the metrics. So don't standardize the choice, just provide
information to developers about the best way to use the metrics.

Henry

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2007 10:36:02 -0700

On Apr 15, 2007, at 7:10 AM, Henning Schulzrinne wrote:

>> called network_max_bandwidth. They are both separate fields and  
>> the application knows what to do with them.
>

I am off in the area of angels on a pin head here so forgive me but ....

The UA needs to know the semantics of local_max_bandwidth means do  
not exceed this. It needs to know the semantics of  
network_max_bandwidth means do not exceed this and it need to pay  
attention to all the config it received or things may not operate as  
expected. I do understand that that a min(a,b) does eventually get  
solved.

The meta point is that only a device that understands the semantics  
of these two things needs to try and know what to do with them or how  
to "merge" them. I don't think of it is merging, it is just using  
them. The merging stuff in the framework was designed such that a  
devices that *did not* understand the semantics of what some data  
item meant could still merge them. Originally people had the idea  
that there would be servers that collected up all the local, network,  
etc profiles for the UA and then merged the data on behalf of the UA  
then passed the merged result down to the UA. I see no need for  
theses types of servers.

I see no need for devices that don't understand the semantics of the  
data to be required to merge the data thus I see no need for the data  
to have self describing rules about how to merge it. I think it adds  
complexity and no one has presented a use case where it is useful.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 13:48:08 -0400

I think we agree that "blind" merging is of very little use, since  
merging two parameters that the client doesn't understand adds little  
value, except in displaying them to the user.

However, the question is what the parameter-related spec should say.  
If the spec does not indicate what a device that knows about  
bandwidth limits should do, it is likely that two devices will differ  
in their behavior. Thus, I think the spec has to specify "min 
(network, local)", say, for this particular parameter. After all,  
there are other semi-reasonable algorithms, such as picking one of  
the parameters (override) or the average or maybe even the maximum.

Otherwise, a network operator can't rely on what a properly  
configured device will do. In that case, configuration becomes  
meaningless and largely useless. Why specify a bandwidth limit if  
every device treats this differently, in unpredictable fashion?

Henning

On Apr 20, 2007, at 1:36 PM, Cullen Jennings wrote:

>> network_). If you want predictable behavior, you presumably need  
>> to standardize which it is.
>>
> attention to all the config it received or things may not operate  
> as expected. I do understand that that a min(a,b) does eventually  
> get solved.
>
> of these two things needs to try and know what to do with them or  
> how to "merge" them. I don't think of it is merging, it is just  
> using them. The merging stuff in the framework was designed such  
> that a devices that *did not* understand the semantics of what some  
> data item meant could still merge them. Originally people had the  
> idea that there would be servers that collected up all the local,  
> network, etc profiles for the UA and then merged the data on behalf  
> of the UA then passed the merged result down to the UA. I see no  
> need for theses types of servers.
>
> I see no need for devices that don't understand the semantics of  
> the data to be required to merge the data thus I see no need for  
> the data to have self describing rules about how to merge it. I  
> think it adds complexity and no one has presented a use case where  
> it is useful.
>

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Apr 2007 14:33:03 -0400

Henning Schulzrinne wrote:
> However, the question is what the parameter-related spec should say. If 
> the spec does not indicate what a device that knows about bandwidth 
> limits should do, it is likely that two devices will differ in their 
> behavior. Thus, I think the spec has to specify "min(network, local)", 
> say, for this particular parameter. After all, there are other 
> semi-reasonable algorithms, such as picking one of the parameters 
> (override) or the average or maybe even the maximum.
> 
I fully agree! I think a rule for merging should be part of the 
semantics of an element and therefore part of the document spec. It 
should enable a device that has received two documents to generate a set 
of properties it understands and can work with.

I believe this is essentially the approach we have taken in the current 
draft. For each element, there is one merging rule as part of the spec 
that explains what to do if someone receives multiple instance of this 
element. The common merging rules in the framework were an attempt to 
simplify the specification and implementations since many of the rules 
look alike. It was not intended that they are used blindly without 
knowing the semantics of a specific element. I guess this needs to be 
clarified in the draft.

Volker

> Otherwise, a network operator can't rely on what a properly configured 
> device will do. In that case, configuration becomes meaningless and 
> largely useless. Why specify a bandwidth limit if every device treats 
> this differently, in unpredictable fashion?
> 
 >
 > Henning
 >
>>>> well you have two things one call local_max_bandwidth and one called 
>> The UA needs to know the semantics of local_max_bandwidth means do not 
>> exceed this. It needs to know the semantics of network_max_bandwidth 
>> means do not exceed this and it need to pay attention to all the 
>> config it received or things may not operate as expected. I do 
>> understand that that a min(a,b) does eventually get solved.
>>
>> The meta point is that only a device that understands the semantics of 
>> these two things needs to try and know what to do with them or how to 
>> "merge" them. I don't think of it is merging, it is just using them. 
>> The merging stuff in the framework was designed such that a devices 
>> that *did not* understand the semantics of what some data item meant 
>> could still merge them. Originally people had the idea that there 
>> would be servers that collected up all the local, network, etc 
>> profiles for the UA and then merged the data on behalf of the UA then 
>> passed the merged result down to the UA. I see no need for theses 
>> types of servers.
>>

-- 
Volker Hilt                      Bell Labs / Alcatel-Lucent
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Apr 2007 14:54:56 -0400

I think Cullen and Henning have different conceptualizations of 
equivalent solutions.

What Cullen seems to say is that the UA is faced with a general 
constraint satisfaction problem: it must satisfy both the 
network-bandwidth parameter and the local-bandwidth parameter.

If both of those are maximum bandwidth values, then satisfying both of 
them does indeed mean conforming to the min of them. But you don't have 
to write that down anywhere - it is implicit in the semantics of the 
parameters.

	Paul

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Apr 2007 15:52:33 -0400

I think it is an advantage if this is written down explicitly in the 
document spec. This seems to produce more predictable results than if 
this is left to the interpretation of each implementation.

Also, it seems somewhat complicated to have a format in which the use of 
an element depends on the role the of the document source. It would for 
example require a server to check the profile type used in the 
subscription to find out if it is acting as local, device or user 
profile server and then use the correct elements when building its 
document. Also, some elements would be defined up to three times or more 
if new sources are added.

Volker

Paul Kyzivat wrote:
>> If the spec does not indicate what a device that knows about bandwidth

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 16:29:23 -0400

I suspect that there will be relatively few basic operations, just  
like we defined in the common policy. In other words, for numeric  
parameters, there will be either min() or max(), for server selection  
some prioritization (try X first) and for others, there may simply be  
a conflict that can't be resolved mechanically. Thus, labeling the  
classes of things is probably sufficient.

I'm not convinced that implicit semantics are a productive approach.  
We got some of it wrong on first writing in the common policy, after  
all.

On Apr 20, 2007, at 2:54 PM, Paul Kyzivat wrote:

> constraint satisfaction problem: it must satisfy both the network- 
> bandwidth parameter and the local-bandwidth parameter.
>
> If both of those are maximum bandwidth values, then satisfying both  
> of them does indeed mean conforming to the min of them. But you  
> don't have to write that down anywhere - it is implicit in the  
> semantics of the parameters.
>
> 	Paul
>
>> merging two parameters that the client doesn't understand adds  
>> little value, except in displaying them to the user.
>> However, the question is what the parameter-related spec should  
>> say. If the spec does not indicate what a device that knows about  
>> bandwidth limits should do, it is likely that two devices will  
>> differ in their behavior. Thus, I think the spec has to specify  
>> "min(network, local)", say, for this particular parameter. After  
>> all, there are other semi-reasonable algorithms, such as picking  
>> one of the parameters (override) or the average or maybe even the  
>> maximum.
>>>>> basically do 1 below but then in the places where you do want  
>>>>> two things, lets say, both local and network can set a  
>>>>> max_bandwidth, well you have two things one call  
>>>>> local_max_bandwidth and one called network_max_bandwidth. They  
>>>>> are both separate fields and the application knows what to do  
>>>>> with them.
>>>>
>>> The UA needs to know the semantics of local_max_bandwidth means  
>>> do not exceed this. It needs to know the semantics of  
>>> The meta point is that only a device that understands the  
>>> semantics of these two things needs to try and know what to do  
>>> with them or how to "merge" them. I don't think of it is merging,  
>>> it is just using them. The merging stuff in the framework was  
>>> designed such that a devices that *did not* understand the  
>>> semantics of what some data item meant could still merge them.  
>>> Originally people had the idea that there would be servers that  
>>> collected up all the local, network, etc profiles for the UA and  
>>> then merged the data on behalf of the UA then passed the merged  
>>> result down to the UA. I see no need for theses types of servers.
>>>
>>> think it adds complexity and no one has presented a use case  
>>> where it is useful.
>>>