Subject: Re: [alto] alto Digest, Vol 57, Issue 23

From: Wendy Roome <[email-masked]>
Date: Mon, 15 Jul 2013 10:59:56 -0400

I agree that if an IRD has multiple network maps, [5] is a good way to do
it.

But that doesn't resolve the problem of how a client decides which of the
several network maps to use.  Right now, I see two approaches:

a. The client retrieves all network maps and analyzes their PID/CIDR
structures to determine which map has more detail in the area(s) of
interest to the client.

b. Something outside the protocol tells the client which id to use -- as
well as which IRD to use.

Theoretically (a) is nice, but how would a client do that? And do we
really expect clients do that much work?

	- Wendy Roome

On 07/14/2013 15:00, "[email-masked]" <[email-masked]> wrote:

>Message: 1
>Date: Sun, 14 Jul 2013 09:13:57 -0700
>From: Richard Alimi <[email-masked]>
>To: "Vijay K. Gurbani" <[email-masked]>
>Cc: alto <[email-masked]>
>Subject: Re: [alto] Chair summary: Status on ALTO protocol document
>Message-ID:
>	<[email-masked]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi All,
>
>We have posted a new version of the protocol draft.  We believe that this
>should address all outstanding issues that Vijay has listed here.
>
>Thanks,
>Rich
>
>On Wed, Jul 10, 2013 at 12:16 PM, Vijay K. Gurbani
><[email-masked]>wrote:
>
>>
>>    - The cost map dependency thread [4] seem to have been
>>      concluded as well by Richard Y.'s summary of the discussion [5].

---

From: Wendy Roome <[email-masked]>
Date: Mon, 15 Jul 2013 11:32:53 -0400

Here's another unresolved question about [5]. Suppose a server provides
full and filtered network map services for the same network map. Does the
server use the same id for both IRD entries?

If so, fine.

But "id" usually means "unique id", so if they're not unique ids for each
service, the document should say that.

This is also a problem for cost map services. Suppose the server provides
full and filtered cost map services for "routingcost". Do those services
have the same id?

It's tempting to say yes -- that the id refers to the underlying data, not
the particular viewport that returns it. Unfortunately that doesn't work.
Suppose a server provides full-map services for "routingcost" and
"hopcount" metrics. I think we'd agree those services should have
different ids. Now suppose the server offers a filter cost map service
that can return either metric. What's the id for that service?

So if we want an "id" for each service, I think it has to be a unique id.
Which in turn means that a cost-map service's "uses" field would have to
list the ids of all the network-map services that return that map.

	- Wendy Roome

On 07/14/2013 15:00, "[email-masked]" <[email-masked]> wrote:

>>Folks: As you are aware, Enrico and my aim has been to get the ALTO
>>protocol document out of the WG to the IESG as soon as possible.
>>
>>We will like to thank the ALTO protocol editor team for taking the
>>time to engage the WG and close open issues in preparation for an
>>upcoming revision (-17) that should be available in the archives on
>>Monday, at the latest.
>>
>>It seems that we are well within the sight of the proverbial light at
>>the end of the tunnel.  While it would have been desirable to be a bit
>>ahead in the process of sending the draft to IESG as we go into Berlin,
>>it is nonetheless gratifying to witness the protocol mature further.
>>Besides the editors, Enrico and I thank all the WG participants that
>>have contributed time  and discussion points to make it so.
>>
>>Post interim meeting on June 20, 2013, all open issues have been
>>resolved.  To wit, these are outlined below.
>>
>>    - Jan's questions on security consideration thread [1] are
>>      adequately answered by Sebastian's response.
>>
>>    - Sebastian's thread on the introduction section [2] appears
>>      to have reached consensus with Richard Y.'s response [3]
>>      that contains suggested text changes.
>>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 16 Jul 2013 12:35:04 -0400

Hi Wendy,

Sorry for the late reply--a big burst of workload in the last few days.
Please see below.

> list the ids of all the network-map services that return that map.
All good comments!

How about we agree on the following guiding principle: every object should
have a unique "id"?

Suppose we can agree on this principle, then let's try to answer the
following questions:

- Q1: what is the unique "id" of a network map?

  A: It is the id+version tag. In this sense, we can say that the id field
in the current draft is the "class" name, and the version tag is the
"instance"/version name.

- Q2: should a filtered map object have the same id as the base map object?

  A: No, as you said. Because they are different objects, unless they have
the same content. For now, let's ignore the
overriding-comparison-use-content-based-comparison part, and we say that
they are different.

 A question that one may raise at this point is whether we want to
represent the relationship between objects (the filtered map and the base
map, in this context). For now, I do not see the need yet, although the
Server can remember it internally. But as you may already see, if we start
the work of multiple layer topologies, this dependency issue will raise
again.

- Q3: What is the meaning of "uses"?

  A: Currently, "uses" only lists the "id", which is only the "class" name,
not including the instance/version. Hence, we may encounter consistency
problem, for example, the cost map object retrieved may be based on one
instance of the "uses" id but the current instance version of "id" is no
longer the version. This case is already raised by you and Rich. I am not
surprised by Rich's answer of using eventual consistency, because I believe
that this is Google's software package management design, but I also heard
that Amazon uses snapshot based design, which works as well. In other
words, one approach is that we extend the API to return a given version
(vtag) of an id, and the uri announced is the base uri that one can
retrieve different versions. For the example in [5]:

  {
        "uri" : "http://alto.example.com/networkmap",
        "media-type" : "application/alto-networkmap+json",
        "id" : "default-networkmap"
      },

It means that one can fetch
http://alto.example.com/networkmap/<tag>

to obtain a given tag of "default-networkmap", if the server still has it.

I thought about making "uses" to list the unique id (i.e., the id and
vtag), just as software packages list not only python but python-3.3.2. But
this then will imply highly dynamic IRD.

- Q4: What is the unique id of a cost map object from a resource that lists
multiple cost types?

  A: Consider the example entry in [5], but with two cost types:

    {
        "uri" : "http://alto.example.com/costmap/num/routingcost",
        "media-type" : "application/alto-costmap+json",
        "id" : "default-costmap",
        "uses": ["default-map"]
        "capabilities" : {
          "cost-type-names" : [ "num-routing", "num-hop" ]
        }
      }

I believe that the right semantics is that the server assigns
"default-costmap" as the id and gives different version for different cost
type.

Do they address all of the questions?

Thanks!

Richard

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Jul 2013 19:52:38 +0100

Richard, Colleagues,

On 16 Jul 2013, at 17:35, Y. Richard Yang wrote:
>   A: Currently, "uses" only lists the "id", which is only the "class" name, not including the instance/version. Hence, we may encounter consistency problem, for example, the cost map object retrieved may be based on one instance of the "uses" id but the current instance version of "id" is no longer the version. This case is already raised by you and Rich. I am not surprised by Rich's answer of using eventual consistency, because I believe that this is Google's software package management design, but I also heard that Amazon uses snapshot based design, which works as well. In other words, one approach is that we extend the API to return a given version (vtag) of an id, and the uri announced is the base uri that one can retrieve different versions. For the example in [5]:
> 
>   {

Why do we need all this complexity? The assumption is the clients are only interested in the latest version of the map, right? (i.e. there are no requirements for ALTO server to store/serve historical versions of maps)

You GET the network map then GET the cost map. If their vtags don't agree you repeat until they do. Apart from fundamental deployment errors/failures the cases where the map versions do not agree are likely to be (relatively) infrequent and transitory.

None of this is any different to before we started discussing "ids" so if it wasn't a problem then, why is it a problem we need to solve now?

Ben

---

From: Wendy Roome <[email-masked]>
Date: Wed, 17 Jul 2013 15:14:51 -0400

I agree that requiring a server to return arbitrary old versions of a
network map is way too much. As Ben said, if the tag in the latest cost
map doesn't match the tag in the network map you've cached, use the id to
find the resource for the full map and fetch it again. If the new tag
doesn't match, back off and try again. And if it still doesn't match, file
a trouble report.

Although that does raise an issue. Suppose you had v0 of the network map,
and you get a cost map based on v1. You re-get the network map, and that
returns v2. Eg, they updated the network map again. In this case you
should reget the costmap until that returns one based on v2.

That implies it would be helpful if tags were ordered, so a client could
tell which one was "newer". Anyone care to take on that can of worms??  Or
should we just resolve it with the pragmatic observation that servers
won't change network maps very often?

	- Wendy Roome

On 07/17/2013 14:52, "Ben Niven-Jenkins" <[email-masked]> wrote:

>>   A: Currently, "uses" only lists the "id", which is only the "class"
>>name, not including the instance/version. Hence, we may encounter
>>consistency problem, for example, the cost map object retrieved may be
>>based on one instance of the "uses" id but the current instance version
>>of "id" is no longer the version. This case is already raised by you and
>>Rich. I am not surprised by Rich's answer of using eventual consistency,
>>because I believe that this is Google's software package management
>>design, but I also heard that Amazon uses snapshot based design, which
>>works as well. In other words, one approach is that we extend the API to
>>return a given version (vtag) of an id, and the uri announced is the
>>base uri that one can retrieve different versions. For the example in
>>[5]:
>> 
>>   {
>Why do we need all this complexity? The assumption is the clients are
>only interested in the latest version of the map, right? (i.e. there are
>no requirements for ALTO server to store/serve historical versions of
>maps)
>
>You GET the network map then GET the cost map. If their vtags don't agree
>you repeat until they do. Apart from fundamental deployment
>errors/failures the cases where the map versions do not agree are likely
>to be (relatively) infrequent and transitory.
>
>None of this is any different to before we started discussing "ids" so if
>it wasn't a problem then, why is it a problem we need to solve now?
>
>Ben
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Jul 2013 20:22:47 +0100

On 17 Jul 2013, at 20:14, Wendy Roome wrote:

> tell which one was "newer". Anyone care to take on that can of worms??

No.

>  Or

I don;t think we need to worry. It's up to the client (based on configured/built-in policy) how to handle that situation, maybe the client caches old versions until it gets some matching pair (as it considers possibly old information to be more useful than no information) and assumes the next matching pair will be later than the current pair it is using.

I think it is fair for a client to assume that repeated requests return the current or later versions of the map. Anything else is outside of the protocol IMO and the desired behaviour will depend on the specific deployment/use case.

Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 17 Jul 2013 17:57:22 -0400

> I don;t think we need to worry. It's up to the client (based on
> configured/built-in policy) how to handle that situation, maybe the client
> caches old versions until it gets some matching pair (as it considers
> possibly old information to be more useful than no information) and assumes
> the next matching pair will be later than the current pair it is using.
>
> I think it is fair for a client to assume that repeated requests return
> the current or later versions of the map. Anything else is outside of the
> protocol IMO and the desired behaviour will depend on the specific
> deployment/use case.

Agree that we do not need to worry about the case and rely on eventual
convergence, for now, considering our use cases.

The dependency between cost map and network map is a simple case of
the more general specification dependency problem. If/when define more
general topology services in ALTO, other consistency such as snapshot
consistency (e.g., supported by allowing retrieval of snapshots) can be
helpful, in particular at modular information representation (divide into
network and cost maps), large scale, more dynamic environments. But it may
be better started some real, specific cases.

Richard

>
> Ben
>
> >
> >       - Wendy Roome
> >
> >
> >
> > On 07/17/2013 14:52, "Ben Niven-Jenkins" <[email-masked]<javascript:;>>
> wrote:
> >
> >> Richard, Colleagues,
> >>