Re: [alto] Mandatory and optional in alto protocol

Richard Alimi <rich@velvetsea.net> Mon, 24 October 2011 16:18 UTC

Return-Path: <richard.alimi@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692E1F0C43 for <alto@ietfa.amsl.com>; Mon, 24 Oct 2011 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.835
X-Spam-Level:
X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ih9RTaIMfIr for <alto@ietfa.amsl.com>; Mon, 24 Oct 2011 09:18:57 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6451F0C35 for <alto@ietf.org>; Mon, 24 Oct 2011 09:18:57 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so6039439vcb.31 for <alto@ietf.org>; Mon, 24 Oct 2011 09:18:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8bCJqqLZqrg5HA4DMzWaDwT05Fk1hqgqMjyF87tri90=; b=Kc8bpw1qvd3LIZ5obeM9hkC3xxLDztb3HBIUQOCcQkLmaz+aVvr/dlowq0lkk0SHLD /ZjI7h1oHfuXOSd8XMkGde5IF1Mwx1wCixbwstZElsAy33fa0s3YAHEEdugldxvAG6oo sqIxPjaHzF4ZhFQO94JL39UuF/pFO1FcABHD4=
Received: by 10.52.181.169 with SMTP id dx9mr5361283vdc.52.1319473137060; Mon, 24 Oct 2011 09:18:57 -0700 (PDT)
MIME-Version: 1.0
Sender: richard.alimi@gmail.com
Received: by 10.52.186.39 with HTTP; Mon, 24 Oct 2011 09:18:37 -0700 (PDT)
In-Reply-To: <CA5EC1A5.1D7F7%manbhard@cisco.com>
References: <4E2ED647.4060602@telecomitalia.it> <CA5EC1A5.1D7F7%manbhard@cisco.com>
From: Richard Alimi <rich@velvetsea.net>
Date: Mon, 24 Oct 2011 09:18:37 -0700
X-Google-Sender-Auth: MaH1GZewIXP8e4GiDo26Lv6QKBE
Message-ID: <CA+cvDaZ-1edezOv6k+vUqfojBYCJt1yxOWHqo1wi6z3EFVV0wA@mail.gmail.com>
To: manbhard <manbhard@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] Mandatory and optional in alto protocol
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 16:18:58 -0000

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 <manbhard@cisco.com> 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" <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 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
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>