Subject: RE: [MEDIACTRL] Charter

From: "Chris Boulton" <[email-masked]>
Date: Wed, 3 Jan 2007 10:32:15 -0000

I agree with Cullen.  In the first instance (Charter), we need to make
sure we don't bite off more than we can chew in this area.  We can
always revisit and revise our goals at a later date if all goes well and
be are feeling brave :-).  So MS 'reporting' simple capability sets and
AS 'getting' a list of available servers (and there basic capability
sets) seems fine to me for a first hurdle (bearing in mind that this is
only a side portion of the primary goals of this group).

Chris.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: 02 January 2007 22:06
To: Media Ctrl
Subject: [MEDIACTRL] Charter

This thursday, I am going to put the Charter on the agenda for the  
IESG call on Jan 11. After this it will probably go out for IETF wide  
review. There is only one area I still have concern with it and it is  
about the media  broker stuff. It wold be nice if we could sort this  
out before this thursday but if we don't, I am putting it on the  
agenda with the current wording and we can sort it out during the  
IETF wide review period.

The text I am taking about is:

         4. Means for locating, and possibly establishing sessions  
to, media servers with appropriate resources at the request of  
clients. By appropriate, we mean the characteristics of a given media  
server required or desired for handling a given request and the  
overall efficient use of a pool of media servers.

I have no problem with a server reporting it capabilities, like it  
can do transcoding from 729 to GSM or it is supports some PDU.  I  
have no problem with clients somehow finding a list of server names  
they talk to or being configured with this list. The problem I worry  
about getting into is a complex optimal server usage question like  
where an application wants to be able to ask some service "please  
tell me a server that can be reserved to do 100 channels of G.729  
conferencing and can also can do 10 channels of H.264 video mixing  
with the following resolution of video".  Having a service that can  
figure out what is the best server to meet the needs of this request  
is a thorny problem - particularly if one allows for reservations. Do  
you pick the least loaded server? If you have two servers that could  
do it but only one of them has speech rec do you use the one that  
does not have speech rec since you might want to keep that server  
clear for applications that need the speech rec?

So, I'm open to where we want to draw the line on or the initial work  
- somewhere between minimal capabilities descriptions and advanced  
reservations for specific services. I lean strongly towards the  
simple end of this line. The "overall efficient use of a pool of  
media servers" scares me a little bit. If we could find some  
agreement on what level of complexity we want to tackle, then get  
some text to match that, it would make me happy :-)

PS - the version of the charter I have is attached - if this does not  
look like the latest version, whack me before I send it to the IESG :-)

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 3 Jan 2007 14:15:24 +0200

Hi,
I support Chris view, the text looks fine to me
Roni

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2007 12:32 PM
> To: Cullen Jennings; Media Ctrl
> Subject: RE: [MEDIACTRL] Charter
> 
> Information contained in this e-mail and any attachments are intended
for
> the use of the addressee only, and may contain confidential
information of
> Ubiquity Software Corporation.  All unauthorized use, disclosure or
> distribution is strictly prohibited.  If you are not the addressee,
please
> notify the sender immediately and destroy all copies of this email.
> Unless otherwise expressly agreed in writing signed by an officer of
> Ubiquity Software Corporation, nothing in this communication shall be
> deemed to be legally binding.  Thank you.
> 
>

---

From: <[email-masked]>
Date: Wed, 3 Jan 2007 10:34:18 -0500

I'm okay with the changed wording (eliminating the problematic phrase)
as per Dave Burke.

The choice of algorithm that a media resource broker runs to select
particular media resources should be left to the service provider. I.e.,
that "thorny problem" is out of scope. However, the media resource
broker has to be able to get sufficient information about
characteristics of a conference or IVR session from the AS/client in
order for the media resource broker to run its algorithm. I believe that
problem is in scope, is not thorny, and the changed wording still allows
for it. (Whether it's viewed as a work priority is another matter.)  

cheers,

Gary

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Wednesday, January 03, 2007 7:15 AM
To: Chris Boulton; Media Ctrl
Subject: RE: [MEDIACTRL] Charter

Hi,

for
information of
please

---

From: "Adnan Saleem" <[email-masked]>
Date: Wed, 3 Jan 2007 09:41:31 -0800

I also agree with the view posted here by Gary and others.
The modified statement, removing the problem phrase, as Dave 
had suggested is okay with me.

However, I also feel that just knowing the capability set and
and list of available servers will not be enough, as the load
condition of the servers and the availability of the resources they 
control (eg: conference mixers, etc) would be needed by the media 
resource broker for it to adequetly perform its broker function.

Adnan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: January 3, 2007 7:34 AM
To: [email-masked]; [email-masked];
[email-masked]

I'm okay with the changed wording (eliminating the problematic phrase) as
per Dave Burke.

The choice of algorithm that a media resource broker runs to select
particular media resources should be left to the service provider. I.e.,
that "thorny problem" is out of scope. However, the media resource broker
has to be able to get sufficient information about characteristics of a
conference or IVR session from the AS/client in order for the media resource
broker to run its algorithm. I believe that problem is in scope, is not
thorny, and the changed wording still allows for it. (Whether it's viewed as
a work priority is another matter.)  

cheers,

Gary

-----Original Message-----
From: Even, Roni [mailto:[email-masked]]
Sent: Wednesday, January 03, 2007 7:15 AM
To: Chris Boulton; Media Ctrl
Subject: RE: [MEDIACTRL] Charter

Hi,
I support Chris view, the text looks fine to me Roni

> agenda with the current wording and we can sort it out during the IETF 
> wide review period.
> 
>          4. Means for locating, and possibly establishing sessions to, 
> media servers with appropriate resources at the request of clients. By 
> appropriate, we mean the characteristics of a given media server 
> required or desired for handling a given request and the overall 
> efficient use of a pool of media servers.
> 
> I have no problem with a server reporting it capabilities, like it can 
> do transcoding from 729 to GSM or it is supports some PDU.  I have no 
> problem with clients somehow finding a list of server names they talk 
> to or being configured with this list. The problem I worry about 
> getting into is a complex optimal server usage question like where an 
> application wants to be able to ask some service "please tell me a 
> server that can be reserved to do 100 channels of G.729 conferencing 
> and can also can do 10 channels of H.264 video mixing with the 
> following resolution of video".  Having a service that can figure out 
> what is the best server to meet the needs of this request is a thorny 
> problem - particularly if one allows for reservations. Do you pick the 
> least loaded server? If you have two servers that could do it but only 
> one of them has speech rec do you use the one that does not have 
> speech rec since you might want to keep that server clear for 
> applications that need the speech rec?
> 
> reservations for specific services. I lean strongly towards the simple 
> end of this line. The "overall efficient use of a pool of media 
> servers" scares me a little bit. If we could find some agreement on 
> what level of complexity we want to tackle, then get some text to 
> match that, it would make me happy :-)
> 
> 
for
information of
please

---

From: "Dave Burke" <[email-masked]>
Date: Thu, 4 Jan 2007 10:26:40 -0000

Certainly, an ideal MRB does need to know the load condition of the 
resources it distributes over. However, (and to expand upon my rather terse 
"I agree" to Cullen's e-mail), a load-sensing MRB is IMO a "Charter 2.0" 
work item because:

o A "first generation" solution can live without [knowing the load 
condition] when one involves random/round robin distribution over homogenous 
groups - homogenity can be ascertained via capability set knowledge.

o The type of protocol for communicating load condition is likely to be 
different to one for MS control (e.g. an optimum solution might use 
lightweight transport such as UDP, involve some kind of heartbeat reporting, 
and may use an existing OA&M protocol).

o As per Chris, we ought not attempt to standardise everything at once. 
Coming up with a standard MS ctrl protocol and a framework for admitting an 
MRB will be an admirable accomplishment in itself. Further, allowing for 
vendor differentiation (e.g. in how load condition is determined) is not in 
the first instance a necessarily bad thing.

Dave

----- Original Message ----- 
From: "Adnan Saleem" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 03, 2007 5:41 PM
Subject: RE: [MEDIACTRL] Charter

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 4 Jan 2007 12:43:34 +0200

David,
I think I agree with Adnan,
As long as you are talking about single connections like IVR or announcement and one media like audio conferencing, this is simple. 
My view is that we have in scope also multimedia (voice, video, data, IM) conferencing and the information that is needed is more important to enable optimal usage.
Roni Even 

> From: Dave Burke [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 12:27 PM
> To: Adnan Saleem; [email-masked]; Even, Roni;
> [email-masked]; [email-masked]
> Subject: Re: [MEDIACTRL] Charter
> 
> as
> broker
> > thorny, and the changed wording still allows for it. (Whether it's
> viewed
> > as