Subject: Re: [alto] Authoritative status of costs

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

Apologies for being late to the party :) Circling back to prepare for
a round of updates to the draft, and a few responses and a proposed
way to move forward.

On Wed, Aug 31, 2011 at 11:23 AM, Vijay K. Gurbani
<[email-masked]> wrote:
> <As individual>
>
> Bill Roome says:
>>
>> Basically, I think adding a "quality" modifier to the cost -- be it
>> a binary "authoritative vs non-" flag, or a continuous "reliablity"
>> value -- is an exercise in futility.
>>
>> Why? At best, the cost reported by an ALTO server is an indication of
>> the recent performance of the network. [...]
>
> I think this depends on the type of cost being reported.
>
> Clearly, if the cost is derived from some monetary agreements
> between transit partners or some reciprocal agreement between
> peering partners, then the ISP operating that ALTO server is
> in the best position to act as an authority for the cost metric.
>
> As such, I don't see why we would not indicate this.
>
> On the other hand, if the cost is derived from some characteristics
> of the network itself (instantaneous queue length at routers,
> percent of network link in use, etc.) I agree that reporting
> this has diminishing value, irrespective of whether or not
> the ISP is authoritative or not.
>
> A third-party ALTO server or even an ALTO server being operated
> by an ISP will not have much knowledge about the topology and
> any costs associated with the parts of the network it does not
> "own".
>
> Therefore, we need to make sure that the protocol can answer
> a routing queries of the type we saw during the interoperability
> event: wanting to know the routing cost from of a peer in a
> peering network to another peer in a transit network.  In such
> a case, both the ISP ALTO server and a third party ALTO server
> are indulging in a guess.  And if so, this should be reflected
> in the response.
>
> My personal feeling is that we should not preclude an authoritative
> qualifier on the response.  We can make it optional and leave
> it to the server to insert one.

>From this discussion it sounds like the general agreement is that a
continuous value is probably not a good way to go (cool - I agree with
that decision :) ).

My personal opinion is that I could imagine where an ALTO Server might
be able to venture a guess (with the intention of being helpful) from
external sources that it has that are not immediately accessible to an
ALTO Client (meaning the ALTO Client might not be able to arrive at
that conclusion).

Thus, one proposal would be the following:
(1) An ALTO Server determine a cost from its own perspective (note
that I'm purposefully not saying that it knows exactly what the cost
is).  In this case, it puts an entry in the cost matrix just like
today.
(2) ALTO Server might not have any idea at all (in which case the
entry is simply omitted from the matrix -- this can be a big
efficiency win if there are many PIDs with addresses outside of an
ISP's administrative domain).  Regardless of the authoritative /
non-authoritative bit, I strongly believe this should be done anyways.
(3) An ALTO Server ventures a guess to help the client.  These can be
marked with an extra 'non-authoritative' bit in the cost matrix.  Note
that this inverts Vijay's proposal of marking things as authoritative;
I tend to think that authoritative should be the default, and
non-authoritative be the exception since the protocol document is
already clear that "An ALTO Server conveys the network information
from the perspective of a network region."

>From the client side, a simple implementation might be to just ignore
anything that is non-authoritative if there is any other information
available at all (of course this is left to implementation-defined
policy, though).  Additionally, (3) could be done as an extension if
we wanted to table this for later.

Thoughts?

Thanks,
Rich

>
> 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/
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 25 Oct 2011 15:31:08 -0500

In reference to the choices Richard presented in
http://www.ietf.org/mail-archive/web/alto/current/msg01253.html

> Thoughts?

(2) or (3).  I can live with either.

I like that you propose that we do (2) and shelf (3) for an
extension later.  That way, at the very least the ALTO server
is not reporting costs for which it is not authoritative.

To be sure, we should state what form the "entry is simply omitted
from the matrix" takes on the wire.  That is, blank, "-", N/A, NaN,
or something else.

Thanks,

- vijay

---

From: Richard Alimi <[email-masked]>
Date: Tue, 25 Oct 2011 15:30:00 -0700

> from the matrix" takes on the wire.  That is, blank, "-", N/A, NaN,

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  }
       }
     }
   }

Thanks,
Rich

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Oct 2011 11:22:10 -0500

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

Thanks,

- vijay

---

From: Richard Alimi <[email-masked]>
Date: Thu, 27 Oct 2011 10:22:16 -0700

> where "NaN" is essentially an infinite cost (replace NaN by your

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: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Oct 2011 12:47:48 -0500

On 10/27/2011 12:22 PM, Richard Alimi wrote:
[...]
> Any complaints with that?

Rich: Works for me.

Thanks,

- vijay

---

From: Sabine Randriamasy <[email-masked]>
Date: Fri, 28 Oct 2011 15:21:27 +0200

Hi all,

As this way unambiguously shows that the source/destination pair exists 
in the network map but that the requested Cost is not available for this 
pair, it's ok with me as well.

As for the the possible extension (3), with non-authoritative cost 
information, the presence of non-authoritative information could be 
indicated in a global way in a cost attribute called for example 
reliability ratio, eg "nb of authoritative S/D costs/nb of S/D costs or 
something more fancy like "sum of S/D reliability %/nb of S/D pairs" or 
whatever preferred indicator.
An ALTO Client reading this may decide to GET the related Cost Map or 
not, and possibly save an ALTO transaction.

Sabine

-- 

---------------------------------------------------------
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
---------------------------------------------------------