Re: [alto] Mandatory and optional in alto protocol

Richard Alimi <rich@velvetsea.net> Mon, 24 October 2011 16:22 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 5A54221F8E20 for <alto@ietfa.amsl.com>; Mon, 24 Oct 2011 09:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level:
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.132, 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 h1FMRcNwz2ew for <alto@ietfa.amsl.com>; Mon, 24 Oct 2011 09:22:04 -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 8AA8C21F8997 for <alto@ietf.org>; Mon, 24 Oct 2011 09:22:04 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so6043022vcb.31 for <alto@ietf.org>; Mon, 24 Oct 2011 09:22:04 -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=b+pMZHNBFN4lCg3RJWASsTpjaSJEcB0IhODZ4blKg5Q=; b=mtuthHywtPW00hbzFGme7YGzj84YKBmOo4KqYqEhV8i+T/bVc10XSEy9yPhZoW7c5I FmbyZtqLk3K+iM1B2Q+gj7w9fTK7RC9a1ABonherBBHzl2EW7ZiKDLoZ2S4Rq3g4ttSg sSa/L4VnCT5vX5vVheACIfzFQrtJ1Y800X8/Q=
Received: by 10.52.34.177 with SMTP id a17mr6545036vdj.103.1319473324075; Mon, 24 Oct 2011 09:22:04 -0700 (PDT)
MIME-Version: 1.0
Sender: richard.alimi@gmail.com
Received: by 10.52.186.39 with HTTP; Mon, 24 Oct 2011 09:21:44 -0700 (PDT)
In-Reply-To: <4E54EFBE.10807@pantheon.sk>
References: <CA5EC1A5.1D7F7%manbhard@cisco.com> <4E54EFBE.10807@pantheon.sk>
From: Richard Alimi <rich@velvetsea.net>
Date: Mon, 24 Oct 2011 09:21:44 -0700
X-Google-Sender-Auth: JPfWzvKTYwepcaW8Wk_QoPJfB6Y
Message-ID: <CA+cvDaYtd2JWt6i3H9=Odw012+dNEZa49POJ6ehidNY3W6rspQ@mail.gmail.com>
To: Robert Varga <robert.varga@pantheon.sk>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: 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:22:05 -0000

On Wed, Aug 24, 2011 at 5:34 AM, Robert Varga <robert.varga@pantheon.sk> wrote:
> Hi,
>
> On 08/03/11 18:13, manbhard wrote:
>>
>> 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.
>
> 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
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>