Mark Nottingham | 28 Jul 05:54 2014
Picon

Re: JSON Patch vs. custom representation for incremental updates

PATCH isn't idempotent.

Cheers,

On 28 Jul 2014, at 1:52 pm, Paul C. Bryan <pbryan <at> anode.ca> wrote:

> On Mon, 2014-07-28 at 12:48 +1000, Mark Nottingham wrote:
> 
>> Just that the PATCH method is defined for generic mechanisms, not application-specific ones; if your
payload is application-specific, you might as well use POST.
> 
> If the intent is for the operation to be idempotent, then I believe PATCH can still be more suitable for an
application-specific payload.
> 
> Paul

--
Mark Nottingham   https://www.mnot.net/

Adrian Farrel | 25 Jul 20:02 2014
Picon

Call for review draft-farrkingel-pce-abno-architecture

Hi,

The authors of draft-farrkingel-pce-abno-architecture are in the process of
requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture

This I-D is a bit of an architecture and a bit an applicability statement. It
spans quite a lot of IETF technology including ALTO.

The last call will obviously pop out sometime, but it would be nice to have
review comments before then.

Thanks,
Adrian

Enrico Marocco | 22 Jul 20:38 2014
Picon

Meeting materials

Hi all,

in order to accommodate remote participation for the Friday meeting, the 
chairs are requested to upload meeting materials by Thursday night.

If you have been assigned a slot on the agenda, please send your slides 
and the name of the presenter by Thrusday, 6pm.

Enrico

Attachment (smime.p7s): application/pkcs7-signature, 5795 bytes
Hi all,

in order to accommodate remote participation for the Friday meeting, the 
chairs are requested to upload meeting materials by Thursday night.

If you have been assigned a slot on the agenda, please send your slides 
and the name of the presenter by Thrusday, 6pm.

Enrico

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>

Gmane