Subject: [CDNi] draft-ietf-cdni-requirements-05.txt

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 6 Mar 2013 23:08:31 +0000

Hi folks. The requirements draft was updated based on the feedback from the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), draft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-logging.

In preparation for the next WG session, the edits were published in the draft for review. Please provide your comments to the list of requirement changes below.  Thanks.

1. New CDNI Control Interface requirement

         a. Based on recommendations in ID-HAS, CCID is introduced for HAS content without the need for HAS-aware CDN.

         CNTL-12  [MED] The CDNI Control interface should allow for multiple	
 	            content items identified by a Content Collection ID to be	
 	            purged using a single Content Purge action.

2. New CDNI Request Routing Interface requirements

          a. This is an explicit requirement for RRI to support per-chunk request routing. Since the chunk is same as any content, it's not clear if the requirement is needed?

          REQ-15  [HIGH] The CDNI Request-Routing interface shall allow for	
 	           per-chunk request routing of HTTP Adaptive Streaming content.	
 	           [Ed: chunk is treated as any content, is this needed?]	
 		
          b. Manifest rewrite by uCDN is considered as optional feature in the ID-HAS, should the priority be LOW instead of MED?

          REQ-16  [MED] The CDNI Request-Routing interface should allow the	
 	           Upstream CDN to use the information conveyed by the	
 	           Downstream CDN during the Recursive Request Routing process	
 	           to rewrite an HTTP Adaptive Streaming manifest file.  [Ed:	
 	           should this be LOW?]	
 
           c. Manifest rewrite by uCDN for URI Signing is considered as optional feature in the ID-HAS, should the priority be LOW instead of MED?
		
           REQ-17  [MED] The CDNI Request-Routing interface should allow the	
 	           Upstream CDN to re-sign the invariant portion of the chunk	
 	           URIs embedded in the HTTP Adaptive Streaming manifest file.	
 	           [Ed: should this be LOW?]	
 		
          d. Use of cookie for URI Signing is is considered as optional feature in the ID-HAS, should the priority be LOW instead of MED?

          REQ-18  [MED] The CDNI Request-routing interface should allow the use	
 	           of HTTP cookie to associate the chunks with the HTTP Adaptive	
 	           Stream manifest file (which is verified by the URI signature)	
 	           basedon the Authorization Group ID (which is an identifier	
 	           used to correlate the manifest file to the related chunks).	
 	           [Ed: should this be LOW?]	
 
          e. 	LOW instead of MED priority?	

          REQ-19  [MED] The CDNI Request-Routing interface may allow for an	
 	           efficient method of transferring request routing information	
 	           for multiple chunks from the Downstream CDN to the Upstream	
 	           CDN as part of the recursive request routing process.  [Ed:	
 	           should this be LOW?]	
 	
          f. Based on ID-HAS and logging drafts, the following requirement was introduced to log HAS content and customization of the logging.
	
          REQ-20  [MED] The CDNI Request-Routing/Footprint and Advertising	
 	           interface shall support advertisement of the following	
 	           capabilities:	
 		
 	           *   support for customized CDNI Logging	
 		
 	           *   support of Content Collection ID logging	
 		
 	           *   support for Session ID logging

3. Removed CDNI Metadata Distribution Interface requirement.

          a. Based on the metadata draft, there is no need for dCDN to indicate to the uCDN the result of delivering the metadata since the "pull" or "triggered pull" model is used (i.e. dCDN request for metadata from uCDN).

META-13  [HIGH] The CDNI Metadata Distribution interface shall	 		
            provide indication by the Downstream CDN to the Upstream CDN	 		
            of whether the CDNI metadata (and corresponding future	 		
            request redirections) is accepted or rejected.  When	 		
            rejected, the CDNI Metadata Distribution protocol Must allow	 		
            the Downstream CDN to provide information about the cause of	 		
            the rejection.	 		

4. New CDNI Metadata Distribution Interface requirements

        a. Based on ID-HAS's recommendations, this is introduced.

        META-19  [HIGH] The CDNI Metadata interface shall provide indication	
 	            of related content (e.g.  HTTP Adaptive Bit Rate chunks) by	
 	            the Content Collection ID (CCID) metadata.  This could be	
 	            used by the Downstream CDN for operations on the group of	
 	            content.  For example, this could potentially include:	
 		
 	            *   content acquisition for the entire set of files when one	
 	                piece of content is requested	
 		
 	            *   local file management and storage bundles all the files	
 	                for the content	
 		
 	            *   purging the entire set of files associated with the	
 	                content	
 		
 	            *   logging of the delivery of the content for the session	
 	                when at least one file in the set was delivered	
 		
        b. Based on the logging draft, this is introduced.

        META-20  [HIGH] The CDNI Metadata Distribution interface shall	
 	            support an OPTIONAL mechanism allowing the Upstream CDN to	
 	            indicate to the Downstream CDN which CDNI Log fields are to	
 	            be provided for all, for specific sets of, or for specific	
 	            content items delivered using HTTP.  A CDNI implementation	
 	            that does not support this optional CDNI Metadata	
 	            Distribution Interface mechanism MUST ignore this log format	
 	            indication and generate CDNI logging format for HTTP	
 	            Adaptive Streaming using the default set of CDNI Logging	
 	            fields.	
 		
        c. Based on the ID-HAS's recommendations, this is introduced.

        META-21  [MED] The CDNI Metadata Distribution interface shall allow	
 	            the Upstream CDN to signal to the Downstream CDN the Content	
 	            Collection ID value for all, for specific sets of, or for	
 	            specific content items delivered using HTTP.  Whenever the	
 	            Downstream CDN is instructed by the Upstream CDN to report	
 	            the Content Collection ID field in the log records, the	
 	            Downstream CDN is to use the value provided through the CDNI	
 	            Metadata interface for the corresponding content.  Note the	
 	            Session ID field along with Content Collection ID may be	
 	            used for HTTP Adaptive Streaming content.	
 		
        d. Based on ID-HAS's recommendations, this is introduced.

        META-22  [MED] The CDNI Metadata Distribution interface shall allow	
 	            the Upstream CDN to signal to the Downstream CDN the	
 	            Authorization Group ID value for all the related HTTP	
 	            Adaptive Streamin content (i.e. manifest file and chunks).	
 	            The authorization result of a content (e.g. manifest file)	
 	            is transferred over to related content (e.g. chunks).  [Ed:	
 	            need to improve wording?]

5. Remove CDNI Logging Interface requirement

        a. It is deemed unnecessary for dCDN to obtain logs from uCDN, which has access to all the logs for trouble-shooting and auditing.

LOG-4   [HIGH] The CDNI Logging interface shall provide logging of	 	
           distribution performed by the Upstream CDN as a result of	 		
           acquisition request by the Downstream CDN.

6. Add CDNI Logging Interface requirements

          a. Based on the logging draft, this is introduced.

          LOG-17  [HIGH] The CDNI Logging interface shall support the	
 	           notification from Downstream CDN to Upstream CDN for the	
 	           event that the logging retention duration or maximum size of	
 	           logging data has exceeded.	
 		
          b. Based on the ID-HAS, CCID is a field to report in the log. Also, based on the logging draft, Session ID is another field needed in the log.

          LOG-18  [MED] The CDNI Logging interface should support the ability	
 	           for the Downstream CDN to include the Content Collection ID	
 	           and Session ID fields in CDNI log entries generated for HTTP	
 	           Adaptive Streaming content.  This fields can be supported by	
 	           the "customizable" log format which is expected to be defined	
 	           independently of HTTP Adaptive Streaming.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, February 23, 2013 1:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt

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-05.txt
	Pages           : 23
	Date            : 2013-02-23

Abstract:
   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 "High Priority", "Medium Priority" and "Low Priority"
   in this document are to be interpreted in the following way:

   o  "High Priority" indicates requirements that are to be supported by
      the CDNI interfaces.  A requirement is stated as "High Priority"
      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 "[HIGH]".

   o  "Medium Priority" 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 "[MED]".

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-requirements-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-requirements-05

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

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:07:46 +0000

Kent and all,

I have received consistent feed-back from two CDN operators and a Content Provider that the CDNI solution ought to support:
	*A* enforcement of caching directives by dCDN that are different to the ones signalled in the HTTP headers
	*B* choice of ignoring/factoring query string in dCDN caching
	*C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Download) 

*A* and *B* are already mostly covered in META-18 but it is listed as [LOW]. I would recommend we raise META-18 to [MED].

I don't think *C* is covered. I would recommend we add rate-pacing as a 3rd example of "surrogate cache behaviour" in META-18. 

I will bring this up in the CDNI session today, but wanted to give folks some heads-up.

I also have other comments on -05 which I will either pass on to Kent directly or post on the list.

Cheers

Francois

"
  META-18  [LOW] The CDNI Metadata Distribution interface may allow
            signaling of CDNI-relevant surrogate cache behavior
            parameters.  For example, this could potentially include:

            *   control of whether the query string of HTTP URI is to be
                ignored by surrogate cache

            *   content revalidation parameters (e.g.  TTL)
"

---

From: "Dave Oran (oran)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:18:59 +0000

> 	*C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Download) 
Stupid naïve question. Why should an uCDN care if a dCDN decides to provide better/faster service by allowing higher download rates if it wants? The uCDN can always himself rate limit how fast it primes the dCDN caches if it want to protect its own peak-rate service resources.

I can see the converse - that the uCDN may want via service contract to have the dCDN support certain minimum rates and *not* arbitrarily rate limit the customers of the uCDN. Is that was was intended by *C*?

Enlightenment greatly appreciated.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:28:43 +0000

Hello Dave,

> Stupid naïve question. Why should an uCDN care if a dCDN decides to provide better/faster service by allowing higher download rates if it wants? The uCDN can always himself rate limit how fast it p…

The motivation is that some Content Providers want to minimise their delivery costs (and hence minimise the volume and/or peak streaming rate, depending on what metric they are charged on) when the users are only watching the first parts of a piece of content, which, as we know is common behaviour. So the Content Provider is asking the authoritative CDN (who then needs to ask its dCDNs) to only start to stream the content at the "necessary" rate (i.e. something marginally higher than playrate). If the user switches to some other content, the Content Provider only gets charged for marginally more than what was viewed.

> 
> I can see the converse - that the uCDN may want via service contract to have the dCDN support certain minimum rates and *not* arbitrarily rate limit the customers of the uCDN.

I can see that too. But I'd expect that to happen mostly at the Business layer initially. I can see a few cases where you might want to signal some information uCDN-->dCDN and have dCDN take actions about it, but that seems more sophisticated than what we are focusing on in initial scope.

> Is that was was intended by *C*?
> 

Are you feeling enlightened or darkened?

Francois

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 12 Mar 2013 16:53:58 +0000

Hi Francois. Comments below in "KL>".

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Tuesday, March 12, 2013 7:08 AM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt

Kent and all,

KL> That sounds reasonable to me. Unless others object, this requirement will be set to MED priority in the next version.

KL> I can see some value of this feature. I'll see how the debate settles before updating the draft.

KL> Thanks for the heads up.

KL> Thanks.

Kent

Cheers

Francois

"

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Sat, 30 Mar 2013 09:50:19 +0000

Hi Kent and all,

In addition to the comment already discussed below, here are my remaining comments (as an Individual):

OLD:
"
 GEN-4   [HIGH] The CDNI solution shall not require intra-CDN
           information ...
"
NEW:
"
 GEN-4   [HIGH] The CDNI solution shall not depend on intra-CDN
           information ...
"

OLD:
"
GEN-5   [HIGH] The CDNI solution shall support delivery to the user
           agent based on HTTP [RFC2616].  (Note that while delivery and
           acquisition "data plane" protocols are out of the CDNI
           solution scope, the CDNI solution "control plane" protocols
           are expected to participate in enabling, selecting or
           facilitating operations of such acquisition and delivery
           protocols.  Hence it is useful to state requirements on the
           CDNI solution in terms of which acquisition and delivery
           protocols).

GEN-6   [HIGH] The CDNI solution shall support acquisition across
           CDNs based on HTTP [RFC2616].
"
NEW:
"
GEN-5   [HIGH] The CDNI solution shall support delivery to the user
           agent based on HTTP [RFC2616].  

GEN-6   [HIGH] The CDNI solution shall support acquisition across
           CDNs based on HTTP [RFC2616].

(Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols.  Hence it is useful to state requirements on the CDNI solution in terms of which acquisition and delivery protocols).
"
(Rationale: the note applies to both GEN-5 and GEN-6)

Regarding:
"
GEN-13  Removed.
"
I suggest you just remove altogether the requirements that were dropped and renumber the following ones to avoid gaps.

Regarding:
"
CNTL-1   [HIGH] The CDNI Control interface shall allow the Upstream
            CDN to request that the Downstream CDN (and, if cascaded
            CDNs are supported by the solution, that the potential
            cascaded Downstream CDNs) perform the following actions on
            an object or object set:

            *   Mark an object or set of objects and/or its CDNI
                metadata as "stale" and revalidate them before they are
                delivered again

            *   Delete an object or set of objects and/or its CDNI
                metadata from the CDN surrogates and any storage.  Only
                the object(s) and CDNI metadata that pertain to the
                requesting Upstream CDN are allowed to be purged.
"
It is clear to me that the 2nd bullet is a [HIGH]. 
But it is not clear to me that the first bullet is really a [HIGH]. I see it as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW]. In fact, does the "triggers" interface actually cope for that ?
Perhaps you can split the two bullets so they can have a different priority level.

Regarding:
"
  CNTL-3   [HIGH] The CDNI Control interface shall support initiation
            and control by the Upstream CDN of pre-positioned CDNI
            metadata acquisition by the Downstream CDN.
"
I thought we have agreed that pre-positioning would be a [MED] whether content or metadata. CNTL-4 is already a [MED]. I suggest making CNTL-3 a [MED] also.

Regarding:
"
CNTL-10  [LOW] The CDNI Control interface may allow exchange and
            negotiation of delivery authorization mechanisms to be
            supported across the CDNs (e.g.  URI signature based
            validation).
"
This functionality has moved to the FCI. How about, you move this functionality with the rest of the text discussing the FCI requirements?

Regarding:
"
CNTL-12  [MED] The CDNI Control interface should allow for multiple
            content items identified by a Content Collection ID to be
            purged using a single Content Purge action.
"
I suggest moving this requirement up so it follows the first purge-related requirements i.e. place it right after CNTL-1.

Regarding Section 5:
I strongly recommend that:
	* you split this into separate sections for RI and FCI. 
	* in each requirement, you mention the actual interface (i.e. RI or FCI) instead of "the Request Routing Interface".
It will make it much easier to read, and much more useful so we know which requirements applies to which interface.

Regarding REQ-15 and "[Ed: chunk is treated as any content, is this needed?]"
I vote for keeping it in. Explicit is better. 

Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file-Manipulation approaches as nice-to-allow but not [MED].

Regarding REQ-19: it is a [MED] but you use "may". I think it shoudl say "should" for a [MED].
BTW: at the very end of editing , you should probably do a pass and check the shall/should/may correspond to HIGH/MED/LOW in each and every requirement. e.g. there is also a mismatch in REQ-20.

Regarding REQ-20:
The list of capabilities here is a little out of date (e.g. "support for customised CDNI logging" - which is dropped) and only covers the ones related to logging while it shoudl bring up the other ones (e.g. delivery protocol). Since the actual capabilities are discussed in the FCI semantics draft, I would suggest not trying to list specific capabilities in that requirement, and instead keep it high level and probably just list the types of capabilities (e.g. mention it needs to cover capabilities associated with logging, with distribution protocols, with acquisition protocols, etc..)

OLD:
"
META-7   [HIGH] The CDNI Metadata Distribution interface shall allow
            the Upstream CDN to request addition and modification of
            CDNI Metadata into the Downstream CDN.
"
NEW:
"
META-7   [HIGH] The CDNI Metadata Distribution interface (possibly in conjunction with the CDNI Control interface) shall allow
            the Upstream CDN to request addition and modification of
            CDNI Metadata into the Downstream CDN.
"

OLD:
"
META-8   [HIGH] The CDNI Metadata Distribution interface shall allow
            removal of obsolete CDNI Metadata from the Downstream CDN
            (this could, for example, be achieved via an explicit
            removal request from the Upstream CDN or via expiration of a
            Time-To-Live associated to the Metadata).
"
NEW:
"
META-8   [HIGH] The CDNI Metadata Distribution interface (possibly in conjunction with the CDNI Control interface) shall allow
            removal of obsolete CDNI Metadata from the Downstream CDN
            (this could, for example, be achieved via an explicit
            removal request from the Upstream CDN or via expiration of a
            Time-To-Live associated to the Metadata).
"

OLD:
"
META-15  [HIGH] The CDNI Metadata interface shall be able to exchange
            a set of well-accepted metadata elements with specified
            semantics (e.g. start of time window, end of time window).
"
NEW:
"
META-15  [HIGH] The CDNI Metadata interface shall be able to exchange
            a set of metadata elements with specified
            semantics (e.g. start of time window, end of time window).
"

Regarding META-18: see thread below.

Regarding META-20: As documented in http://www.ietf.org/mail-archive/web/cdni/current/msg01375.html, it is felt that this requirement shoudl not be pursued for initial deliverables. Besides, there was no hard conclusion as to whether this would belong to MI or CI. This requirement should be a [MED] (instead of a [HIGH]) and I suggest you add a note indicating that there is still some thinking to be done to conclude whether this should really be MI or CI.

OLD:
"
LOG-1   [HIGH] The CDNI logging architecture and interface shall
           ensure reliable logging of CDNI events.
"
NEW:
"
LOG-1   [HIGH] The CDNI logging architecture and interface shall
           ensure reliable transfer of CDNI logging information across CDNs.
"

OLD:
"
LOG-7   [HIGH] The CDNI Logging interface shall define a log file
           format and a set of fields to be exported through the Logging
           protocol, with some granularity (e.g.  On a per content type
           basis).
"
NEW:
"
LOG-7   [HIGH] The CDNI Logging interface shall define a log file
           format and a set of fields to be exported for various CDNI logging events.
"

re LOG-8:
s/mechanisms/mechanism/

re LOG-14:
This requirement should be removed since it is already covered by another requirement on the CI.

OLD:
"
LOG-17  [HIGH] The CDNI Logging interface shall support the
           notification from Downstream CDN to Upstream CDN for the
           event that the logging retention duration or maximum size of
           logging data has exceeded.
"
NEW:
"
LOG-17  [HIGH] The CDNI Logging interface shall allow a CDN to notify another CDN about which CDNI logging information is available for transfer (and/or no longer available, say because it exceeded some logging retention period or some logging retention volume).
"
Rationale: The current wording was overly prescriptive. I think the key point is that the CDNs should inform each other about which info can be obtained. 

OLD:
"
LOG-18  [MED] The CDNI Logging interface should support the ability
           for the Downstream CDN to include the Content Collection ID
           and Session ID fields in CDNI log entries generated for HTTP
           Adaptive Streaming content.  This fields can be supported by
           the "customizable" log format which is expected to be defined
           independently of HTTP Adaptive Streaming.
"
NEW:
"
LOG-18  [MED] The CDNI Logging interface should support the ability
           for the Downstream CDN to include the Content Collection ID
           and Session ID fields in CDNI log entries generated for HTTP
           Adaptive Streaming content.
"
Rationale: again custom log likely not supported initially.

Francois