Subject: [CDNi] Questions and comments on draft-spp-cdni-rr-foot-cap-semantics-04

From: Jan Seedorf <[email-masked]>
Date: Thu, 11 Jul 2013 09:12:16 +0000

Dear Scott,

Many thanks for your comments. Please let me comment below only on the ones where I have questions or where I would like to get opinions from the WG. Your other comments (i.e. the ones that are clear to me) are already incorporated into the -00 version of the WG item document which we will submit next Monday.

WG: I would appreciate other comments on the issues raised by Scott. Especially on the open issues (Section 7 of the draft) any opinion / discussion is appreciated. 

> | o The uCDN has received footprint and/or capability advertisements from a
> set of dCDNs.  Footprint advertisement and capability advertisement need
> not use the same underlying protocol.
> 
> I think we want to use the same protocol in order to avoid having another
> layer of referencing between a footprint associated with a capability.  I think
> we concluded that capability would be fairly static (e.g. HTTP) and the
> footprint is more likely to change.  They are intrinsically coupled even if they
> are coupled implicitly.
JAN: I agree to a certain extent. It is indeed one thing that we have worked out and that has always come up: footprint and capabilities are tied together. Thus, it makes sense to use the same protocol to convey them, so that they can be linked easily. However, this document is not about defining solutions, but only about the semantics and guidelines for solutions. So even though in practice I agree with you, I am not sure the semantics document should put the constraint on solutions of having only a single protocol for footprint advertisement and capability advertisement. Any other opinions?

>  ... I would replace this whole section with a motivation for advertising limited
> coverage.
JAN: Actually, I like the text in Section 3.1. because it gives a good introduction into the problem space and what needs to be considered. Your text describes how dCDNs may not want to advertise footprints where they cannot guarantee good delivery quality, but the actual problem in my view is how to make sure that the dCDNs are consistent in where they draw the line on what "good enough quality" is, or rather how the uCDN can distinguish that among several dCDNs. Therefore I like your last paragraph "The quality of 'coverage' and 'reach' may be somewhat subjective.  It is incumbent upon the uCDN to assess the relative quality of a dCDN; therefore, a dCDN should advertise a footprint that is contextually consistent with the advertisements of any other dCDN." I suggest to add that text towards the end of Section 3.1. Any other opinions?

> | 5. Towards Semantics for Footprint Advertisement
> 
> Two types of footprint may be advertised - topological and geographical.  A
> topological advertisement describes the dCDN's footprint relative to it's
> connectivity to the Internet using the BGP ASN attributes.  A geographical
> advertisement describes the dCDN's footprint relative to its coverage of a
> define location.
> 
> We might consider two models:
> 
> a. Topological Footprint (ASN) scoped by a geographical boundary (think of a
> global ASN where CDN coverage is limited to a particular continent)
> 
>     ASN <#>: FR, GE, UK, BE, ...
> 
> b. Geographical Footprint scoped by a set of topological boundaries (think of
> a continent where CDN coverage includes a set of ASN)
> 
>     US: ASN <#1>, ASN <#2>, ...
> 
> If the FCI is intended to provide the temporary state of the negotiated
> contract, either of the above could change over time.  A dCDN that covers an
> ASN (by contract) could be expanded to include new countries.  Likewise, a
> dCDN that covers a region (by contract) could be expanded to include new
> ASN.
> 
> Should the FCI support one or the other of the above models?
JAN: Sorry, but I am not sure I fully understand these models. Are they alternatives or yet another dimension with respect to the models we have already in the text ("coverage/reachability" vs. "resources"). Also, what is the purpose of adding the connectivity dimension? To add something like a "score" (see Section 3.1) for a geographical footprint?

> | 6. Towards Semantics for Capabilities Advertisement
> 
> My experience has highlighted the fact that most of the base capabilities
> must be configured (according to a negotiated contract) to facilitate
> redirection.  What seems relevant to me is where the footprint of a given
> capability changes.  Let's say uCDN has negotiated with dCDN to delivery
> both HTTP and RTMP.  At the time of service initialization, the RTMP footprint
> is smaller than the HTTP footprint; therefore, the capability should be
> advertised and scoped according to a footprint.  The default case might be
> that HTTP and RTMP are configured (no capability advertisement required),
> but that assumes both capabilities have global footprint.  Not sure that is
> always the case.
JAN: I fully agree with you. In fact, the main use case we are considering (provided by Anne/Emile) is exactly about this case where a capability is not globally available in a dCDN, and where (i.e. in which partial footprint) it is available may change over time. 
> That is why I'm inclined to include a capability update which is scoped by a
> footprint.
I am not sure what you mean by that. The semantics draft is outlining what capabilities are mandatory, but leaves it to solution proposals on how capabilities and footprint may be tied together. The section now contains the following text on this: "For example, the dCDN might in general offer RTMP but not in some specific areas, either for maintenance reasons or because the caches covering this particular area cannot deliver this type of service.  Hence, in certain cases footprint and capabilities are tied together and cannot be interpreted independently from each other.  In such cases, i.e. where capabilities must be expressed on a per footprint basis, it may be beneficial to combine footprint and capabilities advertisement." Is this text not enough?

> | 7. Open Issues and Questions
> 
> | o What is the service model of this interface:...
> I'm inclined to say the dCDN advertises its capability and footprint to the
> uCDN and periodically refreshes that advertisement.
JAN: so you are saying "dCDN push to uCDN"?

> | o In addition to "reachability" types of footprint, ...
> 
> Not clear that a dCDN will want to advertise resource availability ... just
> service availability.
JAN: this issue is actually solved. We agreed in Orlando to allow for optional footprint types, while the mandatory one will be "coverage/reachability" types of footprint.

> 
> | o Does a footprint need to explicitly include the "transitive" ...
> 
> I would think that the transitive dCDN MAY aggregate and represent a
> concatenated footprint.  
JAN: I agree. So no explicit information for the uCDN about transitive dCDNs. Any other opinions?

> | o How exactly can a give dCDN derive its footprint?
> 
> I would expect this to be configured.  A dCDN might have a large footprint,
> but only want to advertise to a uCDN a portion of its footprint in accordance
> to a contract.
JAN: So you are saying manual configuration, and manual re-configuration when the footprint changes?

> 
> | o Should the footprint/capabilities advertisement interface only ...
> 
> I think the capability advertisement should be mandatory (e.g. HTTP | RTMP
> | RTSP) and it should conform to the contract.  It SHOULD be scoped by
> geography and/or topology where the absence of both footprint means
> global coverage.
JAN: the discussions we had are rather about signaling the whole dCDN state each time, or just signaling what has changed since the last dCDN advertisement (delta). There are obvious pros and cons (e.g. signaling the full state each time means larger messages, but provides better fault tolerance against lost messages). In my memory, we did not conclude on this issue. Opinions?

Again,
Many thanks for your comments, Scott!

 - Jan

> -----Original Message-----
> From: Scott Wainner [mailto:[email-masked]]
> Sent: Monday, April 29, 2013 5:50 PM
> To: Jan Seedorf
> Cc: [email-masked]
> Subject: Re: [CDNi] New Version Notification for draft-spp-cdni-rr-foot-cap-
> semantics-04
> 
> | 1. Introduction and scope
> 
> | o The uCDN has received footprint and/or capability advertisements from a
> set of dCDNs.  Footprint advertisement and capability advertisement need
> not use the same underlying protocol.
> 
> I think we want to use the same protocol in order to avoid having another
> layer of referencing between a footprint associated with a capability.  I think
> we concluded that capability would be fairly static (e.g. HTTP) and the
> footprint is more likely to change.  They are intrinsically coupled even if they
> are coupled implicitly.
> 
> | 2. CDNI FCI in existing CDNI Documents
> 
> | In the following section, the existing descriptions of the CDNI FCI interface
> in existing documents will be examined.  After this, the apparent common
> understanding of what this interface is intended to offer and accomplished
> will be carved out.
> 
> Descriptions of the CDNI FCI interface are highlighted in the CDNI Problem
> Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft
> requirements [I-D. ietf-cdni-requirements], and the CDNI framework draft
> [I-D ietf-cdni-framework].  An assessment of these descriptions is
> highlighted in the subsequent sections where the ambiguity associated with
> footprint and capabilities is highlighted.  The objective of this document is to
> clarify the meaning of footprint and capability and define the semantics and
> method for which these attributes are exchanged between two cooperating
> CDN's.
> 
> | 3.1
> 
>  ... I would replace this whole section with a motivation for advertising limited
> coverage.
> 
> CDN's are built to minimize the cost of transport and optimize the
> performance of content delivery across that transport.
> 
> A dCDN operator may elect to advertise only the footprint for which the CDN
> is optimized.  While a dCDN might feasibly 'reach' a much larger footprint, the
> operator of the dCDN has elected to narrow the scope of footprint to insure
> that the CDN is only used for media delivery when clients are topologically or
> geographically close.
> 
> A uCDN may have global coverage enabling media delivery anywhere on the
> Internet; however, the uCDN may recognize that a specific dCDN has been
> optimized for media delivery in a specific topological footprint or a specific
> geographic region.
> 
> The quality of 'coverage' and 'reach' may be somewhat subjective.  It is
> incumbent upon the uCDN to assess the relative quality of a dCDN;
> therefore, a dCDN should advertise a footprint that is contextually consistent
> with the advertisements of any other dCDN.
> 
> | 5. Towards Semantics for Footprint Advertisement
> 
> Two types of footprint may be advertised - topological and geographical.  A
> topological advertisement describes the dCDN's footprint relative to it's
> connectivity to the Internet using the BGP ASN attributes.  A geographical
> advertisement describes the dCDN's footprint relative to its coverage of a
> define location.
> 
> We might consider two models:
> 
> a. Topological Footprint (ASN) scoped by a geographical boundary (think of a
> global ASN where CDN coverage is limited to a particular continent)
> 
>     ASN <#>: FR, GE, UK, BE, ...
> 
> b. Geographical Footprint scoped by a set of topological boundaries (think of
> a continent where CDN coverage includes a set of ASN)
> 
>     US: ASN <#1>, ASN <#2>, ...
> 
> If the FCI is intended to provide the temporary state of the negotiated
> contract, either of the above could change over time.  A dCDN that covers an
> ASN (by contract) could be expanded to include new countries.  Likewise, a
> dCDN that covers a region (by contract) could be expanded to include new
> ASN.
> 
> Should the FCI support one or the other of the above models?
> 
> | 6. Towards Semantics for Capabilities Advertisement
> 
> My experience has highlighted the fact that most of the base capabilities
> must be configured (according to a negotiated contract) to facilitate
> redirection.  What seems relevant to me is where the footprint of a given
> capability changes.  Let's say uCDN has negotiated with dCDN to delivery
> both HTTP and RTMP.  At the time of service initialization, the RTMP footprint
> is smaller than the HTTP footprint; therefore, the capability should be
> advertised and scoped according to a footprint.  The default case might be
> that HTTP and RTMP are configured (no capability advertisement required),
> but that assumes both capabilities have global footprint.  Not sure that is
> always the case.
> 
> That is why I'm inclined to include a capability update which is scoped by a
> footprint.
> 
> | 7. Open Issues and Questions
> 
> | o What is the service model of this interface:...
> 
> I'm inclined to say the dCDN advertises its capability and footprint to the
> uCDN and periodically refreshes that advertisement.
> 
> | o In addition to "reachability" types of footprint, ...
> 
> Not clear that a dCDN will want to advertise resource availability ... just
> service availability.
> 
> | o Does a footprint need to explicitly include the "transitive" ...
> 
> I would think that the transitive dCDN MAY aggregate and represent a
> concatenated footprint.  Alternatively, the dCDN MAY advertise a subset of
> footprint to conform to a contract between the uCDN and the transitive CDN.
> 
> | o How exactly can a give dCDN derive its footprint?
> 
> I would expect this to be configured.  A dCDN might have a large footprint,
> but only want to advertise to a uCDN a portion of its footprint in accordance
> to a contract.
> 
> | o Should the footprint/capabilities advertisement interface only ...
> 
> I think the capability advertisement should be mandatory (e.g. HTTP | RTMP
> | RTSP) and it should conform to the contract.  It SHOULD be scoped by
> geography and/or topology where the absence of both footprint means
> global coverage.
> 
> 
> On 2/26/13 5:27 AM, Jan Seedorf wrote:
> 
> 
> 	Dear all,
> 
> 	We have submitted a new version of the footprint/capabilities
> semantics draft. We revised in particular the sections on what a footprint and
> capabilities should actually look like, so that the document now reflects the
> latest agreements in the design team. Thanks to Kevin and Ray for their help
> with the revision.
> 
> 	Small note: we submitted yesterday the -03 version and shortly after
> the -04 version, which only fixed minor things in the author's affiliations
> compared to the -03 version. Just for people who were wondering how we
> got from -02 to -04.
> 
> 	If you are interested in this, please join the phone call this afternoon.
> We also intend to update the WG during the CDNI sessions at the upcoming
> IETF-86 in Orlando.
> 
> 	 - Jan
> 
> 	-----Original Message-----
> 	From: [email-masked] [mailto:[email-masked]]
> 	Sent: Monday, February 25, 2013 5:13 PM
> 	To: Jan Seedorf
> 	Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 	Subject: New Version Notification for draft-spp-cdni-rr-foot-cap-
> semantics-04.txt
> 
> 
> 	A new version of I-D, draft-spp-cdni-rr-foot-cap-semantics-04.txt
> 	has been successfully submitted by Jan Seedorf and posted to the
> 	IETF repository.
> 
> 	Filename:	 draft-spp-cdni-rr-foot-cap-semantics
> 	Revision:	 04
> 	Title:		 CDNI Request Routing: Footprint and Capabilities
> Semantics
> 	Creation date:	 2013-02-25
> 	Group:		 Individual Submission
> 	Number of pages: 22
> 	URL:             http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-
> foot-cap-semantics-04.txt
> 	Status:          http://datatracker.ietf.org/doc/draft-spp-cdni-rr-foot-
> cap-semantics
> 	Htmlized:        http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-
> semantics-04
> 	Diff:            http://www.ietf.org/rfcdiff?url2=draft-spp-cdni-rr-foot-
> cap-semantics-04
> 
> 	Abstract:
> 	   This document tries to capture the semantics of the "Footprint and
> 	   Capabilities Advertisement" part of the CDNI Request Routing
> 	   interface, i.e. the desired meaning and what "Footprint and
> 	   Capabilities Advertisement" is expected to offer within CDNI.  The
> 	   discussion in this document has the goal to facilitate the choosing
> 	   of one or more suitable protocols for "Footprint and Capabilities
> 	   Advertisement" within CDNI Request Routing.
> 
> 
> 
> 
> 	The IETF Secretariat
> 
> 	_______________________________________________
> 	CDNi mailing list
> 	[email-masked]
> 	https://www.ietf.org/mailman/listinfo/cdni
> 	.
> 
>