Subject: Re: [alto] minor inconsistency in draft 14

From: Wendy Roome <[email-masked]>
Date: Mon, 18 Mar 2013 10:38:25 -0400

We've worked hard to allow ALTO servers to use ordinal mode instead of
numerical mode. However, Section "9.1.2 Cost Maps" (first paragraph, last
sentence) says:

	This resource MUST be provided for at least the
	'routingcost' Cost Type and 'numerical' Cost Mode.

I think that should read

	... Cost Type and either 'numerical' or 'ordinal' Cost Mode.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Mar 2013 15:12:37 -0400

Hi Wendy,

So you think each implementation MUST provide both numerical and ordinal
modes for the 'routingcost' metric. I believe that this is true for all
existing implementations, and hence a useful requirement.

If no objection from others, we should add this to ensure interop.

Thanks!

Richard

On Mon, Mar 18, 2013 at 10:38 AM, Wendy Roome <[email-masked]>wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Wendy Roome <[email-masked]>
Date: Tue, 19 Mar 2013 10:01:24 -0400

Whoops -- I meant [9.1.2] should say that an ALTO server must provide
'numerical' OR 'ordinal' mode, not that a server must support both!

Related question: Do we really need to require that all ALTO servers support
a Cost Type named 'routingcost'? Suppose I have an ALTO server that provides
a custom Cost Type to a select group of authorized clients. None of those
clients need 'routingcost'. Why must my server support a Cost Type that no
client will ever use? So I'd be happy to drop that requirement altogether.

Aside: My design philosophy is Libertarian, so I tend to challenge "MUST"
requirements. I think they should exist only if they are absolutely
necessary for interoperability.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Mon, March 18, 2013 15:12
Subject:  Re: [alto] minor inconsistency in draft 14

Hi Wendy,

Thanks!

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 19 Mar 2013 16:20:51 -0400

Hi Wendy,

On Tue, Mar 19, 2013 at 10:01 AM, Wendy Roome <[email-masked]>wrote:

> Related question: Do we really need to require that all ALTO servers
> support a Cost Type named 'routingcost'? Suppose I have an ALTO server that
> provides a custom Cost Type to a select group of authorized clients. None
> of those clients need 'routingcost'. Why must my server support a Cost Type
> that no client will ever use?
>

This argument can apply to other components of the spec as well. For
example, the current spec includes that the "pid" Endpoint property must be
supported and one can come with a customized deployment case where pid is
not used.

My understanding of the decision that an ALTO Server must provide
"routingcost" is also related with the design of allowing default. For
example, CostMapCapability can be empty and implies "routingcost". One
analogy one might or may not like is that TLS (RFC5246) defines that
TLS_RSA_WITH_AES_128_CBC_SHA
is mandatory. But we can imagine that there is no mandatory and hence
allows TLS negotiation to fail. But I agree with you that removing the so
far MUST supported cost type and endpoint property will not impact interop
in the sense that the protocol still works, and a conforming ALTO Server
may just not returning any information. What do you and others think?

Thanks for your always good comments!

Richard

> So I'd be happy to drop that requirement altogether.
>

---

From: Wendy Roome <[email-masked]>
Date: Tue, 19 Mar 2013 16:44:35 -0400

I think the PID property is different. The protocol defines what PIDs are
and how to determine how to map an endpoint to a PID. So it's hard to
imagine an ALTO server that couldn't determine the PID for an IP address.

As for the default cost type, how about this: If the client doesn't specify
a Cost Type, and if that uri only supports one type, return that type. If
the uri supports more than one type, default to "routingcost". And if
"routingcost" isn't one of the types supported by that uri, return the
"MISSING FIELD" error.

BTW, thanks for the complement!

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Tue, March 19, 2013 16:20
To:  Wendy Roome <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [alto] minor inconsistency in draft 14

> Related question: Do we really need to require that all ALTO servers support a
> Cost Type named 'routingcost'? Suppose I have an ALTO server that provides a
> custom Cost Type to a select group of authorized clients. None of those
> client will ever use?

My understanding of the decision that an ALTO Server must provide
"routingcost" is also related with the design of allowing default. For
example, CostMapCapability can be empty and implies "routingcost". One
analogy one might or may not like is that TLS (RFC5246) defines that
TLS_RSA_WITH_AES_128_CBC_SHA is mandatory. But we can imagine that there is
no mandatory and hence allows TLS negotiation to fail. But I agree with you
that removing the so far MUST supported cost type and endpoint property will
not impact interop in the sense that the protocol still works, and a
conforming ALTO Server may just not returning any information. What do you
and others think?

Richard

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 19 Mar 2013 22:10:40 +0100

> My understanding of the decision that an ALTO Server must 
> provide "routingcost" is also related with the design of 
> allowing default. For example, CostMapCapability can be empty 
> and implies "routingcost". One analogy one might or may not 
> like is that TLS (RFC5246) defines that 
> TLS_RSA_WITH_AES_128_CBC_SHA is mandatory. But we can imagine 
> that there is no mandatory and hence allows TLS negotiation 
> to fail. But I agree with you that removing the so far MUST 
> supported cost type and endpoint property will not impact 
> interop in the sense that the protocol still works, and a 
> conforming ALTO Server may just not returning any 
> information. What do you and others think?

Another option would be to replace the term "routingcost" by something that does not specifically refer to a way how to determine that cost. For instance, "defaultcost"?

But I don't have a strong preference here.

Michael

---

From: Richard Alimi <[email-masked]>
Date: Thu, 21 Mar 2013 00:38:00 -0700

> 'numerical' OR 'ordinal' mode, not that a server must support both!

I agree.  9.1.2 should be brought in sync with the requirement we stated in
5.1.2 which states:

 An ALTO Server MUST support at least one of 'numerical' and 'ordinal'
 costs.

Actually, in 9.1.2 how about we simply state:

'routingcost' Cost Type.

[ For the moment I'm assuming that we keep the 'routingcost' Cost Type ]

> that no client will ever use? So I'd be happy to drop that requirement
> altogether.
>

---

From: Richard Alimi <[email-masked]>
Date: Thu, 21 Mar 2013 00:43:57 -0700

On Tue, Mar 19, 2013 at 1:44 PM, Wendy Roome <[email-masked]>wrote:

> As for the default cost type, how about this: If the client doesn't
> specify a Cost Type, and if that uri only supports one type, return that
> type. If the uri supports more than one type, default to "routingcost". And
> if "routingcost" isn't one of the types supported by that uri, return the
> "MISSING FIELD" error.
>

I don't have a strong feeling about this.  On one hand, I don't see the
need to add this, but on the other hand we already do a similar thing with
the list of source and destination PIDs (we assume defaults if they aren't
specified).

> analogy one might or may not like is that TLS (RFC5246) defines that TLS_RSA_WITH_AES_128_CBC_SHA

---

From: Richard Alimi <[email-masked]>
Date: Thu, 21 Mar 2013 00:47:27 -0700

On Tue, Mar 19, 2013 at 2:10 PM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> Another option would be to replace the term "routingcost" by something
> that does not specifically refer to a way how to determine that cost. For
> instance, "defaultcost"?
>

I slightly prefer 'routingcost' because what we're actually conveying is
the cost from the provider's point of view for routing traffic from a
source to a destination.  Of course, we've intentionally left the actual
metric only loosely specified.  'defaultcost' (to me, anyways) seems to
convey something like "I'm going to tell you the cost is X because I don't
know any better".

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 26 Mar 2013 16:27:44 +0000

De : [email-masked] [mailto:[email-masked]] De la part de Richard Alimi
Envoyé : jeudi 21 mars 2013 08:47
À : Scharf, Michael (Michael)
Cc : ROOME, Wendy D (Wendy); [email-masked]
Objet : Re: [alto] minor inconsistency in draft 14

I slightly prefer 'routingcost' because what we're actually conveying is the cost from the provider's point of view for routing traffic from a source to a destination.  Of course, we've intentionally left the actual metric only loosely specified.  'defaultcost' (to me, anyways) seems to convey something like "I'm going to tell you the cost is X because I don't know any better".

[     ] Hi,
[     ] Although the Cost (Map or Endpoint) is not a MUST, whenever cost values are provided, having at least one common cost type would allow reliable information retrieval from multiple ALTO Servers as well as better inter ALTO Server communication.

The 'routingcost' is a simple and generic way to tell "this way or endpoint for application traffic is better" or has this cost, with cost having a commonly understood meaning. Even with heterogeneous value ranges or accuracy levels throughout ALTO Servers or restriction to ordinal in some of them, knowing that the cost is generic and quantizes preference allows every ALTO Client to understand the values. And this in turn allows each Client to define its composition rules in order to infer its needed information.

In other words, I understand that a client should be able to live with what it gets and use consistent and intelligent rules to efficiently use it. On the other hand it would hugely benefit from the possibility of using information that may be gathered from several servers to optimize applications running across several (ALTO) domains, thus covered by different ALTO servers, such as content delivery or virtualized applications, involving data centers distributed in multiple ALTO domains. Another case is when a client would like to aggregate ALTO information provided at different levels of details by cascaded ALTO Servers.

Sabine

Michael
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto