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

"Martin Stiemerling" <Stiemerling@nw.neclab.eu> Mon, 13 October 2008 15:02 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 9407E28C108; Mon, 13 Oct 2008 08:02:57 -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 9BA4E3A688A; Mon, 13 Oct 2008 08:02:56 -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=[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 9MlXTGUO7PsE; Mon, 13 Oct 2008 08:02:55 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4605D3A67F1; Mon, 13 Oct 2008 08:02:55 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DCA932C0012C2; Mon, 13 Oct 2008 17:03:09 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq1u2FT0-LYy; Mon, 13 Oct 2008 17:03:09 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id AB83A2C000304; Mon, 13 Oct 2008 17:02:44 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Oct 2008 17:02:41 +0200
Message-ID: <547F018265F92642B577B986577D671C3DF92C@VENUS.office>
In-Reply-To: <BE82361A0E26874DBC2ED1BA244866B92763750C@NALASEXMB08.na.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: AckrB8UxxycZhW5DQNmtzaNDmm9pNgACj0qwAIwwruA=
References: <20081006203532.B1D673A68AF@core3.amsl.com><BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com><48EFA1B7.7010508@alcatel-lucent.com> <BE82361A0E26874DBC2ED1BA244866B92763750C@NALASEXMB08.na.qualcomm.com>
From: "Martin Stiemerling" <Stiemerling@nw.neclab.eu>
To: "Narayanan, Vidya" <vidyan@qualcomm.com>, "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Cc: p2pi@ietf.org, IESG IESG <iesg@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 Vidja, all,

I believe that the charter is narrow and broad enough to cover the
topic of ALTO, i.e., the charter is not limiting the solution space. 

However, when reading your comments, it sounds that you have a very
specific solution in mind which is probably not covered by the
current charter. 

[...]

> >
> > > Overall, I think we should work with the notion of an ALTO
> "service"
> > >  rather than specifically an ALTO "server".
> >
> > Great.  I believe that is exactly what the charter does;  the
> > charter talks in terms of an "ALTO service" at many places
> > (pedantically speaking, the term "ALTO service" occurs eight
> > times and the term "ALTO server" occurs six.)  The ALTO "server"
> > mentioned in the charter refers to the *host* the client
> > finally queries (calling it a "peer" is ambiguous; if you
> > have a specific term to use here instead of "server", please
> > do let us know.)
> >
> 
> When we consider ALTO as a distributed service, there may not
> necessarily be "a" host that specifically resolves the ALTO queries.
> For instance, consider the case where ALTO is a service offered in an
> overlay.  There may be peers publishing information about themselves on
> the overlay and other peers looking up such information.  These are not
> necessarily client-server style communications.  In fact, all that is
> important in this context is that the overlay acts as a rendezvous for
> sharing such information.  Now, of course, that is one possible model.

You probably have a publish/subscribe system in mind for p2p overlays.
I assume this is not in scope of ALTO. 

> But, in order to allow for that and other models, I do want the charter
> to keep the focus on the service and not on a server.

Is the IETF anyhow standardizing services? I don't see this.  

[...]


> >
> > We have had discussions on the mailing list about this already.
> > Some people felt that providing uplink bandwidth would not be
> > a good idea for various reasons running from privacy concerns
> > to peers skewing traffic in favor of a high uplink bandwidth.
> > Others felt that even if a peers uplink bandwidth was not
> > provided, it could calculated nonetheless by other peers.
> > That is, there are degrees of disagreement here and
> > consequently, including a contentious point in the charter
> > would be counter- productive.
> >
> 
> I'm afraid that would be a mistake.  It actually doesn't matter if we

I'm afraid that carrying up/downlink capacity of the peer's local link
is a complete waste of resource, as this is not indicating something. For
instance, a peer may have a relatively huge uplink but on a shared medium,
i.e., a medium which might be shared by hundreds of other hosts/traffic.
So what does this information express? 

> don't agree today on the exact types of information that can be shared.
> It is important that we have a protocol that allows peers to publish
> ALTO related information.  Having this protocol be extensible would
> allow for any type of information to be carried in it.  So, I strongly

The question is, whether the roots of ALTO are actually intended to carry
any type of information? The main idea is to carry information to optimize
traffic, e.g., decreasing cross ISP traffic. 

> believe we don't need a recharter to consider any information types -
> in fact, I'd be okay if this effort only took on the protocol and if
> all information types were to be registered through other means.  That
> said, I'm not against taking on some subset of those types - I don't
> believe that should be the core focus of this work though.
> 
> > > - The ability to register information types with IANA and extend
> > > these.
> >
> > Having a IANA registry for the information type carried in
> > the protocol is certainly a possibility the charter does not
> > rule out, no?
> >
> 
> Well, it is a bit hard to say what the charter does not rule out -
> typically we try and do what the charter says we should do.  However,
> before we get to the registry, we need to agree on the protocol
> components.  In my view, there are two such components - the publish
> protocol mentioned above and the request/response protocol (actually,
> more generically, a lookup protocol) mentioned below.

It is good to see your ideas but doesn't this go beyond a charter discussion,
as your are discussing a solution?

This comes back to my initial comment about discussing a specific solution,
and we haven't yet reached the times to discuss a solution - at least not
here.

  Martin


stiemerling@nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi