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

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 1 Aug 2012 21:21:53 +0000

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?

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?

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?

Best regards,

Ray

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

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 1 Aug 2012 19:09:42 -0700

Hi Ray,

Thanks for your comments. Please find responses inline.

Thanks, ram

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

Hi Bhumip,

[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.

[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.

[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

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 1 Aug 2012 22:50:08 -0400

Hi Ram,

  inline:

> -----Original Message-----
> From: Kevin J Ma
> Sent: Wednesday, August 01, 2012 10:14 PM
> To: Kevin J Ma
> Subject: FW: Comments on draft draft-krishnan-cdni-tm-has-00
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ramki Krishnan
> Sent: Wednesday, August 01, 2012 10:10 PM
> To: Brandenburg, R. (Ray) van; [email-masked]; [email-masked]
> Subject: Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00
> 
> Hi Ray,
> 
> 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.

I don't think the functionality of HAS is in question.
To Ray's point, if the link is congested, it's congested.
And as Ray mentioned, content acquisition is out of scope.
What is it that is being proposing wrt CDNI?
Nothing prevents definition of a new content acquisition protocol which
incorporates mandatory WRED, however, that seems orthogonal to CDNI.

> 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?
> 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.

I agree with Ray in questioning the premise that bandwidth needs are proporitional
to active users.  Proportional to the number of different content assets being
streamed possibly, but not active users.  It's not clear what prepositioning has
to do with the question of active users?

> 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?
> 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).

I don't think Ray was asking so much what long tail content is.
I believe Ray was saying that if you don't want to cache that content,
because it's long tail, then don't send it through the CDN.

Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing?
The CDNI requirements (specifically META-14) already discuss distribution
control policies, including preventing delegation.  Beyond the ability to
prevent delegation, are you proposing that CDNs be required to implement
analytics-based delegation policies?  That seems somewhat beyond our scope.

thanx.

--  Kevin J. Ma

---

From: ramki Krishnan <[email-masked]>
Date: Thu, 2 Aug 2012 10:46:04 -0700

Hi Kevin,

Thanks for your comments. Content acquisition and data plane is an important part of interconnecting CDNs. If this is considered out of scope for CDNi, is there any group chartered with this activity ?

Thanks, ramki

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 7:50 PM
To: ramki Krishnan; Brandenburg, R. (Ray) van; [email-masked]; [email-masked]
Subject: RE: Comments on draft draft-krishnan-cdni-tm-has-00

Hi Ram,

  inline:

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of ramki Krishnan
> 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:
> 
> 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.

Nothing prevents definition of a new content acquisition protocol which incorporates mandatory WRED, however, that seems orthogonal to CDNI.

> 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?
> 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 
> 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.

I agree with Ray in questioning the premise that bandwidth needs are proporitional to active users.  Proportional to the number of different content assets being streamed possibly, but not active users.  It's not clear what prepositioning has to do with the question of active users?

> 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?
> 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).

I don't think Ray was asking so much what long tail content is.
I believe Ray was saying that if you don't want to cache that content, because it's long tail, then don't send it through the CDN.

Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing?
The CDNI requirements (specifically META-14) already discuss distribution control policies, including preventing delegation.  Beyond the ability to prevent delegation, are you proposing that CDNs be required to implement analytics-based delegation policies?  That seems somewhat beyond our scope.

thanx.

--  Kevin J. Ma