Subject: [CDNi] Comments and next steps re draft-ma-cdni-publisher-use-cases

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 17 Mar 2011 12:22:33 +0100

Hello Kevin, Raj,

Thanks for documenting the use cases/requirements from the content publisher angle.

I think this contains a mixture of:
	* description of additional use case/scenarios for CDNI
	* identification of requirements for CDNI
	* some stuff that would be outside the scope of CDNI

Would you be willing to merge your efforts into the existing documents? i.e.
	*  work with the authors of cdni-use-cases to have the specific additional CDNI use cases/scenarios you brought up merged into their I-D?
	* work with the authors of cdni-requirements to have the specific additional requirements you brought up merged into their I-D

More specifically:

* 3.1: "The WMA must  track and manage the rights of each Authoritative CDN to
      different content files and be able to set delegation policies
      for those CDNs."
I believe this section is pointing out that this use case is largely transparent to CDNs and CDNI, and is only identifying requirements for the Workflow Management Agent. 
It may be worth including a part of that discussion & conclusion (about CDNs/CDNIs) into the cdni-use-cases (dropping the reqt on WMA).

* 3.2: This is actually providing a good discussion on the specific requirements associated with "content purge" (eg disable vs delete, delete confirmation,...). This point has also been discussed on the list and the conclusions reflected into cdni-requirements. Can you please review R15 and R16 (in cdni-requirements-01) and let us know if you still see anything missing?

*3.3: I think this relates to the discussion we've had on the list about potential SLA parameter signaling in CDNI. I think we converged we don't want to do that (at least in initial scope). 

* 4.1/4.2: these two are both about the same fundamental point ie if we convey inside CDN distribution metadata some awareness of content relationship (e.g. if you are serving this "content item/segment", it is likely you will have to serve this other "content item/segment" soon) then it can do interesting optimizations (e.g. smart pre-fecthing). Note that another way these benefits could be achieved would be to make the CDN really aware of formats and do transformation itself as needed.
I see that topic as a level of optimization that could be added as a second step to a base CDNI solution. So I'd suggest that we make a note of this future "direction/requirement" so the initial solution keeps them in mind, but would not include it as a MUST requirement for initial scope.
Is that reasonable?
(Note also that even without segment/adaptive-scheme awareness in the CDNs, existing HTTP/DNS mechanisms/behavior can be used to ensure that request routing does not have to deal with each individual segment request - I think this is the point Ben has also brought up). 

*4.3:
"An extension to this scenario
       is switching between different devices either within the same
       NSP ... or across multiple NSPs"
This seems worth adding into cdni-use-cases.

*4.4:
An extension to this
       scenario is the condition where the origin server (OS1) becomes
       either temporarily or permanently unreachable to CDN1.  In this
       case, there are two possible options:
          o Redirect the request to CDN2, in the hope that CDN2 still
          has connectivity to the origin server (OS1).
          o Failover to a secondary origin server (OS2) and attempt to
          retrieve the content from OS2 in order to service the
          request.
"
This scenario & the first of the two options above (the second option seems outside CDNI scope) seem worth adding into cdni-use-cases.

Cheers

Francois

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 17 Mar 2011 14:07:35 -0400

Francois,

  We would be happy to work with the authors of the other I-Ds to merge
  in the additional use cases and requirements.

  One general comment: it was not our intention to over emphasize the
  workflow management itself.  A core functionality of CDNI is the
  ability to set delegation policies, i.e., each CDN needs to know:
  "for a given piece of content, who am I allowed to delegate to?".
  Whether the content provider calls the authoritative CDN and asks them
  to set it, or whether they have a workflow management station that can
  set it directly, the same metadata API should be used to actually set it.
  I think the goal is the same: a sound and versatile core API.

  further comments inline.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francois Le Faucheur
> Sent: Thursday, March 17, 2011 7:23 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CDNi] Comments and next steps re draft-ma-cdni-publisher-use-cases
> 
> Hello Kevin, Raj,
> 
> 	*  work with the authors of cdni-use-cases to have the specific
> additional CDNI use cases/scenarios you brought up merged into their I-D?
> 	* work with the authors of cdni-requirements to have the specific
> additional requirements you brought up merged into their I-D
> 
> More specifically:
> 
> I believe this section is pointing out that this use case is largely
> transparent to CDNs and CDNI, and is only identifying requirements for the
> Workflow Management Agent.
> It may be worth including a part of that discussion & conclusion (about
> CDNs/CDNIs) into the cdni-use-cases (dropping the reqt on WMA).

I agree that the setting of policies is beyond the scope of CDNI.
We just wanted to highlight that certain policies exist to make sure that
the protocols we define do not prevent their implementation.
I think the updates to metadata precedence and grouping (R54/R55) help.

> * 3.2: This is actually providing a good discussion on the specific
> requirements associated with "content purge" (eg disable vs delete, delete
> confirmation,...). This point has also been discussed on the list and the
> conclusions reflected into cdni-requirements. Can you please review R15 and
> R16 (in cdni-requirements-01) and let us know if you still see anything
> missing?

I think the updated R15 and R16 reflect the discussions well.
 
> *3.3: I think this relates to the discussion we've had on the list about
> potential SLA parameter signaling in CDNI. I think we converged we don't want
> to do that (at least in initial scope).

As was discussed on the list, I think it should have been more about
advertisement and enforcement, than actual negotiation.
The updated R28 and R40 requirements addresses this to some degree,
though we may want to add to it in the future.
I agree that this does not need to be in the initial scope.

> * 4.1/4.2: these two are both about the same fundamental point ie if we convey
> inside CDN distribution metadata some awareness of content relationship (e.g.
> if you are serving this "content item/segment", it is likely you will have to
> serve this other "content item/segment" soon) then it can do interesting
> optimizations (e.g. smart pre-fecthing). Note that another way these benefits
> could be achieved would be to make the CDN really aware of formats and do
> transformation itself as needed.
> I see that topic as a level of optimization that could be added as a second
> step to a base CDNI solution. So I'd suggest that we make a note of this
> future "direction/requirement" so the initial solution keeps them in mind, but
> would not include it as a MUST requirement for initial scope.
> Is that reasonable?
> (Note also that even without segment/adaptive-scheme awareness in the CDNs,
> existing HTTP/DNS mechanisms/behavior can be used to ensure that request
> routing does not have to deal with each individual segment request - I think
> this is the point Ben has also brought up).

I think that this may ultimately be an extension of metadata precedence
and grouping (R54/R55).  We just wanted to highlight the case.
I am fine with marking it as a future item.

> This seems worth adding into cdni-use-cases.

Sounds good.

> This scenario & the first of the two options above (the second option seems
> outside CDNI scope) seem worth adding into cdni-use-cases.

Sounds good.
As for the second option, I think it is an extension of content acquisition
R50?  the ability to have a backup?

thanx.

--  Kevin J. Ma

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