Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-00.txt

From: [email-masked]
Date: Mon, 12 Sep 2011 09:23:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

	Title           : Content Distribution Network Interconnection (CDNI) Requirements
	Author(s)       : Kent Leung
                          Yiu Lee
	Filename        : draft-ietf-cdni-requirements-00.txt
	Pages           : 20
	Date            : 2011-09-09

   Content Delivery Networks (CDNs) are frequently used for large-scale
   content delivery.  As a result, existing CDN providers are scaling up
   their infrastructure and many Network Service Providers (NSPs) are
   deploying their own CDNs.  There is a requirement for interconnecting
   standalone CDNs so that their collective CDN footprint can be
   leveraged for the end-to-end delivery of content from Content Service
   Providers (CSPs) to end users.  The Content Distribution Network
   Interconnection (CDNI) working group has been chartered to develop an
   interoperable and scalable solution for such CDN interconnection.

   The goal of the present document is to outline the requirements for
   the solution and interfaces to be specified by the CDNI working
   group.  This draft is a work in progress and requirements may be
   added, modified, or removed by the working group.

Requirements Language

   The key words &quot;High Priority&quot;, &quot;Medium Priority&quot; and &quot;Low Priority&quot;
   in this document are to be interpreted in the following way:

   o  &quot;High Priority&quot; indicates requirements that are to be supported by
      the CDNI interfaces.  A requirement is stated as &quot;High Priority&quot;
      when it is established by the working group that it can be met
      without compromising the targeted schedule for WG deliverables, or
      when it is established that specifying a solution without meeting
      this requirement would not make sense and would justify re-
      adjusting the WG schedule, or both.  This is tagged as &quot;[HIGH]&quot;.

   o  &quot;Medium Priority&quot; indicates requirements that are to be supported
      by the CDNI interfaces unless the WG realizes at a later stage
      that attempting to meet this requirement would compromise the
      overall WG schedule (for example it would involve complexities
      that would result in significantly delaying the deliverables).
      This is tagged as &quot;[MED]&quot;.

   o  &quot;Low Priority&quot; indicates requirements that are to be supported by
      the CDNI interfaces provided that dedicating WG resources to this
      work does not prevent addressing &quot;High Priority&quot; and &quot;Medium
      Priority&quot; requirements and that attempting to meet this
      requirement would not compromise the overall WG schedule.  This is
      tagged as &quot;[LOW]&quot;.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-requirements-00.txt

---

From: Daryl Malas <[email-masked]>
Date: Mon, 12 Sep 2011 16:57:56 -0600

A couple of comments on this draft:

- Should R27 be under Section 4 rather than 5?
- I think R28 should be a MUST, and it should be written in the context
ofŠ"The Upstream CDN MUST request aggregate information from the
Downstream CDN to facilitateŠ"  If it's not a request, then it must go the
other way (the Downstream CDN MUST report to the Upstream CDN).
- In addition, I think R28 should really be part of the control protocol.
This information should be known prior to initiating a Route Request.
- Under the control protocol requirements, there is no requirement as to
how often this should occur.
- Should R30 also be under Section 4 rather than 5?
- R35 - I did not see a requirement for "loop detection".  Did I miss it?
I see what looks like a requirement in R42.  If this is the case, it
should be broken out and placed in section 4.
- R44 - Again, this looks like a requirement for loop prevention, but
there is still no hard requirement saying "there MUST be a loop prevention
mechanism!" Note: it would be good to group like requirements for clarity.
- Section 6 - Is this intended to be a protocol within the control
protocol?  To me it looks like it should.  Another way to ask it is, can
this be included within the control protocol?
- R59 - Should it also include "alternative content" sources, options,
etc. in the case of "blackouts"?
- Section 7 - Should there be a "quality" metric or respond from the
downstream CDN on the delivered content to the End user?

With regards to cascaded CDNs, this could be very bad.  I think there must
be a control mechanism to indicate how many "cascades" are involved in the
CDNI and allow the Upstream CDN to cut it off at some point.

Also, should there be any mechanism to indicate whether entitlements are
an issue to downstream CDNs from the CSP?

Thanks,

Daryl

On 9/12/11 10:23 AM, "[email-masked]" <[email-masked]>
wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the Content Delivery Networks
>Interconnection Working Group of the IETF.
>
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 12 Sep 2011 16:10:05 -0700

Hi Daryl.  The WG document, draft-ietf-cdni-requirements-00, maintains a requirement naming convention based on the CDNI interface (e.g. CNTL-xxx, REQ-xxx).  Just so that we are clear on the specific requirement, please use the new labels.  Thanks.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Monday, September 12, 2011 3:58 PM
To: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-requirements-00.txt

Thanks,

Daryl

---

From: Daryl Malas <[email-masked]>
Date: Mon, 12 Sep 2011 17:18:04 -0600

Kent,

My apologies.  I actually reviewed a previous revision of the draft.  I
will try and align my comments below to the new nomenclature.

Regards,

Daryl

On 9/12/11 5:10 PM, "Kent Leung (kleung)" <[email-masked]> wrote:

>Hi Daryl.  The WG document, draft-ietf-cdni-requirements-00, maintains a
>requirement naming convention based on the CDNI interface (e.g. CNTL-xxx,
>REQ-xxx).  Just so that we are clear on the specific requirement, please
>use the new labels.  Thanks.
>
>Kent
>

---

From: Daryl Malas <[email-masked]>
Date: Mon, 12 Sep 2011 17:45:36 -0600

Kent,

I updated my comments below with the new requirements nomenclature.  I
also updated my comment on loop detection/prevention.  This is now a
requirement under GEN-11.  I did notice some amount of potential
redundancy left over in other requirements though.  I just ask the authors
to review all references to Loop Detection/Prevention and see if a simply
reference to GEN-11 will suffice.

Let me know if you have any other questions.

Thanks,

Daryl

On 9/12/11 5:10 PM, "Kent Leung (kleung)" <[email-masked]> wrote:

>- Should REQ-1 be under Section 4 rather than 5?
>- I think REQ-2 should be a MUST, and it should be written in the context
>- In addition, I think REQ-2 should really be part of the control
>protocol.
>- Should REQ-4 also be under Section 4 rather than 5?
>- GEN-11 - With this requirement, it appears some other requirements are
>redundant or unnecessary.

---

From: Daryl Malas <[email-masked]>
Date: Mon, 12 Sep 2011 17:49:26 -0600

Whoops...missed one...R59 = META-14.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 13 Sep 2011 18:04:58 -0700

Hi Daryl.  Thanks for your review and updated requirement numbering.  See comments below in "KL>".

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Monday, September 12, 2011 4:49 PM
To: Kent Leung (kleung); [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-requirements-00.txt

>>- Should REQ-1 be under Section 4 rather than 5?

KL> This is noted in the "OPEN ISSUE" statement.  Unless there are objections, this requirement should be moved to Section 4 CDNI Control Interface.

>>other way (the Downstream CDN MUST report to the Upstream CDN).

KL> This requirement can be split into two.  One for mandatory parameters for base function of CDN selection (e.g. content types, footprint).  The other for optional parameters that can be useful (e.g. metrics/attributes, affinities). The specific parameters should be left for the solution draft to deal with.  The "request" and "report" are RRI pull and push, respectively.  (See terms in framework draft).  In this requirement description, we've describe it more generically.

>>how often this should occur.

KL> The need for information to be known by uCDN prior to route request is only for the iterative CDNI request routing case.  RRI supports this with the push model.

>>- Should REQ-4 also be under Section 4 rather than 5?

KL> I think there may still be some more debate on which functions belong to RRI vs. Control Interface.  If this requirement remains in the Control Interface, it should be moved to Section 5 CDNI Control Interface.

>>redundant or unnecessary.

KL> For what it's worth, this is a generic requirement for loop free information exchange.   There may need to be explicit requirements within the CDNI interface based on specific context.  I think there's some value in that.  Open to disagreements and suggestions to delete requirements or add new requirements. 

>>this be included within the control protocol?

KL> Section 6 is for CDNI Metadata Distribution Interface.  The function is to distribute CDNI metadata.  So we can avoid coupling protocols or not debate in the requirements draft.  That should be left to the solution draft.

>>etc. in the case of "blackouts"?

KL> The list contains examples of content distribution control policies.  It's open to other examples that are commonly use or deemed valuable.  I'm not clear about alternative content sources.  Maybe you can provide some text to clarify?

>>downstream CDN on the delivered content to the End user?

KL> This could be a new [MED] or [LOW] priority requirement.

>>CDNI and allow the Upstream CDN to cut it off at some point.

KL> I think this comment is not specific to CDNI Logging.  You are suggesting having a requirement to limit the number of cascaded CDNs (GEN-9)?

>>an issue to downstream CDNs from the CSP?

KL>  Not sure if entitlements have been discussed in the past.  Others can chime in.

Kent