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

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Fri, 5 Jun 2009 11:49:25 -0400

Hi Chris, Lorenzo,

Firstly, thanks again very much for all your work on this topic/draft.
Below are comments from me on the draft.

Cheers,

Gary

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.]

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.]

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.]

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.

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?

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.

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. 

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.

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.]

-----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

---

From: Chris Boulton <[email-masked]>
Date: Fri, 05 Jun 2009 17:15:32 +0100

Hi Gary - some comments in-line.  Thanks for the input.

Chris.
> 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).
> 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.

> know, and that's really not the case. It's MRB that wants to know this
[Chris] TODO list for next version.
> 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.

> <mediaResourceError> element, same as for Query mode, but in a SIP
[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.
> when the block (or some portion) is no longer needed.
[Chris] See earlier mail on resource reservation.
> AS got sick and didn't/couldn't tell the MRB to free up resources. 
[Chris] See earlier mail on resource reservation.
> 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.
> case, it is the MRB that decides which MS resource.]
[Chris] All editorials are noted for the next version.

Chris.

> ------------------------------------------------------------------------
>
>
> 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
>
>

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
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!!!!

Chris.

[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.

Chris.