Subject: Re: [CDNi] The role of Multicast in CDNI

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 2 Jan 2012 10:58:12 +0100

Hello Ad,

Thanks for your input.

Regarding:
> At this moment I’m not sure whether these problems are in-scope of this WG, or in which documents these problems need to be discussed. Maybe we could add a multicast use case to the Use Case draft? Or say something about it in the Problem Statement draft?
> I’m looking forward to the WG’s ideas on this topic,
As per the charter, the "CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry" therefore the WG has to focus on the most important and well-understood requirements. 
Like Ben, my personal take is that the use of multicast dCDN-to-user does not qualify as one of the most important and well-understood requirements that we should focus on right now. This is not to say, it does not have value, of course.

If you agree with this assessment, my suggestion would be that you reached out to the authors of the "Catalogue of Advanced Use Cases for Content Delivery Network Interconnection", draft-fmn-cdni-advanced-use-cases-00: http://tools.ietf.org/id/draft-fmn-cdni-advanced-use-cases-00.txt, and discuss whether you could add a "dCDN-to-User Multicast" use case in that document. This document is intended by its authors to keep track of CDNI use cases that are deemed out of the current scope of the CDNI WG but could be considered if/when the CDNI WG re-charters in the future.

Cheers

Francois

On 30 Dec 2011, at 11:40, Ben Niven-Jenkins wrote:

> Ad,
> 
> On 30 Dec 2011, at 10:26, <[email-masked]> wrote:
> 
>> Ben,
>> 
>>>> As you may know, for some operators multicast is an important aspect of their
>>> CDN. I use the term multicast here in general, but in practice this may refer to IP
>>> Multicast, Ethernet Multicast, Broadcast or MBMS. It is important to note that
>>> I'm talking about using multicast from the delivering CDN to the end-user and
>>> not about multicast between CDN's or internet-wide multicast. For operators,
>>> using multicast is an important method in limiting traffic peaks in their access
>>> networks.
>>> 
>>> Multicast from a CDN to End Users is not something that as far as I am aware is
>>> any more than an R&D topic at this stage.
>>> 
>>> Multicast to deliver IPTV type services to TVs/STBs is a different story but those
>>> services aren't delivered off CDNs.
>> 
>> (Trying to avoid IPTV and CDN discussions)
>> So it is clear that connecting video servers to a multicast network is not rocket science.
>> 
>> I'm now seeing ISP's starting to distribute TV channels over the Internet connection of their customers by using their CDN's. Depending on their network architecture, they could benefit from using multicast. This has obviously not that much to do with CDN interconnection, but makes it likely that multicast capabilities will be linked to a CDN in the foreseeable future.
> 
> I don't disagree. However there are still many outstanding questions on what such a deployment would involve, e.g. what capabilities the User Agent/client will have, where the multicast terminates in the subscriber domain, what is actually carried in the multicast "stream", does it leverage an existing content provider workflow or require a different workflow etc. that are all out of scope for CDNI so I won't go into more details here.
> 
> Until it is clear what the deployment model(s) look like any work by the CDNI WG is just guesswork which is what led to my previous statement:
> 
> "My view is that the CDNI WG should focus on figuring out how CDNs can interconnect the services they are delivering today and not try to figure out how to interconnect services that don't yet exist. When new services/technologies come along we can figure out how to extend CDNI to cover them at that point in time and not try and second guess what those service/technologies will look like before they exist."
> 
> Ben
> 
> 
>> It is very unlikely that multicast capabilities of access networks can be exposed over the Internet. A CDN enabling it for CDN operators and content owners, would increase the efficiency of the content distribution. This efficiency can not be realized by the CDN operators and content owners; cooperation / interconnection is needed for this.
>> 
>> Kind regards,
>> 
>> Ad
>> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: <[email-masked]>
Date: Mon, 2 Jan 2012 16:46:15 +0100

Hi Ben and Francois,

Thank you for the opportunity to react again ;-)

The design we made a year ago on how to enable the multicast capability on an access network via a CDN - CDN interface, we found out that the information exchange between the two CDN's could be pretty similar to the exchange I would expect for normal content.

On a basic CDN Interconnection one would expect the uCDN to provide the dCDN with the content and the dCDN would provide the uCDN with content delivery information, that can be used by the end-user to retrieve the content. This would typically be an URL. (simplified description of the process of course) 

On a CDN Interconnection that will support multicast delivery by the dCDN, the uCDN would provide the dCDN the content with some kind of multicast flag / bit and the dCDN would provide the uCDN with content delivery information, that can be used by the end-user retrieve the content. In this case multicast retrieval information.

Ben wrote:

> > I'm now seeing ISP's starting to distribute TV channels over the Internet
> connection of their customers by using their CDN's. Depending on their network
> architecture, they could benefit from using multicast. This has obviously not that
> much to do with CDN interconnection, but makes it likely that multicast
> capabilities will be linked to a CDN in the foreseeable future.
> 
> I don't disagree. However there are still many outstanding questions on what
> such a deployment would involve, e.g. what capabilities the User Agent/client
> will have, where the multicast terminates in the subscriber domain, what is
> actually carried in the multicast "stream", 

I actually agree and this partly also true for basis CDNi (like no of redirects that all devices will support). The impact of adding multicast delivery to CDNi, doesn't seem that big as we found out in our design. 

> does it leverage an existing content
> provider workflow or require a different workflow etc. 

It appears to me that the suggested additions exactly fit in the workflow of both the uCDN and the dCDN.

Francois wrote:

> Thanks for your input.
> 
> Regarding:
> > At this moment I'm not sure whether these problems are in-scope of this WG,
> or in which documents these problems need to be discussed. Maybe we could
> add a multicast use case to the Use Case draft? Or say something about it in the
> Problem Statement draft?
> > I'm looking forward to the WG's ideas on this topic,
> As per the charter, the "CDNI WG aims at delivering a targeted, deployable
> solution in a short timeframe (18-24 months) as needed by the industry"
> therefore the WG has to focus on the most important and well-understood
> requirements.

When the multicast support is added in the way described at the top, the impact seems pretty low to me and the solution can be deployed in the described timeframe. 

Kind regards,

Ad

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 3 Jan 2012 09:43:04 +0100

Hello Ad,

>> When the multicast support is added in the way described at the top, the impact seems pretty low to me and the solution can be deployed in the described timeframe. 

My impression is that the use of multicast dCDN-to-user would affect most aspects of CDNI and open up many design spaces. Just to mention a few for illustration:
	* how can we support consistent logging/accounting when dCDN uses Multicast for delivery? would dCDN correlate dCDN log information with completely independent Multicast stats information? would completely new "logging" records have to be defined for logging/accounting when multicast is used for delivery by dCDN? what information can be logged and which one cannot when relying on L3 multicast statistics?
	* how can we support consistent reporting?
	* how does endpoint learn the mapping between a given CSP "program" and the corresponding multicast-related information that an enduser needs to use to access that program on a given dCDN? Given that an enduser may access that same CSP program through different dCDN at different time, how is the request routing decision factored into selection of multicast access information?
	* what happens when a dCDN runs in a different AS than the access network? is that dCDN not allowed to use multicast delivery? or do we assume that inter-AS multicast would be available (which is generally not)?
	* how do we support consistent access control (time window, geoblocking, URI signing,..)?

It might be the case that someone has made some specific decision for each of these design questions that made things simple enough in one specific environments with limited requirements (eg no access control, no/limited accounting/reporting,...), but I personally believe that getting convergence from an open working group on each of the intersection points between CDNI and multicast delivery would be a very significant impact.

Cheers

Francois

> Ad

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: <[email-masked]>
Date: Wed, 4 Jan 2012 11:20:23 +0100

Hi Francois,

>             * how can we support consistent logging/accounting when dCDN uses Multicast for delivery? would dCDN correlate dCDN log information with completely independent Multicast stats informati…

Using (network) multicast for content delivery is actually an architectural strange, but straightforward process.
Imagine the case were the dCDN uses IP multicast for the delivery. The dCDN puts the stream on the IP network with a multicast address, the viewers connect to the multicast network stream (IGMP join) and the network ensures the content is delivered to the viewer.
So the dCDN server probably only sees the initial hit, but doesn’t see additional IGMP joins because those are handled by the network. As the dCDN server can only report the information it receives, the reporting about the multicasted content is pretty limited.
One could argue that the dCDN server should receive the network IGMP joins and leaves from the network to send them to the uCDN. On the other hand, client based reporting (from the player) does make more sense. It is pretty similar to the way some IP TV implementations get their logging information.

So yes, there is reporting impact. But due to the nature of multicast the impact is low.

In addition to:
> Ad wrote:

The dCDN could provide the uCDN with information of the end-points that can be reached by multicast. Providing reachability information over the CDN interconnection interface is a good idea anyway (I didn’t check if this is already in the requirements).
Based on this information the uCDN / CSP can take the request routing decision.

But it might be that I missed the idea behind the CSP “program”.

>             * what happens when a dCDN runs in a different AS than the access network? is that dCDN not allowed to use multicast delivery? or do we assume that inter-AS multicast would be available…

The only dCDN that can deliver by multicast, is the one that can directly inject the multicast information. As you correctly stated inter-AS multicast is hardly used, so the multicast delivering dCDN will be in the AS of the end-user.

>             * how do we support consistent access control (time window, geoblocking, URI signing,..)?

I think this is consistent for both models. And some access control is even simpler because the uCDN can simply stop transmitting the stream.

> It might be the case that someone has made some specific decision for each of these design questions that made things simple enough in one specific environments with limited requirements (eg no acc…

Due to the limitations of multicast delivery by the dCDN, I think that basic multicast support needs work. To me it seams that the amount of work doesn’t have to affect the planned timelines.

_Cool_ advanced use cases like “unicast retransmission of missed multicast information” and “support for fast stream change” could go into the advanced use cases.

Kind regards,

Ad

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 4 Jan 2012 12:00:58 +0100

Hello Ad,

> So yes, there is reporting impact. But due to the nature of multicast the impact is low.

I disagree. I think a more accurate statement would be:
"If you assume that there is no need for the dCDN to support accurate logging/reporting, then the impact is low. But if you assume that there is a need for the dCDN to support accurate logging/reporting (which, BTW, the WG has been assuming so far), then the impact would be very high because you would need to somehow correlate L3 Multicast stats with content delivery and re-generate corresponding log reports".

> But it might be that I missed the idea behind the CSP “program”.

The above is discussing a different question than the one I raised.
The question I raised is more the following:
	* say a user access a portal somewhere
	* the user is provided with a URI
	* the user clicks that URI and issues a request that is pointed to the uCDN Request Router.
	* let's say that the uCDN decides to redirect this user to a dCDN that happens to support multicast delivery
	* how is the user told to issue a Multicast join to a particular Multicast group that will give him access to this particular live content from that particular dCDN (instead of the user receiving a 302 or a DNS response)? Obviously one can invent such a protocol, but the User-CDN interface is currently outside the scope of the CDNI WG, so working on this would be a significant impact (if not even a rechartering).

> The only dCDN that can deliver by multicast, is the one that can directly inject the multicast information. As you correctly stated inter-AS multicast is hardly used, so the multicast delivering dC…

OK. That would limit applicability, but I think this is a reasonable choice.

> I think this is consistent for both models. And some access control is even simpler because the uCDN can simply stop transmitting the stream.

We seem to be working off different assumption.
In the model I am thinking, the uCDN feeds the content once to the dCDN, which is then responsible for fanning it out to endusers. When we use unicast requests between enduser and dCDN, it is reasonably easy to perform per-user/per-request authorization check (eg via some form or URI signing). If you were to use multicast delivery, to achieve a similar per-user/per-request authorization check you would have to add it onto your L3 Multicast infrastructure (eg with every Multicast join being subject to some AAA checks). Again, all conceivable but a lot of work.
So my assessment here would be:
"If you assume that there is no need for any access control, then the impact is low. But if you assume that there is a need for access control (which, BTW, the WG has been assuming so far), then the impact would be very high because you would need to somehow introduce a consistent/interoperable access control solution into the L3 Multicast".

> Due to the limitations of multicast delivery by the dCDN, I think that basic multicast support needs work. To me it seams that the amount of work doesn’t have to affect the planned timelines.

My conclusion is that, even if you were to make a lot of simplifying assumptions (eg no logging/reporting, no access control,...) which would seriously limit the solution applicability, there would still be some tough design choices to make and interesting problem to solve (such as the one discussed above about how to communicate to the enduser the multicast information needed to access content) that would not be compatible with our target timeframe.

It'd be interesting to hear other opinions.

Cheers

Francois

---

From: <[email-masked]>
Date: Wed, 4 Jan 2012 11:37:53 +0000

Hi,

Reading the discussion and the questions raised so far I feel it's pretty clear that the likely deployment models & architectures for Multicast via CDN are not clear and they are even less clear in a CDNI context. I think trying to resolve consensus in the WG for what the solution should look like will be almost entirely based on second guessing these deployment models & architectures and I'd therefore agree with Francois suggestion that this would very likely impact the current CDNI timeframe and generate a significant amount of work.

My view is that CDNI should focus on the basics as a first iteration, which I'd define as Interconnecting CDNs as they currently/typically operate. That's already a reasonable ask without including potential futures which, so far as I am aware, are not currently widely deployed and for which there is little or no CDN equipment vendor adoption.

g-

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur
Sent: 04 January 2012 11:01
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [CDNi] The role of Multicast in CDNI

Hello Ad,

On 4 Jan 2012, at 11:20, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Francois,

> On 2 Jan 2012, at 16:46, <[email-masked]<mailto:[email-masked]>> wrote:

Using (network) multicast for content delivery is actually an architectural strange, but straightforward process.
Imagine the case were the dCDN uses IP multicast for the delivery. The dCDN puts the stream on the IP network with a multicast address, the viewers connect to the multicast network stream (IGMP join) and the network ensures the content is delivered to the viewer.
So the dCDN server probably only sees the initial hit, but doesn't see additional IGMP joins because those are handled by the network. As the dCDN server can only report the information it receives, the reporting about the multicasted content is pretty limited.
One could argue that the dCDN server should receive the network IGMP joins and leaves from the network to send them to the uCDN. On the other hand, client based reporting (from the player) does make more sense. It is pretty similar to the way some IP TV implementations get their logging information.

>> On a CDN Interconnection that will support multicast delivery by the dCDN, the uCDN would provide the dCDN the content with some kind of multicast flag / bit and the dCDN would provide the uCDN wi…

The dCDN could provide the uCDN with information of the end-points that can be reached by multicast. Providing reachability information over the CDN interconnection interface is a good idea anyway (I didn't check if this is already in the requirements).
Based on this information the uCDN / CSP can take the request routing decision.

But it might be that I missed the idea behind the CSP "program".

> It might be the case that someone has made some specific decision for each of these design questions that made things simple enough in one specific environments with limited requirements (eg no acc…

Due to the limitations of multicast delivery by the dCDN, I think that basic multicast support needs work. To me it seams that the amount of work doesn't have to affect the planned timelines.

Cheers

Francois

_Cool_ advanced use cases like "unicast retransmission of missed multicast information" and "support for fast stream change" could go into the advanced use cases.

Kind regards,

Ad

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Jan 2012 07:33:51 -0500

I do not see how multicast delivery comes anywhere close to the CDNI model.  AFAIK, there are no broadcast use cases; all of the use cases are all on-demand.

Something that might be of interest, although I believe we should prioritize it below content adaptation, might be a multicast or anycast implementation of multiple downstream CDN's being populated by a single upstream CDN.

On Jan 4, 2012, at 6:37 AM, <[email-masked]> <[email-masked]> wrote:

> Hi,
>  
> Reading the discussion and the questions raised so far I feel it’s pretty clear that the likely deployment models & architectures for Multicast via CDN are not clear and they are even less clear in a CDNI context. I think trying to resolve consensus in the WG for what the solution should look like will be almost entirely based on second guessing these deployment models & architectures and I’d therefore agree with Francois suggestion that this would very likely impact the current CDNI timeframe and generate a significant amount of work.
>  
> My view is that CDNI should focus on the basics as a first iteration, which I’d define as Interconnecting CDNs as they currently/typically operate. That’s already a reasonable ask without including potential futures which, so far as I am aware, are not currently widely deployed and for which there is little or no CDN equipment vendor adoption.
>  
> g-
>  
>  
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 4 Jan 2012 13:36:30 +0000

Speaking as an individual, not a co-chair.

> there would still be some tough design choices to make and interesting problem to solve

I have a very simple viewpoint on this. If we have "interesting problems to solve", then that implies we're still inventing. If we are still inventing, then that implies we're not ready to standardize.

In addition to what others have stated below, I have a few thoughts.

- I could imagine a combination of unicast and multicast delivery being used for a single content program; the client joins the multicast feed for "live video" and downloads unicast chunks for "catch up video" (ala "Start Over" from Time Warner Cable, easily found by Google search if you want details).

- I could imagine that the client could discover the multicast feed through downloading a "manifest file" -- that is, prior to CDN request routing. Or the client could discover it by communication with the dCDN after DNS/URL redirection -- that is, subsequent to CDN request routing. Maybe these are good alternatives, maybe they are not.

-- Rich

---

From: "George, Wes" <[email-masked]>
Date: Wed, 4 Jan 2012 13:34:22 -0500

Sorry for the top post. I'm thinking that perhaps the concept of multicast CDNI in general is not necessarily something that needs a defined use case and design at this point. In other words, the CDNI infra and architecture should say something about supporting multicast on general terms, because there's no reason why it *couldn't* support Multicast if the underlying network and CDN devices do. We don't want to explicitly say that it's not supported, I don't think. But we have to be clear that the implementation details are specific enough that actually making it work at the forwarding level is out of scope for this WG (at least for now).
In the current form, this is more about something that the metadata and information exchange/capability negotiation needs to support, so, perhaps the CDNI-metadata drafts would be a place to add some discussion about multicast.
Eg:
Supports multicast content ingestion [y/n]
Supports multicast content delivery (to end user) [y/n]
Supports multicast content delivery (to other CDN caches) [y/n]
Etc...

That way the participating CDNs know what their options are, and could use this in conjunction with something like the metadata telling it whether this is live content or on-demand content, which figures into the liklihood that multicast delivery in any part of the path actually generates any efficiency, and then can take the right action, such as the things that Rich discusses below.

That way, once we figure out the details of how to make it work, we don't have to modify the core protocol (or not as much), and it gets us thinking about it in terms of having the flexibility to do it later.

Thanks
Wes George

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Woundy, Richard
> Sent: Wednesday, January 04, 2012 8:37 AM
> To: [email-masked]
> Cc: [email-masked]
> I have a very simple viewpoint on this. If we have "interesting
> problems to solve", then that implies we're still inventing. If we are
> still inventing, then that implies we're not ready to standardize.
>
> - I could imagine a combination of unicast and multicast delivery being
> used for a single content program; the client joins the multicast feed
> for "live video" and downloads unicast chunks for "catch up video" (ala
> "Start Over" from Time Warner Cable, easily found by Google search if
> you want details).
>
> - I could imagine that the client could discover the multicast feed
> through downloading a "manifest file" -- that is, prior to CDN request
> routing. Or the client could discover it by communication with the dCDN
> after DNS/URL redirection -- that is, subsequent to CDN request
> routing. Maybe these are good alternatives, maybe they are not.
>
> -- Rich
>
> I do not see how multicast delivery comes anywhere close to the CDNI
> model.  AFAIK, there are no broadcast use cases; all of the use cases
> are all on-demand.
>
> Something that might be of interest, although I believe we should
> prioritize it below content adaptation, might be a multicast or anycast
> implementation of multiple downstream CDN's being populated by a single
> upstream CDN.
>
> > Reading the discussion and the questions raised so far I feel it's
> pretty clear that the likely deployment models & architectures for
> Multicast via CDN are not clear and they are even less clear in a CDNI
> context. I think trying to resolve consensus in the WG for what the
> solution should look like will be almost entirely based on second
> guessing these deployment models & architectures and I'd therefore
> agree with Francois suggestion that this would very likely impact the
> current CDNI timeframe and generate a significant amount of work.
> >
> > My view is that CDNI should focus on the basics as a first iteration,
> which I'd define as Interconnecting CDNs as they currently/typically
> operate. That's already a reasonable ask without including potential
> futures which, so far as I am aware, are not currently widely deployed
> and for which there is little or no CDN equipment vendor adoption.
> >
> > g-
> >
> >
> >
> > >> When the multicast support is added in the way described at the
> top, the impact seems pretty low to me and the solution can be deployed
> in the described timeframe.
> > >
> > > My impression is that the use of multicast dCDN-to-user would
> affect most aspects of CDNI and open up many design spaces. Just to
> mention a few for illustration:
> > >             * how can we support consistent logging/accounting when
> dCDN uses Multicast for delivery? would dCDN correlate dCDN log
> information with completely independent Multicast stats information?
> would completely new "logging" records have to be defined for
> logging/accounting when multicast is used for delivery by dCDN? what
> information can be logged and which one cannot when relying on L3
> multicast statistics?
> >
> > Using (network) multicast for content delivery is actually an
> architectural strange, but straightforward process.
> > Imagine the case were the dCDN uses IP multicast for the delivery.
> The dCDN puts the stream on the IP network with a multicast address,
> the viewers connect to the multicast network stream (IGMP join) and the
> network ensures the content is delivered to the viewer.
> > So the dCDN server probably only sees the initial hit, but doesn't
> see additional IGMP joins because those are handled by the network. As
> the dCDN server can only report the information it receives, the
> reporting about the multicasted content is pretty limited.
> > One could argue that the dCDN server should receive the network IGMP
> joins and leaves from the network to send them to the uCDN. On the
> other hand, client based reporting (from the player) does make more
> sense. It is pretty similar to the way some IP TV implementations get
> their logging information.
> >
> > "If you assume that there is no need for the dCDN to support accurate
> logging/reporting, then the impact is low. But if you assume that there
> is a need for the dCDN to support accurate logging/reporting (which,
> BTW, the WG has been assuming so far), then the impact would be very
> high because you would need to somehow correlate L3 Multicast stats
> with content delivery and re-generate corresponding log reports".
> >
> >
> >
> > >             * how does endpoint learn the mapping between a given
> CSP "program" and the corresponding multicast-related information that
> an enduser needs to use to access that program on a given dCDN? Given
> that an enduser may access that same CSP program through different dCDN
> at different time, how is the request routing decision factored into
> selection of multicast access information?
> >
> > In addition to:
> > > Ad wrote:
> > >> On a CDN Interconnection that will support multicast delivery by
> the dCDN, the uCDN would provide the dCDN the content with some kind of
> multicast flag / bit and the dCDN would provide the uCDN with content
> delivery information, that can be used by the end-user retrieve the
> content. In this case multicast retrieval information.
> >
> > The dCDN could provide the uCDN with information of the end-points
> that can be reached by multicast. Providing reachability information
> over the CDN interconnection interface is a good idea anyway (I didn't
> check if this is already in the requirements).
>
> >             * let's say that the uCDN decides to redirect this user
> to a dCDN that happens to support multicast delivery
> >             * how is the user told to issue a Multicast join to a
> particular Multicast group that will give him access to this particular
> live content from that particular dCDN (instead of the user receiving a
> 302 or a DNS response)? Obviously one can invent such a protocol, but
> the User-CDN interface is currently outside the scope of the CDNI WG,
> so working on this would be a significant impact (if not even a
> rechartering).
> >
> >
> >
> >
> > >             * what happens when a dCDN runs in a different AS than
> the access network? is that dCDN not allowed to use multicast delivery?
> or do we assume that inter-AS multicast would be available (which is
> generally not)?
> >
> > The only dCDN that can deliver by multicast, is the one that can
> directly inject the multicast information. As you correctly stated
> inter-AS multicast is hardly used, so the multicast delivering dCDN
> will be in the AS of the end-user.
> >
> > I think this is consistent for both models. And some access control
> is even simpler because the uCDN can simply stop transmitting the
> stream.
> >
> > In the model I am thinking, the uCDN feeds the content once to the
> dCDN, which is then responsible for fanning it out to endusers. When we
> use unicast requests between enduser and dCDN, it is reasonably easy to
> perform per-user/per-request authorization check (eg via some form or
> URI signing). If you were to use multicast delivery, to achieve a
> similar per-user/per-request authorization check you would have to add
> it onto your L3 Multicast infrastructure (eg with every Multicast join
> being subject to some AAA checks). Again, all conceivable but a lot of
> work.
> > "If you assume that there is no need for any access control, then the
> impact is low. But if you assume that there is a need for access
> control (which, BTW, the WG has been assuming so far), then the impact
> would be very high because you would need to somehow introduce a
> consistent/interoperable access control solution into the L3
> Multicast".
> >
> >
> > > It might be the case that someone has made some specific decision
> for each of these design questions that made things simple enough in
> one specific environments with limited requirements (eg no access
> control, no/limited accounting/reporting,...), but I personally believe
> that getting convergence from an open working group on each of the
> intersection points between CDNI and multicast delivery would be a very
> significant impact.
> >
> > Due to the limitations of multicast delivery by the dCDN, I think
> that basic multicast support needs work. To me it seams that the amount
> of work doesn't have to affect the planned timelines.
> >
> > My conclusion is that, even if you were to make a lot of simplifying
> assumptions (eg no logging/reporting, no access control,...) which
> would seriously limit the solution applicability, there would still be
> some tough design choices to make and interesting problem to solve
> (such as the one discussed above about how to communicate to the
> enduser the multicast information needed to access content) that would
> not be compatible with our target timeframe.
> >
> > _Cool_ advanced use cases like "unicast retransmission of missed
> multicast information" and "support for fast stream change" could go
> into the advanced use cases.
> >
> > Kind regards,
> >
> > Ad
> >
> >
> >

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Daryl Malas <[email-masked]>
Date: Wed, 4 Jan 2012 14:06:24 -0700

+1

On 1/4/12 11:34 AM, "George, Wes" <[email-masked]> wrote:

>Sorry for the top post. I'm thinking that perhaps the concept of
>multicast CDNI in general is not necessarily something that needs a
>defined use case and design at this point. In other words, the CDNI infra
>and architecture should say something about supporting multicast on
>general terms, because there's no reason why it *couldn't* support
>Multicast if the underlying network and CDN devices do. We don't want to
>explicitly say that it's not supported, I don't think. But we have to be
>clear that the implementation details are specific enough that actually
>making it work at the forwarding level is out of scope for this WG (at
>least for now).
>In the current form, this is more about something that the metadata and
>information exchange/capability negotiation needs to support, so, perhaps
>the CDNI-metadata drafts would be a place to add some discussion about
>multicast.
>Eg:
>That way the participating CDNs know what their options are, and could
>use this in conjunction with something like the metadata telling it
>whether this is live content or on-demand content, which figures into the
>liklihood that multicast delivery in any part of the path actually
>generates any efficiency, and then can take the right action, such as the
>things that Rich discusses below.
>
>That way, once we figure out the details of how to make it work, we don't
>have to modify the core protocol (or not as much), and it gets us
>thinking about it in terms of having the flexibility to do it later.
>
>Thanks
>Wes George
>
>> Eric Burger
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.

---

From: <[email-masked]>
Date: Fri, 6 Jan 2012 11:13:47 +0100

Hi everyone,

To the best of my knowledge, no standard documents the use of multicast
in a mono-CDN context today. I think it would be reasonable to first
standardize multicast aspects for a mono-CDN context before tackling the
problem in a multi-CDN context.

Best regards,

Gilles