Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Yu-Shun Wang <Yu-Shun.Wang@microsoft.com> Fri, 24 October 2008 17:40 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94ABB3A68F0; Fri, 24 Oct 2008 10:40:20 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26393A68F0; Fri, 24 Oct 2008 10:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF5XDzLPBn-4; Fri, 24 Oct 2008 10:40:18 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AA9ED3A6841; Fri, 24 Oct 2008 10:40:18 -0700 (PDT)
Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 24 Oct 2008 10:41:40 -0700
Received: from NA-EXMSG-C102.redmond.corp.microsoft.com ([157.54.110.48]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.54.46.186]) with mapi; Fri, 24 Oct 2008 10:41:40 -0700
From: Yu-Shun Wang <Yu-Shun.Wang@microsoft.com>
To: "Narayanan, Vidya" <vidyan@qualcomm.com>, IESG IESG <iesg@ietf.org>
Date: Fri, 24 Oct 2008 10:41:38 -0700
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFfNfAAFNViIAAfhK2w
Message-ID: <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC96F@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9284E7855@NALASEXMB08.na.qualcomm.com> <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> <BE82361A0E26874DBC2ED1BA244866B9284E791E@NALASEXMB08.na.qualcomm.com>
In-Reply-To: <BE82361A0E26874DBC2ED1BA244866B9284E791E@NALASEXMB08.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "p2pi@ietf.org" <p2pi@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Hi Vidya,

> > > > Other usages will be considered as extensions to the charter once
> > > > the work for the initial services has been completed.
> > >
> > > I think we should delete the sentence above.
> >
> > While it may seem redundant, I don't see anything wrong with
> > that. It just means we may have a narrow scope now, but we
> > will think about new extensions once we are done.
>
> I actually believe that if we designed the protocols right, we don't
> need a recharter to carry other types of information - we can allow
> registration of new information types for ALTO beyond the life of the
> WG.

Agreed in principle, and I don't think anyone on the list would
disagree we should design an extensible protocol/solution. The
need for such wording is, imo, for the practical purpose of
scoping a working group. Any new type of info the wg considers
must be carefully evaluated for the impacts and such. The current
charter just says we will focus on the protocol and certain types
of info. Note that it doesn't say the protocol must NOT be
extensible. (If it does, then we should change that.)

<...>

> > I read the list below somewhat differently. These are not for
> > relative importance of the information, but kind of a min bar
> > for what we want to do. While some may need re-wording, the
> > intent is fine, IMO.
>
> I'm not so sure.  Basically, it is a question of what usage these are
> evaluated based on.  Let's take a couple of examples.  Whether the ALTO
> service can provide a piece of information is dependent on various
> factors - some things are dependent on whether such information is
> available from other places today (e.g., topology or ASNs, etc.); I
> think this set of questions has been written with that mindset.  But,
> there are others (e.g., quality, reputation, semantic expertise, etc.)
> that are totally based on the type of the p2p overlay and whether
> clients can provide that information.  Similarly, whether some
> information is useful to a client is totally contextual to the
> application as well.

Once again, I don't think we are that far apart, and in a sense,
what is missing is really a note that the answers to these questions
largely depend on the type of info they apply to. Although I still
think these are fair questions to ask on the info under consideration.

I would totally agree that these need re-wording for clarity. Let's
wait for the next round of charter update. :-)

Thanks,
yushun

> > > > - Can the ALTO service technically provide that information?
> > > > - Is the ALTO service willing to obtain and divulge that
> > > >   information?
> > > > - Is it information that a client will find useful?
> > > > - Can a client get that information without excessive privacy
> > > >   concerns(e.g. by sending large lists of peers)?
> > > > - Is it information that a client cannot find easily some
> > > >   other way?
> > > >
> > > > After these criteria are met, the generality of the data will be
> > > > considered for prioritizing standardization work, for example the
> > > > number of operators and clients that are likely to be able to
> > > > provide or use that particular data.
> > >
> > > The above again gets into our evaluation of what is
> > > important based on
> > > what we know today and is limiting.
> >
> > This point does need some clarification and rewording.
> >
> > Thanks,
> > yushun


_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi