Re: [alto] Mandatory and optional in alto protocol

On Tue, Jul 26, 2011 at 7:59 AM, Enrico Marocco
<enrico.marocco@telecomitalia.it> 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 think that this is where your point about "optimizations" comes in,
as well as Robert Varga's reply below.  In such constrained
environments, either a provider could offer the endpoint services via
the same IRD, or they could setup cache-type ALTO Servers that just
gather updated maps from the authoritative ALTO Server, and have the
additional logic to provide the endpoint services (replicated as
necessary for scalability).  Furthermore, this caching ALTO Server
doesn't even have to be owned/managed by the same entity as the
authoritative one (but of course, you need to trust that entity...)

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

The major concern I would have with making all services optional is
interoperability.  I think David Harrington (our AD) puts it well --
in the end, we need to define standards such that different
implementations can speak with each other.

It is very important to realize the background for why the current
services are defined as REQUIRED vs. OPTIONAL up until now.  It seems
to be common belief that it was because one would be more useful than
the other - that is not true. The rationale was that the OPTIONAL
services can be *derived* from the REQUIRED ones.  That basically
enables the caching ALTO Servers approach I mentioned above.

I think it goes without saying that my personal opinion would be to
make the maps services required, and the other services that can be
derived from the maps service optional.  In the case of the endpoint
property service (for properties other than "pid"), I don't think it
matters much since providing properties beyond "pid" is optional
already.  That said, we will certainly update the document according
to whatever working group consensus says :)

Thanks,
Rich

>
> --
> Ciao,
> Enrico
>
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>