Re: [CDNi] footprint and capability mechanisms

[Scott Wainner <[e-mail]>]

On 2/6/14 1:41 PM, Peterson, Jon wrote:
> Following our discussion about the FCI mechanism in Vancouver, I took a
> look at two drafts out there today: draft-ma and draft-seedorf. In short,
> I think both express promising directions, and both have a long way to go
> before they will describe fully fleshed-out mechanisms. At a high level,
> their architectures are similar: both are about pushing JSON objects that
> describe footprints and capability via HTTP. It¹s often when the choices
> are so similar that it¹s hardest to figure out which is the right approach.
>
> One of the prominent distinctions between the two is that Kevin specifies
> a capability-sharing system with an optional footprint, whereas Jan
> specifies a footprint-sharing system with the option of capabilities.
> Jan¹s choice is an artifact of using ALTO as a basis, which already has a
> concept of sharing 'network maps' in this fashion, and can be extended to
> add further information to these maps such as capability. Kevin works from
> the ground up on a bespoke system for sharing capabilities, which may not
> ever involve sharing footprint data. I¹ve turned this over in my head a
> bunch of times, and I¹m not really sure there¹s any practical advantage
> one approach has over the other. One of the non-obvious reasons why is
> that the concept of a PID (the groupings of network elements) in ALTO is
> so abstract that it serves as a layer of indirection, and can serve as a
> placeholder for a footprint that¹s effectively specified implicitly.
My opinion is:

1) the capabilities must match before we even care about the properties 
of the footprint
2) the properties of the footprint are likely defined in a contract 
(i.e. global coverage, regional coverage)
3) retraction of a portion of footprint probably violates a contractual 
obligation; therefore, no CDN would announce it
4) the advertisement of a footprint (that conforms to a contract) is 
probably just a means of automating the CDN selection by the uCDN which 
already has the ability to statically assign a footprint to a dCDN based 
on the contract
5) the uCDN probably has many other rules that it must consider before 
footprint comes into play (i.e. geo-location, quotas, performance, 
time-of-day, etc.).  For example, footprint becomes somewhat irrelevant 
if the performance of the dCDN doesn't meet an SLA.  It doesn't matter 
how close the dCDN is to the client.  If the dCDN can't deliver the 
content in a timely manner or with sufficient throughput, the uCDN 
should pick a different dCDN.

>
> An important feature we want this mechanism to have is incremental FCI
> updates. Both Kevin and Jan have a story about this, though I think both
> will require substantial work to advance. Kevin, for example, sketches a
> system of primitives (replace, include, exclude) to allow a dCDN to update
> a uCDN about changes, based on tracking update sequencing with a new
> 'CDNI-FCI-Seq' HTTP header. State freshness of web resources is a pretty
> thoroughly-studied problem, though, and there are other HTTP facilities
> (Etags, say) that address this. I think it¹s pretty unlikely that our
> problem is enough of a special case that we could convince Application
> folks here at the IETF that we need to standardize a custom HTTP header
> for it. Jan¹s draft, on the other hand, references existing ALTO work on
> incremental updates, in particular draft-schwan-alto-incr-updates. That
> draft contains a good overview of the different approaches, including HTTP
> If-Modified-Since and Etags, as well as looking at JSON-specific
> incremental change techniques like JSON Patch (RFC6902). Sounds great, but
> - draft-schwan is currently an expired I-D (for like a year), and it is
> really more of a survey than a draft that makes a concrete recommendation.
> This work would need to be resumed and made far more concrete for this to
> be a viable approach.
... or deferred so we can get a basic Footprint and Capabilities 
Interface specified.  Most likely the dCDN will want to advertise global 
coverage (to maximize their perceived utility).  The exception is an ISP 
CDN that only wants to serve content for their own clients.  Thus, a 
specific footprint is defined which probably correlates with the ISP's 
address space advertised via E-BGP.
>
> Asynchronous updates are another very important feature. We don¹t want to
> force uCDNs to poll dCDNs, we want dCDNs to be capable of asynchronously
> notifying uCDNs when a change to network state happens. Kevin again has a
> sketch of a solution here, where capability information can either be
> acquired by a GET from the uCDN or a POST by the dCDN. While as described
> it is very lightweight, I suspect it¹s probably a bit too lightweight: I¹d
> want to know a lot more about how resource identifiers are discovered or
> formulated, and a ton more about error-handling and security. This
> mechanism almost certainly should be ReST-based, as it will then inherit
> many of the right principles. ALTO, based on Jan¹s draft, of course is
> already ReST-based, and has exhaustive sections on JSON encoding, errors,
> security, and the way to formulate queries via POSTs. What it lacks is an
> asynchronous publication capability. Once again, there are some I-Ds we
> can point to, but nothing I¹d consider very concrete. Worse still, even
> the capability data that ALTO might carry is based on a -00 I-D
> (draft-roome-alto-pid-properties) which is very sketchy, to the point
> where providing even a mock-up of the JSON encoding for capabilities in
> ALTO is probably impossible today.
If we simplify the requirements, we might conclude that a RESTful POST 
from the dCDN that describes the capabilities and the associated 
footprint is all we need.  What the uCDN needs to know is the 
availability of the dCDN's ability to route content requests. The 
recursive mode is no problem, but the iterative mode may be a problem.  
Having a periodic HTTP POST from the dCDN to the uCDN may serve as a 
'keep-alive' for a given capability and footprint.

We can focus on enhancing the granularity of the advertisement in a 
subsequent release.
>
> So where does this leave us? Fleshing out either of these approaches will
> take work. We don¹t want to do needless work articulating two proposals
> where we only need one. It is however difficult to have a serious
> discussion about the advantages of either mechanism when they are only
> specified to this limited degree. Ideally some kind of merger would be
> possible here, and the sooner we can get to that the better. I don¹t think
> the baseline JSON formats for rendering either footprints or capability
> will ultimately vary significantly in the two proposals. It then just
> becomes a question of whether it is more practical to start tabula rasa,
> as Kevin does, or to build on an existing mechanism, as Jan does. ALTO
> comes with baggage, but that baggage has accumulated from several years
> now of comment and review, and surely a lot of those components (like
> error handling, encoding, security) would have to be incorporate into
> Kevin¹s draft if we went forward with it. I suspect that would ultimately
> be a longer path, but neither of these paths are particularly short.
>
> Jon Peterson
> Neustar, Inc.
>
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
> .
Scott

=======================
  Scott Wainner
   Cisco, Distinguished SE
   USSP Verizon
   [phone]
   [e-mail]
=======================
_____ .:|:.:|:. _______