Subject: Re: [MEDIACTRL] MRB!!!!

From: "Lorenzo Miniero" <[email-masked]>
Date: Sat, 06 Jun 2009 11:39:23 +0200

Hi Gary,

first of all thanks a lot for your comments, they're really
appreciated! We definitely need feedback from people who
will actually be using this.

I'm writing just for a few thoughts about your interesting
considerations. First of all, before proceeding with your
answer to Chris, I'd like to discuss with you about comment
[C] from your previous mail, since it actually is the base
upon which all the discussion then unwinds.  In comment [C]
you said that it's the MRB which is interested to the
information which may or may not be provided, and not the
ASs as we stated in the paper. Thinking about it, it's
probably a matter of perspective on the role the MRB is
actually supposed to cover. From my understanding, its
purpose is mainly of assisting (especially in the Query
mode) an interested AS in locating resources, by providing
it with the related information which could help it in
choosing a MS rather than another. So, something like, AS:
"I need an IVR dialog with these codecs", MRB: "OK, MS1,
MS4, and MS5 are able to give you that right now". Looking
at it like that, the ASs can be seen as the interested
parties in comment [C]. But in case the MRB is actually
relaying the requests and taking the resources on behalf of
the AS, it's like you envisage it instead (AS: "I need an
IVR dialog with these codecs", MRB: "OK, I've prepared the
resources on MS4, use those"). I can see such an approach
for the Inline model (at least in a indirect way, sine the
MRB would act as a proxy for the MediaCtrl and SIP
signaling), but I find it difficult to imagine it for the
Query model as well. I'm not saying it's wrong, just
different from how I've been seeing it so far, which of
course affected my way of writing the text in the document.
What is your view on how it all works?

Of course, considering the diverging perspective, use cases
also unwind in a different way. So, coming back to your
latest mail and starting from the previous cosiderations,
I've given some thoughts on your second point. From how I
see it (which means, from my perspective of the MRB as said
before), it's hard to make that distinguo between
reservation and 'reservation', especially if you look at how
the MediaCtrl framework is conceived. In fact, you can be
really sure you're actually taking a resource only once you
negotiate it, which means only once you have made the MS and
the UAC create a media channel between each other, and set
up the codecs. Same thing for what concerns dialogs and
mixers.

That said, saying, to recall your example, "I need 100
conference ports now" may be considered simple or not:

    (i) you could create a conference with the mixer control
package and specify the number of listeners and talkers
according to your requirements; anyway, this would assume
the invoked implementation of the package actually reserves
the needed resources, which cannot be given for granted; in
fact, an implementation may see those attributes just as
thresholds after which joins must be refused, and/or as
policies to follow when changing the role of existing
participants in the conference (e.g. muting/unmuting
participants depends on the available talker seats);

    (ii) or, you could have the AS (or MRB) originate the
100 calls you need as placeholders, and then udate the
sessions whenever those placeholders must be replaced by
real users; this may also work for the scenario you were
considering ("I'm dropping 25 of the 50 ports I reserved")
since you would just need to tear down some of the
placeholders; of course, this is all but an elegant
solution, quite a very ugly workaround indeed, but as I see
it it would be the only way to be sure the chosen MS won't
give the resources you need to someone else.

So, to summarize, I guess the real question I'm asking
myself is this: when an AS needs some resources, is it going
to query the MRB for available resources according to its
requirements, and according to the response pick an MS and
use it (MRB as an assistant), OR is it going to place a
request to the MRB describing all it needs, so that the MRB
actually takes the resources on the MS it deems more apt to
the scenario and pass them to the AS?

Thanks,
Lorenzo

----- Original Message -----
From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
To: "Chris Boulton" <[email-masked]>,
<[email-masked]>
Subject: Re: [MEDIACTRL] MRB!!!!
Date: Fri, 5 Jun 2009 13:45:38 -0400

> Hi Chris,
> 
> Thanks for the reply.
> 
> I'm pulling out two things here (rather than embed below
> replies to your replies) for further, hopefully
> self-contained, discussion. 
> 
> 1) Regarding In-Line and whether AS should provide MRB
> with the same attribute list as it does with Query - I
> would suggest making it optional, but not mandatory. Then
> the AS could be as simple as you suggest by not supporting
> that. Or it could employ the attribute list and gain its
> benefits. For the latter, yes the AS is more complicated,
> but doesn't have to support a separate interface to MRB as
> it does with Query. My thinking is also that In-Line (with
> attribute list) might suffice for IVR typically or
> lightweight conferencing, whereas you'd go to Query for
> large/more sophisticated conferencing scenarios or maybe
> 'interesting' IVR cases. But there's also the aspect of
> the particular application/AS identifying itself to MRB so
> MRB can potentially allocate resources differently for
> different applications. Even if MRB could infer that in
> some way from, say, SIP message header content, I would
> argue for separation of concerns.
> 
> 2) On the reservation theme. There's reservation, and then
> there's reservation.
> a) I want to have a conference call next Wed. with 100
> participants. Yes, I understand that kind of reservation
> to be out of scope. And that's fine because I think it is
> a separable topic. b) I (as an AS) want a conference call
> 'now' that will have up to 100 participants. Or I (as an
> AS) want up to 200 ports starting 'now' for some
> anticipated bursty high-volume, short holding time IVR
> application - so I don't need to bother going back to MRB
> for each of the huge rate of individual calls that will
> occur in, say, the next hour or so. Those are the kinds of
> things I was considering below. I didn't think covering
> those kinds of important scenarios was out of scope, and
> is partly what motivates a Query mode approach to begin
> with. And it's arguable whether it's reservation. The 100
> ports for conferencing or the 200 ports for IVR may fill
> up arbitrarily fast. So is it reservation or not
> reservation? Who knows? Besides, even if one calls it
> reservation, however temporary, that's what Query mode
> does in *all* cases: AS makes a request, MRB identifies a
> resource back to AS, but MRB doesn't really know
> whether/when the AS uses it. The basic ingredients that I
> think are needed with Query mode (doesn't make sense with
> In-Line) are
>  - AS can ask for multiple ports/resources for call legs
> with one query
>  - AS declares when it's done with the resources
>  - AS can revise the request
> Without those we run the risk/greater risk of undesirable
> situations like
>   - AS gets surprised when it needs 100 ports for a
> conference and on the 50th MRB
>     says it can't provide any more
>   - MRB may more likely have to provide ports across
> multiple MSes for the 
>     same conference (because it didn't know 100 were
> needed to begin with)
>   - conferees who temporarily dropped off a conference
> can't get back on because
>     meanwhile MRB assigned their ports to some other AS
> for something else
>   - that intense IVR application can't get the resources
> it needs, or it overloads MRB
> Again, I'm simply trying to address real use cases that I
> think need to be supported in a sufficient manner. 
> 
> cheers,
> 
> Gary
> 
> -----Original Message-----
> From: Chris Boulton [mailto:[email-masked]] 
> Sent: Friday, June 05, 2009 12:16 PM
> To: MUNSON, GARY A, ATTLABS
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] MRB!!!!
> 
> Hi Gary - some comments in-line.  Thanks for the input.
> 
> Chris.
> > Substantial comments:
> >
> > A) Here are a few elements that I believe should still
> be added for the
> > Consumer Interface 5.2.1.1. I don't recall any
> unfavorable discussion on
> > these, and thought there was some favorable discussion
> >     ...  - application identifier (e.g., Consumer Gold
> > or American Idol 8YY or Gov't Emergency Conferencing
> >    ...) - geo preference of MS resources location
> >    - operator-specific characterization of MS resources
> (e.g., 'red' or
> > 'blue')
> >   [--> Because MRB may not treat all applications alike
> when it comes to
> > allocation; picking a bridge close to the majority of
> > conferees helps QoS and reduces cost; and allowing
> operator-specific shorthand labeling
> > can cure a lot of ills and may be how operators prefer
> > to more simply manage the MS resource pool to begin
> with.] >
> >   
> [Chris] These are listed in the candidates for the
> Consumer interface  and will be sent to the list when we
> move on to that topic (should be  next week).
> > B) Section 4.2 In-line MRB. The AS should be able to
> pass the same kind
> > of attributes to the MRB in In-Line mode as Query Mode,
> > in which case the section should be revised to that
> effect. I.e., pass payload in the
> > SIP INVITE to the MRB with desired MS resource
> > attributes. [--> Because it makes In-line much more
> useful, and MRB can use the same
> > information from AS for In-Line as for Query mode. And
> > seems straightforward to allow.]
> >   
> [Chris] This is worth looking at in more detail.  I had
> always thought  of an in-line MRB as being the indirection
> for an AS that has not  implemented the consumer interface
> and is not 'MRB-Aware'.  In this case
> 
> it can simple add a SIP hop to the MRB and let it sort out
> the media  resource.  Making the AS have to implement a
> mechanism to supply the MRB
> 
> with information means that it needs to comply - in which
> cased wouldn't
> 
> it just implement the consumer interface?  I am not saying
> I am against  this - but I am trying to understand the use
> cases for it.
> 
> > C) Section 3 Problem Discussion, last paragraph starting
> > "Please note that, while the MRB ..." Change to -
> >     "Note that while the Publishing interface provides
> > MRB with information on available Media Server resources
> , there may be additional
> > information important or even critical for MRB to have
> > in order to perform its task, but that is outside the
> > scope of the Publishing interface. For example,
> > reservation requests, MS resource allocation rules
> across different application types, planned or unplanned
> > downtime of MS resource, the planned addition of future
> > MS resources and the like."
> >   [--> Because the current wording says this is stuff
> > the AS wants to know, and that's really not the case.
> > It's MRB that wants to know this stuff.]
> >   
> [Chris] TODO list for next version.
> > D) It would be highly desirable to address the use case
> where an AS can
> > revise its original request upward or downward. This is
> > especially important for conferencing. For example an
> initial AS request may be for
> > 50 ports for a conference, but after a half hour and
> only 10 conferees,
> > the AS may choose to relinquish say 25 of the 50 ports.
> Has application
> > to peaky/bursty IVR uses as well. For Query mode only,
> >   of course. 
> [Chris] So currently we don't cover resource reservation
> (based on  discussion previously).  The current direction
> of the MRB is that is  mediates between supplying a view
> of the media resources so that the AS  can make an
> informed decision.
> 
> > E) Need to address the case for In-line of how MRB
> > responds to AS when there are no acceptable MS resources
> > available. Return a <mediaResourceError> element, same
> > as for Query mode, but in a SIP Response?
> >   
> [Chris] Yes - we definitely need to talk more about
> in-line operation  and how it handles such cases.  For
> query, currently the thinking is  that it provides
> potential resources and then if it can't be serviced  when
> the request arrives - SIP does its thing.  I would suggest
> that an  in-line MRB would act the same.
> > F) Need to explicitly address the topic of how with
> > Query mode the MRB knows when MS resources are to be
> freed up. We have had some discussion
> > on this. I would argue that we need the AS to explicitly
> > tell MRB, rather than MRB inferring status info over the
> > Publish interface. Because especially for conferencing,
> the fact that a conferee drops does
> > not imply that the port should be freed up. For example,
> > conferees may temporarily drop on a conference break
> > (coffee, lunch, bathroom) or to temporarily move to
> > another call. The AS is in the best position to decide
> when the resources are to be freed up, and therefore to
> > declare so to MRB. Likewise, an IVR type application/AS
> could request a block of
> > MS ports for some peaky-bursty application, and that AS
> > should decide when the block (or some portion) is no
> longer needed. >
> >   
> [Chris] See earlier mail on resource reservation.
> > G) For reliability, perhaps we should consider for Query
> > mode a capability for MRB to question an AS as to
> > whether a particular prior resource request is still in
> effect. E.g., to address the case where an
> > AS got sick and didn't/couldn't tell the MRB to free up
> resources.  >
> >   
> [Chris] See earlier mail on resource reservation.
> > H) General thought on relationship between the Consumer
> > and Publishing interfaces: As a sanity test, it would
> > seem that a MS characteristic should be provided to MRB
> > on the Publishing interface if and only if it's a
> characteristic that an AS can ask for, either explicitly
> > or implicitly.  Side thought: it may be worthwhile
> > putting in a comment that with In-Line mode the MRB can
> > optionally factor in the INVITE SDP info for selecting
> > MS resources, hence influencing the
> granularity/extensiveness of some of the Publishing
> > interface content opposed to the Consumer interface
> content. >
> >   
> [Chris] Agreed.  We definitely need to look at both
> interface and check  the relationship.  I was expect this
> to be an exercise for the next  version which will have
> much more substance to the interface definitions.
> > Editorial comments:
> >
> > 1) Suggestion: Section 2, for both Query MRB and In-line
> > MRB def'ns, instead of saying 'instantiation', say
> >    "operating mode".  [  --> Because the word
> > instantiation has connotations of a particular
> manifestation or particular concrete instance, whereas
> > Query and In-line are two conceptual/functional modes of
> > MRB. A particular instantiation could actually provide
> both modes.] >
> > 2) Section 2, In-line MRB def'n - Delete last sentence
> >    (or clarify).  [--> Because the statement 'decision
> making process' belonging to MRB
> > is not a distinguishing factor between Query and
> > In-line. In either case, it is the MRB that decides
> which MS resource.] >
> >   
> [Chris] All editorials are noted for the next version.
> 
> Chris.
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On
> > Behalf Of Chris Boulton
> > Sent: Thursday, May 21, 2009 12:28 PM
> > To: [email-masked]
> > Subject: [MEDIACTRL] MRB!!!!
> >
> > Hi fellow media controllers,
> >
> > As you might have noticed, a new version of the Media
> > Resource Broker  (MRB) draft has been submitted to the
> archives and can be retrieved from
> >
> > the following link - 
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-00.txt.
> >   This draft signifies the final major piece of work
> that this group needs
> >
> > to complete and the authors kindly request one final
> > effort from you  all.  YOUR WORK GROUP NEEDS YOU!!!!.
> >
> > In summary, the authors have started fleshing out the
> draft as the first
> >
> > adopted work group version.  We would like the next
> > version to be  extremely well baked and be as close as
> > possible to WGLC.  This will  take a big effort and so
> > your continued help is vital.  The main area  that needs
> > work is the definition of the 'Consumer' and 'Publisher'
>  interfaces.  We would firstly like your opinions on the
> raw content of
> 
> > the interfaces so that we can come to an agreement that
> > can then be  crafted into the appropriate definitions
> for the next versions. >
> > Please keep your eyes open for two subsequent mails that
> > will aim to  independently discuss the content that will
> > covered by the 'Consumer'  and 'Publisher' interfaces. 
> We have attempted this approach before and 
> > only received limited feedback and so the authors are
> appealing for some
> >
> > extra effort on this occasion.  Commenting on the
> > content of the two  interfaces during WGLC will not be
> very helpful to us (you know who you 
> > are :-).
> >
> > The finish line is close - lets give it one final push
> :-). >
> >
> > Best Regards.
> >
> > Chris Boulton.
> >
> > _______________________________________________
> > MEDIACTRL mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> > _______________________________________________
> > MEDIACTRL mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> >
> ----------------------------------------------------------
> -------------- >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com 
> > Version: 8.5.339 / Virus Database: 270.12.53/2155 -
> Release Date: 06/04/09 17:55:00
> >
> >   
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Mon, 8 Jun 2009 10:59:37 -0400

Hi Lorenzo,

I hadn't realized that we (the two of us at least) were thinking so
conceptually differently. And so that fundamental conceptual model will
certainly lead us down different paths, as you say.

So, yes, I was thinking of this in a very specific way: In the case of
Query, the AS asks for some type of MS resource, and the MRB returns the
address of a MS that the AS should use. As far as MRB is concerned, that
resource is awarded or devoted (or however you want to say it) to that
AS until MRB finds out otherwise.  So it's a rather tight model.

Regarding some of your observations below, with the conceptual model the
way I am thinking about it -

- For Query, MRB finds out the Media resource is no longer being used by
the AS because the AS tells MRB so. (For In-Line, MRB can directly infer
it from a SIP BYE).

- Regarding the topic/terminology of reservation, yes the MRB doesn't
know precisely when the AS makes the connection to the Media server and
starts using it. But neither does the MRB care. All MRB knows and cares
about is that a certain resource is assigned to an AS until MRB finds
out otherwise, and so MRB won't assign that resource to some other AS.
(Side note: I think it's a very reasonable and practical assumption that
the AS are acting sanely and requesting resources because they intend to
use them.)

- Regarding the 100 port conference scenario ...for the conceptual model
as I see it, it would be neither i) nor ii) below for Query. It would be
iii) The AS requests 100 ports (and may offer some other
characteristics) in a single query. The MRB assigns a MS that can
support that request. So as far as the MRB is concerned, that resource
is taken. As a consequence, the target MS can't get overloaded (in
normal conditions) because cumulatively the MRB will never assign to the
MS a higher conference volume than the MS can handle. For our particular
100-port conference, as calls come into the network, the AS sends them
along to the already-identified target MS. Yes, the AS still negotiates
the use of the MS with the MS over the control channel, but it shouldn't
at that point be a question of whether the MS has the resources.
 
Now with your conceptual model, my understanding would be that the MRB
has knowledge of the load on each MS, and therefore spare capacity on
each, by snapshots in time taken over the Publish interface. That can
take you pretty far, but I don't see how it supports certain uses cases,
or nearly as well. E.g., things I mentioned like

- The 100 port conference - I really don't see how this is reasonably
supported at all. Can the AS tell the MRB that it's going to be a
100-port conference? If not, the risk increases of the MRB offering the
AS a MS that can't support that size. Even if the AS can tell the MRB
it's going to be 100 ports, does MRB remember that it offered the AS a
particular MS1, say that has only 150 spare ports? If another AS2 next
requests another 100 port conference, will MRB also potentially offer
AS2 the same MS1, even though MS1 can't handle both conferences, because
the conference from the first AS1 hasn't filled up MS1 for it to be
visible to MRB through the next Publish snapshot? What if it's a
20-minte health/coffee break on the first conference and 30 of the legs
temporarily drop off but intend to come back - MRB in the next Publish
snapshot would infer that 30 ports are now freed up for somebody else to
use, and when the 30 people come back from break they might not be able
to rejoin. 
- The short-time peaky/bursty IVR (e.g.,Toll Free American Idol or maybe
some government emergency scenario) extremely critical application. How
can an AS request an MRB to set aside X ports? And then give them back?

So the conceptual model as I have been thinking about it feels more
robust and flexible; I see how it supports some use cases that I think
are important. I don't see how those are supported in another model. But
am willing to be educated.

cheers,

Gary

P.S. I hope nobody gets hung up on my using 'ports'. It just a
convenient way of taking about MS resources. Also, I am *not* suggesting
that the MRB assigns a *particular* port to an AS upon an AS request.
MRB identifies a MS with the right type of idle resource, say for
playing an announcement in English, and provide AS the address of that
MS. That MS may currently have X such available ports. MRB simply notes
that now that are X-1 such ports left unawarded. MRB doesn't care which
such particular MS port the AS used, since that MS port is simply one of
X in an equivalent set.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, June 06, 2009 5:39 AM
To: MUNSON, GARY A, ATTLABS; Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] MRB!!!!

Hi Gary,

Thanks,
Lorenzo

----- Original Message -----
From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
To: "Chris Boulton" <[email-masked]>,
<[email-masked]>

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 9 Jun 2009 10:42:52 +0200

Hi Gary,

by reading your contribution I think our view are probably not so distant as they seem. I also agree that the MRB must mantain a view on the requested resources and act accordingly. What I don't think it should do is actually reserving the resources on the MS itself, considering the difficulties it would raise. I mean, if an AS requests the usual conference with 100 ports, the MRB might remember which MS was chosen and on a subsequent request from another AS "lie" about the available resources (i.e. it won't report X as available ports but X-100) for that MS. I'm not sure it instead should actually (physically) take those ports on the chosen MS for the reasons I said in my previous mail. If we want it to, then we need an additional interface (beyond publishing and consumer) to allow the MRB to instruct MSs explicitly.

L.

On Mon, 8 Jun 2009 10:59:37 -0400

-- 
Lorenzo Miniero <[email-masked]>

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Tue, 9 Jun 2009 14:01:10 -0400

Hi all,

On this topic - comparing ideas on conceptually how are we thinking MRB
is actually working (and ultimately does it meet important envisioned
use cases), as per the mediactrl conference call discussion today we
agreed I would set up an unofficial conference call so we can probe on
that further.

So here I am simply asking who wants to be included. So far it would be
Gary M.
Lorenzo M.
Chris B.

Any other takers?

I'll wait ~ day to see whether there are other takers and then try find
a mutual day/time. Please respond to me directly - [email-masked] - so
we don't clutter the exploder with that administrivia email.

Thanks!

Gary

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 4:43 AM
To: MUNSON, GARY A, ATTLABS
Cc: Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] MRB!!!!

Hi Gary,

by reading your contribution I think our view are probably not so
distant as they seem. I also agree that the MRB must mantain a view on
the requested resources and act accordingly. What I don't think it
should do is actually reserving the resources on the MS itself,
considering the difficulties it would raise. I mean, if an AS requests
the usual conference with 100 ports, the MRB might remember which MS was
chosen and on a subsequent request from another AS "lie" about the
available resources (i.e. it won't report X as available ports but
X-100) for that MS. I'm not sure it instead should actually (physically)
take those ports on the chosen MS for the reasons I said in my previous
mail. If we want it to, then we need an additional interface (beyond
publishing and consumer) to allow the MRB to instruct MSs explicitly.

L.