On 10/31/11 11:27 AM, Richard Alimi wrote:
On Mon, Oct 31, 2011 at 7:51 AM, Vijay K. Gurbani<[email protected]>  wrote:
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.
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).

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).
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?
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


Thanks,
Rich

[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 protected]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

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

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

Reply via email to