Subject: [pm-dir] Performance Directorate Review of cdni footprint capabilities semantics

From: Vinayak Hegde <[email-masked]>
Date: Sun, 8 Sep 2013 00:00:11 +0530

Hi,

I reviewed the CDNI footprint capabilities semantics draft (as a reviewer
on the Performance directorate). My comments on the draft follow:

In section 2 you reference CDNI requirements drafts and mention several
metrics such as streaming bandwidth but they are not explicitly listed or
defined anywhere in the draft. Also the measurement methodology for the
smae is not outlined. Can you please do that using RFC 6390 template to
bring more clarity.

Also in section 6 you mention

   At a first glance, several broad categories of capabilities seem
   useful to convey via an advertisement interface (and indeed many such
   candidate capabilities have been suggested in CDNI drafts, see
   Section 2).  However, advertising capabilities that change highly
   dynamically (e.g. real-time delivery performance metrics, CDN
   resource load, or other highly dynamically changing QoS information)
   should probably not be in scope for the CDNI FCI.  First, out of the
   multitude of possible metrics and capabilities, it is hard to agree
   on a subset and the precise metrics to be used.  Second, and perhaps
   more importantly, it seems not feasible to specify such highly
   dynamically changing capabilities and the corresponding metrics
   within the CDNI charter time-frame.

It might be useful here to atleast list out the possible metrics (as
use-cases/scenarios such as in static content/streaming capabilities)
rather than leave it out completely to the discretion of the implementer
(which will cause interop issues later on).

-- Vinayak

---

From: Jan Seedorf <[email-masked]>
Date: Wed, 18 Sep 2013 12:33:17 +0000

Dear Vinayak,

Thank you for your review. The point if the CDNI footprint capabilities semantics draft is to give guidance for yet-to-be-specified CDNI footprint/capabilities advertisement solution documents. Thus, the draft is not normiative for any metrics, and should also not cause interop issues. Actually the guidance the CDNI footprint capabilities semantics draft gives is not to use capabilities with complex metrics such as streaming bandwidth for downstream CDN selection (the text on streaming bandwidth is taken from the CDNI requirements RFC). 

>    within the CDNI charter time-frame.
Instead of listing all the possible metrics that the draft advised not to use, the draft takes the approach of listing mandatory capabilities (which are explained in some detail), and specifying a procedure for adding new capabilities later on.

In summary, I do not think it is needed to precisely define the metrics of capabilities the draft explicitly excludes from being relevant for the CDNI specifications. But maybe I am missing something, or some of the co-authors have different views.

What so you think?

 - Jan

> -----Original Message-----
> From: Vinayak Hegde [mailto:[email-masked]]
> Sent: Saturday, September 07, 2013 8:30 PM
> To: [email-masked]; Jan Seedorf; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Performance Directorate Review of cdni footprint capabilities
> semantics
> 
> Hi,
> 
> I reviewed the CDNI footprint capabilities semantics draft (as a reviewer on
> the Performance directorate). My comments on the draft follow:
> 
> smae is not outlined. Can you please do that using RFC 6390 template to bring
> more clarity.
> 
> It might be useful here to atleast list out the possible metrics (as use-
> cases/scenarios such as in static content/streaming capabilities) rather than
> leave it out completely to the discretion of the implementer (which will cause
> interop issues later on).
> 
> 
> -- Vinayak

---

From: Vinayak Hegde <[email-masked]>
Date: Mon, 23 Sep 2013 13:47:28 +0530

Hi Jan,

Since end-user performance is one of the main goals of the CDNI group, the
draft would be incomplete without specifying and agreeing on metrics for
atleast the following decisions:
1. Choosing the downstream CDN
2. Penalising the downstream CDN for faking metrics / not adhering to SLAs
(example large number of timeouts).
3. Checking and evaluating the performance of each of the downstream CDN
providers in case there are multiple choices.

The draft may gloss over these now but the WG will have to specify these
(atleast non-normative) to make sense to implementers. I am leaving out the
mechanics out of this mail. The metrics can be specified in this draft or
another one. Either was this draft should include or point to this
information.

By not specifying it in this draft or a linked one, you are essentially
kicking the can down the road.

-- Vinayak

On Wed, Sep 18, 2013 at 6:03 PM, Jan Seedorf <[email-masked]> wrote:

> Dear Vinayak,
>
> Thank you for your review. The point if the CDNI footprint capabilities
> semantics draft is to give guidance for yet-to-be-specified CDNI
> footprint/capabilities advertisement solution documents. Thus, the draft is
> not normiative for any metrics, and should also not cause interop issues.
> Actually the guidance the CDNI footprint capabilities semantics draft gives
> is not to use capabilities with complex metrics such as streaming bandwidth
> for downstream CDN selection (the text on streaming bandwidth is taken from
> the CDNI requirements RFC).
>
> Instead of listing all the possible metrics that the draft advised not to
> use, the draft takes the approach of listing mandatory capabilities (which
> are explained in some detail), and specifying a procedure for adding new
> capabilities later on.
>
> In summary, I do not think it is needed to precisely define the metrics of
> capabilities the draft explicitly excludes from being relevant for the CDNI
> specifications. But maybe I am missing something, or some of the co-authors
> have different views.
>
> What so you think?
>
>  - Jan
>
> bring