Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI

From: Kevin J Ma <[email-masked]>
Date: Wed, 16 Nov 2011 13:24:37 -0500

Serge (and Kent),

  Some questions/comments on the requirements in the draft:

  LOG-A1/A2 seem like a good idea.  They seem to mimic the existing
  LOG-2/3 requirements, respectively, which seems fine, but do we need
  to have separate requirements for these or can we just update LOG-2/3
  to include failures?

  One question about LOG-2 and LOG-A1: is the text "deliveries to
  User Agents" intended to imply that the data should track and be
  aggregatable per unique user?  We may want to clarify that?

  LOG-A3/A4 sound reasonable.  Should we include bandwidth or other
  usage metrics as well and can they all be included in one usage
  metric requirement (similar to META-14)?

  The example metrics in LOG-A3 seem like they could be exposing
  intra-CDN information (e.g., total GB)?  Does this go against the
  GEN-4 requirement?

  LOG-A5 could be interpreted as either: a) configure the dCDN to do
  storage reporting, or b) ask the dCDN to immediately send out logs?
  If the latter, it seems to overlap with the existing LOG-9 requirement?

  Are LOG-A3/A4 intended to be periodic, or only on-demand?  If the
  latter, then is it just an issue of raising LOG-9 from LOW to MED?
  Note: LOG-9/A5 should probably be included in the 'trigger' discussion?

  LOG-A6 seems like two requirements, that could be parts of a more
  generic set of LOG-A3/A5 requirements?

  LOG-A7 sounds ok, but is the confirmation from the delete request not
  sufficient?  Is a log of individual deleted objects only meaningful
  if the object was there to be deleted, i.e. does it need to compare
  against everything that was acquired but not yet evicted?

  LOG-A8/A9 seem reasonable, though they feel more like a MED than a
  HIGH to me.  Assuming they are HIGH, could we just update the existing
  LOG-7 requirement to include extensibility?  Is there an existing
  log description language that could/should be used here?

  CNTL-A1 seems to overlap with the existing CNTL-2 requirement.
  Could we just fix the wording in CNTL-2?

  CNTL-A2 may need to clarify who created the sub-objects?  If the
  dCDN created the sub-objects, then that may be intra-CDN information
  that falls under the GEN-4 requirement?  Otherwise, it feels like a
  normal delete failure?  Is this requirement to get a more detailed
  error in the CNTL-A3 case?

  CNTL-A3 seems to have a couple of aspects.  I think bulk delete is
  already covered by the existing CNTL-1 requirement.  The second part
  which lists filters for bulk delete seems to imply that the dCDN needs
  to know what the content is and who it belongs to?  That seems like it
  may need some type of companion metadata requirement?

  CNTL-A4 feels out of scope.  Reservation seems more like a precondition
  to interconnecting?  Is the reservation just a suggestion to, or a
  requirement for, the dCDN?  Is there an existing reservation protocol
  that could/should be used here?  Maybe a use case would be helpful to
  describe the CDNI scope?

thanx.

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of Serge Manning
Sent: Friday, October 21, 2011 5:47 PM
To: [email-masked]
Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI

I am resurrecting this old thread to let you know that a draft has finally been submitted. The authors have tried to analyze ATIS CSF's requirements and determine the additional requirements that are appropriate for CDNI. Our hope is that these additional reqs might be adopted into CDNI. 
 
Please take a look at the draft and provide your feedback. Thanks.
 
Filename:        draft-manning-cdni-additional-csf-reqs
Revision:        00
Title:           Additional Content Distribution Network Interconnection (CDNI) Requirements Based on ATIS CSF
Creation date:   2011-10-21
WG ID:           Individual Submission
Number of pages: 9

---

From: Serge Manning <[email-masked]>
Date: Fri, 18 Nov 2011 00:25:36 -0600

Thanks for looking at the draft and providing feedback Kevin. See inline.

On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma <[email-masked]>wrote:

> That sounds fine.

> My interpretation is that a logging record is generated for each content
delivered to an end user by the dCDN on behalf of the uCDN. Not sure what
you mean about "aggregate."

> That would be OK. We can probably just keep the requirements general as
bandwidth, storage, etc. and determine the parameters in the solutions
documents.

> The intention of LOG-A3 is to report usage of aggregate storage used by
the dCDN on behalf of the uCDN and not other internal storage resources
private to the dCDN.

> I think LOG-A5 is the same as LOG-9 except for storage. So this could be
folded into LOG-9.

> The thinking was to have normal periodic with on-demand as an additional
capability if the uCDN wanted to do a check of what storage is outstanding
at the moment.

> No, I think LOG-6 is talking about the logging interface itself and its
ability to be responsive for some near real-time uses. While LOG-A3/A5 is
talking about the types of parameters in the logging messages.

> IMO, the response to the delete is more a control plane acknowledgement
while the logging interface is a complete record of transactions between
the CDNs. Thus, we need both.

> I believe that making the messaging extensible is easy and needs to be
done on the first release so that small proprietary fields can be carried
over this otherwise standardized interface resulting in wide use of the
standard. We should not make the messaging fixed and then later decide to
make it extendable.

> Yes, we can fold the confirmation into CNTL-2.

> If the delete is successful, everyone is happy. If the delete fails, you
get confirmation of that. If the delete *partially* fails which would mean
its an object with sub-objects, then this is asking for a more detailed
partial delete report. I think the sub-objects have to be known and
understandable by the uCDN for this to be of any value. So I don't think
this applies if the dCDN creates the sub-objects. Right now, I don't myself
understand how the dCDN would do this sub-object creation on its own. Maybe
you could explain.

>  I don't see the bulk delete in CNTL-1. I think the two aspects here are
linked. Hmm...it seems like it may need some metadata requirement. Let me
think about it some more.

> I will look up the ATIS use case and report it back here.

Thanks again for your analysis and feedback.

> I am resurrecting this old thread to let you know that a draft has finally
> been submitted. The authors have tried to analyze ATIS CSF's
> requirements and determine the additional requirements that are appropriate
> for CDNI. Our hope is that these additional reqs might be adopted into
> CDNI.
>

-- 
--Serge

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 21 Nov 2011 16:21:30 -0800

Hi Serge and Kevin.  Comments below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Serge Manning
Sent: Thursday, November 17, 2011 10:26 PM
To: Kevin J Ma
Cc: [email-masked]
Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI

Thanks for looking at the draft and providing feedback Kevin. See
inline.

On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma <[email-masked]>
wrote:

Serge (and Kent),

That sounds fine.

KL> Proposed update to LOG-2:

LOG-2   [HIGH] The CDNI Logging interface shall provide logging of

           deliveries and incomplete deliveries to User Agents performed
by 

           the Downstream CDN as

           a result of request redirection by the Upstream CDN.

KL> Proposed update to LOG-3:

LOG-3   [MED] In the case of cascaded CDNs, the CDNI Logging
           interface shall allow the Downstream CDN to report to the
           Upstream CDN logging for deliveries and incomplete deliveries
performed by the
           Downstream CDN itself as well as logging for deliveries
           performed by cascaded CDNs on behalf of the Downstream CDN.

	 One question about LOG-2 and LOG-A1: is the text "deliveries to
	 User Agents" intended to imply that the data should track and
be
	 aggregatable per unique user?  We may want to clarify that?

My interpretation is that a logging record is generated for each content
delivered to an end user by the dCDN on behalf of the uCDN. Not sure
what you mean about "aggregate." 

	 LOG-A3/A4 sound reasonable.  Should we include bandwidth or
other
	 usage metrics as well and can they all be included in one usage
	 metric requirement (similar to META-14)?

KL> Proposed new requirements:

     LOG-##  [MED] The CDNI Logging interface shall support logging of
             consumed resources (e.g. storage, bandwidth) to the
upstream CDN for deliveries where
             content is stored by the downstream CDN for delivery to
             User Agents. The information logged may include the type
             of storage (e.g., Origin, Intermediate, Edge, Cache) as
             well as the amount of storage (e.g., total GB, GB used,
             per time period, per content domain) all of which may
             impact the cost of the services.
 
     LOG-##  [MED] In the case of cascaded CDNs, the CDNI Logging
             interface shall support the Downstream CDN to report
             consumed resources (e.g. storage, bandwidth) to the
Upstream CDN where content is
             stored by the Downstream CDN itself as well as logging for
             storage resources when content storage is performed by
             cascaded CDNs on behalf of the Downstream CDN.

	 The example metrics in LOG-A3 seem like they could be exposing
	 intra-CDN information (e.g., total GB)?  Does this go against
the
	 GEN-4 requirement?

	 LOG-A5 could be interpreted as either: a) configure the dCDN to
do
	 storage reporting, or b) ask the dCDN to immediately send out
logs?
	 If the latter, it seems to overlap with the existing LOG-9
requirement?

KL> Note LOG-9 is [LOW] vs. LOG-A5 [MED].  The former is a superset to
obtain any logging records including storage.  So no need to change
LOG-9 other than to raise the priority level.

   LOG-9   [MED] The CDNI Logging interface may allow a CDN to query
           another CDN for relevant current logging records (e.g.  For
           on-demand access to real-time logging information).

	 Are LOG-A3/A4 intended to be periodic, or only on-demand?  If
the
	 latter, then is it just an issue of raising LOG-9 from LOW to
MED?
	 Note: LOG-9/A5 should probably be included in the 'trigger'
discussion?

The thinking was to have normal periodic with on-demand as an additional
capability if the uCDN wanted to do a check of what storage is
outstanding at the moment.

	 LOG-A6 seems like two requirements, that could be parts of a
more
	 generic set of LOG-A3/A5 requirements?

No, I think LOG-6 is talking about the logging interface itself and its
ability to be responsive for some near real-time uses. While LOG-A3/A5
is talking about the types of parameters in the logging messages.

KL> My interpretation of LOG-A6 is that uCDN indicates which performance
data should be reported by dCDN in the Logging Interface.  This seems to
be same though better worded requirement for LOG-11.

Propose to update LOG-11.  Priority remain as [LOW]?

     LOG-11  [LOW] The CDNI Logging interface shall support logging of
             performance data for deliveries to User Agents performed
             by the Downstream CDN as a result of request redirection
             by the Upstream CDN. Performance data may include various
             traffic statistics (the specific parameters are to be
             determined). The Logging interface shall support the
             upstream CDN to indicate the nature and contents of the
             performance data to be reported by the downstream CDN.

	 LOG-A7 sounds ok, but is the confirmation from the delete
request not
	 sufficient?  Is a log of individual deleted objects only
meaningful
	 if the object was there to be deleted, i.e. does it need to
compare
	 against everything that was acquired but not yet evicted?

KL> There's value to log a delete event.  Should this be [MED] instead?
Proposed new requirement:

     LOG-##  [MED] The CDNI Logging interface shall support logging of
             deleted objects from the downstream CDN to the upstream
             CDN as a result of explicit delete requests on via the
             Control interface from the upstream CDN.

	 LOG-A8/A9 seem reasonable, though they feel more like a MED
than a
	 HIGH to me.  Assuming they are HIGH, could we just update the
existing
	 LOG-7 requirement to include extensibility?  Is there an
existing
	 log description language that could/should be used here?

I believe that making the messaging extensible is easy and needs to be
done on the first release so that small proprietary fields can be
carried over this otherwise standardized interface resulting in wide use
of the standard. We should not make the messaging fixed and then later
decide to make it extendable.

KL> I agree there's value to have extensibility built in the Logging
Interface.  This includes the ability to support proprietary
information.  Proposed new requirements.

     LOG-##  [HIGH] The CDNI Logging interface shall support
             extensibility to allow proprietary information fields to
             be carried. These information fields must be agreed upon
             ahead of time between the corresponding CDNs.
 
     LOG-##  [HIGH] The CDNI Logging interface shall support the
             exchange of extensible log file formats to support
             proprietary information fields. These information fields
             must be agreed upon ahead of time between the
             corresponding CDNs.

KL> Proposed update to requirement:

   CNTL-2   [HIGH] The CDNI Control interface shall allow the downstream
            CDN to report on the completion of these actions (by itself,
            and if cascaded CDNs are supported by the solution, by
            potential cascaded Downstream CDNs), in a manner appropriate
            for the action (e.g. synchronously or asynchronously).  
            The confirmation receipt should include a success or
            failure indication. The failure indication is used if the
            dCDN cannot delete the content in its storage.

	 CNTL-A2 may need to clarify who created the sub-objects?  If
the
	 dCDN created the sub-objects, then that may be intra-CDN
information
	 that falls under the GEN-4 requirement?  Otherwise, it feels
like a
	 normal delete failure?  Is this requirement to get a more
detailed
	 error in the CNTL-A3 case?

If the delete is successful, everyone is happy. If the delete fails, you
get confirmation of that. If the delete *partially* fails which would
mean its an object with sub-objects, then this is asking for a more
detailed partial delete report. I think the sub-objects have to be known
and understandable by the uCDN for this to be of any value. So I don't
think this applies if the dCDN creates the sub-objects. Right now, I
don't myself understand how the dCDN would do this sub-object creation
on its own. Maybe you could explain.

	 CNTL-A3 seems to have a couple of aspects.  I think bulk delete
is
	 already covered by the existing CNTL-1 requirement.  The second
part
	 which lists filters for bulk delete seems to imply that the
dCDN needs
	 to know what the content is and who it belongs to?  That seems
like it
	 may need some type of companion metadata requirement?

 I don't see the bulk delete in CNTL-1. I think the two aspects here are
linked. Hmm...it seems like it may need some metadata requirement. Let
me think about it some more.

KL> Proposed update to requirement:

   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 related CDNI
metadata as "stale"
                and revalidate them before they are delivered again
 
            *   Delete an object or set of objects and/or related 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.

	 CNTL-A4 feels out of scope.  Reservation seems more like a
precondition
	 to interconnecting?  Is the reservation just a suggestion to,
or a
	 requirement for, the dCDN?  Is there an existing reservation
protocol
	 that could/should be used here?  Maybe a use case would be
helpful to
	 describe the CDNI scope?

Agree with most points here.

Kent

	thanx.
	
	--  Kevin J. Ma

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Serge Manning
	Sent: Friday, October 21, 2011 5:47 PM
	To: [email-masked]
	Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI

	I am resurrecting this old thread to let you know that a draft
has finally been submitted. The authors have tried to analyze ATIS CSF's
requirements and determine the additional requirements that are
appropriate for CDNI. Our hope is that these additional reqs might be
adopted into CDNI. 
	 
	Please take a look at the draft and provide your feedback.
Thanks.
	 
	Filename:        draft-manning-cdni-additional-csf-reqs
	Revision:        00
	Title:           Additional Content Distribution Network
Interconnection (CDNI) Requirements Based on ATIS CSF
	Creation date:   2011-10-21
	WG ID:           Individual Submission
	Number of pages: 9

-- 
--Serge

---

From: Serge Manning <[email-masked]>
Date: Tue, 29 Nov 2011 11:28:46 -0600

Sorry for the delayed response (with Thanksgiving holidays in US and all...)

Thanks Kent for proposing merged text for a bunch of these requirements. I
am mostly happy with all of your changes. I just have a couple of comments
below.

On Mon, Nov 21, 2011 at 6:21 PM, Kent Leung (kleung) <[email-masked]>wrote:

> Hi Serge and Kevin.  Comments below.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Serge Manning
> *Sent:* Thursday, November 17, 2011 10:26 PM
> *To:* Kevin J Ma
> *Cc:* [email-masked]
> *Subject:* Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI****
>
> ** **
>
> Thanks for looking at the draft and providing feedback Kevin. See inline.*
> ***
>
> wrote:****
>  to include failures?****
> That sounds fine.****
> ** **
> KL> Proposed update to LOG-2:****
>
>  ****
>
> LOG-2   [HIGH] The CDNI Logging interface shall provide logging of****
>
> by ****
>            the Downstream CDN as****
>
>            a result of request redirection by the Upstream CDN.****
>
> ** **
>
> KL> Proposed update to LOG-3:****
>
> ** **
>
> LOG-3   [MED] In the case of cascaded CDNs, the CDNI Logging****
>
>            interface shall allow the Downstream CDN to report to the****
>
>            Upstream CDN logging for deliveries and incomplete deliveries performed by the****
>
>            Downstream CDN itself as well as logging for deliveries****
>
>            performed by cascaded CDNs on behalf of the Downstream CDN.****
>
> **
>

[Serge] I would just want to make it clear that incomplete deliveries
should be cascaded up the chain, so a small modification to LOG-3.

LOG-3   [MED] In the case of cascaded CDNs, the CDNI Logging****

           interface shall allow the Downstream CDN to report to the****

           Upstream CDN logging for deliveries and incomplete
deliveries performed by the****

           Downstream CDN itself as well as logging for deliveries
*****and incomplete deliveries*

 [Serge] <snip>

KL> There’s value to log a delete event.  Should this be [MED] instead?
> Proposed new requirement:****
>
> ** **
>
> ** **
>
>      LOG-##  [MED] The CDNI Logging interface shall support logging of****
>
>              deleted objects from the downstream CDN to the upstream****
>
>              CDN as a result of explicit delete requests on via the****
>
>              Control interface from the upstream CDN.****
>
> **
>
[Serge] I feel that its important for the logging interface to hold a
complete record of basic transactions from the first version. To me, basic
transactions are content add (i.e., delivery) and delete. Also, given that
operators in ATIS are sensitive to delete operations, I would suggest to
keep this as [HIGH].

Let me know your thoughts.

Thanks.

-- 
--Serge

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 29 Nov 2011 10:58:59 -0800

Hi Serge.  No problem.  Most of us are in the same situation.  My
response to your comments are marked as "KL>>" below.  BTW, I'll let
others have a chance to contribute their inputs for another week.  Then
I plan to make the changes to the requirements draft according to the WG
discussions before publishing the next version.

From: Serge Manning [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2011 9:29 AM
To: Kent Leung (kleung)
Cc: Kevin J Ma; [email-masked]
Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI

Sorry for the delayed response (with Thanksgiving holidays in US and
all...)

Thanks Kent for proposing merged text for a bunch of these requirements.
I am mostly happy with all of your changes. I just have a couple of
comments below.

On Mon, Nov 21, 2011 at 6:21 PM, Kent Leung (kleung) <[email-masked]>
wrote:

Serge (and Kent),

That sounds fine.

           the Downstream CDN as

LOG-3   [MED] In the case of cascaded CDNs, the CDNI Logging
           interface shall allow the Downstream CDN to report to the
           Upstream CDN logging for deliveries and incomplete deliveries
performed by the
           Downstream CDN itself as well as logging for deliveries and
incomplete deliveries

KL>> OK

 [Serge] <snip>

	KL> There's value to log a delete event.  Should this be [MED]
instead? Proposed new requirement:

	     LOG-##  [MED] The CDNI Logging interface shall support
logging of
	             deleted objects from the downstream CDN to the
upstream
	             CDN as a result of explicit delete requests on via
the
	             Control interface from the upstream CDN.

[Serge] I feel that its important for the logging interface to hold a
complete record of basic transactions from the first version. To me,
basic transactions are content add (i.e., delivery) and delete. Also,
given that operators in ATIS are sensitive to delete operations, I would
suggest to keep this as [HIGH]. 

KL>> I don't have a strong opinion.  So requirement will be [HIGH]
unless others object.

Kent

Thanks.

-- 
--Serge