Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00

[ramki Krishnan <[e-mail]>]

Hi Ray,

Thanks for your comments. Please find responses inline.

Thanks, ram

From: [e-mail] [mailto:[e-mail]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Wednesday, August 01, 2012 2:22 PM
To: [e-mail]; [e-mail]
Subject: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00


Hi Bhumip,



In response to your question during yesterday's CDNI meeting, I read your draft draft-krishnan-cdni-tm-has-00.



Since I'm not an expert on TCP and the way router queues are implemented, I can't comment on the more technical aspects of your draft. However, when looking at the rationale behind the draft I have some questions.



If I understand your draft correctly, your main premise is that in cases where HTTP Adaptive Streaming is used, the content acquisition interface between the dCDN and uCDN (which in itself is out-of-scope of the WG) could become congested. I have a number of questions related to this:



1) What I don't understand from your draft is what the relationship is between this supposed content congestion and the use of adaptive streaming. Of course, in peak hours, there will generally be more traffic across the link than outside peak hours. But isn't true regardless of the case of whether HAS is used or not?

[ramki Krishnan] HAS automatically adapts to the network congestion and available bandwidth and delivers acceptable video quality to the user. For example, during normal hours, high resolution HD video would be delivered to the end user. Whereas, during peak hour congestion, low resolution HD video would be delivered to the end user.

2) Furthermore, you state that "The bandwidth needs of HAS is directly proportional to the number of active end users who are streaming video." Isn't the general idea behind using a (d)CDN that the necessary bandwidth between two CDNs is NOT directly proportional to the number of active end-users?

[ramki Krishnan] Below are cases where caching in dCDN may not work very well.

Pre-positioning of content may not work for all types of content; it often hard to predict in advance the content needs of users. With this background, CDNi network congestion could occur in the following scenarios 1) During peak hours, in a pull model caching, the first copy of many HAS streams would be delivered. 2) Long-tail personalized content, which is not amenable to caching, is desired by the end user.

3) In section 3. you refer to Long-tail personalized content. I'm not sure what this means. Do you mean dynamic content that is being generated on a per-user basis by the uCDN or the CSP? If so, what would be the use case for wanting to have this content be delivered by a dCDN? Wouldn't this defeat the purpose of having a dCDN at all, since the content has to be delivered on a per-user basis by the uCDN anyway? If the uCDN has to deliver the content to the dCDN for each individual user, wouldn't it be more efficient for the uCDN to deliver this content to the end-user directly?

[ramki Krishnan] Please find a short backgrounder below on long tail content.
http://www.wired.com/wired/archive/12.10/tail.html
http://whatis.techtarget.com/definition/long-tail
Amazon.com and Netflix.com both earn a larger percentage of their profits from relatively obscure, niche books and movies (long tail) than from rentals and purchases of best sellers and blockbusters (most popular).

Best regards,



Ray





This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer