Subject: Re: [alto] Authoritative status of costs

From: Bill Roome <[email-masked]>
Date: Mon, 31 Oct 2011 09:49:03 -0400

I don't have complaints, but I do have an observation: A client cannot
distinguish between "pids are invalid" and "pids are valid but this server
doesn't have reliable cost data for that pair."

Does that bother anyone?

	- Bill Roome

On 10/27/2011 15:00, "[email-masked]" <[email-masked]> wrote:

>Date: Thu, 27 Oct 2011 10:22:16 -0700
>From: Richard Alimi <[email-masked]>
>Subject: Re: [alto] Authoritative status of costs
>
>On Thu, Oct 27, 2011 at 9:22 AM, Vijay K. Gurbani <[email-masked]>
>wrote:
>>On 10/25/2011 05:30 PM, Richard Alimi wrote:
>>>
>>>The intent would be that it just isn't there. So, something like this:
>>>
>>>? ?{
>>>? ? ?"meta" : {},
>>>? ? ?"data" : {
>>>? ? ? ?"cost-mode" : "numerical",
>>>? ? ? ?"cost-type" : "routingcost",
>>>? ? ? ?"map-vtag" ?: "1266506139",
>>>? ? ? ?"map" : {
>>>? ? ? ? ?"PID1": { "PID1": 1, ?"PID2": 5 },
>>>? ? ? ? ?"PID2": { "PID1": 5, ?"PID2": 1, ?"PID3": 15 },
>>>? ? ? ? ?"PID3": { "PID2": 15, "PID3": 1 ?}
>>>? ? ? ?}
>>>? ? ?}
>>>? ?}
>>
>>Rich: The above is fine when the answer contains multiple PIDs
>>and one PID is omitted from the response.
>>
>>However, consider a query involving a singleton destination PID, i.e.,
>>what happens if a client asked for the cost between a source PID
>>representing a transit network (say PID1) to a destination
>>PID representing the Internet (say PID5)?
>>
>>Is the right answer:
>>
>>(a) "PID1:" {}
>>(b) "PID1:" { "PID5" : NaN }
>>
>>where "NaN" is essentially an infinite cost (replace NaN by your
>>favorite token).
>
>I think I would opt for (a), since it should convey the same
>information and avoids us having to define a special identifier.
>Along the same lines, I could imagine just omitting the entire entry
>for the source PID in this case too.  The end result is the same - the
>entry just doesn't exist when reconstructing the matrix.
>
>To keep the specification simple, perhaps it would be more clear to
>state it in the affirmative -- something to the effect of "the ALTO
>Server need only include source/destination pairs that exist" (and we
>can ensure that the existing rules are in line with this).  Then ALTO
>Clients can just iterate through the returned JSON and fill in the
>entries in the matrix that they find (and just not complain about
>missing ones). The actual syntax of the JSON matters less then -
>servers could either omit the entire row for the source PID,  or have
>the row empty, whatever.
>
>Any complaints with that?
>Rich

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 31 Oct 2011 15:13:21 +0100

Hi,

yes, I think it is necessary to distiguish between both cases. For some 
costs, information may be unavailable on some source/dest pairs where as 
it is for others. So I propose a specific tag for unavailable 
information such as "NAv" for "not available" or whatever other tag 
signifying "not available".

Sabine

Bill Roome a écrit :
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>   

-- 

---------------------------------------------------------
Sabine RANDRIAMASY
Alcatel-Lucent Bell Labs France 
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE

E-MAIL : [email-masked]
TEL: +33 (0)1 30 77 27 45 
         (On Net) 2 103 27 45
---------------------------------------------------------

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 31 Oct 2011 14:19:53 +0000

> doesn't have reliable cost data for that pair."

Can this not be achieved by looking at the network map - if the pair of PIDs are in the version of the network map indicated by map-vtag but not in the cost map it is a valid PID but the server doesn't have reliable cost data for that pair.

If the pair of PIDs are not in the version of the network map indicated by map-vtag they're not valid.

?

Ben

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 31 Oct 2011 09:51:38 -0500

On 10/31/2011 08:49 AM, Bill Roome wrote:
> I don't have complaints, but I do have an observation: A client
> cannot distinguish between "pids are invalid" and "pids are valid but
> this server doesn't have reliable cost data for that pair."
>
> Does that bother anyone?

The problem, at least as I understand it, is not predicated on a PID
being valid or invalid.

The validity (or lack thereof) of the PIDs is a function on whether
they appear in the network map and cost map.  Presumably, if they
appear there, the PIDs are valid.

However, the greater question is this: does the ALTO provider know
authoritatively the cost between all PIDs?  That is the issue
under discussion.

Clearly, the ALTO provider cannot know the costs between all PIDs.
Again, consider our sample topology we used for the bakeoff [1].  In
that topology, the ALTO provider had authoritative costs for

mypid{1,2,3} -> mypid{1,2,3} +
                 peeringpid{1,2} +
                 transitpid{1,2} +
                 defaultpid

However, asking the ALTO server to provide a cost between defaultpid
(Internet) and transitpid1 is useless, since at best, the server will
be indulging in a guess (and at worst, it'd be lying).

[1] http://www.ietf.org/mail-archive/web/alto/current/msg01147.html

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Richard Alimi <[email-masked]>
Date: Mon, 31 Oct 2011 08:27:05 -0700

> appear there, the PIDs are valid.

I agree with Vijay and Ben that looking at the Network Map should be
sufficient (presumably the ALTO Client already has it in order to
interpret the Cost Map).

> be indulging in a guess (and at worst, it'd be lying).

I agree - so, just to be sure I'm understanding correctly, do you
think that letting the Cost Map be a sparse matrix solves this issue?
Or do you think there is something else that should be done?

Thanks,
Rich

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 31 Oct 2011 10:41:42 -0500

On 10/31/2011 10:27 AM, Richard Alimi wrote:
> think that letting the Cost Map be a sparse matrix solves this
> issue? Or do you think there is something else that should be done?

Rich: Unless Bill has a concern that I fail to see, I will remain
blissfully ignorant and happy with the resolution we reached last week
on this [1].

Thanks,

http://www.ietf.org/mail-archive/web/alto/current/msg01268.html

- vijay

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 31 Oct 2011 12:29:47 -0400

On 10/31/11 11:27 AM, Richard Alimi wrote:
> On Mon, Oct 31, 2011 at 7:51 AM, Vijay K. Gurbani<[email-masked]>  wrote:
In a "typical" understanding, a sparse matrix means that the missing
elements have a value of "0" and hence do not need to be explicitly
represented. In our context, then we may need to make clear the
semantics that  the cost is unknown or not revealed. This can be
important in that a client may use a sparse matrix library (database)
which may use the "standard"  interpretation and then generate some
wrong results.

Thanks.

Richard

---

From: Richard Alimi <[email-masked]>
Date: Mon, 31 Oct 2011 09:51:53 -0700

> which may use the "standard"  interpretation and then generate some

Yes - good point. The actual language in the draft (to be posted
today) is along the lines of omitting entries that are not defined by
the ALTO server -- "sparse" is not mentioned at all.  I should have
been more specific in my reply above.

Rich