Subject: [CDNi] Proposed update to CDNI requirements draft

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 19 Oct 2011 12:40:09 -0700

Hi folks.  We've received a few comments from the WG on the base requirements draft (-00).  There are some open issues marked for review.  In the attempt to "clean up" and expedite progress, here's a list of proposed resolutions for the identified open issues in draft and WG feedback.  Since it may be easier to read the requirements document in its entirety, the ver-01 will be published with the changes.  Of course, any further WG discussions and conclusions will be captured in the subsequent version.  

Please review and comment.  We believe that the draft is in stable condition.  If anyone disagrees, please specify any open issues that need to be addressed.  Thanks.

-----

Open issue list in draft ver-00:

1. Intro: OPEN ISSUE: Should requirements in each section be ordered by priority?

Resolution: Requirements are logically grouped.  No need to be ordered by priority which may change during working group discussions.

2. GEN-9: OPEN ISSUE: arbitrary number should more than one level?)

Resolution: Change "to an arbitrary number of levels" to "to an arbitrary number of levels beyond the first level"

3. GEN-13: OPEN ISSUE: Virtualization is transparent to CDNI, remove requirement or justify why uCDN/dCDN needs to be aware?)

Resolution: Requirement removed.

4. GEN-14: OPEN ISSUE: Add HTTP ABR requirements

Resolution: Update requirement with "GEN-14: [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate (ABR) content."

5. CNTL-4: OPEN ISSUE: how much influence the Upstream CDN ought to have on pre-positioning of the content on surrogates inside the Downstream CDN is TBD

The surrogates in the Downstream CDN are not required to be exposed to the Upstream CDN.  

Resolution: Remove OPEN ISSUE comment.

6. REQ-1: OPEN ISSUE: Belong to Control Interface section?

Resolution: Change "Control" to "Request-Routing" as the information pertains to request routing function.

7. REQ-5/REQ-6: OPEN ISSUE: Surrogate selection is out of scope?

Accuracy of the Surrogate selection was described as an example.  There is no requirement for Surrogate selection.

Resolution: Remove OPEN ISSUE comment.

8. REQ-9: OPEN ISSUE: Why route looped request?

The loop prevention mechanism should avoid request redirection loop.

Resolution: Add "... by avoiding the loop ..." in the requirement as clarification.

9. META-3: OPEN ISSUE: Confirm high priority

Dynamic CDNI metadata acquisition is required.

Resolution: Remove OPEN ISSUE comment

10. META-4: OPEN ISSUE: Confirm medium priority

Pre-positioned CDNI metadata acquisition is considered medium priority?

Resolution: Remove OPEN ISSUE comment

11. META-14: OPEN ISSUE: Expiration time needed?

Expiration time may be included to remove content.

Resolution: Remove OPEN ISSUE comment

10. LOG section: Editor's note: should we add a requirement for support of aggregate/ summarized logs

Resolution: Add the following new requirement:

LOG-10 [LOW] The CDNI Logging interface may support aggregate/ summarized logs (e.g. total bytes delivered for a content regardless of individual User Agents to which it was delivered).

11. CNTL-1: Added "Only the object(s) and CDNI metadata that pertain to the requesting Upstream CDN are allowed to be purged." to "Delete an object" bullet.

-----

WG feedback:

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

Resolution: See #6 above.

2. >>- I think REQ-2 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).

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.

After consulting with other authors, the conclusion was that the essential parameters used for request routing can be configured at the Upstream CDN.  Therefore, Request Routing Interface support for any of the parameters is considered as optional.

Resolution: No action.

3. >>- In addition, I think REQ-2 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.

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.

Resolution: No action.

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

Resolution: Changed "Control interface" to "Request-Routing architecture" in requirement because the information pertains to request routing function.

5. >>- GEN-11 - With this requirement, it appears some other requirements 

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

Resolution: No action.

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

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.

Resolution: No action

>>- R59 - Should it also include "alternative content" sources, options, 

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

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

Resolution: No action

8. >>- Section 7 - Should there be a "quality" metric or respond from the 

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

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

Resolution: Add new requirement, LOG-11, as follows:

LOG-11 [LOW] The CDNI Logging interface may provide "quality" metrics in the logging of deliveries to User Agents performed by the Downstream CDN.

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

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

This may be an implementation knob to limit levels of redirection.  Though it conflicts with GEN-9 on arbitruary levels.

Resolution: No action.

10. >>Also, should there be any mechanism to indicate whether entitlements 

>>are an issue to downstream CDNs from the CSP?

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

Not clear if this is covered in the delegation blacklist in META-14 requirement?  

Resolution: No action

Kent