Qin Wu | 20 Jul 04:18 2014

Re: [ALTO] Statistics operators for TE metrics

 

发件人: yang.r.yang <at> gmail.com [mailto:yang.r.yang <at> gmail.com] 代表 Y. Richard Yang
发送时间: 2014719 8:12
收件人: Leeyoung
抄送: Qin Wu; Sabine Randriamasy; Dhruv Dhody; Qin Wu
主题: Re: TE metrics slides

 

Hi Young,

 

Good question. The intention of the question is whether to use ALTO to expose various statistics of the metrics, not limited to only mean/avg. Increasingly more networks care about higher percentile than standard mean/avg. Hence, an extensible design should allow such easy extensibility. What do you think?

 

[Qin]: I think not all TE metrics needs to use percentile, e.g., delay, I think still stick to use mean and delayjitter will still stick to use variance.

But for bandwidth related metrics, I think maximum bandwidth, maximum reservable bandwidth,unreserved  bandwith can keep on using bytes per sec as measurement unit,

But residue bandwidth, available bandwidth and utilized bandwidth can use percentile.

 

Richard

 

On Fri, Jul 18, 2014 at 11:39 AM, Leeyoung <leeyoung <at> huawei.com> wrote:

Hi Qin and Richard,

 

Thanks for putting a good quality slide together. I think it is good with this version.

 

On one question:

      Do we allow more flexible statistics operators (e.g., mean, avg, x-percentile, variance)

       In current draft, delay and delay jitter are both on delay, with one reflect mean and the other variance

 

Do you mean, “Do we allow more flexible statistics for/from/?? operator?” Not sure what you mean. If the network operators are the ones that provide these stats to ALTO application, then we may say, “Do we need more flexible statistics for some applications?” for instance. May be I am missing something here.

 

Flexible stat such as percentile and variance are all good, yet there might be scaling issues and usability of such data and the networks that provide such data do not normally have in their TED  except jitter variance. This could imply an overhead for networks.

 

Thanks,

Young

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<div>
<p class="MsoNormal"><span>&#21457;&#20214;&#20154;<span lang="EN-US">:</span></span><span lang="EN-US"> yang.r.yang <at> gmail.com [mailto:yang.r.yang <at> gmail.com]
</span><span>&#20195;&#34920; </span><span lang="EN-US">Y. Richard Yang<br></span><span>&#21457;&#36865;&#26102;&#38388;<span lang="EN-US">:</span></span><span lang="EN-US"> 2014</span><span>&#24180;<span lang="EN-US">7</span>&#26376;<span lang="EN-US">19</span>&#26085;<span lang="EN-US"> 8:12<br></span>&#25910;&#20214;&#20154;<span lang="EN-US">:</span><span lang="EN-US"> Leeyoung<br></span>&#25220;&#36865;<span lang="EN-US">:</span><span lang="EN-US"> Qin Wu; Sabine Randriamasy; Dhruv Dhody; Qin Wu<br></span>&#20027;&#39064;<span lang="EN-US">:</span><span lang="EN-US"> Re: TE metrics slides<p></p></span></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Young,<p></p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Good question. The intention of the question is whether to use ALTO to expose various statistics of the metrics, not limited to only mean/avg. Increasingly more networks care about higher percentile than standard mean/avg.
 Hence, an extensible design should allow such easy extensibility. What do you think?<p></p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">[Qin]: I think not all TE metrics needs to use percentile, e.g., delay, I think still stick to use mean and delayjitter will still stick to use
 variance.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">But for bandwidth related metrics, I think maximum bandwidth, maximum reservable bandwidth,unreserved &nbsp;bandwith can keep on using bytes per sec
 as measurement unit,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">But residue bandwidth, available bandwidth and utilized bandwidth can use percentile.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Richard<p></p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Fri, Jul 18, 2014 at 11:39 AM, Leeyoung &lt;<a href="mailto:leeyoung <at> huawei.com" target="_blank">leeyoung <at> huawei.com</a>&gt; wrote:<p></p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Qin and Richard,</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks for putting a good quality slide together. I think it is good with this version.
</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">On one question:
</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal">
<span lang="EN-US">&ndash;</span><span lang="EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-US">Do we allow more flexible statistics operators (e.g., mean, avg, x-percentile, variance)</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal">
<span lang="EN-US">&bull;</span><span lang="EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-US">In current draft, delay and delay jitter are both on delay, with one reflect mean and the other variance</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Do you mean, &ldquo;Do we allow more flexible statistics
for/from/?? operator?&rdquo; Not sure what you mean. If the network operators are the ones that provide these stats to ALTO application, then we may say, &ldquo;Do we need more flexible statistics for some applications?&rdquo; for instance. May be I am missing something
 here. </span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Flexible stat such as percentile and variance are all good, yet there might be scaling
 issues and usability of such data and the networks that provide such data do not normally have in their TED &nbsp;except jitter variance. This could imply an overhead for networks.
</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Young</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
Qin Wu | 18 Jul 14:17 2014

Measurement timing for cost metric

Hi,

We talked about measurement timing for cost metric for several times.

In the current draft, we use fixed measurement interval for each cost metrics.

Is it too much restrictive? Shall we allow multiple fixed Measurement Timing specification

That will be conveyed in IRD to relax such restriction?

Comments or opinions?

 

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">We talked about measurement timing for cost metric for several times.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">In the current draft, we use fixed measurement interval for each cost metrics.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Is it too much restrictive? Shall we allow multiple fixed Measurement Timing specification<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">That will be conveyed in IRD to relax such restriction?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Comments or opinions?<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>
</div>
</div>
Qin Wu | 18 Jul 14:13 2014

statistics operators for ALTO cost metrics

Hi,

Motivated by RFC3630 and draft-ietf-isis-te-metric-extensions, we define 11 alto cost metrics,

The value of these alto cost metrics are high aggregated value, we may have several statistics operators, e.g.,

Mean, variance, avg, percentile).

In the current draft, delay and delay jitter are both on delay, we use mean

For delay and use variance for delayjitter.

It is not clear these statistics operator are appropriate for them? E.g., should we use percentile for bandwidth related cost metric?

Any opinion?

 

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">Motivated by RFC3630 and draft-ietf-isis-te-metric-extensions, we define 11 alto cost metrics,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The value of these alto cost metrics are high aggregated value, we may have several statistics operators, e.g.,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Mean, variance, avg, percentile).<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">In the current draft, delay and delay jitter are both on delay, we use mean<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">For delay and use variance for delayjitter.
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">It is not clear these statistics operator are appropriate for them? E.g., should we use percentile for bandwidth related cost metric?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Any opinion?<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>
</div>
</div>
Qin Wu | 18 Jul 14:02 2014

Hopcount in ALTO TE Metrics draft

Hi, all:

Hopcount is a cost metric used in the example ALTO base protocol. We clarified its properties(e.g., cost metric string, metric value type) in the ALTO TE metrics draft.

The hop count is usually refers to the intermediate devices (like routers) through which data must pass between source and destination

I am wondering if we need to distinguish hop count in IP layer from hop count in higher layer or lower layer? Is there any hop count in lower layer,e.g., optical layer?

 

Regards!

-Qin

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi, all:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Hopcount is a cost metric used in the example ALTO base protocol. We clarified its properties(e.g., cost metric string, metric value type) in the ALTO TE metrics draft.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The hop count is usually refers to the intermediate devices (like routers) through which data must pass between source and destination<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">I am wondering if we need to distinguish hop count in IP layer from hop count in higher layer or lower layer? Is there any hop count in lower layer,e.g., optical layer?<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>
</div>
</div>
Wendy Roome | 17 Jul 22:00 2014

Re: Should get-mode services accept post requests?

Ben,

However, if a significant number of ALTO servers accept POST as well as
GET for full map services, that will establish a de-facto standard, and it
will be difficult to define different semantics for POST in the future.

Also, the current spec allows a server to use the same URI for Full and
Filtered Map services. Eg, consider this IRD fragment:

        "my-default-network-map" : {
		"uri" : "http://alto.example.com/networkmap",
		"media-type" : "application/alto-networkmap+json"
	},
        "filtered-network-map" : {
		"uri" : "http://alto.example.com/networkmap",
		"media-type" : "application/alto-networkmap+json",
		"accepts" : "application/alto-networkmapfilter+json",
		"uses": [ "my-default-network-map" ]
	},

That says that for http://alto.example.com/networkmap, GET returns a full
network map, while POST (with the appropriate content type) returns a
filtered network map.

	- Wendy Roome

On 07/17/2014, 03:39, "Ben Niven-Jenkins" <ben <at> niven-jenkins.co.uk> wrote:

>Wendy,
>
>On 16 Jul 2014, at 16:10, Wendy Roome <w.roome <at> alcatel-lucent.com> wrote:
>
>> Here is a fringe case that doesn't seem to be covered in the protocol
>>spec.
>> 
>> If a client sends a POST request to a GET-mode service, like Full Cost
>> Map, should the ALTO server reject the request? Or should the server
>> accept the request anyway, and just return the map?
>> 
>> And would it depend on the content the client sent? Eg, should the
>>server
>> accept a POST request with no content, but reject a POST request if the
>> client sent a body of (say) type application/alto-costmapfilter+json, on
>> the grounds that the client mistakenly thought this was a Filtered Cost
>> Map service?
>> 
>> My inclination is to reject an POST request, even if there is no
>>content.
>> Normally I prefer to forgive obvious errors, but unless all servers have
>> the same level of forgiveness, error-tolerant servers will be seen as
>> "correct", while other servers will be seen as "incorrect".
>> 
>> What does the group think?
>
>My view is that the behaviour is server implementation specific and that
>clients must not rely on a particular response unless they have further
>information to suggest otherwise.
>
>I don¹t like the idea of mandating returning an error as I¹d like to leave
>the door open to allowing POST later on, e.g. as a possible means to
>update
>the map.
>
>Ben
>

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto
Wendy Roome | 17 Jul 21:51 2014

Re: Should get-mode services accept post requests?

Yes, most web servers accept POST as well as GET. But most web pages don't
have an RFC defining their content. :-)

Also, regular web pages generally use POST for form submission. Form-field
encoding is well-defined for both POST & GET requests, so except for the
low-level field decoding, web servers can treat GET & POST identically.
The difference is only important in the browser (for caching) or in
proxies along the way.

	- Wendy Roome

On 07/17/2014, 03:26, "Stephane Bortzmeyer" <bortzmeyer <at> nic.fr> wrote:

>On Wed, Jul 16, 2014 at 11:10:21AM -0400,
> Wendy Roome <w.roome <at> alcatel-lucent.com> wrote
> a message of 29 lines which said:
>
>> If a client sends a POST request to a GET-mode service, like Full
>> Cost Map, should the ALTO server reject the request? Or should the
>> server accept the request anyway, and just return the map?
>
>Note that a regular HTTP server, serving static data (such as a
>network map), accepts POST and generates the same reply as a GET.
>
>% curl -v -X POST http://www.ietf.org/meeting/90/index.html
>...
>> POST /meeting/90/index.html HTTP/1.1
>> User-Agent: curl/7.37.0
>> Host: www.ietf.org
>> Accept: */*
>> 
>< HTTP/1.1 200 OK
>< Server: cloudflare-nginx
>< Date: Thu, 17 Jul 2014 07:25:27 GMT
>< Content-Type: text/html
>...
>

Wendy Roome | 16 Jul 17:10 2014

Should get-mode services accept post requests?

Here is a fringe case that doesn't seem to be covered in the protocol spec.

If a client sends a POST request to a GET-mode service, like Full Cost
Map, should the ALTO server reject the request? Or should the server
accept the request anyway, and just return the map?

And would it depend on the content the client sent? Eg, should the server
accept a POST request with no content, but reject a POST request if the
client sent a body of (say) type application/alto-costmapfilter+json, on
the grounds that the client mistakenly thought this was a Filtered Cost
Map service?

My inclination is to reject an POST request, even if there is no content.
Normally I prefer to forgive obvious errors, but unless all servers have
the same level of forgiveness, error-tolerant servers will be seen as
"correct", while other servers will be seen as "incorrect".

What does the group think?

	- Wendy

Wendy Roome | 14 Jul 18:18 2014

Re: Yet another ALTO discovery technique

Sebastian et al,

Has anyone considered the following ALTO server discovery mechanism? Create a global registry of all public ALTO servers, with a well-known, persistent uri. We would strongly encourage anyone who fields a public ALTO server to register it. Since (presumably!) ISPs and the like want customers to use their ALTO servers, I think it would be easy to get them to register the servers.

So what would the interface be? Why ALTO, of course! Specifically, the global registry would be an ALTO server with an Endpoint Property Service (and the PID Property Service, draft-roome-alto-pid-properties, assuming that extension is adopted) with the property “Preferred-ALTO-Server”, whose value is the URI of ALTO server with the best local knowledge around that endpoint.

If this is a PID property, a p2p tracker could download the network map and full set of PID properties, so it would not need to consult the global registry for each request.

I think this is the moral equivalent of getting the ALTO server through DNS, except that it doesn’t require updating DNS tables. And it allows clients like trackers to discover the ALTO server for remote regions. 

Comments?

- Wendy

<div>
<div>Sebastian et al,</div>
<div><br></div>
<div>Has anyone considered the following ALTO server discovery mechanism? Create a global registry of all public ALTO servers, with a well-known, persistent uri. We would strongly encourage anyone who fields a public ALTO server to register it. Since (presumably!) ISPs and the like want customers to use their ALTO servers, I think it would be easy to get them to register the servers.</div>
<div><br></div>
<div>So what would the interface be? Why ALTO, of course! Specifically, the global registry would be an ALTO server with an Endpoint Property Service (and the PID Property Service,&nbsp;<a href="https://datatracker.ietf.org/doc/draft-roome-alto-pid-properties/">draft-roome-alto-pid-properties</a>,&nbsp;assuming that extension is adopted) with the property &ldquo;Preferred-ALTO-Server&rdquo;, whose value is the URI of ALTO server with the best local knowledge around that endpoint.</div>
<div><br></div>
<div>If this is a PID property, a p2p tracker could download the network map and full set of PID properties, so it would not need to consult the global registry for each request.</div>
<div><br></div>
<div>I think this is the moral equivalent of getting the ALTO server through DNS, except that it doesn&rsquo;t require updating DNS tables. And it allows clients like trackers to discover the ALTO server for remote regions.&nbsp;</div>
<div><br></div>
<div>Comments?</div>
<div><br></div>
<div>
<span class="Apple-tab-span">	</span>- Wendy</div>
<br>
</div>
Wendy Roome | 9 Jul 21:14 2014

Re: JSON Patch vs. custom representation for incremental updates

Here's why I think we need a representation for incremental updates that's
tailored to the ALTO data model, rather than using the general JSON Patch
representation.

As I understand it, JSON is a standardized way for a computer to create a
serialized, machine-independent representation of a data structure, send
that serialization over a stream to another computer, and have the other
computer recreate that data structure. This is a simplification, of
course, but I believe that's the goal.

JSON Patch is a standard way to represent the changes to a data structure,
ship them to another computer, and have a JSON Patch library on the other
computer automatically update the remote data structure, with little
additional work for either computer.

That's a wonderful goal. Unfortunately that has three problems when we
apply it to ALTO: (1) JSON does not have data representations that
directly correspond to the ALTO data structures, so JSON cannot capture
the semantics of the ALTO data. (2) As a result, JSON Patch is an
inefficient representation of the legal changes. (3) For the clients who
need incremental update, that inefficiency is a deal breaker.

Let's take the last first. What clients need incremental update? Clients
who keep full cost and network maps. But what clients would do that? After
all, clients care about costs between endpoints. Clients don't really care
about PIDs. PIDs are just an abstraction to make the space of endpoints
more manageable. For most ALTO clients, the Endpoint Cost Service (ECS) is
exactly what they want, and they'd much rather use that than go though the
hassle of downloading the maps, searching them, and keeping them
up-to-date.

So why would a client use full maps? Because the client needs to lookup
costs very quickly, and cannot tolerate the delay of querying the ALTO
Server. For example, a P2P tracker must select, out of 5,000 peers, the 50
with the lowest cost to a given peer. And a tracker might do that 10 times
a second.

As for the second point, incremental update is only necessary for large
maps. If a map only has 25 PIDs, why bother? Just download a new version.
What do I mean by "large"? A Network Map with 5,000 PIDs, 250,000
prefixes, and up to 25,000,000 cost points.

Yes, that seems huge. Will anyone ever build that large an ALTO server? I
don't know. But I think a lot of us remember when the ipv4 address space
seemed infinite. Or when a 100 meg disk was big.

Now consider point 1: JSON does not do a good job of representing the ALTO
data. Take Cost Maps. A Cost Map is a square sparse matrix of numbers
indexed by strings. JSON has no such data structure, so in JSON we
represent that as a lookup table of lookup tables of costs. But that
consumes a lot more space than necessary. Furthermore, at least for most
cost metrics, the values are low precision (do you really think that a
routingcost of 49.99999 is any better than a cost of 50?), and the string
indexes -- the PID names -- don't change very often.

So if a client needs to handle a 5,000 x 5,000 Cost Map, and lookup costs
in microseconds, the client convert the PID names to numbers from 0 to
N-1, so it can use a sparse numerically indexed array, and it stores the
costs single-precision floats, not double-precision, to save 100 megs of
RAM.

The mismatch is even worse for Network Maps. A Network Map is a lookup
table from PID names to sets of prefixes. ALTO has lookup tables, but
doesn't have sets, so we represent the sets by arrays. But this confounds
JSON Patch, because order matters in arrays. Furthermore, the JSON
representation does not capture the semantics that a prefix can only be in
one PID. So if the server moves 1.2.3.4 from PID1 to PID2, JSON Patch
would need the following update commands:

     add 1.2.3.4 at index 17 in the array for PID1
     delete index 6 from the array for PID2

But if we know the real semantics of ALTO Network Maps, we can represent
that update as:

     add 1.2.3.4 to PID1

The delete from PID2 is implicit.

Here's the bottom line: Clients who need incremental update will NOT store
data in a format that looks like JSON data model. Such a client will read
the JSON data, convert it in a totally different form, and then discard
the original JSON. If we use JSON Patch to represent deltas, a client
would NEVER be able to use a standard JSON library to automatically apply
the patches. Instead, the client would need custom code that understands
every possible JSON Patch update command, and figures out how to apply
them to the client's representation of the data. And the client may be
forced to use a suboptimal data structure to allow that (e.g., store
prefixes as arrays rather than sets).

This does not simplify anything; it just makes more work for the client.

    - Wendy Roome

Vijay K. Gurbani | 7 Jul 16:24 2014

ALTO agenda posted

Folks: The agenda for the Toronto IETF has been posted (please see
https://datatracker.ietf.org/meeting/90/agenda/alto/).

It is a full agenda; presenters, please be mindful of the timing
constraints as you prepare your presentations.

Cheers,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

TR: New Version Notification for draft-randriamasy-alto-cost-calendar-01.txt


Hi all,

A version 01 of draft ALTO Calendar has just been posted. The updates clarify sections on the design
considerations, ALTO Cost Calendar attributes specification and ALTO transaction examples. These
sections will be updated upon discussions in the ALTO WG.
Please use this new version for feedback and discussion.

Best regards
Sabine



>>-----Message d'origine-----
>>De : internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
>>Envoyé : samedi 5 juillet 2014 01:47
>>À : RANDRIAMASY, SABINE (SABINE); Qin Wu; Wenson Wu; Richard Yang;
>>RANDRIAMASY, SABINE (SABINE); Nico Schwan; Deng Lingli; Yang Yang;
>>Lingli Deng; Nico Schwan
>>Objet : New Version Notification for draft-randriamasy-alto-cost-
>>calendar-01.txt
>>
>>
>>A new version of I-D, draft-randriamasy-alto-cost-calendar-01.txt
>>has been successfully submitted by Sabine Randriamasy and posted to the
>>IETF repository.
>>
>>Name:		draft-randriamasy-alto-cost-calendar
>>Revision:	01
>>Title:		ALTO Cost Calendar
>>Document date:	2014-07-04
>>Group:		Individual Submission
>>Pages:		24
>>URL:            http://www.ietf.org/internet-drafts/draft-randriamasy-

>>alto-cost-calendar-01.txt
>>Status:         https://datatracker.ietf.org/doc/draft-randriamasy-

>>alto-cost-calendar/
>>Htmlized:       http://tools.ietf.org/html/draft-randriamasy-alto-cost-

>>calendar-01
>>Diff:           http://www.ietf.org/rfcdiff?url2=draft-randriamasy-

>>alto-cost-calendar-01
>>
>>Abstract:
>>   The goal of Application-Layer Traffic Optimization (ALTO) is to
>>   bridge the gap between network and applications by provisioning
>>   network related information in order to allow applications to make
>>   informed decisions.  The present draft proposes to extend the cost
>>   information provided by the ALTO protocol.  The purpose is to
>>broaden
>>   the decision possibilities of applications to not only decide
>>'where'
>>   to connect to, but also 'when'.  This is useful to applications that
>>   have a degree of freedom on when to schedule data transfers, such as
>>   non- instantaneous data replication between data centers or service
>>   provisioning to end systems with irregular connectivity.  ALTO
>>   guidance to schedule application traffic can also efficiently help
>>   for load balancing and resources efficiency.
>>
>>   The draft specifies a new Cost Mode, "Calendar" Mode, that is
>>   applicable to time-sensitive ALTO metrics and allows Applications to
>>   carefully schedule their connections or data transfers.  In the
>>   Calendar Mode, an ALTO Server exposes ALTO Cost Values in JSON
>>arrays
>>   where each value corresponds to a given time interval.  The time
>>   intervals as well as other Calendar attributes are specified in the
>>   IRD.  Besides the functional time-shift enhancement the ALTO Cost
>>   Calendar also allows to schedule the ALTO requests themselves and
>>   thus save a number of ALTO transactions.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission until the htmlized version and diff are available at
>>tools.ietf.org.
>>
>>The IETF Secretariat

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

Gmane