Subject: Re: [alto] Are ALTO costs always End to End?

From: Bill Roome <[email-masked]>
Date: Wed, 01 Feb 2012 10:07:58 -0500

I guess I'm also late to this discussion. But I always assumed:

1. The ALTO costs are end-to-end. Always.

2. An ALTO server is expected to give the costs between *every* pair of
PIDs. It can omit a cost only if it cannot determine that cost at all.

3. You cannot infer a topology from the 'holes' in the cost map.

4. If it were possible to calculate the missing costs by using SPF (or
whatever) on the other costs, then the ALTO server should do that! The
ALTO server shouldn't push that task onto the clients.

	- Bill Roome

>On Mon, Jan 30, 2012 at 9:03 AM, Ben Niven-Jenkins
><[email-masked]> wrote:
>>Colleagues,
>>
>>In the current specification of ALTO, are costs always End to End?
>>
>>What I mean by that is when looking at ALTO cost maps is it possible to
>>safely assume that of there is a cost between PIDX & PID Y and a cost
>>between PIDY & PIDZ then the cost between PIDX & PIDZ can be calculated
>>as cost(PIDX,PIDY)+cost(PIDY,PIDZ)? [If this assumption does hold, it is
>>obviously not applicable to ordinal cost types].
>>
>>I suspect the answer is no, but I wanted to check what the definitive
>>answer is.
>>
>>
>>For example if a cost map contains:
>>
>>? "map" : {
>>? ? "PID1": { "PID2": 1 },
>>? ? "PID2": { "PID1": 1, "PID3": 2 },
>>? ? "PID3": { "PID2": 2 }
>>
>>Can one assume that the cost between PID1 & PID3 is 3 (PID1->PID2 +
>>PID2->PID3)?
>>
>>How about if the cost map contains:
>>
>>? "map" : {
>>? ? "PID1": { "PID2": 1, "PID3": 3 },
>>? ? "PID2": { "PID1": 1, "PID3": 2 },
>>? ? "PID3": { "PID2": 2, "PID1": 3 }
>>
>>Can one assume PID2 is on a path between PID1 & PID3?
>>
>>Thanks
>>Ben
>>
>>_______________________________________________
>>alto mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/alto
>

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 1 Feb 2012 17:50:33 +0100

Bill, all,

> 1. The ALTO costs are end-to-end. Always.

ack.

> PIDs. It can omit a cost only if it cannot determine that cost at all.

My assumption was different: I'd say that the protocol specification
must allow the ALTO server to return a full NxN matrix indicating all
end-to-end costs between all N PIDs (maybe even different costs in the
two directions between two given PIDs).  

But I also assume that in a real deployment we will rather have a very
sparse matrix, with the default value "I don't know / I am not allowed
to tell". I could even imagine that my ISP would operate an ALTO server,
which gives my hosts only an 1xN vector, which tells me how "expensive"
it is for me to reach all possible destinations in the Internet.

> 3. You cannot infer a topology from the 'holes' in the cost map.

ack.

> ALTO server shouldn't push that task onto the clients.

ack.

Btw: which application needs to know the topology? If I remember
correctly once upon a time our primary goal was assisting peer selection
(i.e., I know that I can get the desired resource form IP address A, B,
or C, so please ALTO service tell me which address I should give a
connect()-try first). To that end, the 1xN vector would be enough.

  -- Sebastian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 01 Feb 2012 11:00:07 -0600

On 02/01/2012 10:50 AM, Sebastian Kiesel wrote:
> correctly once upon a time our primary goal was assisting peer
> selection (i.e., I know that I can get the desired resource form IP
> address A, B, or C, so please ALTO service tell me which address I
> should give a connect()-try first). To that end, the 1xN vector would
> be enough.

Sebastian: There are other emerging uses of ALTO being discussed.  CDNs
and data centers are the two widely cited ones.  See [1] for more on
this.

[1] http://tools.ietf.org/html/draft-marocco-alto-next-00

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: stefano previdi <[email-masked]>
Date: Wed, 1 Feb 2012 18:04:23 +0100

On Feb 1, 2012, at 5:50 PM, Sebastian Kiesel wrote:

> My assumption was different:

the differences in assumptions tend to demonstrate we would need 
to be more precise on the semantic.

> I'd say that the protocol specification
> Btw: which application needs to know the topology?

E.g.: a CDN may want to operate autonomously with maps rather than 
using ECS. Not that I'm advocating this but it all depends on where 
do you want to place the complexity of topology hint: inside ALTO 
server (ECS like of approach) or inside the application (Maps that 
allows you to compute paths/trees).

> If I remember

The CDN is not substantially different in its logic.

s.

---

From: Richard Alimi <[email-masked]>
Date: Wed, 1 Feb 2012 09:33:03 -0800

> it is for me to reach all possible destinations in the Internet.

The current interpretation is: The ALTO protocol makes no statement on
what entries in the cost map must or must not be filled in.  It is
assumed that if an entry is not there, the ALTO server did not wish to
make a statement on the cost (either because it didn't know, or
because it didn't want to tell you).  IIRC, Vijay proposed an
extension that would provide some more detail there, which was to
indicate how certain the ALTO Server was in its answer.

Certainly let us know if you think the protocol draft needs to make
this clearer.

> connect()-try first). To that end, the 1xN vector would be enough.

In the CDN world (and other non-P2P cases) in some deployements there
may be additional trust between the ALTO Server and ALTO Client.  That
opens up the possibility of exposing more fine-grained information,
including something resembling the topology of the network.  Yes, it
is straying from the original context of P2P - but the charter now is
open to CDN use cases too (and there is a mailing list for possible
ALTO extensions which may or may not need rechartering :) ).

Rich

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 1 Feb 2012 23:49:01 +0100

Stefano, all,

On Wed, Feb 01, 2012 at 06:04:23PM +0100, stefano previdi wrote:
> using ECS. 

Downloading a map and operating autonomously with it is one thing,
trying to derive missing fields in the map/matrix by some kind
of triangulation is another thing.

> Not that I'm advocating this but it all depends on where 

Maybe part of the confusion is that we need a clear definition what
end-to-end is. I'd say that ALTO should always give the end-to-end
costs for sending IP packets between two endpoints using "normal"
IP-layer forwarding.  Based on that knowledge one can of course
build efficient paths/trees that involve proxies, media relays
or the like (i.e., this higher-layer path is a concatenation of
several IP-layer end-to-end paths). Does this make sense?

> The CDN is not substantially different in its logic.

this is my feeling as well, that's why I was asking.

   Thanks, 
   Sebastian

---

From: stefano previdi <[email-masked]>
Date: Thu, 2 Feb 2012 07:45:45 +0100

> several IP-layer end-to-end paths). Does this make sense?

why do you believe alto should only deliver end-to-end costs ?
In a slightly different context it could even deliver a path.

> this is my feeling as well, that's why I was asking.

there are case other than p2p or cdn. Think about cloud 
networking, data center resources advertisement and distribution, 
DNS optimizations, Demand Engineering, ...

If we want to think about extending alto to other (non p2p) case, 
these are interesting examples.

s.

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 2 Feb 2012 13:05:10 +0100

Stefano,

> In a slightly different context it could even deliver a path.

what exactly do you mean by "deliver a path"?

And would that require that a host and/or the ALTO server can influence
how packets travel through the network (source routing, take actively
part in OSPF/BGP/... , etc)?

> these are interesting examples.

sure. extending the scope of ALTO makes sense.

but what is different to the P2P use case? One difference is that
- as Rich pointed out - due to other trust relationships we may be able
to expose more information. OK, but how do we use it?  Is this more than
just shifting complexity?

Thanks,
Sebastian

---

From: stefano previdi <[email-masked]>
Date: Thu, 2 Feb 2012 14:55:05 +0100

> part in OSPF/BGP/... , etc)?

well, I don't go that far. However, an application may ask for network 
guidance and get some preferences (rankings) computed by an alto server 
that goes along with some form of path description associated to that 
preference.

> but what is different to the P2P use case?

p2p and cdn have some similarities but there are a few other 
substantially different cases.

s.

> One difference is that

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 2 Feb 2012 17:35:53 +0100

> that goes along with some form of path description associated to that 

and what would the application do with that additional information?

if it is used for re-calculating ALTO's preferences, why can't that
be done in the ALTO server in the first place?

Thanks,
Sebastian

---

From: stefano previdi <[email-masked]>
Date: Thu, 2 Feb 2012 17:38:57 +0100

> and what would the application do with that additional information?

the application may make a more accurate choice between two 
endpoint if it known also the characteristics of the paths 
to these endpoints.

s.