Re: [CDNi] footprint and capability mechanisms

["Matt Caulfield (mcaulfie)" <[e-mail]>]

Yes - that action is still in my queue. 

Expect my analysis sometime in the next week or so.

Thanks,
Matt

-----Original Message-----
From: CDNi [mailto:[e-mail]] On Behalf Of Kevin J Ma
Sent: Sunday, February 09, 2014 11:48 PM
To: Jan Seedorf; Peterson, Jon; [e-mail]
Subject: Re: [CDNi] footprint and capability mechanisms

I think my question is still about the actual call flows for the ALTO implementation, and whether there are any significant inefficiencies?
Though, to Jon's point, both approaches are going to need more work, so it's hard to assess from the current state.

I believe Matt had an action from Vancouver to also do an analysis?

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Jan Seedorf
> Sent: Friday, February 07, 2014 4:01 AM
> To: Peterson, Jon; [e-mail]
> Subject: Re: [CDNi] footprint and capability mechanisms
> 
> Dear Jon,
> 
> Thank you for the good and fair summary below, this is pretty much the 
> status quo. Just one comment: the reason why some of the necessary 
> ALTO extensions have been delayed is that the ADs/chairs have 
> disallowed such work to be discussed before the core ALTO protocol has 
> been published; just recently green light for continuing work on 
> extensions has been given.
> 
> What in my view it boils down to (as you highlight below):
> -- ALTO has error handling, encoding, security worked out (pro for 
> using
> ALTO)
> -- incremental and asynchronous updates for ALTO is early stage; in 
> fact the ALTO WG is right now re-chartering to add those two items to 
> the charter item list, early work exists, but it will take some time 
> for those specs to be ready (con for using ALTO)
> 
> What Richard and I have in mind was to drive these 
> very-soon-to-be-on-the- chartered ALTO extensions (i.e. 
> incremental/asynchronous updates) by the concrete CDNI FCI use case. 
> In other words we intend to define a solution for CDNI/FCI and kick 
> that back into the ALTO WG. But no doubt, having these ALTO extensions 
> done in ALTO will likely take longer than the current CDNI milestone for the FCI solution spec.
> 
> Kevin, all: anything you want to share to the discussion?
> 
>  - Jan
> 
> > -----Original Message-----
> > From: CDNi [mailto:[e-mail]] On Behalf Of Peterson, Jon
> > Sent: Thursday, February 06, 2014 7:41 PM
> > To: [e-mail]
> > Subject: [CDNi] footprint and capability mechanisms
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cdni