Subject: mboned: comments on draft-hayashi-rac-issues-00

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Mar 2005 17:49:35 +0200 (EET)

Hi,

I didn't read this completely, but a few high-level comments below....

4.1.2 Maintain guaranteed quality-level of data delivery (Voice, Video)

    For NSP to guarantee and charge for a certain quality of data
    delivery it is important that they can limit the number of receivers
    to a level that their bandwidth and servers can handle.

==> I don't understand this requirement.  We're talking about multicast
here.  Why is a bandwidth reservation important?  Are you just looking at
this at the customer access link or..?

4.1.3.2. Number of groups delivered from a physical port of edge router
and switch

    So that the NSP can guarantee a certain level of QoS to the CSP and
    the receivers it is important that it be able to control the number
    of groups that are served from any certain edge router or switch at
    any certain time.

==> you seem to be actually requiring something else.  The number of groups
should not be any factor, rather, the bandwidth those groups need, right? 
Or why would the number of groups be a useful metric?

4.3 Capability to distinguish between users (as opposed to merely
    hosts)

    Many content providers would like to have detailed information on
    what users are consuming their content and information on their usage
    behavior. This information might be used for ratings information,
    billing, auditing, and programming decisions.  Also content and
    network providers may wish to provide users with access to their
    usage history.  If a network provider and content provider are
    separate entities there are no protocols for sharing such information
    on a user basis.
[...]

==> there are actually multiple different kinds of user-tracking, and I'm
not sure which one you're interested at.  Are you interested in being able
to ensure the "portability" of user authorization, or do you want to be able
to follow log of what each user has been doing or not doing (privacy
concerns), like "the users who subscribed to Simpsons also watch Family
Guy" ?

The examples you cite don't yet seem to require user tracking as such,
because the user-based authentication might also be temporal.  That is, if a
family had one PC, and they really wanted to bill each user separately, it
might be conceivable that even though the user's identifier (the PC's mac
address, IP address, or whatever) would be the same, the family members
wouldn't still be watching different soap operas _at the same time_.  So,
the router could, for example, just keep track that:
  - at 14:01 jane doe watched X from IP 1.2.3.4
  - at 14:10 she stopped
  - at 14:30 john doe watched Y from IP 1.2.3.4
  ....

  4.4 Channel "leave latency"

==> for channel surfing, I guess you'd also be interested in fast joining..

          ii. Resource consumption
                With a low "leave latency" network providers could
    minimize streaming content when there are no audiences.

==> again, what does this have to do with multicast?   If there are no
receivers, the feed is pruned.  Or are you referring to the user's access
link, which sends packets as (basically) unicast?

4.5.1 Precise access log

    In many commercial multicast situations, NSP and CSP would like to be
    able to precisely grasp the content consumption of end-users.  Such
    information might be used for "identifying highly viewed content" for
    advertising revenue, ratings calculations, programming decisions, etc.

    To assemble such an understanding of end-user behavior, it is
    necessary to precisely log information such as who (host/user) is
    accessing what content at what time (join action) until what time
    (leave action).  The result of the access-control decision (e.g.
    results of authorization) would also be valuable information.

==> see my above comment about user-tracking.  Do you really need the full
log to be able to correlate what users did or didn't do?

Please note that to be able to see what's highly viewed content and what's
not, there is no need for _this_ precise access log, just the logs how many
viewers there have been.

Another important issue is how
    the edge router should be able to access and then maintain user
    information. The current situation of present architectures is that
    only the NSP can get information about user activity, because user
    activities are only observable from join/leave information logged on
    edge devices which are under control of the NSP.

==> a key point here will be whther CSP could trust logs provided by NSP, or
in more general, how safe "assurance" does CSP require ?

6.1 Access limit capabilities, compared by architecture

    - L2 authentication with ACL:
    With an ACL it is possible to limit access of multicast groups.
    However it should be discussed as to how scalable this approach is
    because configuring an ACL could be a labor-intensive task.

==> uhh.. wasn't configuring ACLs supposed to be automatic, from the policy
server?  No labor there...

    -Multicast Encryption:
    It is possible for receivers to receive IP packets, even if they do
    not possess the keys to decrypt them. A receiver may also be able to
    store such received data until they discover a way to decrypt it.
    Another disadvantage of this method is that network resources are
    wasted if an ineligible receiver receives an encrypted content even
    if they do not have a valid key.

==> unless I'm missing something, there's no harm in wasting network
resources -- I mean, it's just one user wasting _his_ resources, i.e.,
making his own life miserable.  Doesn't seem like a problem to me...?

    -L2 authentication with ACL:
    At the moment of L2 authentication it is possible to recognize
    receivers, but if there are multiple content service providers (CSP)
    a single L2 Authorization Server cannot distinguish among the CSPs.

==> I'm not sure if I can see why that needs to be the case.  different
group addresses can be mapped to different CSPs, so the information and
queries could be directed to the correct place?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Stephen Rife <[email-masked]>
Date: Mon, 07 Mar 2005 22:53:44 +0900

Pekka

Thanks for your comments.  I am working with the coauthors of this draft
so I can comment on a few of the points you touched on.

-----------------------------------------
4.1.2 Maintain guaranteed quality-level of data delivery (Voice, Video)

SR==> It may be possible for a number of possible streams to exist but
that the resource assumption is only a certain number of these channels
will be ever be served at a certain time.  So it is conceivable for
there to be bandwidth issues between a content provider and the network
provider providing the multicasting service when the **first** user
joins.

-----------------------------------------
4.3 Capability to distinguish between users (as opposed to merely
    hosts)

SR==> Portability of authorization is something we are interested in. 
Also, after a user has watched something-- from wherever-- we want to be
accurately identify them, track their usage (for billing, rating
evaluation, service report claims, etc. ) 

Related to access control and/or accounting for billing, certain
subscription contracts may limit per user simultaneous access to
multiple content.  If we want to offer portability then we need to make
sure that a user isn't accessing a volume of contents beyond what
his/her subscription level allows. 

----
Stephen Rife
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Mar 2005 16:17:10 +0200 (EET)

> provider providing the multicasting service when the **first** user

I still don't get it.  Even if a content provider was on a FE link, it 
could handle 20 simultaneous 5 Mbit/s streams.  Most CP's would be on 
a 1000 Mbit/s link.

I don't understand how this is a problem.

> evaluation, service report claims, etc. )

I'm not sure if these requirements are elaborate enough.  The point 
is, all of these above are doable with IP-address based tracking -- is 
there something that needs more than that?

> his/her subscription level allows.

This can obviously be limited by allowing only X amount of groups on 
an interface (but for channel surfing, the joins/leaves need to be 
fast)

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 7 Mar 2005 09:39:40 -0500

They may be thinking about multicast on demand video channels (i.e.,
using multicast routing, but with a typical viewer / channel ratio of ~ 
1).

> an interface (but for channel surfing, the joins/leaves need to be 
                                  Regards
                                  Marshall Eubanks

T.M. Eubanks
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

---

From: Stephen Rife <[email-masked]>
Date: Tue, 08 Mar 2005 00:05:01 +0900

Pekka and Marshall

So yes many of the channels might have a typical viewer/ channel ratio
of 1.  For example one usage would be during sporting event making a
number of camera angles available.  
A main camera angle may be viewed by many.
Most camera angles would not viewed most of the time, but certain camera
angles might be viewed by 1 or so viewers at a time, with surges
depending on events of the game.  
The content provider might have 1000s of possible channels available,
but not the bandwidth to pass them all onto the network provider.
Even if they could it is quite possible the network provider would want
to limit for other reasons such as processing power on their side.

-Steve

On Mon, 7 Mar 2005 09:39:40 -0500
Marshall Eubanks <[email-masked]> wrote:

> ---
> You are currently subscribed to mac-external as: [email-masked].
> To unsubscribe send an e-mail to [email-masked]
> and in the body type unsubscribe mac-external
> 

----
Stephen Rife
[email-masked]

---

From: Hiroaki Satou <[email-masked]>
Date: Tue, 08 Mar 2005 04:13:19 +0900

Hi

 >of 1.

Maybe on a subscriber access line, ( I don't think so on provider access lines)
  but bandwidth of an subscriber access line is shared by many subscribers 
even if 100M FTTH, e.g. L2SWs concentrate many lines.
So QoS control is needed on it for TV-like applications.
If a glut of channels flows, video quality degrades not only  on a newcomer 
channel, but also on existing channels.

---

From: Stephen Rife <[email-masked]>
Date: Mon, 07 Mar 2005 22:43:42 +0900

Pekka

----
Stephen Rife
[email-masked]