Re: [alto] Mandatory and optional in alto protocol

"Vijay K. Gurbani" <vkg@bell-labs.com> Thu, 27 October 2011 16:33 UTC

Return-Path: <vkg@bell-labs.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 9B29821F8B04 for <alto@ietfa.amsl.com>; Thu, 27 Oct 2011 09:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.552
X-Spam-Level:
X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 t43Jf95X4rB0 for <alto@ietfa.amsl.com>; Thu, 27 Oct 2011 09:33:30 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id DB65421F8AF2 for <alto@ietf.org>; Thu, 27 Oct 2011 09:33:29 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p9RGXTAu027275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Oct 2011 11:33:29 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9RGXSjm018565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 11:33:29 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9RGXSn1021013; Thu, 27 Oct 2011 11:33:28 -0500 (CDT)
Message-ID: <4EA98888.7000700@bell-labs.com>
Date: Thu, 27 Oct 2011 11:36:24 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0
MIME-Version: 1.0
To: Richard Alimi <rich@velvetsea.net>
References: <4E2ED647.4060602@telecomitalia.it> <CA+cvDaZs5FKYCTJQ+gYd5-TC7Dn_SkQtypwmUBVtqbyx2R=83w@mail.gmail.com>
In-Reply-To: <CA+cvDaZs5FKYCTJQ+gYd5-TC7Dn_SkQtypwmUBVtqbyx2R=83w@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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: Thu, 27 Oct 2011 16:33:30 -0000

On 10/24/2011 11:33 AM, Richard Alimi wrote:
> 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 :)

(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} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/