RE: [ANCP] Comments on draft-maglione

["OOGHE Sven" <[e-mail]>]

Hi,
 
Please find my comments inline.
 
Regards,
Sven

________________________________

From: Curtis Sherbo [mailto:[e-mail]] 
Sent: dinsdag 17 juli 2007 0:08
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: [ANCP] Comments on draft-maglione



Greetings, 

I think the flexibility of the solution proposed in
draft-maglione-ancp-mcast-00.txt is necessary when you consider
applications beyond simple broadcast IPTV.

I think it is useful in certain scenarios in IPTV, but I also think it
is useful in a few other applications as listed below:

1) Nomadicity/Roaming - whether wired or wireless it would be more
effective to have a centralized policy decision as opposed to a
distributed one.  This is especially true in a wireless instance where a
client may be moving from one access point to another, the session would
need to be handed off, would you want to see a full authentication step
each hop so that you can refresh policies on the access point? 

I agree that there will be some central system that holds the subscriber
policy information. In the case of nomadicity, this system will be in
the "home network" (I don't mean customer premises network) and will
need to be contacted by the "visiting network". This could be done in a
push mode - bringing the relevant policy information to the network
elements in the visiting network - or in a pull mode - outsourcing the
decision to the home network. In my view, in the case of multicast, the
push model leads to less signaling than the pull model (unless some
special tricks based on session grouping with timeouts are introduced in
access platforms - but these have their own issues as I highlighted in
my previous email). Hence I'm more in favor of using the push model even
in nomadic/roaming cases.

2) Video Conferencing - As conferences would likely be ad-hoc, where the
multicast groups may not be known in advance, it would likely be more
efficient to update data centrally and query it as a participants join
conferences. 

See next point.

3) Future Over the Top Video Partnerships - Service providers may choose
to partner with internet video providers to provide QoS and multicast
capabilities through a partnership on a per event basis.  Like the video
conferencing scenario, this would be somewhat ad-hoc where the multicast
group mappings may not be known in advance, or may be reused for
different content in succession, requiring repeated policy refresh.
Again, a centralized approach would appear to be more scalable for this
model.

I agree that these are channels which may not be known to the access
provider in advance. There's however an easy way to solve this case:
thanks to IGMPv3 SSM, it is possible to create two categories of
channels:

- those with a known IP source address: these would include e.g. the
access/service provider's own IPTV offering

- those with an unknown IP source address: these would include over the
top video, or video conferencing

The Access Node can use the IP source address to filter IGMPv3's in
different replication contexts (e.g. IPTV, Internet TV). Within this
context, it could then decide to offer the content with the required
QoS, and decide whether or not to accept or reject the channel.

To be noted, zap time is less of an issue with these three applications,
as there is typically an accepted processing time. 

Can you clarify what you mean with this? 

Obviously it is not the job of the IETF to define these services or
business models, but I thought it might be helpful for us to consider
services beyond the starting point of IPTV.  

As suggested by others on this list, the existing framework may be able
to fulfill some of the requirements put forward by this draft, but I
argue that there is validity in the flexibility that the draft brings
for IPTV as well as support for the applications I have discussed here.

I welcome your comments. 

Cheers, 
Curtis 

Curtis Sherbo, P.Eng 
Product Line Manager 
Redback Networks Canada Inc. 
Phone: [phone] 
Mobile: [phone] 

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