Re: [CDNi] footprint and capability mechanisms

[Kevin J Ma <[e-mail]>]

Basically that's what I meant.
Initialization as well as asynchronous/incremental updates.

> -----Original Message-----
> From: Peterson, Jon [mailto:[e-mail]]
> Sent: Monday, February 10, 2014 2:56 PM
> To: Kevin J Ma; Jan Seedorf; [e-mail]
> Subject: Re: footprint and capability mechanisms
> 
> 
> Do you mean inefficiencies beyond the need for asynchronous and
> incremental updates? This is the discussion I think we need to have.
> 
> Jon Peterson
> Neustar, Inc.
> 
> On 2/9/14, 8:47 PM, "Kevin J Ma" <[e-mail]> wrote:
> 
> >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