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

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

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

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

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.

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

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.

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.

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.

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

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.

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

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.

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.

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

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.

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.

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.

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

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.

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 ..." ?

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?

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.

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

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











-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Chris Boulton
Sent: Tuesday, December 15, 2009 6:32 AM
To: [e-mail]
Subject: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

All,

The authors are pleased to announce that the latest version of the MRB 
document has been submitted - 
http://www.ietf.org/id/draft-ietf-mediactrl-mrb-02.txt.  For details of 
specific changes take a look at the section 10.1.

As you can see, this version has taken large steps forward and now has 
complete versions of both consumer and publish interfaces.  We welcome 
all feedback and would be grateful for any volunteers that are willing 
and able to provide expert review.

Thanks,

Chris & Lorenzo.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681
_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl