Subject: Re: [alto] Mandatory and optional in alto protocol

From: manbhard <[email-masked]>
Date: Wed, 03 Aug 2011 09:13:09 -0700

Hi,
I agree with the opinion in the meeting that all services should be
optional. A client should use an ALTO server that advertises the service it
needs via the directory service. As mentioned below, downloading full
network and cost maps (and maintaining them) might be a disincentive for
certain clients. Similarly it might be a disincentive to servers run by SPs
who do not want to export their prefix list, and if forced to will do quite
a lot of aggregation which undermines the effectiveness of ALTO.

An approach that would satisfy the client and server constraints above would
be all the services that only provide information (properties, costs) for
that client only.

-Thanks,
Manish.

On 7/26/11 7:59 AM, "Enrico Marocco" <[email-masked]>
wrote:

> Hi all,
> 
> I would like to re-spin the discussion about what features in the
> protocol should be mandatory and what should be optional, offering a
> slightly different view from an application developer perspective.
> 
> Current version of the protocol defines a minimal set of mandatory basic
> features and a bunch of optional services that, with probably the only
> exception of the endpoint cost service, basically constitute optimizations.
> 
> This is certainly the ideal situation from a server implementation and
> deployment point of view, but I'm worried that from an application
> developer point of view it may constitute a disincentive for ALTO
> adoption. The case I have in mind is that of applications intended to
> run in constrained environment -- in smartphones or browser-embedded
> VMs, for instance -- where filtering services would enable optimization
> whilst downloading full network and cost maps, and process them locally,
> would not be an option.
> 
> I don't have a strong opinion about whether the right approach would be
> to put the burden of mandatory implementing the optimization on the
> server, or the burden of being always prepared for the worst case
> scenario on the application -- or possibly something in between -- and
> would appreciate to hear any opinions from the group.

---

From: Robert Varga <[email-masked]>
Date: Wed, 24 Aug 2011 14:34:06 +0200

Hi,

> be all the services that only provide information (properties, costs) for

I second this opinion. In the pre-08 revisions of the draft, when 
services resided on fixed URIs, the notion of mandatory and optional 
services made sense, in that the client could make a blind query as soon 
as it (somehow) got a server address.

With the latest draft, though, the client needs to find a service which 
is able to execute its query. Since current ALTO discovery deals only 
with servers, I think it is safe to assume the result of the discovery 
will be an URI pointing to a server IRD. From the IRD the client needs 
to select the appropriate service, and that service may reside on a 
completely different host than the one which hosts the IRD.

This has the interesting consequence that a 'server' as resolved from 
the discovery service may actually be a set of logical servers, tied 
together by the IRD. Each of them is an ALTO server in the sense they 
speak the protocol, but in my mind that does not mean that each of them 
has to provide a Network Map service -- or anything beyond the service 
advertised by the IRD.

To sum this up: I think an 'RFC-compliant ALTO server' should be 
required to provide the IRD service. All other services should be purely 
optional. That way each deployment site is free to combine multiple ALTO 
server implementations to provide a mix of services which are most 
appropriate for that particular site, but at the same time 
implementations are not limited in what services they can provide.

Bye,
Robert