Re: [CDNi] footprint and capability mechanisms

["Peterson, Jon" <[e-mail]>]

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