Subject: [alto] ALTO Interop test in July

From: Wendy Roome <[email-masked]>
Date: Thu, 04 Jun 2015 15:34:53 -0400

To get the ball rolling on an ALTO interop test, I have submitted
draft-roome-interop-ietf93-00. Please, please, someone else please read it.

https://datatracker.ietf.org/doc/draft-roome-interop-ietf93/

It specifies quite a lot: two network maps, two cost metrics, and a custom
property. However, only *required* resources are the default network map,
one routingcost cost map (numerical or ordinal), and an EPS for the
default network's pid property. Everything else is optional.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 5 Jun 2015 12:36:19 -0400

Wendy,

Great work! Here are some early comments.

- Page 4: "If a server provides a numerical-mode cost map, ..." => "If a
server provides a numerical-mode cost map for the "routingcost" metric.,"
The reason is to make clear that Figure 2 is for the only routingcost
metric only.

- Page 4: "If a server provides an ordinal-mode cost map, the server may
use whatever values it wants, provided the ordinal values preserve the
order of the numerical values. "

   I see that there are duplicate values in Figure 2 (e.g., 75.0). A
question is to define the meaning of "preserve", as RFC7285 does not define
it, I believe. Here is an attempt in defining it precisely. First, for
non-equal case, we should have num[x] > num[y] => ord[x] < ord[y]. An issue
is if we define the case for num equal, e.g., num[x] == num[y] => ord[x] ==
ord[y]. I assume that we have it?

- Page 4: Can a server provide both a numerical and an ordinal cost map?

- Page 5: "a numerical-mode cost map MUST use these values, and an
ordinal-mode cost map may use any values consistent with this ordering."
  Page 4 used the word preserve and here it is consistent. How about the
draft uses one word, say consistent, and the draft defines the meaning
consistent as above?

Similar small consistent use for the alternate map.

- When I read Page 7: "A server MAY provide whatever additional resources
it desires, as long as they are consistent with the network maps, cost maps
and endpoint properties defined in Section 2. ", a question of 3 network
maps came to mind. I liked that you clarified on page 8.

- Page 7: "Cost Map resources for the "routingcost" and/or "hopcount"
metrics, in either "numerical" or "ordinal" modes, using the values defined
above." How about clarify that it is for the alternate network map?

- Page 9: "However, each client MUST be able to verify the default network
map and the associated "routingcost" cost map." Does this handle the case
of both modes, if provided?

Overall, a great design, and I am looking forward to seeing the ECS test
cases as well :-)

Richard

On Thu, Jun 4, 2015 at 3:34 PM, Wendy Roome <[email-masked]>
wrote:

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Droome-2Dinterop-2Dietf93_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bqET3V84WZLd20R9K89VK4Hm0aQzcWdZF7f9JgZZ42Q&s=xMKyCEnwH7PvUBYG16p4mpynr8QXYjHQakn4U8R_mK4&e=
>
> _______________________________________________
> alto mailing list
> [email-masked]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bqET3V84WZLd20R9K89VK4Hm0aQzcWdZF7f9JgZZ42Q&s=0CuB6ojyak7XxLmBQ2liCZzG5JiQaSfxqSPnBloJLX4&e=

---

From: <[email-masked]>
Date: Fri, 5 Jun 2015 17:11:42 +0000 (UTC)

Wendy, 
          Thanks for your great work!          Answering the question from Richard, Page 4: Can a sever provide both a numerical and an ordinal cost map?          According to RFC7285, an ALTO sever MUST support at least one of the following modes: numerical and ordinal. Which should means, an ALTO sever can provide both a numerical and an ordinal cost map in some cases. In this case, no matter the client desires a numerical or an ordinal mode, the sever can meet its demand.

Best,
Haoran

    _____________________________
From: "Y. Richard Yang" <[email-masked]>
Sent: 星期六, 六月 6, 2015 12:39 上午
Subject: Re: [alto] ALTO Interop test in July
To: Wendy Roome <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

       Wendy,       
          Great work! Here are some early comments.           
          - Page 4: "If a server provides a numerical-mode cost map, ..." => "If a server provides a numerical-mode cost map for the "routingcost" metric.," The reason is to make clear that Figure 2 is for the only routingcost metric only.          
          - Page 4: "If a server provides an ordinal-mode cost map, the server may use whatever values it wants, provided the ordinal values preserve the order of the numerical values. "          
             I see that there are duplicate values in Figure 2 (e.g., 75.0). A question is to define the meaning of "preserve", as RFC7285 does not define it, I believe. Here is an attempt in defining it precisely. First, for non-equal case, we should have num[x] > num[y] => ord[x] < ord[y]. An issue is if we define the case for num equal, e.g., num[x] == num[y] => ord[x] == ord[y]. I assume that we have it?          
          - Page 4: Can a server provide both a numerical and an ordinal cost map?          
          - Page 5: "a numerical-mode cost map MUST use these values, and an ordinal-mode cost map may use any values consistent with this ordering."     
  Page 4 used the word preserve and here it is consistent. How about the draft uses one word, say consistent, and the draft defines the meaning consistent as above?          
          Similar small consistent use for the alternate map.          
          - When I read Page 7: "A server MAY provide whatever additional resources it desires, as long as they are consistent with the network maps, cost maps and endpoint properties defined in Section 2. ", a question of 3 network maps came to mind. I liked that you clarified on page 8.          
          - Page 7: "Cost Map resources for the "routingcost" and/or "hopcount" metrics, in either "numerical" or "ordinal" modes, using the values defined above." How about clarify that it is for the alternate network map?          
          - Page 9: "However, each client MUST be able to verify the default network map and the associated "routingcost" cost map." Does this handle the case of both modes, if provided?          
          Overall, a great design, and I am looking forward to seeing the ECS test cases as well :-)          
          Richard                      

         On Thu, Jun 4, 2015 at 3:34 PM, Wendy Roome      <[email-masked]> wrote:     
           To get the ball rolling on an ALTO interop test, I have submitted      
 draft-roome-interop-ietf93-00. Please, please, someone else please read it.      

       
         - Wendy Roome

---

From: Wendy Roome <[email-masked]>
Date: Fri, 05 Jun 2015 16:08:47 -0400

I naively assumed that it was easy to define & detect order conservation.
Ha!

So how about this procedure:

First, for all (src,dst) pairs, ord(src,dst) exists iff num(src,dst) exists.

Next consider the array of triples <num(src,dst), src, dst> for all defined
numerical costs. Sort this array by cost.

Then do the same for the array of triples <ord(src,dst), src, dst>.

Finally compare the two arrays. The src,dst entries must be in the same
order, except for sequences where the numerical cost is the same, in which
case they can be in any order within that sequence.

BTW, that allows a server to assign unique ordinal values to break ties in
numerical values.

- Wendy Roome

Date:  Fri, June 5, 2015 at 12:36

 I see that there are duplicate values in Figure 2 (e.g., 75.0). A question
is to define the meaning of "preserve", as RFC7285 does not define it, I
believe. Here is an attempt in defining it precisely. First, for non-equal
case, we should have num[x] > num[y] => ord[x] < ord[y]. An issue is if we
define the case for num equal, e.g., num[x] == num[y] => ord[x] == ord[y]. I
assume that we have it?

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 8 Jun 2015 08:08:46 -0400

This procedure looks good to me. The server may assign the same (need
client tie breaker) or different (server tie breaker) ordinal values. Works
for me!

Richard

On Saturday, June 6, 2015, Wendy Roome <[email-masked]> wrote:

> Next consider the array of triples <num(src,dst), src, dst> for all
> defined numerical costs. Sort this array by cost.
>
> From: "Y. Richard Yang" <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> To: Wendy Roome <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> Cc: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>

-- 
Richard

---

From: [email-masked]
Date: Thu, 11 Jun 2015 02:10:08 +0000 (UTC)

Add answer to the question from Richard, Page 9, Does this handle the case of both modes, if provided?
Yes. The ALTO client MUST be cognizant of whether the desired cost mode is supported by ALTO sever or not. If an ALTO sever provides both modes or the mode desired by ALTO client, the client will receive what it exactly wants. However when a client desiring numerical cost unfortunately encounters an ALTO sever with only ordinal cost available, it will adjust its behaviors, like assuming to find another sever or give up the request for numerical cost and return the ordinal cost or return an error(from my unseasoned conjecture ); a client desiring ordinal cost MAY transfer the numerical cost into ordinal through ranking algorithm if only numerical cost is supported.
Haoran

On Fri, Jun 5, 2015 at 10:12 AM -0700, <[email-masked]> wrote:

Wendy, 

Best,
Haoran

       Wendy,       

       

         - Wendy Roome