Subject: RE: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

From: "Syrett, Mark" <[email-masked]>
Date: Mon, 30 Jul 2007 16:41:35 +0200

Hi,
 
a few commnents/questions/random thoughts:
 
re:
- the manner in which MS capabilities are described for Query can also
be used for In-Line and just passed as payload in the SIP INVITE toward
the MRB
 
I think this point is worth highlighting further in the document - most
scenarios I have seen can be handled in either model - think the
difference is in the complexity and whether or not the MRB should be on
the call signalling/media control path or not.
 
For example the conference examples below can be handled by passing the
conference policy information (size and other related resources) to the
MRB, then to the selected MS.
 
For conferencing there are other good reasons why you might want to have
conference policy information available on a MS anyway - some are
described in 3GPP 24.880 section 4.4.1 (use of media conference policy).
 
This information can also be updated mid-call - although this might
bring up discussions as to whether both the SIP and media server control
(in the case of a dedicated control channel) should go through an
in-line MRB. Chris any thoughts on this to put in the document?
 
Not much to say on the interfaces placeholder, don't care much about the
transport, think the contents are the interesting/hard bit:
 
MS Resource Consumer Interface 
=> For conferencing related information how about sending the related
XML bits of the XCON conference datamodel.
 
On the hybrid models - where would you put the MRB when the AS and MS's
are in different networks?
 
Finally a comment for clarification: Does the MRB as documented also
handle resource reservation - e.g. find and reserve resources for a 200
user conference for me starting in 2 hours? Is it limited to brokering
only with no advance reservation?
 
regards,
 
    Mark

Mark Syrett 

HP OpenCall
www.hp.com <http://www.hp.com/> 

________________________________

From: Chris Boulton [mailto:[email-masked]] 
Sent: 19 June 2007 15:55
To: [email-masked]; [email-masked]
Subject: RE: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

Hi Gary - thanks for the review.  I have noted the changes for the next
version of the document (when we have more comments - hint hint :-)).

More comments in-line.

Chris.

1) It should be explained that the Query Model more naturally can
support a broader set of potential requirements than In-Line.

a. For example, with In-Line, presumably the MRB is left to determine
that a MS resource is freed up when a call leg to it is ended (i.e.
seeing a SIP BYE). Whereas with Query, it is the AS that determines when
a MS resource is to be freed up. That may be critical, for example for
conferencing, where participants may be taking an ad-hoc brief coffee or
lunch break and some callers temporarily drop off; the AS doesn't want
those port resources released and thrown back into the pool because
those will be shortly in use again, so it should be up to the AS to
decide when ports are freed up.

[Chris Boulton] Good point.

b. As another example, again for conferencing, suppose the AS initially
requests MS resources for a conference for 50 ports. An hour into the
conference only 10 ports may be in use, so the AS can tell MRB it is
releasing, say, 35 of the originally requested ports.

c. As another example, Query can straightforwardly allow you some mild
negotiation. AS may ask for a port that can do DTMF and/or speech
recognition, and MRB might not have such a port available, but could
respond to the AS with a DTMF-only port. AS could accept it or not.

[Chris Boulton] It does help with such models.  Let the AS decide if
what is provided is 'good' enough.

2) In-Line may be fine for some scenarios, for example IVR where it's
obvious that when the call leg clears from the MS that the MS resource
is indeed intended to be freed up, and assuming you don't care about (c)
above.

You make the important observation in Section 4.2 that with In-Line the
MRB functionality may have to get a lot more complicated wrt looking
inside messages/message manipulation, including control protocol; and I
agree. I would personally not be in favor of that complexity, and MRB
would have to be renamed to MRBroker/Meddler. But, as just observed,
depending on the scope of application for a given scenario, such as
perhaps IVR, In-Line works fine without hitting that level of
complexity. 

[Chris Boulton] Agreed.

3) As you can probably tell by now, I think that a solution/tool kit
should allow both models. If you have Query, then you also basically
have In-Line because

- as you already say about the "Media Server Resource Publishing
Interface": it can be the same for In-Line as Query

- the manner in which MS capabilities are described for Query can also
be used for In-Line and just passed as payload in the SIP INVITE toward
the MRB

4) Regarding placeholder section on MS Resource Publishing Interface
(5.1), my initial thoughts are

SNMP - you're probably going to want an 'operations' interface like this
for certain reasons anyway; e.g. for MRB to know about planned/unplanned
MS downtime, or potentially as a way of telling MRB about conference
reservations, or setting other rules about which ASes (or services) can
have what portion of the MS pool when push comes to shove

Control Channel - Huh??

[Chris Boulton] So making use of the Control Framework (new package) for
interactions with an MRB.

SOAP  - Maybe.

SIP Publish or Subscribe - Maybe.  And with Subscribe are you thinking
along the lines of Presence?

[Chris Boulton] Not really.  Just using RFC 3265 mechanisms + RFC 3903
for resource state reporting/querying.

5) Regarding placeholder section on MS Resource Consumer Interface
(5.2), my initial thoughts are

SNMP - Huh??

[Chris Boulton] could not the MRB seen as an operations entity that can
convey am accumulated view?

Control Channel - Huh??

[Chris Boulton] as above for other interface.

SOAP - Good choice. Low overhead and suffices. I don't see it as a
hardship for a SIP AS to be doing SOAP/http for this. Would want to be
clear on exactly what value-added SOAP has over the use of straight
http. 

[Chris Boulton] I quite like this one as well.  Not so sure about the
requirement for 'pushing' state on change.  Is this just a query?

SIP Publish/Subscribe - Doesn't seem as straightforward. 

6) Hopefully we all agree that the algorithm that the MRB uses to select
MS resources is out of scope, and so we should say that. It could be
simple or sophisticated; not our concern. 

[Chris Boulton] Agreed.

7) Editorial nit. I would not say that the difference between Query and
In-Line is 'subtle' (section 4.2 first sentence).

[Chris Boulton] I will change the language.

cheers,

Gary

________________________________

From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, June 07, 2007 8:12 AM
To: [email-masked]
Subject: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

Hi All,

As promised on a call a couple of weeks ago, Roni and I have put
together a discussion document for Media Resource Brokering.  This is a
very rough '00' and we are looking for lively discussion and ideas to
expand for the Chicago meeting.  Until it appears in the archives it can
be retrieved form the following link -
http://www.ubiquitysoftware.com/goto/mediactrl/draft-boulton-mediactrl-m
rb-00.txt.

Best Regards.

Chris & Roni.

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. Ubiquity Software Corporation plc, a company registered
under the laws of England and Wales, Registration 2719723, registered
offices at Eastern Business Park, Building 3, Wern Fawr Lane, St.
Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Mon, 30 Jul 2007 11:56:50 -0400

Hi Mark,

A few thoughts in response below ( <Gary: ...> )

cheers,

Gary

From: Syrett, Mark [mailto:[email-masked]] 
Sent: Monday, July 30, 2007 10:42 AM
To: Chris Boulton; MUNSON, GARY A (GARY A); [email-masked]
Cc: Syrett, Mark
Subject: RE: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

Hi,

re:

For example the conference examples below can be handled by passing the
conference policy information (size and other related resources) to the
MRB, then to the selected MS.
<Gary: I don't see how "in-line" handles some of the examples, unless
you award more functionality to the MRB or MS that seems less
straightforward/clean to me. I.e., mild negotiation with the MRB about
what's acceptable to the AS; or decide whether to free up or request
more ports (without the AS knowing?), or connecting together multiple
MSes for a large conference that spans them. >

For conferencing there are other good reasons why you might want to have
conference policy information available on a MS anyway - some are
described in 3GPP 24.880 section 4.4.1 (use of media conference policy).
<Gary: Despite my other comments here, I can appreciate that having some
of the conference policy info at an MS may be useful, however it may be
conveyed to the MS.>

This information can also be updated mid-call - although this might
bring up discussions as to whether both the SIP and media server control
(in the case of a dedicated control channel) should go through an
in-line MRB. Chris any thoughts on this to put in the document?
<Gary: Having AS-MS control channels go through MRB doesn't feel like a
good approach to me. We'd be funneling a lot of traffic through MRB that
it doesn't care about in order for it to find/act on the little bit it
might possibly. On the other hand, if you don't do that, it raises the
question for the in-line option of what the mechanics are for an AS to
know which already-existing control channel to use or to what MS it
should set one up. >

<Gary: Seems to me that MRB must know about and handle reservations.
Otherwise it may assign resources to spontaneous conferences that would
be needed later for reserved conferences; or else we've split the MS
shared resources into reservationless and reservationed and excluded MRB
from the latter, which is a self-defeating constraint. Reservation
requests would come to MRB through some kind of service support system
or from an AS. You may also want to reserve some amount of resources on
a per-'service' basis, even for IVR applications, so one service can't
hog all the resources, and it could vary by schedule.  So I think
there's a fundamental necessity/assumption that MRB handles
reservations, and the question is whether the Mediactrl group chooses to
address that aspect or decides it's out of scope. The content of a
reservation request would certainly look very much like a spontaneous
request, wherever it comes from, SSS or AS ...>

regards,

    Mark

Mark Syrett 

HP OpenCall

More comments in-line.

Chris.

[Chris Boulton] Agreed.

Control Channel - Huh??

SOAP  - Maybe.

SNMP - Huh??

Control Channel - Huh??

 

[Chris Boulton] Agreed.

cheers,

Gary

Hi All,

Best Regards.

Chris & Roni.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 31 Jul 2007 09:36:46 +0100

[Chris Boulton] From a Media resources perspective (Not just simple
server selection - load-balancing) I would like to delve a little deeper
into these topics.  By abstracting the 'selection' away from the
Application layer I wonder if we are adding unwanted complexity.  By
co-locating the application logic and the selection point you provide
the ability to make dynamic decisions based on the 'query' operation.  A
simple, contrived example could be:

1)      I have a conferencing app which also supports text.

2)      I create a conference instance on my app server and dispatch the
'create conf' request to my in-line MRB.

3)      The MRB takes a look at all the MS is has on offer -it has
plenty of Media resources BUT none that can support text - what does it
do?  Reject?  Have a voice only conference?  This is really the decision
of the application.  It might have some reason that text MUST be
supported and so abandons the operation OR it might be lenient and
continue.

Before we move onwards with the 'in-line' discussion I would like to
discuss the general concepts.  Does an 'in-line model really provide the
functionality that we (as MediaCtrl) require?  What does this doc need
moving forward.  My proposal is to fully document both deployment models
BUT concentrate on the interfaces for 'Query'.

[Chris Boulton] Agreed.  And we will kick that off in phase 2 before
Vancouver.

[Chris Boulton] Being the IETF we should certainly take such factors
into account when selecting interface protocols.

[Chris Boulton] Resource reservation was decided to be out of scope for
the MediaCtrl group.

regards,

    Mark

Mark Syrett 

HP OpenCall

  _____  

More comments in-line.

Chris.

[Chris Boulton] Agreed.

Control Channel - Huh??

SOAP  - Maybe.

SNMP - Huh??

Control Channel - Huh??

 

[Chris Boulton] Agreed.

cheers,

Gary

  _____  

Hi All,

Best Regards.

Chris & Roni.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 31 Jul 2007 09:43:23 +0100

[Chris Boulton] Some more comments in-line.

Chris.

Hi,

re:

[Chris Boulton] Agreed - I think this is a similar point to my previous
mail.

[Chris Boulton] Also agreed.  Certainly in the XCON model I can see
policy residing close to the conference Focus.

[Chris Boulton] The MRB would provide a resource address - that resource
address would be associated with a control channel - if it doesn't exist
then create one.

[Chris Boulton] This 'currently' out of scope for the group.  I think we
need to hit our current charter targets and then if we all fancy a trip
down a rat hole we should buckle up and enjoy the ride :-).

Chris.

regards,

    Mark

Mark Syrett 

HP OpenCall

  _____  

More comments in-line.

Chris.

[Chris Boulton] Agreed.

Control Channel - Huh??

SOAP  - Maybe.

SNMP - Huh??

Control Channel - Huh??

 

[Chris Boulton] Agreed.

cheers,

Gary

  _____  

Hi All,

Best Regards.

Chris & Roni.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 31 Jul 2007 11:14:57 +0200

Hi all,

a small comment inline upon resource reservation.

> down a rat hole we should buckle up and enjoy the ride :-).

I was a strict 'defender' of the needed support for resource reservation in
MediaCtrl, expecially considering the conferencing scenario. But after
discussing this issue with other people in the group, I finally understood that
this is definitely all application logic, and so is, and should remain, out of
scope here.

To make a very basic example, an AS who has been requested the schedulation of a
conference on thursday at 4 PM might create such a conference on the MS let's
say a couple of hours before, though actually attaching users at it only when
it's time. It's a quite dumb example, which nonetheless clarifies how an AS can
handle this burden itself according to any kind of custom policy and logic it
thinks is better.

Regards,
Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Tue, 31 Jul 2007 09:58:38 -0400

Hi Lorenzo, Chris, & co

Another small comment, also acknowledging Chris's other email that reservation is out of scope. I'm okay with that, as a means of managing the current work as Chris said.

I'm not on the same page with Lorenzo's comment below that ' it is definitely all application logic ' as a rationale for being out of scope. 

I simply offer that as an observation/mental footnote that I'm happy to discuss further with anyone by way of example scenarios. If so, perhaps better done directly with me and *off* the mediactrl exploder, since it's on an out-of-scope topic. 

cheers,

Gary

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2007 5:15 AM
To: Chris Boulton
Cc: MUNSON, GARY A (GARY A); [email-masked]
Subject: RE: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

Hi all,

Regards,
Lorenzo

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 31 Jul 2007 18:48:34 +0200

Dear all,

just my two cents. I share Gary's viewpoint. As I said at the meeting, I think
that QoS issues might be dealt with at least "slightly", by providing hooks to
the right frameworks which are currently addressing dynamic (policy-based)
management of heterogeneous networks. This is especially true in case we also
consider the "time" dimension (e.g. time-aware resource reservation) as part of
the game.

In such cases, the in-line model involving the MRB (do you remember things like
the old-fashioned Diffserv Bandwidth Broker??) might play a crucial role.

Cheers,

Simon

-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: [email-masked]

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

Scrive "MUNSON, GARY A (GARY A)" <[email-masked]>:

> Hi Lorenzo, Chris, & co
> 
> Another small comment, also acknowledging Chris's other email that
> reservation is out of scope. I'm okay with that, as a means of managing the
> current work as Chris said.
> 
> I'm not on the same page with Lorenzo's comment below that ' it is definitely
> all application logic ' as a rationale for being out of scope. 
> 
> I simply offer that as an observation/mental footnote that I'm happy to
> discuss further with anyone by way of example scenarios. If so, perhaps
> better done directly with me and *off* the mediactrl exploder, since it's on
> an out-of-scope topic. 
> 
> cheers,
> 
> Gary
>