Enrico Marocco | 15 Apr 09:02 2014
Picon

Revised charter update

Hi all,

below you can find an updated version of the charter that should reflect
the comments and discussions the WG had in London and afterwards.

We would like to give people another week for reviewing and commenting,
before sending it to the responsible AD and possibly the IESG for
consideration.

Enrico and Vijay

Application-Layer Traffic Optimization Working Group Charter

The ALTO working group was established in 2008 to devise a
request/response protocol for allowing a host to benefit from a server
that is more cognizant of the network infrastructure than the host
would be. The working group has developed an HTTP-based protocol
(RFC-to-be) to allow hosts to benefit from the network infrastructure
by having access to a pair of maps: a topology map and a cost map.

The origins of the ALTO protocol lie in peer-to-peer (P2P)
applications, where the host is a peer in a P2P network and desires a
rendezvous with other peers for file sharing, real-time
communications, etc. It is a testament to the flexibility of the ALTO
protocol that it is now being considered as a solution for problems
outside the P2P domain, such as in datacenter networks and in content
distribution networks (CDN) where exposing abstract topologies helps
applications.

To support the emerging new uses of ALTO, certain extensions are being
(Continue reading)

Enrico Marocco | 26 Mar 15:25 2014
Picon

Draft minutes for IETF89

Here: http://www.ietf.org/proceedings/89/minutes/minutes-89-alto

Many thanks to Jan and Diego for taking notes during the meeting, and to 
Vijay for putting them together.

Enrico

Attachment (smime.p7s): application/pkcs7-signature, 5795 bytes
Here: http://www.ietf.org/proceedings/89/minutes/minutes-89-alto

Many thanks to Jan and Diego for taking notes during the meeting, and to 
Vijay for putting them together.

Enrico

Wendy Roome | 20 Mar 14:54 2014

Format of ALTO cost-types?

Folks,

We were careful to spell out the length and character set restrictions on
cost-metrics, PID names, and so on. But unless I missed it, we didn¹t put
any restrictions on cost-type names. I think the natural place for that
would be {10.7}.

Are the restrictions listed somewhere else and I missed them?

If not, should we say that cost-type names must follow the same rules as
resource-ids, as defined in {10.2}?

Yes, I know it¹s too late to change the official document; I assume this
is a candidate for the errata sheet.

	- Wendy Roome

Qin Wu | 6 Mar 19:24 2014

bandwidth calendaring on Recharter discussion

Hi:

Somebody pointed me my clarification on bandwidth calendaring is not very clear when

Chair asked me in the meeting what the cost value array stands for in the bandwidth calendaring example slide,

 

Here I like to emphasize again.

the cost value array in the example represent a list of availbandwidth values in the output.

Each value is reported at specific measurement interval, The first value in the cost value array will be reported

At the “start time” defined in the description metadata of Information resource directory exchange.

The duration in the description metadata of Information resource directory exchange represent time difference

Between start time to report the first value and end time to report the last value in the cost value array.

 

For example, I as alto client want to know the avail bandwidth values that are applied to specific path from source endpoint to dest endpoint.

The avail bandwidth values is measured every 1 hour, the first avail bandwidth is measured at 10:20am, the last measured avail bandwidth

Will be measured at 5:20pm, then we list all the avail bandwidth values in the form of cost value array in the output.

 

Also I want to emphasize the clear use cases for alto cost map extension have already been clearly specified in several other working group drafts

e.g.,draft-ietf-isis-te-metric-extensions-01, draft-ietf-ospf-te-metric-extensions-01. What alto is doing is abstract these metrics gathered from routing protocol into

alto cost metric from one endpoint to another endpoint.

 

Regards!

-Qin

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Somebody pointed me my clarification on bandwidth calendaring is not very clear when<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Chair asked me in the meeting what the cost value array stands for in the bandwidth calendaring example slide,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Here I like to emphasize again.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">the cost value array in the example represent a list of availbandwidth values in the output.
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Each value is reported at specific measurement interval, The first value in the cost value array will be reported
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">At the &ldquo;start time&rdquo; defined in the description metadata of Information resource directory exchange.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The duration in the description metadata of Information resource directory exchange represent time difference<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Between start time to report the first value and end time to report the last value in the cost value array.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">For example, I as alto client want to know the avail bandwidth values that are applied to specific path from source endpoint to dest endpoint.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The avail bandwidth values is measured every 1 hour, the first avail bandwidth is measured at 10:20am, the last measured avail bandwidth<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Will be measured at 5:20pm, then we list all the avail bandwidth values in the form of cost value array in the output.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Also I want to emphasize the clear use cases for alto cost map extension have already been clearly specified in several other working group drafts<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e.g.,draft-ietf-isis-te-metric-extensions-01, draft-ietf-ospf-te-metric-extensions-01. What alto is doing is abstract these metrics gathered from routing protocol into<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">alto cost metric from one endpoint to another endpoint.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Qin<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>
Wendy Roome | 6 Mar 15:33 2014

Re: alto Digest, Vol 65, Issue 4

Given that PIDs could have 100¹s of CIDRs, I suggest we use a different
format for Network Map incremental updates. The servers¹s response would
have three lists: add-cidrs, drop-cidrs and drop-pids. Something like

 {
   "add-cidrs": {"PID1": {"ipv4": ["1.2.3.0/24", ... }],
                 "PID2": { ... } }
   "drop-cidrs": {"ipv4": ["4.3.2.1/24", ... ]},
   "drop-pids": ["PID12", "PID13", ... ]
}

add-cidrs gives cidrs to be added to pids. The client is expected to
remove those cidrs from whatever pid they had been in before. drop-cidrs
means remove those cidrs from the network map altogether. drop-pids means
remove those pids and the cidrs they contain (except for cidrs named in
add-cidrs).

I think that representation is compact, simple for a server to generate
from the network changes, and easy for a client to apply to whatever data
structure the client uses to store the network map. It does assume the
client keeps an index from cidrs to pids, but I think any client who wants
incremental updates would keep such an index.

	- Wendy Roome

On 03/06/2014, 05:08, "alto-request <at> ietf.org" <alto-request <at> ietf.org>
wrote:

>>
>>
>>
>>A higher-level question is how many CIDRs will PIDs have?
>
>
>This is the key question. I start to think BGP, which can go up to
>hundreds
>or thousands.
>
>
>>Our incremental
>>update proposal updates a PID?s CIDR set as a unit. So if one CIDR is
>>added to a PID, the incremental update message gives all the CIDRs that
>>were in  the PID. That?s fine if PIDs only have (say) 5 or 10 CIDRs. But
>>if we expect PIDs to have 100 or more CIDRs, then it?s not. In that case
>>we need to consider an add/delete model to update a PID?s CIDR set
>>without
>>repeating the ones that didn?t change.
>>
>>
>Yes. Indeed. If possible, I want to see what this model might look like.
>What do you think?

Songhaibin (A | 6 Mar 11:08 2014

re-chartering discussion slides

Hi,

 

Are there any slides on the topics that are listed under the re-chartering discussion? I prefer to read slides before the meeting.

 

BR,

-Haibin

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Are there any slides on the topics that are listed under the re-chartering discussion? I prefer to read slides before the meeting.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">BR,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Haibin<p></p></span></p>
</div>
</div>
The IESG | 6 Mar 10:26 2014
Picon

Protocol Action: 'ALTO Protocol' to Proposed Standard (draft-ietf-alto-protocol-27.txt)

The IESG has approved the following document:
- 'ALTO Protocol'
  (draft-ietf-alto-protocol-27.txt) as Proposed Standard

This document is the product of the Application-Layer Traffic
Optimization Working Group.

The IESG contact persons are Spencer Dawkins and Martin Stiemerling.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-alto-protocol/

Technical Summary

   Applications using the Internet already have access to some topology
   information of Internet Service Provider (ISP) networks.  For
   example, views to Internet routing tables at looking glass servers
   are available and can be practically downloaded to many network
   application clients.  What is missing is knowledge of the underlying
   network topologies from the point of view of ISPs.  In other words,
   what an ISP prefers in terms of traffic optimization -- and a way to
   distribute it.

   The Application-Layer Traffic Optimization (ALTO) Service provides
   network information (e.g., basic network location structure and
   preferences of network paths) with the goal of modifying network
   resource consumption patterns while maintaining or improving
   application performance.  The basic information of ALTO is based on
   abstract maps of a network.  These maps provide a simplified view,
   yet enough information about a network for applications to
   effectively utilize them.  Additional services are built on top of
   the maps.

   This document describes a protocol implementing the ALTO Service.
   Although the ALTO Service would primarily be provided by ISPs, other
   entities such as content service providers could also operate an ALTO
   Service.  Applications that could use this service are those that
   have a choice to which end points to connect.  Examples of such
   applications are peer-to-peer (P2P) and content delivery networks.

Working Group Summary

  The specification process has been particularly long and
  articulated. The WG had to make many decisions -- the architectural
  ones reflected in the related requirements document -- that took
  time. However, quite broad consensus was reached on almost all of
  them.

Document Quality

  The document shepherd has followed the specification process
  closely, implementing a proof-of-concept client application himself
  (http://alto.tilab.com/alto-xkcd/). He has proofread the final
  version of the document and believes it is ready for publication.

  Implementations: three implementations with some interoperability
  were demostrated during a "running code show" organized at
  IETF80. Seven client and five server implementations were tested in
  an "interoperability event" at IETF81, with pretty good results
  (http://www.ietf.org/mail-archive/web/alto/current/msg01181.html). A
  second interoperability event was arranged during IETF85, were four
  server and two client implementations were tested against 21 test
  cases, with again good success rates (last slide of
  http://www.ietf.org/proceedings/85/slides/slides-85-alto-0.pdf).

  Expert supervision: since the protocol, despite being developed in
  TSV, is an application level protocol, based on HTTP and following a
  REST-ful approach, Peter Saint-Andre (also former responsible AD for
  ALTO, before the WG was moved to TSV) was appointed as APPS expert
  and has supervised the specification process in its crucial phases
  (Peter stepped back as Tech advisor at a later phase). Other experts
  from APPS (Martin Thomson, Alexey Melnikov), SEC (Richard Barnes,
  Hannes Tshofenig) and OPS (David Harrington, Benoit Claise) have at
  some point been involved and provided feedback on various aspects.

  Ted Hardie kindly provided a early apps-dir review
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05406.html)
  that helped in improving the document quality quite a lot.

  A Media Type review was requested on media-types <at> ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request, no issues were raised.

Personnel

  Enrico Marocco is the document shepherd, Spencer Dawkins is the
  responsible AD.

Wendy Roome | 4 Mar 16:59 2014

Re: comments on incremental update

Richard,

The immediate issue has a simple solution. A CIDR can only be in one PID.
So let¹s define the semantics of Network Map Incremental Update to be ³if
the update message puts CIDR C in PID P, then client must remove C from
whatever PID it was in before.²

Incidentally, that points out a ³gotcha² with JSON patch. We encode a
PID¹s CIDR set as a JSON array. As far as the server & client are
concerned, that¹s a set, and the order of CIDRs doesn¹t matter. But JSON
patch doesn¹t know that! The moral is that if we use JSON patch, the ALTO
server MUST create the array of CIDRs for each PID in a consistent,
repeatable order. Otherwise, if the server creates a JSON Network Map with
the same set of CIDRs but in a different order, JSON Patch will think the
entire list changed.

A higher-level question is how many CIDRs will PIDs have? Our incremental
update proposal updates a PID¹s CIDR set as a unit. So if one CIDR is
added to a PID, the incremental update message gives all the CIDRs that
were in  the PID. That¹s fine if PIDs only have (say) 5 or 10 CIDRs. But
if we expect PIDs to have 100 or more CIDRs, then it¹s not. In that case
we need to consider an add/delete model to update a PID¹s CIDR set without
repeating the ones that didn¹t change.

Finally, there¹s the whole question of how often do Network Maps change,
and will incremental update ever be worth it for Network Maps? I believe
the ALTO protocol makes the tacit assumption that Network Maps change less
often than Cost Maps ‹ a change to a Network Map is almost a flag day. And
unless PIDs have 100¹s of CIDRs, Cost Maps will always be much larger than
Network Maps, because Cost Maps go as the square of the number of PIDs. So
do we really need to bother with incremental update for Network Maps? I
think it¹s good to define it, but I suspect few servers would implement
it, and few clients would bother to use it.

	- Wendy Roome

On 03/03/2014, 15:00, "alto-request <at> ietf.org" <alto-request <at> ietf.org>
wrote:

>Message: 1
>Date: Sun, 2 Mar 2014 21:44:46 -0500
>From: "Y. Richard Yang" <yry <at> cs.yale.edu>
>To: IETF ALTO <alto <at> ietf.org>
>Subject: [alto] Comment on
>	http://tools.ietf.org/id/draft-roome-alto-incr-updates-00.txt
>Message-ID:
>	<CANUuoLr0R+S6rzLuuE-zFZ1_LWYJQo73O7_v9hYHoJdK=e0oxQ <at> mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Dear Wendy, Nico,
>
>I am reading the draft, and it is very well written.
>
>I see that you use a replacement approach for both the Network Map and
>Cost
>Map. A question is whether this provides efficient encoding, in
>particular,
>for Network Map changes. Assume that a change is to move an IP prefix
>pref1
>from PID1 to PID2, then the replacement based approach will require that
>the values of both PID1 and PID2 to be sent out on the wire. This can be
>large.
>
>I agree that RFC6902 could be difficult to use as well.
>
>To be concrete, consider the following Network Map, and the goal is that
>192.0.2.0/24 is moved from PID1 to PID2:
>
>HTTP/1.1 200 OK
>   Content-Length: 449
>   Content-Type: application/alto-networkmap+json
>
>   {
>     "meta" : {
>       "vtag": {
>         "resource-id": "my-default-network-map",
>          "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
>       }
>     },
>     "network-map" : {
>       "PID1" : {
>         "ipv4" : [
>           "192.0.2.0/24",
>           "198.51.100.0/25"
>         ]
>       },
>      "PID2" : {
>         "ipv4" : [
>           "198.51.100.128/25"
>         ]
>       },
>   ...
>}
>
>In particular, using RFC6902, a compact encoding might be the following:
>
>[
>     { "op": "move", "from": "/network-map/PID1/ipv4/0", "path":
>"/network-map/PID2//ipv4/0"
>    }
>]
>
>I agree that this requires the Client to remember the original JSON array
>to know the index. But I do see that it can be more compact.
>
>In other words, at sub-array level operations, RFC6902 can provide compact
>encoding.
>
>A related question is whether we always use replacement semantics for all
>future updates, if we consider consistency of protocol design.
>
>Any thought?
>
>Thanks for the always good work!
>
>Richard

Y. Richard Yang | 3 Mar 03:44 2014
Picon

http://tools.ietf.org/id/draft-roome-alto-incr-updates-00.txt

Dear Wendy, Nico,

I am reading the draft, and it is very well written.

I see that you use a replacement approach for both the Network Map and Cost Map. A question is whether this provides efficient encoding, in particular, for Network Map changes. Assume that a change is to move an IP prefix pref1 from PID1 to PID2, then the replacement based approach will require that the values of both PID1 and PID2 to be sent out on the wire. This can be large.

I agree that RFC6902 could be difficult to use as well. 

To be concrete, consider the following Network Map, and the goal is that 192.0.2.0/24 is moved from PID1 to PID2:

HTTP/1.1 200 OK
   Content-Length: 449
   Content-Type: application/alto-networkmap+json

   {
     "meta" : {
       "vtag": {
         "resource-id": "my-default-network-map",
          "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
       }
     },
     "network-map" : {
       "PID1" : {
         "ipv4" : [
           "192.0.2.0/24",
           "198.51.100.0/25"
         ]
       },
      "PID2" : {
         "ipv4" : [
           "198.51.100.128/25"
         ]
       },
   ...
}

In particular, using RFC6902, a compact encoding might be the following:

[
     { "op": "move", "from": "/network-map/PID1/ipv4/0", "path": "/network-map/PID2//ipv4/0" 
    }
]

I agree that this requires the Client to remember the original JSON array to know the index. But I do see that it can be more compact.

In other words, at sub-array level operations, RFC6902 can provide compact encoding.

A related question is whether we always use replacement semantics for all future updates, if we consider consistency of protocol design.

Any thought?

Thanks for the always good work!

Richard
<div><div dir="ltr">
<div>Dear Wendy, Nico,</div>
<div><br></div>
<div>I am reading the draft, and it is very well written.</div>
<div><br></div>
<div>I see that you use a replacement approach for both the Network Map and Cost Map. A question is whether this provides efficient encoding, in particular, for Network Map changes. Assume that a change is to move an IP prefix pref1 from PID1 to PID2, then the replacement based approach will require that the values of both PID1 and PID2 to be sent out on the wire. This can be large.</div>
<div><br></div>
<div>I agree that RFC6902 could be difficult to use as well.&nbsp;</div>
<div><br></div>
<div>To be concrete, consider the following Network Map, and the goal is that <a href="http://192.0.2.0/24">192.0.2.0/24</a> is moved from PID1 to PID2:</div>
<div><br></div>
<div>
<div>HTTP/1.1 200 OK</div>
<div>&nbsp; &nbsp;Content-Length: 449</div>
<div>&nbsp; &nbsp;Content-Type: application/alto-networkmap+json</div>
<div><br></div>
<div>&nbsp; &nbsp;{</div>
<div>&nbsp; &nbsp; &nbsp;"meta" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;"vtag": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"resource-id": "my-default-network-map",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;}</div>
<div>&nbsp; &nbsp; &nbsp;},</div>
<div>&nbsp; &nbsp; &nbsp;"network-map" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;"PID1" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ipv4" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://192.0.2.0/24">192.0.2.0/24</a>",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://198.51.100.0/25">198.51.100.0/25</a>"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;]</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;},</div>
</div>
<div>
<div>&nbsp; &nbsp; &nbsp; "PID2" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ipv4" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://198.51.100.128/25">198.51.100.128/25</a>"</div>
<div>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;]</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;},</div>
</div>
<div>&nbsp; &nbsp;...</div>
<div>}</div>
<div><br></div>
<div>In particular, using RFC6902, a compact encoding might be the following:</div>
<div><br></div>
<div>
<div>[</div>
<div>&nbsp; &nbsp; &nbsp;{ "op": "move", "from": "/network-map/PID1/ipv4/0", "path": "/network-map/PID2//ipv4/0"&nbsp;</div>
<div>&nbsp; &nbsp; }</div>
<div>]</div>
</div>
<div><br></div>
<div>I agree that this requires the Client to remember the original JSON array to know the index. But I do see that it can be more compact.</div>
<div><br></div>
<div>In other words, at sub-array level operations, RFC6902 can provide compact encoding.</div>
<div><br></div>
<div>A related question is whether we always use replacement semantics for all future updates, if we consider consistency of protocol design.</div>
<div><br></div>
<div>Any thought?</div>
<div><br></div>
<div>Thanks for the always good work!</div>
<div><br></div>
<div>Richard</div>
</div></div>
Jan Seedorf | 27 Feb 15:35 2014
Picon

FW: FCI Analysis

ALTO Folks,

Just a reminder and FYI: ALTO is currently one of two candidates for the CDNI FCI interface
(draft-seedorf-cdni-request-routing-alto). Matt below provided a good comparison of the ALTO-based
approach that Richard Yang and I am proposing, and the alternative approach which would be a
CDNI-specific JSON-based encoding.

 - Jan

-----Original Message-----
From: CDNi [mailto:cdni-bounces <at> ietf.org] On Behalf Of Matt Caulfield (mcaulfie)
Sent: Saturday, February 22, 2014 9:51 AM
To: cdni <at> ietf.org
Subject: [CDNi] FCI Analysis

As promised in Vancouver, I have read through the two current FCI proposals (along with some of their
normative references) and I have put together the following analysis. 

The text below first reviews the CDNI Requirements for FCI as well as some of the highlights from the FCI
Semantics. Next, a short list of (what I feel are) the key points from each draft. Finally, my analysis
comparing the drafts based on their approach to FCI (and not the quality or the level of detail in the documents).

If you have not done so already, then I would also  recommend reading Jon Peterson's email from February 6
("footprint and capabilities mechanisms"). 

=======================================
FCI Requirements (draft-ietf-cdni-requirements)
-------------------------------------------------------------
The CDNI FCI must allow a dCDN to communicate the following to a uCDN:
1) Ability/willingness of dCDN to handle requests from uCDN
2) Information to facilitate selection of a dCDN by uCDN (e.g. capabilities, resources, affinities)
3) Aggregated versions of #1 and #2 in the cascaded CDN case
4) Administrative limits and policies (e.g. max number of requests)
5) Specific capabilities including:
	a) delivery protocol
	b) acquisition protocol
	c) redirection mode (DNS vs HTTP)
	d) logging options
	e) metadata options
6) Delivery authorization mechanisms (e.g. uri signing)

The FCI must also support extensibility and versioning for new capabilities and footprints.

=======================================
FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) 
-------------------------------------------------------------
Design Decisions
1) Advertising Limited Coverage - should footprints be binary or rated via qualitative score?
2) Capabilities and Dynamic Data - what capabilities are static vs dynamic? If dynamic, how dynamic?
3) Advertisement vs Queries - synchronous query response model (per end client request) or state
replication? 
4) Avoiding / Handling Cheating dCDNs - capabilities should be eventually verifiable by the uCDN

Mandatory footprint types:
1) List of ISO Country Codes
2) List of AS numbers
3) Set of IP-prefixes

FCI must be able to convey the entire footprint/capabilities and optionally dynamic updates.

Footprints and Capabilities are dependent and tied together. Certain capabilities are only available
for specific footprints.

Important to note that most footprint information will be agreed upon out of band (e.g. via contracts). FCI
can be considered a means for providing changes or updates to that previously agreed upon set of
footprints and capabilities.

=======================================
 FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) 
-------------------------------------------------------------
This proposal is based on the ALTO (Application Layer Traffic Optimization) protocol
(draft-ietf-alto-protocol), currently under development by the ALTO working group. ALTO protocol
specification is currently an Active Internet-Draft in the "Submitted to IESG for Publication" state. 

Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to determine footprint and capabilities of dCDN.

An ALTO Network Map indicates coverage/reachability to groups of endpoints. Endpoints are grouped into
PIDs. All endpoints within a single PID share the same capabilities. 

Each PID is associated with a set of properties. Each property corresponds to a capability. The concept of a
PID Property Map is defined by draft-roome-alto-pid-properties (an active Internet-Draft). The same
draft defines rules for implicit inheritance of properties for overlapping PIDs (e.g. one PID may
correspond to a set of IP prefixes which is a subset of another PID; in this case, properties in the PID
Property Map for the bigger set (i.e. shorter IP prefix) also apply to the smaller set (i.e. longer IP prefix)).

Presumably the uCDN is configured with the URI for an ALTO IRD (Information Resource Directory) per dCDN.
The IRD in turn provides two URIs. One for accessing the dCDN's Network Map and another for the dCDN's PID
Property Map. However, this is not described explicitly.

The draft defines the same basic set of capabilities as defined in the requirements but does not describe
their encoding in depth.

The ALTO protocol only registers IPv4 and IPv6 endpoint types. Assuming that this draft would register ISO
Country Codes and AS numbers as new endpoint types, but not clear from the text.

ALTO Cost Map could be used to determine the cost of the dCDN delivering to each group of endpoints (PID). 

The PID concept offers a level of indirection between footprints and capabilities allowing them to vary independently.

ALTO also offers filtered querying in order to avoid fetching an entire network map or pid property map. 

Future extensions to ALTO will include asynchronous notifications and incremental updates as described
by draft-schwan-alto-incr-updates (currently an Expired Internet-Draft). Expecting progress soon
in this area from the ALTO WG.

=======================================
FCI using HTTP and CDNI-specific Representation (draft-ma-cdni-capabilities-04) 
-------------------------------------------------------------
This proposal is based on a CDNI-specific representation of footprints and capabilities. Footprints and
capabilities are encoded in JSON and transported via HTTP.

Stated objective is to distill dCDN resource knowledge into simple set of capabilities and their
footprints. That is, each capability has an associated footprint.

The draft defines the same basic set of capabilities as defined in the requirements and provides some
examples of their encoding.

Each capability has a name, a list of values, and an optional list of footprints. The list of values is
specific to the capability name.

The optional footprint list restricts its capability. Each footprint has a type, list of values, and an
optional mode. The list of values is specific to the footprint type. A registry is defined for footprint
types and includes country code, AS number, and IP prefix.

The footprint mode may be set to "replace", "include", or "exclude" which indicates how the footprint
should be treated with respect to "previous" footprint information. In this context, "previous" refers
to incremental updates which are sent asynchronously from the dCDN to the uCDN. The "replace" mode
indicates that any previous information about the footprint should be discarded and replaced entirely
with the new information. The "include" mode indicates an addition to the footprint while "exclude"
indications a subtraction.

The draft does not provide a means for conveying footprint cost information.

In practice, the dCDN FCI Server would return a full F&C document in response to HTTP GET requests. An HTTP
GET would be used to initialize the state of the uCDN. In response to a GET, all modes are set to "replace".

The proposal also allows the dCDN to send asynchronous HTTP POSTs to uCDN for updating the F&C. Updates may
use "include" and "exclude" modes for partial updates. Each update includes a sequence numbers (via an
CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates result in a reset and a re-initialization.

=======================================
Analysis
-------------------------------------------------------------

Transport and Encoding: both proposals rely on HTTP transport and JSON encoding. This is a good starting
point and is in line with current CDNI WG documents (e.g. triggers and metadata drafts). 

Data Representation: in the case of draft-seedorf, the existing ALTO representations for network and
property maps are leveraged. These data structures clearly fit the CDNI use case and have the benefit of
prior review. In the case of draft-ma, a new CDNI-specific representation is defined. There is no clear
technical deficiency with either approach given that a newly defined representation can be as flexible
as needed and the ALTO representation is generic enough to support the CDNI use case. Leveraging an
existing protocol has obvious advantages but it is unclear to me whether or not adding a dependency on the
ALTO WG will be problematic in any way.

Hierarchy: in the case of draft-seedorf, footprints have capabilities. In the case of draft-ma,
capabilities have footprints. In the single CDN case, neither option is deficient. In the cascaded CDN
case, the draft-seedorf approach seems more intuitive. Aggregated footprint and capability
information is constructed simply by appending the footprints of all dCDNs. 

Cost Information: in the case of draft-seedorf, a loose description is provided of how to apply ALTO Cost
Maps to footprints. In the case of draft-ma, no solution is described. Cost information is only useful
when multiple dCDNs can claim the same end clients in their footprint advertisements. However,
regardless of the use case, business logic is likely to kick in before such cost metrics would be useful.
Neither approach includes a definitive proposal in this area.

Extensibility and Versioning: Versioning of the FCI protocol is not discussed by either draft.
Extensibility is alluded to and is clearly possible. However, the details are lacking in this area.

Dependence on ALTO WG: In the case of draft-seedorf, a dependency is introduced on the ALTO WG and a few
drafts in progress. In the case of draft-ma, no such dependency is required. The benefits of leveraging
ALTO include the ability to easily reuse the work that the ALTO WG has done in hardening the error handling,
security, encoding, and processing of the ALTO protocol. However, the difficulty of these efforts is not
insurmountable and could be reproduced in a CDNI-specific proposal. 

Capability Inheritance: in the case of draft-seedorf, the PID Property Map defines rules for implicit
inheritance between multiple overlapping PIDs. In the case of draft-ma, no special inheritance rules
exist. These inheritance rules may complicate implementation of FCI. Completely explicit
capabilities, such as in draft-ma, may be a better approach.

Update Notifications: in the case of draft-seedorf, no strong story for update notifications is
provided. The ALTO Incremental Updates draft is referenced. However, this draft is expired. In the case
of draft-ma, an HTTP POST may be sent from dCDN to uCDN which includes the incremental update. Assuming
that update notifications is a real requirement, then draft-ma has a more concrete approach in this area.
However, a bidirectional HTTP interface breaks the RESTful nature of the interface. 

Incremental Updates: in the case of draft-seedorf, the ALTO Incremental Update draft is referenced. This
draft describes the use of JSON Patch for encoding incremental changes to ALTO information.
Additionally, ALTO allows for filtered queries which could be used for obtaining partial information.
In the case of draft-ma, a scheme including sequence numbers, a new HTTP header, and a "mode" is used for
conveying incremental changes via HTTP POST. Like the update notifications, the draft-ma proposal is
more concrete in this area. However, again, the ALTO approach is more RESTful. Additionally, adding a new
HTTP header for this purpose may not be workable.

Draft Maturity: both draft-seedorf and draft-ma require another level of detail. Neither describe
versioning and extensibility. Neither discuss the encoding of logging and metadata capabilities which
may pose significant challenges. 

=======================================
Conclusion
-------------------------------------------------------------
All in all, both drafts are well-written and viable candidates as a starting point for our FCI standard. 

I would suggest that the working group must first decide whether the benefits of reusing the ALTO syntax and
semantics outweigh the costs or if defining something CDNI-specific is a better option. As far as I can
tell, the data representation defined by ALTO meets the needs of CDNI. My only concern is a dependency on
the progress of the ALTO WG. Starting with a CDNI-specific representation provides maximum flexibility.

I would also recommend that we first focus on a simple HTTP GET interface and then, once stable, turn our
attention to incremental updates.

Cheers,
Matt

_______________________________________________
CDNi mailing list
CDNi <at> ietf.org
https://www.ietf.org/mailman/listinfo/cdni

Wendy Roome | 25 Feb 16:06 2014

Ambiguity in ALTO draft 25

I just noticed that draft 25 says that an Endpoint Cost Service MAY be declared as depending on a network/cost map:

11.5.1.5. Uses
It is important to note that although this resource allows an ALTO
Server to reveal costs between individual endpoints, an ALTO Server
is not required to do so. A simple implementation of an ECS resource
may compute the cost between two endpoints as the cost between the
PIDs corresponding to the endpoints, using one of the exposed network
and cost maps defined by the server. However, to preserve
flexibility, the ECS resource MAY omit declaring in the "uses"
attribute the network map and/or cost map on which it depends.

The ambiguity is whether the ECS uses a Network Map, a Cost Map, or both. ECS is a post-mode service, and can return one of several different cost types, as selected by the client. So if an ECS uses a Cost Map, it would have to use several Cost Maps, one for each cost-type it ca return.

The IRD example doesn’t help, because that ECS resource doesn’t have a “uses” attribute.

My suggestion: say that if ECS uses anything, it just uses the Network Map. The client can infer the related Cost Maps — they’re the ones that use that Network Map.  Eg, change the last sentence to:


Accordingly, the ECS resource MAY declare a Network Map resource in its “uses” attribute. If the ECS does so, the ECS costs should be consistent with those returned by the Cost Map resources associated with that Network Map.

and maybe add a “uses” attribute to the ECS IRD example in 9.2.3, as in:

"endpoint-cost" : {

    "uri" : "http://alto.example.com/endpointcost/lookup",

    "media-type" : "application/alto-endpointcost+json",

    "accepts" : "application/alto-endpointcostparams+json”,

    "capabilities" : {

        "cost-constraints" : true,

        "cost-type-names" : [ "num-routing", "num-hop",

                              "ord-routing", "ord-hop"]

    },

    “uses” : [ “my-default-network-map” ]

}



If y’all agree, can we get this in the rfc, or does it need to wait for an errata?

- Wendy Roome
<div>
<div>I just noticed that draft 25 says that an Endpoint Cost Service MAY be declared as depending on a network/cost map:</div>
<div><br></div>
<div>
<blockquote>
<div>11.5.1.5. Uses</div>
<div>It is important to note that although this resource allows an ALTO</div>
<div>Server to reveal costs between individual endpoints, an ALTO Server</div>
<div>is not required to do so. A simple implementation of an ECS resource</div>
<div>may compute the cost between two endpoints as the cost between the</div>
<div>PIDs corresponding to the endpoints, using one of the exposed network</div>
<div>and cost maps defined by the server. However, to preserve</div>
<div>flexibility, the ECS resource MAY omit declaring in the "uses"</div>
<div>attribute the network map and/or cost map on which it depends.</div>
<div><br></div>
</blockquote>
<div>The ambiguity is whether the ECS uses a Network Map, a Cost Map, or both. ECS is a post-mode service, and can return one of several different cost types, as selected by the client. So if an ECS uses a Cost Map, it would have to use several Cost Maps, one for each cost-type it ca return.</div>
</div>
<div><br></div>
<div>The IRD example doesn&rsquo;t help, because that ECS resource doesn&rsquo;t have a &ldquo;uses&rdquo; attribute.</div>
<div><br></div>
<div>My suggestion: say that if ECS uses anything, it just uses the Network Map. The client can infer the related Cost Maps &mdash; they&rsquo;re the ones that use that Network Map. &nbsp;Eg, change the last sentence to:</div>
<div><br></div>
<div><br></div>
<div>
<blockquote>
<div>Accordingly, the ECS resource MAY declare a Network Map resource in its &ldquo;uses&rdquo; attribute. If the ECS does so, the ECS costs should be consistent with those returned by the Cost Map resources associated with that Network Map.</div>
<div><br></div>
</blockquote>
<div>and maybe add a &ldquo;uses&rdquo; attribute to the ECS IRD example in 9.2.3, as in:</div>
<div><br></div>
<div><blockquote>
<p>"endpoint-cost" : {</p>
<p>&nbsp; &nbsp; "uri" : "http://alto.example.com/endpointcost/lookup",</p>
<p>&nbsp; &nbsp; "media-type" : "application/alto-endpointcost+json",</p>
<p>&nbsp; &nbsp; "accepts" : "application/alto-endpointcostparams+json&rdquo;,</p>
<p><span>&nbsp; &nbsp; "capabilities" : {</span></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; "cost-constraints" : true,</p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; "cost-type-names" : [ "num-routing", "num-hop",</p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "ord-routing", "ord-hop"]</p>
<p>&nbsp; &nbsp; },</p>
<p>&nbsp; &nbsp; &ldquo;uses&rdquo; : [&nbsp;&ldquo;my-default-network-map&rdquo; ]</p>
<p>}</p>
</blockquote></div>
<blockquote><div><br></div></blockquote>
</div>
<div><br></div>
<div>If y&rsquo;all agree, can we get this in the rfc, or does it need to wait for an errata?</div>
<div><br></div>
<div>
<span class="Apple-tab-span">	</span>- Wendy Roome</div>
</div>

Gmane