Re: [magma] BoF: New draft and ML for well managed IP multicasting issues (fwd)

[Pekka Savola <[e-mail]>]

[re-send, the mailing list doesn't allow posts from non-subscribers --
IETF mailing lists MUST allow that.]

On Thu, 16 Sep 2004, Hiroshi Ohta wrote:
> The draft is: <draft-hayashi-maccnt-00.txt>
> The mailing list is: <[e-mail]>

Are there web-accessible archives for that list?  That's pretty much a 
requirement..

A few comments on the draft itself, which seems to be needing a lot of
work yet to be more precise about the actual requirements.

Two higher-level comments:

 1) you state that ASM must be supported, but you don't specify 
requirements for restricting the users from disturbing the integrity 
of the group by sending bogus packets to it (see 
draft-ietf-mboned-mroutesec-03).  Does this need to be added or at 
least referred to?

 2) the technical solution seems to be pretty close to what MSEC WG
(http://www.ietf.org/html.charters/msec-charter.html and RFC3740) has
been standardizing.  This may not directly address NSP's accounting
requirements, but those could be gathered from the first-hop routers
with appropriate (or extended) MIBs.

substantial
-----------

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

==> this uses the old boilerplates, but what's worse is that the right 
to produce derivative works is not granted -- that's unacceptable.  By 
the process, such documents cannot be considered as WG items (for 
example), and I'd argue this would be an unacceptable basis for this 
BoF.  Please change the boilerplate.

==> also, the standard IPR disclosures and other boilerplates at the 
end of the draft are missing.  These are needed.

....
                                                                     
However, multicasting according to current
   standard has drawbacks compared to unicasting.  Appropriate
   accounting of each user is not possible when multicasting is used
   while it is possible under unicasting.  Accounting consists of
   grasping each user's behavior, when she/he starts/stops to receive a
   channel, which channel she/he receives, etc.

==> I don't think this is entirely accurate.  You can get accounting 
statistics if you just bother.  It's more of an issue with
deployment assumptions and the granularity of the information.

For example, one could monitor the amount of multicast traffic per
group or per IGMP/MLD joiner at the first hop router.  If all your
users would have their own virtual interface, you'd get per-user
statistics.

==> "current standard" -- reword? (these are not full standards, and 
there is no single standard)

   On the other hand, in multicast communication as in Fig.1, the server
   just feeds its information to the multicast router.  Then, multicast
   router replicates the information to distribute the clients.
   According to the current standard (e.g., IGMPv3[1] or MLDv2[2]), the
   multicast router feeds the replicated information to any link which
   has at least one client requesting the information.  In this process,
   no eligibility check is conducted.  Any client can request to receive
   the information.  In other words, no accounting capabilities are
   provided for multicasting by the current standard.

==> the word "accounting" seems incorrect here.  What you meant was 
probably "authorization" ?

The same later on.  You need to be careful which terms you use.  The
best might be if you said precisely what exactly you believe the
operator or the content provider needs to be able to do if it's not
authorization.

Similar later on, but there are also instanced where "accounting" is 
valid.

....

   (1) Network should be able to identify each client when eligible user
      access, and should be able to reject to connect ineligible
      clients.

==> the first part is confusing, reword to e.g.:

   (1) Network should be able to identify eligible user accessing the 
      service, and should be able to reject to service ineligible
      clients.

Note: this requirement should actually be broken in two (if that was 
what you meant), roughly:

 1.a) the service must be able to accept eligible users, and deny 
ineligible users.

 1.b) the service must be able to identify every user using the 
service.

 (does the service need to be able to identify the eligible users
before they use the service ["all the potential users"], or just after
they've used it?)

....

   (2) Network can grasp each client's behavior.  For example, network
      should be able to detect:
                                                                                                                  
     - that the client connects to the network,
     - that the client starts receiving certain information,
     - that the information which the client is receiving,
     - that the client terminates receiving the information,
     - that the client disconnects from the network.

==> you need to be much more precise here.  First, you need to specify 
clearly what you mean by "client", "connect", etc.

Why would this particular specification require to know when the user 
turns on his computer?  That's well beyond the scope of multicast 
accounting!

You also need to be much more precise which client behaviours you want 
to be able to track.  Please state the full list of actions.

...

                                                    
   (3) Mobility functions should be supported as an option so that 
users
      can use the service from anywhere.

==> 'Mobility' can mean a dozen different things.  Please be more 
precise here what you mean.  I suspect you mean that the user must be 
able to be authorized to get particular multicast feed no matter where 
he is in a particular providers network. (e.g., the accounting cannot 
be done based on IP addresses, unless IP addresses are static, or 
something like Mobile IP is used).  What about inter-provider issues 
-- if the user moves temporarily to another ISP, which may or may not 
support this at all?

...


   4. Application example and its specific requirements

==> the text here is more a description of a scenario than the actual, 
solution-independent requirements.  Therefore I'd consider rewording 
this to just say "scenario description", and remove the "requirement" 
word completely.

....
                                                                                                                  
  The NSPs are responsible for delivering the content and are required
  to meet certain QoS level or SLA (service level agreements). For
  example, video quality is very sensitive to packet losses. So if a
  NSP cannot meet the quality requirements due to limited network
  resources if it receives an additional user request, the NSP should
  reject that end user clientCYs access request instead of charging the
  user for bad services.

==> where is the problem here?  last hop congestion? (the multicast 
distribution tree is already there...)

4.1.2.3 Authentication Requirements
                                                                                                                  
   There are two different aims of authentication.  One is an
   authentication to network access, and another one is to each content.
   For the first case of authentication, NSP has a AAA server, and for
   the second case, each CO has a AAA server. In some cases, COs
   delegate (outsource) the operation of user authentication to NSPs.

==> this is not clear.  Why should the NSP have an authentication on
who can use the multicast?  Do you assume that NSPs would charge extra
for multicast-enabled network connectivity?  This seems like a broken
model to me...

   An important issue that discourages the wide deployment of IP
   multicast services is lack of multicast network management functions,
   especially an effective multicast accounting function. In IP
   multicast-based Internet TV, we should support a network model where
   many content owners provide their content to several NSPs which are
   different entities, and where each provider individually holds their
   customer information.

==> there is no technical requirement for the NSPs to have any 
customer information as far as I can see.

 On one
   hand, NSPs of commercial multicast services need to accurately
   identify the users and collect their usage information to generate
   correct billing information. 

==> why should the NSP bill for the multicast feeds?  It's just bits.  
If they want to share the profits, why not strike deals directly with 
the content owners for redistribution expenses?  Seems much better 
model to me.

This is clearly written from NSP revenue perspective.  It seems clear
to me that content owners wish to get some money from each recipient,
but the manner in which the NSP gets profits from that seems
irrelevant.  The best way would probably be to do this out of the
tecnical context, with an agreement with the content provider or a
flat rate with the user ("2$/month for the ability for multicast
services", plus the fees directly to the content owner")


editorial
---------

==> there are 3 too long lines (72 chars is the max) in the draft, and 
5 non-ascii characters.

   The intention of this I-D is to initiate the discussion on especially
   accounting issues related to well-managed IP multicasting services
   and to invite people to participate a potential IETF BoF/WG to
   discuss these issues and find solutions for them.

==> this text and the document title is misleading.  They seem to 
imply that multicast services which would not have these accounting 
etc. requirements placed forward in this memo would not be 
"well-managed".

The same later on, e.g., in section 3.

...

   To match the accounting information with a particular end user client,
   the end user client has to be authenticated. Usually the account
   information of an end user client for content access is maintained by
   the COs. An end user client may have different user accounts for
   different COs. The account is usually in the format of (username,
   password) so an end user client can access the content services from
   anywhere. For example, an end user client can access the CO from
   different NSPs. It should be noted that the user account used for
   content access can be different from the one used for network access
   maintained by NSPs.

==> this seems to be about authentication or authorization, not about 
accounting (under which section it is now)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings









_______________________________________________
magma mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/magma