Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

["MUNSON, GARY A, ATTLABS" <[e-mail]>]

Hi Lorenzo and folks,

I was formulating responses to some of your specific replies below, but
began to suspect that perhaps there's a single underlying issue that
needs clearing up first regarding IAMM. Let me explain the way I see
IAMM working.

(A) The way I have been thinking: The AS sends an INVITE to MRB with (1)
SDP characterizing the *call leg* it wants to send to an MS and (2) MS
characteristics it wants for that call leg. MRB picks one and sends a
modified INVITE along to the MS. When there is a response from the MS,
MRB will insert toward the AS the SIP uri of the chosen MS, which can be
used as the basis for the AS 'directly' establishing a control channel
with the MS, or the AS knowing that it already has one.

(B) Are you thinking instead that with IAMM the SDP is characterizing
the control channel it wants? And then the AS has the opportunity to set
up call legs 'directly' to the MS without the SIP signaling going
through the MRB? I had not been thinking that, although treating these
MRB interfaces as a toolkit, I could see that as a possibility.

It seems to me that we need to cover the way I had been thinking about
it, because there's no necessity of a control channel between the AS and
MS (e.g., AS could be happy using 4240 in a given situation). In
addition one could use MRB a la (B), but it does raise some more
questions - like how MRB knows when the MS resources are freed up.

Thoughts? Thanks. 

Cheers,

Gary

-----Original Message-----
From: Lorenzo Miniero [mailto:[e-mail]] 
Sent: Thursday, December 24, 2009 10:56 AM
To: MUNSON, GARY A, ATTLABS
Cc: Chris Boulton; [e-mail]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

Hi Gary,

thanks a lot for your detailed feedback! We're glad you like how the
doc is going on: hopefully, with the help of your comments, next doc
will be almost ready to go.

Some comments inline [LM]

Merry Christmas and Happy New Year to you as well!

L.


On Mon, 21 Dec 2009 20:56:07 -0500
"MUNSON, GARY A, ATTLABS" <[e-mail]> wrote:

> Hi Chris and Lorenzo,
> 
> Firstly, thank you very much for all your work on this draft. Looking
> fairly complete!
> 
> Below are comments from me. Unfortunately I won't be much help on
sanity
> checking sections 6 and 7. Hopefully others will be.
> 
> I'll be on vacation now through Jan. 1 and won't be looking at email
> much, so no rush to react to my comments.
> 
> Merry Christmas/Happy Holidays/Happy New Year,
> 
> br,
> 
> Gary
> 
> --- GAM Comments below ---
> 
> 
> >> General comments below <<
> 
> 1) For In-line, how does the AS know the identity of the MS for
purposes
> of 
> establishing a mediactrl Control Channel to it? I don't think this
> described anywhere, 
> and it is an important point to cover conspicuously. (I do see a
> sentence in the para 
> after Figure 8 that seems to say at least for In-line an AS could send
a
> Control dialog 
> to MRB, so MRB would select a MS resource for that; but if so, it
raises
> more questions 
> for me, like which comes first, or how you guarantee that a Control
> request and the 
> corresponding call leg request end up at the same MS resource.) 
> 


[LM] That's a good point, and Chris and I discussed while updating
the doc. The Consumer interface now has, in the <response-session-info>
element of a reply, the SIP URI of the MS that the MRB has chosen for
the request. This means that, both in Query and IAMM mode, the AS has a
way to directly contact the MS for what concerns that request (e.g.
attaching UACs there). This solves the issue, but also removes the MRB
from the signaling path, meaning it won't be able to infer resources
being freed by itself (e.g. a UAC sending a BYE). In IUMM that becomes a
problem, since the AS is not aware of a MRB, and just sees it as a MS.
The only solution to this problem is to have the MRB always the same MS
when the same AS uses IUMM. If you think these solutions are ok, we
might add some text about them in the doc to provide some guidance.
Otherwise, any comment (from you or from any other in the list of
course) is more than welcome.


> 2) For In-line, in the case of conferencing, how does the MRB know to
> send legs of the 
> same conference to the same MS resource? I would think by remembering
> the conference ID 
> supplied in the SIP for the first leg it sees. This should be
described.
> (Not needed 
> for Query MRB).
> 


[LM] This can be seen as the same as 1). Or did you have something
different in mind?


> 3) The required/optional aspect of attributes on the Consumer
interface
> is absent in 
> this draft. I had thought the conclusion of the last meeting (IETF 76)
> was to include
> it.
> 


[LM] Yes, there was consensus in Hiroshima. Anyway, there also were
some comments on the ML that raised a few concerns about this approach,
specifically a post by Mark Syrett:

http://www.ietf.org/mail-archive/web/mediactrl/current/msg01433.html

and the following posts. After that, the idea was that we first needed
to better investigate pros and cons of such an approach, considering it
could be considered harmful. I guess it would be a good idea to
keep on discussing about this on the ML and update the doc accordingly.
At the moment, the important thing to have was a more or less complete
Consumer Interface per se: now that we have it, we can shape and
improve it.


> >> Specific sections comments below <<
> 
> 1) Section 1 Intro 1st paragraph. Say "selection" instead of
"location".
> 
>   > Because generally location is taken to mean actual location in
some
> sense, which 
> isn't what is intended here.
> 


[LM] Thanks, noted.


> 2) Section 1 Intro, para above Figure 3, add words ... "In this model
> there are a 
> number (greater than 1) of application servers *, possibly supporting
> dissimilar 
> applications,* controlling a single media server."
> 
>   > Because while the draft acknowledges MS resources are not
> necessarily homogeneous, 
> nowhere does it yet say likewise for applications/ASes, and that's an
> important point.
> 


[LM] I agree, noted.


> 3) In Abstract and Section 1, instead of "1:M and M:M" say either
> "1:Many and 
> Many:Many" or "1:M and M:N"
> 
>   > Because implication is generally that M stands for an arbitrary
> number, but then 
> M:M would imply same number of AS and MS, which we don't mean.
> 


[LM] Thanks, that was proably a typo, noted.


> 4) Section 2, Media Resource Broker MRB term. Change description to 
> 
>     A logical entity that is responsible for
>       both collection of appropriate published Media Server (MS)
>       information and selecting appropriate MS resources on behalf of
>       consuming entities.
> 
>   > Because the current description says "... and supplying
appropriate
> MS information 
> to consuming entities", which is isn't really to the point at least
for
> In-Line use.
> 


[LM] You're right, noted.


> 5) Section 2, Query MRB, change "location" to "address"
> 
>   > Because 'location' is tended to mean actual location as in
> presence/location and/or 
> as in media-server-location
> 


[LM] Thanks, noted.


> 6) Section 2, In-line MRB, change description to 
>    
>     An instantiation of an MRB (See definition) that
>       directly receives requests on the signalling path. There is no
> separate query.
> 
>   > Because present description says "decision making process is
totally
> delegated to 
> the MRB" which a good characterization because (a) even for Query MRB,
> it's the MRB that 
> decides/picks an MS resource and (b) the AS can provide the same kind
of
> information 
> with IAMM In-line as for Query.
> 


[LM] Actually, as you say in IAMM the query is still there, even if it's
part of the INVITE (the multipart/mixed payload). Do you think just
clarifying that the HTTP interface is not involved will be enough?


> 7) Section 3, para 3, say "selection decisions" instead of "routing
> decisions".
> 


[LM] Thanks, noted.


> 8) Section 4, para 4. Revise that para to
> 
>   Please note that there may be additional information that it is
> desirable for the MRB 
> to have for purposes of selecting an MS resource, such as resource
> allocation rules 
> across different applications, planned or
>    unplanned downtime of Media Server resources, the planned addition
of
>    future Media Server resources, or MS resource capacity models. How
> the MRB acquires 
> such information is outside the scope of this document.
> 
>   > Because the real point is that there are additional things the MRB
> might want to 
> know about MS resources to factor into its decision making process.
It's
> not about what 
> else the AS might want to know.
> 


[LM] Good point, noted.


> 9) Section 4.1. At the very end of the section, last paragraph, add
the
> sentence 
> "Additionally, with Query MRB, the MRB is not in the signaling path
> between the AS and 
> the selected MS resource."
> 
>   > Because this is a useful distinction between Query and In-line to
> highlight.
> 


[LM] If we take into account the possible solution proposed in 1), this
also does not apply in IAMM mode, since the AS would be aware of the MS
that was chosen. At least, that's true for UAC calls to proxy, while
it's also true that in the IAMM case the MRB will be in the path for the
Control Channel SIP dialog.


> 9a) Section 4.2, first para, revise to
> 
>    The "In-line" MRB is architecturally different from the "Query"
model
>    that was discussed in the previous section.  The Concept of a
> separate "Media
>    Server Consumer Interface" disappears.  The client of the MRB
simply
>    uses the media server control and media dialog signalling to
involve
> the MRB.  This  
>   type of deployment is illustrated in Figure 8.
> 
>   > Because the current para talks about offloading the decision
making
> process, but 
> that's the MRB role for Query or In-line, so isn't a distinction.
(Also,
> it's Media 
> Resource Consumer Interface, not Media Server Consumer Interface.)
>  


[LM] Thanks, noted.


> 
> 10) Section 4.2, the two paragraphs below Figure 8. Revise what is
> currently there to
> 
>    The Media Servers still use the 'Media Server Publishing Interface'
>    to convey capabilities and resources to the MRB - as illustrated by
>    (1).  The media server Control and Media dialogs are sent to the
MRB
>    (2) which then selects an appropriate Media Server (3) and would
stay
> in the 
> signaling path between the AS and the MS resource for those dialogs.
> 
>   In-line MRB can be split into two distinct logical roles which can
be
>    applied on a per request basis.  They are:
> 
>    In-line Unaware MRB Mode (IUMM):  Allows an MRB to act on behalf of
>       clients requiring media services who are not aware of an MRB or
>       its operation. In this case the AS does not provide explicit
> information on the
>       kind of MS resource it needs (as in Section 5.2) and the MRB is
> left to deduce it
>       by potentially inspecting other information in the request from
> the AS; for 
>       example, SDP content, or 
>       address of the requesting AS, or additional Request-URI
parameters
> as per RFC 4240.
> 
>    In-line Aware MRB Mode (IAMM):  Allows an MRB to act on behalf of
>       clients requiring media services who are aware of an MRB and its
>       operation. In particular it allows the AS to explicitly the
convey
> the same kinds of MS 
>       characteristics desired as does the Query MRB mode (as in
Section
> 5.2).
> 
>    In either role, the MRB would deduce that the selected MS resources
> are no longer 
> needed when the AS terminates the corresponding dialog.
> 
>   > Because some of the current description in the first of the
> paragraph really only 
> applies to IUMM and not IAMM - i.e., about what the MRB knows; 
>     and because the "decision making" on MS resource selection is
always
> the role of 
> the MRB whether for Query or either flavor of In-line.
> 


[LM] Same as before, if an AS using the IAMM mode directly contacts the
chosen MS when it comes to forwarding UAC calls, then the MRB won't
always be on the signaling path (it will for the control channel, it
won't for UAC). Or when you say "the MRB would deduce that the selected
MS resources are no longer needed when the AS terminates the
corresponding dialog" you actually mean the Control Channel SIP dialog
and not any UAC dialog?


> 11) Section 5.1, para 2, revise it to
> 
>    As already anticipated in the introduction, the MRB view
>    of MS resource availability will in practice be approximate - i.e.,
> partial and 
> imperfect. The MRB Publish interface does not provide an exhaustive
>    view of current MS resource consumption, the MS may in some cases
> provide a 
> best-effort computed view of resource consumption 
>    parameters conveyed in the Publish interface (e.g., DSP's with a
> fixed number of 
> streams versus GPU's with CPU
>    availability), there may be licensing constraints not factored in
> (e.g., even if 
> lots of CPU and memory
>    are available, licensing or other configuration elements may
restrict
>    the number of stream types), and MS resource information may only
be
> reported 
> periodically over the Publish interface to MRB. 
>    Nevertheless, despite such limitations and with the aid of good
> engineering the MRB 
> can still perform its function well.
> 
>   > Because - seemed could benefit from better wording. I disagree
about
> the part that 
> the only way an AS could be guaranteed of a specific resource is "to
> reserve it by 
> establishing a session" ... even that doesn't absolutely guarantee the
> entire desired 
> set of resources will be available when needed. And seemed good to add
> some words to the 
> effect that despite the MRB's approximate view, it can still do a good
> job. And I 
> didn't think that the observation about reporting of resource
> availability versus 
> predictive resource allocation was relevant or helpful to the primary
> theme of this 
> paragraph.
> 


[LM] You're right, and I agree that the paragraph did benefit from the
rewording. The "reserve the resource to be sure you have it" came from
face-to-face discussions, and that's why we added it to the text.


> 12) Section 5.1, para 3.  I think this para (copied below as currently
> written for the 
> reader's convenience here) needs some clarification, but I don't have
a
> specific 
> proposal because I'm not sure what the intent is. If the intent is to
> say that ASes can 
> figure out information on MS resource utilization by in effect making
> queries of MRB, I 
> would argue that is exceedingly awkward and limited, and not worth
> mentioning. Or if 
> ASes are thought of as hostile, I would worry about worse things like
> requesting 
> resources they don't need, and thereby tying them up from MRB's point
of
> view. If the 
> intent is that given the use of the Publish interface there is the
> possibility of some 
> interloper entity other than MRB of using the interface and finding
out
> stuff, then the 
> para should be clarified in that direction.
> 
>    It is also worth noting that, while the scope of the MRB is
>    definitely on providing interested Application Servers with the
>    available resources, the MRB also allows for the retrieval of
>    information about the currently occupied resources.  While this is
of
>    course a relevant piece of information (e.g. for monitoring
>    purposes), such a functionality inevitably raises security
>    considerations, and implementations should take this into account.
>    See Section 8 for more details.
> 


[LM] This is related to th security considerations in both the IVR and
Mixer drafts. In fact, in both of the drafts the auditing interface
allows for the probing of package-specific identifiers (e.g. conference
and dialog IDs, and the like), which means, for instance, that an
unauthorized AS could tear down a dialog another AS allocated. The
security considerations there provide some guidance with respect to
that, which should also apply in the MRB draft for the same reason
(since, for intance, we report conference IDs in publish responses).


> 13) 5.2.2, first bullet under 2nd para - I don't understand why the
> application/sdp 
> part is needed.
> 


[LM] In IAMM, the AS adds both an SDP (to create a new CFW control
channel) and a MRB Consumer request (to ask for a capable MS).
According to the MRB request, the MRB chooses a MS, and forwards an
INVITE there by attaching the SDP from the AS. The MS negotiates the
control channel creation by replying with its own SDP. The MRB at this
point can send a 200 back to the AS with a new multipart/mixed payload,
including both the SDP from the chosen MS, and the MRB response to the
original request. The AS can now connect to the MS using the SDP info.

We prepared some examples for all the modes, I guess that this will be
clearer when I'll send them to the list, but that's basically the
procedure.



> 14) 5.2.3 bullet on <action> part about "If the information is
identical
> as the 
> existing request, the MRB will attempt a session refresh." What does
> that mean? Needs 
> clarification.
> 


[LM] We'll reword that so that it makes more sense.


> 15) 5.2.5.1.1, part about expires:,  "If the lease is refreshed before
> expiry, the MRB 
> will re-claim the resources and they will
>       no longer be guaranteed."  --  I think this is meant to say "If
> the lease is NOT 
> refreshed ..." ?
> 


[LM] Yes, that was a typo, thanks for finding it.


> 16) 5.2.5.1.1, Editor's note at end of section as to whether the SIP
URI
> is sufficient, 
> I don't have any ideas about what else is needed, so have nothing to
> suggest, other 
> than to ask whether this single SIP URI is one and the same for
sending
> call legs to 
> the MS and for establishing a control channel? Practically, is there
> some value in 
> allowing for separate URIs for those purposes?
> 


[LM] That's a very good point, and I definitely think it should be in
the document. I guess these two URIs will be enough, unless anyone else
sees any value in having others.


> 17) Section 5.3.1, very last sentence, " The techniques used for
> selecting an    
> appropriate Media Server by an MRB acting in IUMM is outside the scope
> of this document."  - I would think this 
> statement applies to any kind of MRB, so should be generalized and
> placed further up 
> front in the document, perhaps the beginning part of Section 3.
> 


[LM] You're right, but I think it's also safer to make it clear that in
IUMM mode you're more into the wild than in IAMM/Query. We'll reword
the text to take your comment into account.


> 18) Section 5.3.2 on IAMM. I would think that there are a few items
from
> the Consumer 
> interface that don't apply to the IAMM case. Or if they are used, then
I
> think need 
> more description (I at least wouldn't be clear on just how they would
> get used without 
> getting into problems). Specifically, 
>   - the ability to update/change a prior resource request
>   - the ability to ask for multiple ports (in so many words) at least
in
> the IVR case
>   - does the lease mechanism apply? is the client required to renew?
MRB
> knows the call 
> is still up if it's in the signaling path
> 


[LM] I'd rather have some redundancy here than making distinctions for
what concerns the Consumer interface according to the protocol it is
conveyed upon. Do you think it's ok if we just point out that in IAMM
mode you have more ways to do the same thing? (leasing being one of the
best examples)


> >> Editorial nits below <<
> 
> 1) Be consistent of use of MRB Publish interface or MRB Publishing
> interface.
> 
> 2) 5.1.1.2 para 3,  "updating/removing" instead of "update/remove"
> 
> 3) 5.1.4.4 "which represents" instead of 'which representing"
> 
> 4) 5.1.4.5 "number of RTP sessions' instead of "number of RTP session"
> 
> 5) 5.1.4.6 "which represents" instead of 'which representing"
> 
> 6) 5.1.4.11 "can" instead of "cane"
> 
> 7) 5.1.3.14 "media server supports." instead of 'media server
support."
> 
> 8) 5.1.3.19 "... a blue or green one." instead of "... a blue or
green."
> 
> 9) 5.2.3  "in Section 7 and Section 7" --> "in Section 5.2 and Section
> 7"  ?
> 
> 10) 5.2.4.1.1.1 under seq:  "information its use" --> "information
about
> its use"
> 
> 11) 5.2.5.1.1, under expires: "that the media resources reserved" -->
> "that the media resources are reserved"
> 

[LM] All noted, thanks.

-- 
Lorenzo Miniero <[e-mail]>