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

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Fri, 10 October 2008 21:30 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 B71FA3A6A62; Fri, 10 Oct 2008 14:30:46 -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 D10233A69CB; Fri, 10 Oct 2008 14:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 yP0Ntep23v+i; Fri, 10 Oct 2008 14:30:44 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9F75E3A6A62; Fri, 10 Oct 2008 14:30:44 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9ALVUu6001380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 16:31:30 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9ALVT9n011039; Fri, 10 Oct 2008 16:31:29 -0500 (CDT)
Message-ID: <48EFC9B0.8040609@alcatel-lucent.com>
Date: Fri, 10 Oct 2008 16:31:28 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: tme@multicasttech.com
References: <20081006203532.B1D673A68AF@core3.amsl.com> <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.com>
In-Reply-To: <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.com>
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "p2pi@ietf.org" <p2pi@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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Marshall Eubanks wrote:
> I support this moving forward. My reading of the room in Dublin was
> that there was serious support for this and certainly a critical mass
> to move forward.

Marshall: Thank you for your review.  More inline.

> Some comments in the charter below. This document clearly needs some
> more work. As a overall comment, I think it is premature to discuss
> ALTO "servers" and would keep the charter focused on describing the
> ALTO "service." 

In an earlier reply to Vidya I note that the charter does indeed
predominantly refer to "ALTO services" over "ALTO server".
Having said that, if I did not convince you through that
argument, then we can leave the "s/ALTO server/ALTO service"
discussion on the table.

> I do not see consensus at this moment as to a central
> service solution versus a distributed solution.

Agreed.

> s/choose/choose the best peer or peers to exchange data with/

Unfortunately, in the Dublin BoF charter, we did state best peer
(we had termed it "optimal" peer).  This was one reason for the
negative hums in the BoF because people have differing notion of
what an "optimal" (or best) peer is.  Thus, we reverted to the
non-confrontational use of the phrase that you now see in the
charter.

>> - A request/response protocol for querying the ALTO service to
>> obtain information useful for peer selection, and a format for
>> requests and responses.   The WG does not require intermediaries
>> between the ALTO
> 
> This is strange wording, as WG themselves are not protocols.
> 
> More fundamentally, is this a requirement? 

No.  We had some list discussion on whether or not to include
intermediaries, but the resolution of that discussion appeared
to be no (please see the few emails around the following
link: http://www.ietf.org/mail-archive/web/p2pi/current/msg00635.html).

>> - Can the ALTO service technically provide that information?
> 
> I think that what is meant here is "Can the ALTO service
> realistically discover that information?"

OK.

>> - Is the ALTO service willing to obtain and divulge that
>> information?
> 
> Do computers have free will?

AI notwithstanding ;-)  But point taken; we can attempt a
reword (if you have any suggestions, please throw them our way.)

>> After these criteria are met, the generality of the data will be
> 
> What is meant by "the generality of the data" ?
>> 
>> considered for prioritizing standardization work, for example the 

Hmmm ... since we are talking about prioritizing, maybe what is
meant is "importance" -- as in "importance of the service" --
may be a better fit.  Comments?

>> number of operators and clients that are likely to be able to
>> provide or use that particular data.  In any case, this WG will not
>> propose standards on how congestion is signaled, remediated, or
>> avoided, and
> 
> Does this mean that congestion is not an issue to consider ?

It is, but not in ALTO.  That will be part of TANA.

> If the closest peer to me was totally congested and had no available
> bandwidth, isn't that something that I would want to know ?
>> 
>> will not deal with information representing instantaneous network
>> state.
> 
> What is meant by "information representing instantaneous network
> state" ? Isn't this a protocol to share information about the state
> of the network ? Or is this an attempt to separate network topology
> from network performance ? But should network performance also be an
> issue ?

By and large, it has been the case that that instantaneous
network characteristics -- like current link usage, congestion,
etc. --  are not be part of ALTO; they will be  part of TANA.
Hence, congestion control was deemed out of scope.

> What is an Internet coordinate system?

Things like IDMaps, GNP, Vivaldi, etc.  Should we define this
term in the charter?

Thanks, Marshall.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi