Subject: Re: [CDNi] [CDNI] FCI analysis

From: Jan Seedorf <[email-masked]>
Date: Tue, 3 Mar 2015 17:41:02 +0000

Dear Iuniana and all,

in the latest -05 version I just posted, all comments have been addressed, thanks again for the review.

Let me briefly go over your comments:
I think the draft needs a bit more work in the following points:

1.       It's not very clear from the draft how a footprint advertisement of resources (location of surrogate nodes) would work and in what practical context.
JAN: This is what some people felt strongly about to have as a future option included. I checked the text we have on that. It clearly says that the details are out of scope of the document and such extension are optional for the future and need to specify how exactly it would work. So I think it is fine.

2.       The draft states that the FCI specification should define a generic protocol for conveying any capability information. Maybe we should be more precise of what are the requirements for such a protocol and what it is strictly expected to do. What scale of time/reactivity for such a protocol?
JAN : I added some text, and also a reference to the CDNI requirements RFC which actually lists quite a few requirements on an FCI protocol.

3.       There is still a note in the document (end of section 5) about support for logging configuration (control vs. metadata).
JAN: addressed in latest version

4.       There is still a note in section 7 about logging and metadata: include these capabilities in the table. The notes from the meeting in London say something like "Kevin Ma: We still need to add capabilities for optional logging and (if any) for optional metadata fields."
JAN: addressed in latest version

5.       The Security considerations section says "to be discussed in a future version".
JAN: Since the -04 version we have a security consideration section (thank to Jon) which is sufficient in my opinion.

-          Jan

From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma J
Sent: Montag, 21. Juli 2014 14:22
To: [email-masked]; [email-masked]
Subject: Re: [CDNi] [CDNI] FCI analysis

Hi Iuniana,

  Thanx for the review.
  wrt comments 3/4 logging/metadata capabilities: those were addressed in the latest version
  that was just uploaded.  We will review and address the other comments in the next version.

thanx!

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, July 20, 2014 11:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] [CDNI] FCI analysis

Hello CDNI fellows,

[It seems I missed posting this directly to the working group mailing list, so there it is now]

Here goes the analysis of the Footprint and Capabilities semantics draft. Sorry for taking holidays just before the IETF, I didn't get around to this doing this earlier. Hope it helps in taking us closer to WGLC.

FCI Semantics, draft-ietf-cdni-footprint-capabilities-semantics-02
-------------------------------------------------------------------------------

The purpose of the draft is to define the type of information a dCDN advertises regarding its footprint and capabilities. It states that "it is explicitly outside the scope of this document to decide on specific protocols to use for the FCI." It relies on the basic assumption that a bootstrapping process has already been done between the uCDN and the set of dCDNs that are interconnecting. Also, it assumes that footprint and capabilities need not use the same protocol and that the uCDN directly receives the initial request-routing request from the endpoint demanding the resource.

Section 2: Design Decisions for Footprint and Capabilities
Emphasizes the need to understand the definition of footprint in terms of "coverage" and "reachability." The draft also mentions that global CDNs can have global reachability (through IP connectivity) but CDNs with a more limited coverage are suitable for the CDNi use cases. It states that "capabilities with footprint" versus "footprint with capabilities" semantics should be adapted to the respective use case.

1)      Advertising Limited Coverage
There is an example of two regional ISPs that both have CDNs : one CDN belongs to the ISP of the customer E (making the content demand) and the other is the CDN that can offer better coverage to the customer E. Which CDN should serve the request still remains a dilemma. Same interrogation is valid for overlapping footprints advertised by several dCDNS.
To answer the dilemma above, a "score" notion is introduced in order to be able to rank the quality of the dCDN's service, preferably on the same scale. The conclusion is that coverage need not be binary.

2)      Capabilities and Dynamic Data
When footprints overlap, a uCDN might want to evaluate some extra merits of the competing dCDNs. These criteria include state of the caches, network quality and policies, bandwidth etc. that can be highly volatile parameters.

3)      Advertisement versus Queries
Scalability issues may arise if the volume of FCI updates exceeds the volume of content requests to the uCDN. The advantage of a model based on synchronous queries is that the uCDN can operate in a stateless way (doesn't need to keep track of dCDNs status). Choice to be made on a per use case basis.

4)      Avoiding or Handling "cheating" dCDNs
It's desirable to have a way for the uCDN to qualitatively verify the FCI info advertised by the dCDNs. Possibly non-real-time out-of-band audits.

5)      Focus on Main Use Cases May Simplify Things
To narrow down FCI semantics, might be better to pick some real life deployments and tailor according to that.

Section 3: Main Use Case to Consider
Asks questions about practicalities in a simplified use case: uCDN has two dCDNs out of which one has another level-2 dCDN. How does the uCDN take into account failures/changes of the level-2 dCDN? How does uCDN handle subsets of the footprint initially served by one of its dCDNs?

Section 4: Semantics for Footprint Advertisement
Roughly, footprint = ability and willingness to serve. How well a dCDN can serve requests is another piece of information that could be added to the footprint, but will be mostly associated to contractual agreements.
Assuming that the initial footprint is established in the contract, FCI provides changes and updates to the previously agreed footprint. The draft further considers two types of footprint: coverage/reachability (3 types mandatory to support by FCI: set of IP prefixes, list of AS numbers, country ISO codes) and resources (location of the surrogates).

Section 5: Semantics for Capabilities Advertisement
In certain cases, footprint and capabilities cannot be interpreted separately: need to associate the coverage of a geographical region with a certain delivery protocol. In such cases, it should be possible to combine footprint and capabilities advertisements.
Advertisement of highly dynamic capabilities is out of scope. Just like for the footprint, the capabilities advertisement refers to conveying information to a uCDN about changes/updates with respect to a given contract.
Defined "base" capabilities:
                o Delivery Protocol (HTTP, RTMP)
                o Acquisition Protocol
                o Redirection Mode (DNS, HTTP)
                o Capabilities related to CDNI Logging
                o Capabilities related to CDNI Metadata
The FCI spec should define a generic protocol for sending this type of information and should allow for the list above to be further expanded if needed.

6. Negotiation of Support for Optional Types of Footprint/Capabilities
Need to specify the behavior of CDNs that do not support the optional types of footprint/capabilities : how to react in case of failure? The uCDN can ignore or select dCDN based only on the parameters it understands.

7. IANA Considerations
Requires a new IANA registry "CDNI Capabilities"; this namespace should be split into standard (for Mandatory To Implement) and optional. A table provides the initial standard partition: Delivery Protocol, Acquisition Protocol and Redirection Mode. The optional partition conforms to Expert Review policy.
No IANA action required for the defined Footprint Sub-Registry or the Protocol Sub-Registry. A table defines the initial Redirection Modes: Iterative DNS, Recursive DNS, Iterative HTTP, Recursive HTTP.

8. Security Considerations
This section still needs to be done, as there is not much text.

Comments:
The main purpose of the draft is to say what people understand when they say footprint or capabilities. It does a pretty good job at narrowing down the concepts and explaining the implications of the wider notions. There are several examples provided regarding the basic set we should be considering in CDNI.

I think the draft needs a bit more work in the following points:

1.       It's not very clear from the draft how a footprint advertisement of resources (location of surrogate nodes) would work and in what practical context.

2.       The draft states that the FCI specification should define a generic protocol for conveying any capability information. Maybe we should be more precise of what are the requirements for such a protocol and what it is strictly expected to do. What scale of time/reactivity for such a protocol?

3.       There is still a note in the document (end of section 5) about support for logging configuration (control vs. metadata).

4.       There is still a note in section 7 about logging and metadata: include these capabilities in the table. The notes from the meeting in London say something like "Kevin Ma: We still need to add capabilities for optional logging and (if any) for optional metadata fields."

5.       The Security considerations section says "to be discussed in a future version".

See you in Toronto!
-- iuniana

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.