[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Streaming Content
DonE@activate.net wrote:
> I realize the initial emphasis of this WG is web content, but streaming
> content is often mentioned and it is recognized that at least in the future
> it will just as important to deal with streaming media. And it is also
> recognized that most of what is done in the WG will apply to streaming
> content. What I'd like is to be able to use the WG's work as soon as
> possible to help solve current needs, so I'd like to help in this process
> in a way that will have largest impact for streaming, but not detract from
> the main emphasis on web content.
>
> The same CDNP model applies to streaming content as applies to web content,
> but the use of CDNs is a lot further along for web content, as shown by the
> following table:
>
> | Type of Content
> |------------------------------------------------
> | Web | Streaming
> -----------------------+---------------------+--------------------------
> | |
> Matching content & CDN | Manual -> Automated | Manual
> | |
> -----------------------+---------------------+--------------------------
> | |
> Distribution | Semi-Automated | Manual -> Semi-Automated
> | |
> -----------------------+---------------------+--------------------------
> | |
> Request Routing | Automated | Manual -> Automated
> | |
> -----------------------+---------------------+--------------------------
> | |
> Accounting | Manual -> Automated | Manual -> Semi-Automated
> | |
> ------------------------------------------------------------------------
>
> The impression I get is what is currently needed for web content is a way
> to automate the current processes involved in matching CP's content with
> the appropriate CDN(s) and to be able to collect uniform accounting data
> from those CDNs. Currently CPs are successfully using manual methods to
> use multiple CDNs for streaming, but the highest priority need is to
> negotiate request routing between the CDNs.
>
> There are a couple of other differences between web serving and serving
> streaming media content that need to be understood. First, CDNs only become
> important to webcasters for higher bandwidths. Webcasting at bit rates
> 100 kbps or less, which is mostly what has been used up till now, generally
> works fine straight over the Internet with no CDN involved; of course,
> international webcasts are a little harder, so CDNs may be needed even at
> 100 kbps. Second, webcasters may not be content providers and they may not
> have a CDN; that is, they may be in between, owning lots of encoders and
> media servers, but having to rely on CDNs to get broadband to their end
> users. Another difference is that webcasters deal with live (CONTINUOUS
> MEDIA) as well as on-demand content. But the CDNP model still applies to
> the live case. The only difference is in the distribution phase, where,
> instead of distributing content to the CDNs, some sort of connectivity
> between the originating encoder/server/CDN and the destination CDNs needs
> to be set up, so that broadband will get from the CP to the end users at
> the time of the live event.
>
> The request-routing protocol needs to be fast enough so the time of DNS
> lookup is not noticeably increased. I assume the webcaster owns the parent
> CDN that has an algorithm that determines whether a child CDN should be
> used. In the initial implementation, the algorithm would take the IP
> address of the end user (client) and the desired content as input and
> use its knowledge of CDN content distribution, CDN footprint and cost
> that each CDN is charging the webcaster to make a CDN choice; then the
If the request routing system is DNS based then you would not have access
to the client IP address (only the DNS server it used) and would not generally
know "exactly" what content is being asked for, although some of that might
be encoded in the domain name.
>
> protocol would ask that CDN whether it can serve the content, and, if so,
> would pass the request to that CDN, which would return the IP address of
> the surrogate that would serve the content (if not, the parent CDN would
> go on to its second choice, possibly itself). In a later implementation,
> the protocol would return a quality metric (whose meaning would be
> negotiated off line between the parent and the child CDNs), so the parent
> CDN could decide based on current network conditions which CDN to use.
This part of your discussion I am not following that well. However,
I think it does point out that there is some assumed interaction between
the distribution system and the redirection system. The way I was thinking
about it is along the lines of:
- parent CDN negotiate off-line agreement with one or more
child CDNs, this include serving capacity for the parent CDN
from the child CDN
- parent CDN receives updates from child CDN about how
much of that capacity is being used in real time (per region
to make it meaningfull)
- this load information together with the other inputs you mentioned
is used by the redirection system to decide whether to redirect
and which child CDN to direct to.
Now before requests can be redirected to a child CDN the
distribution system would have to tell the child CDN things
like the origin and URL clients will use to access content.
In the case of a pull model this might be done fairly infrequently
e.g. at provisioning timescales. In a pure push model on the
other hand, the distribution system woul have to push content
out to the child CDN before the redirection system can redirect
content there.
Kobus