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

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 09:18:37 -0700

Replying to a couple of specific points here (not necessarily in
relation to the mandatory vs. optional debate)...

On Wed, Aug 3, 2011 at 9:13 AM, manbhard <[email-masked]> wrote:
> 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.

The proposal was not to mandate that clients download maps. The
proposal would have been to mandate that servers provide the map
services.  Clients can certainly still request the endpoint services
if they are offered.

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

I'm not convinced (and there has been much previous discussion to this
effect on the list) that using the endpoint services really affords
any additional privacy for an ISP when it comes to aggregations.  If I
were configuring an ISP to provide maps to distrusted clients (which
seems to be the model in mind here), i would assume that ALTO clients
would be sending queries continuously trying to learn as much as
possible about how addresses were grouped together (and the costs if
provided), reconstructing the same maps exposed by the map service
anyways.  Put another way, I wouldn't offer any more-detailed
information via the endpoint services than I would be comfortable
revealing via maps.

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

---

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 09:21:44 -0700

On Wed, Aug 24, 2011 at 5:34 AM, Robert Varga <[email-masked]> wrote:
> Hi,
>
> On 08/03/11 18:13, manbhard wrote:
>>
>> certain clients. Similarly it might be a disincentive to servers run by
>> SPs
> 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.

When it comes to mandatory vs. optional, the draft intended to refer
to a logical ALTO Server (which may be made up by multiple physical
servers as in your example).  That is, each physical server need not
implement the Network Map service.  Only one of them does.  Does that
affect your opinion?

(Let us know if you think this should be made more clear in the draft.)

Thanks,
Rich

> Bye,
> Robert

---

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 09:33:23 -0700

> whilst downloading full network and cost maps, and process them locally,

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

> 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

---

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

> to whatever working group consensus says :)

(As individual).

I agree with NOT making all services optional.

In fact, during the Quebec City IETF, I had argued at the mic that
we should make all the services required.  We are essentially talking
about 5 core services, not tens or hundreds.

The bar to provide these services is low, and anyone offering a
production ALTO server will provide these services anyway (as a
case in point, during the bakeoff a majority of the servers provided
all of these services, not only the mandatory ones).

That said, if we do not make all the services mandatory, then I think
we should leave the Server Information and Map Service mandatory (as
it is now) and the remaining optional (since, as Rich argues, they
can be derived from the mandatory services).

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/