Re: [alto] PID Properties in ALTO

"Y. Richard Yang" <yry@cs.yale.edu> Tue, 25 October 2011 19:58 UTC

Return-Path: <yry@cs.yale.edu>
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 880F91F0C5A for <alto@ietfa.amsl.com>; Tue, 25 Oct 2011 12:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level:
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599]
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 lr+LKI1v1N1v for <alto@ietfa.amsl.com>; Tue, 25 Oct 2011 12:58:46 -0700 (PDT)
Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id D0A6A1F0C57 for <alto@ietf.org>; Tue, 25 Oct 2011 12:58:45 -0700 (PDT)
Received: from dhcp-128-36-169-41.central.yale.edu (dhcp-128-36-169-41.central.yale.edu [128.36.169.41]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id p9PJwiSi016735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2011 15:58:44 -0400
Message-ID: <4EA714F4.6090008@cs.yale.edu>
Date: Tue, 25 Oct 2011 15:58:44 -0400
From: "Y. Richard Yang" <yry@cs.yale.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: alto@ietf.org
References: <CACC5DB9.5642C%rpenno@juniper.net>
In-Reply-To: <CACC5DB9.5642C%rpenno@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146
Subject: Re: [alto] PID Properties in ALTO
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: Tue, 25 Oct 2011 19:58:46 -0000

I like the idea of indicating properties to a group of points.  The 
particular approach
of annotating a PID appears to be clean and brings endpoints and PIDs 
(aggregations) uniform.
So I could imagine an OO implementation would define a base class to 
handle both, in a single
base class.

One semantics difficulty that this may cause is consistency. For 
example, if an endpoint A
has property P when the query is for A, and then not P, when queried by 
an enclosing PID.
In other words, redundancy may cause inconsistency. But this may not be 
a crucial issue.

I like the idea of extension too.

Richard Y.

On 10/25/11 3:36 PM, Reinaldo Penno wrote:
> As one of the proponents I like the idea but an extension is fine.
>
>
> On 10/24/11 10:10 AM, "Richard Alimi"<rich@velvetsea.net>  wrote:
>
>> I'm fine with leaving this as an extension, I agree it falls outside
>> of the core set of functionality and could easily be done as an
>> extension. Objections to that?
>>
>> Rich
>>
>> On Fri, May 27, 2011 at 11:11 AM, Robert Varga<robert.varga@pantheon.sk>
>> wrote:
>>> Hi,
>>>
>>> I agree we should support it. I am just not sure we need it the base
>>> protocol, though, as it can easily be specified as an extension.
>>>
>>> Bye,
>>> Robert
>>>
>>> On 05/27/11 18:48, Richard Alimi wrote:
>>>> Hi All,
>>>>
>>>> Okay, third and final thread for discussion today :)  Another proposed
>>>> extension to the ALTO protocol has been to associate properties (like
>>>> we currently have with Endpoints) with PIDs.
>>>>
>>>> A proposed use case in draft-penno-alto-cdn was to indicate what types
>>>> of endpoints lived within a single PID. A more general mechanism to
>>>> support this would be to allow properties to be associated with a PID
>>>> as whole. In one light, this could be seen as an efficient way to
>>>> query for the properties of all endpoints within a PID (in which
>>>> membership in the PID determines the value of the property). It could
>>>> also be used to attach some semantic meaning to a PID (instead of
>>>> being an opaque identifier) in particular deployments.
>>>>
>>>> One way to support this would be to provide an additional "PID
>>>> Property" service, with a similar structure to the Endpoint Property
>>>> Service. Basically, it would amount to defining a registry, allowing
>>>> an ALTO Server to indicate its supported properties via capabilities,
>>>> defining encodings for the request and response, etc.
>>>>
>>>> Thoughts about supporting this?
>>>>
>>>> Thanks,
>>>> Rich
>>>> _______________________________________________
>>>> alto mailing list
>>>> alto@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>> --
>>> Robert Varga
>>> Pantheon Technologies, s.r.o.
>>> Mlynske Nivy 56
>>> 831 05 Bratislava
>>>
>>> _______________________________________________
>>> alto mailing list
>>> alto@ietf.org
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto