Re: [p2pi] Refining the ALTO problem statement
John Leslie <john@jlc.net> Mon, 23 June 2008 16:45 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 BEA513A697E; Mon, 23 Jun 2008 09:45:26 -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 0875E3A6910 for <p2pi@core3.amsl.com>; Mon, 23 Jun 2008 09:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 7i6VaLtll0uQ for <p2pi@core3.amsl.com>; Mon, 23 Jun 2008 09:45:24 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 7EA033A68B5 for <p2pi@ietf.org>; Mon, 23 Jun 2008 09:45:24 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 4D5B833C1F; Mon, 23 Jun 2008 12:45:23 -0400 (EDT)
Date: Mon, 23 Jun 2008 12:45:23 -0400
From: John Leslie <john@jlc.net>
To: Lars Eggert <lars.eggert@nokia.com>
Message-ID: <20080623164523.GB26944@verdi>
References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> <20080616173953.GF3759@verdi> <C3D5E72B-76D4-47A0-8CD8-830E5B2E0F33@nokia.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <C3D5E72B-76D4-47A0-8CD8-830E5B2E0F33@nokia.com>
User-Agent: Mutt/1.4.1i
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Refining the ALTO problem statement
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
Lars Eggert <lars.eggert@nokia.com> wrote: > On 2008-6-16, at 20:39, ext John Leslie wrote: > >> For a number of reasons, oracles _could_ be in a better position >> to know path characteristics. Congestion along a path tends to be >> concentrated at relatively few points along the path. Peers know >> what they're seeing (instantaneously) over the whole path, but >> generally lack any understanding about subpaths. > > John: But what matters for a given flow are the characteristics of > the whole path. Why would sub-paths matter? A good question, actually... Sub-paths matter because they're what gets congested. P2P applications have good reason to want to know (instantaneous) congestion, and what the likelihood is that the congestion will get better or worse soon. Oracles _could_ give them "This is what congestion looks like" information. This could be a big win. > Also, how would the oracle learn about the congestion levels of each > router, and on what timescales is this information accurate? Oracles, pretty much by definition, have access to characteristics over a _long_ time period. _How_ they learn congestion levels of each router is not in scope of this work. (Certainly there are standard tools ISPs use to divine congestion levels.) It's not important for us to say what timescales Oracles should use, we merely want to specify how they report their timescales. >> It is reasonable to expect P2P applications to learn how to use more >> than one remote peer at a time. Statistical information is never a >> guarantee that you'll see exactly the predicted situation. > > True, but unless the information is accurate much more often than not, This shouldn't be a difficult goal -- unless we do a poor job of defining a protocol to accurately communicate _what_ has been measured, on what timescale. > why bother designing a mechanism to provide it? Apps will just ignore > it then. ... giving other Oracles a shot at the market... > I question whether we actually can design an oracle that is right much > more often than wrong with regards to performance-related information. It really isn't hard! Oracles can almost trivially find maximum bandwidth and minimum latency along subpaths, and unless the routing changes, these will stay rather constant. The apps, given just that much information, can make a much better judgment of instantaneous congestion than they could without it. Anything an Oracle could do about predicting future trends in congestion would be icing on the cake, hardly even necessary to prove their worth. > Trying to answer this question as a research effort is very > interesting, doing standardization around it is IMO premature. There's certainly room for a lot of research; but standardizing the _interface_ between oracle and P2P app would be a _major_ benefit to that research, while giving some immediate benefit to the apps and the ISPs. -- John Leslie <john@jlc.net> _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
- [p2pi] discussing P2PI-related standardization in… Lars Eggert
- Re: [p2pi] discussing P2PI-related standardizatio… Lars Eggert
- Re: [p2pi] discussing P2PI-related standardizatio… Vijay K. Gurbani
- Re: [p2pi] discussing P2PI-related standardizatio… Peterson, Jon
- Re: [p2pi] discussing P2PI-related standardizatio… Livingood, Jason
- [p2pi] Refining the ALTO problem statement [Was: … Enrico Marocco
- Re: [p2pi] Refining the ALTO problem statement [W… stefano previdi
- Re: [p2pi] Refining the ALTO problem statement [W… John Leslie
- Re: [p2pi] Refining the ALTO problem statement [W… Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement [W… Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement [W… Lars Eggert
- Re: [p2pi] discussing P2PI-related standardizatio… Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement [W… Enrico Marocco
- Re: [p2pi] Refining the ALTO problem statement John Leslie
- Re: [p2pi] discussing P2PI-related standardizatio… Richard Bennett
- Re: [p2pi] discussing P2PI-related standardizatio… Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement [W… Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement [W… stefano previdi
- Re: [p2pi] Refining the ALTO problem statement Spencer Dawkins
- Re: [p2pi] Refining the ALTO problem statement John Leslie
- Re: [p2pi] Refining the ALTO problem statement John Leslie
- Re: [p2pi] Refining the ALTO problem statement Spencer Dawkins
- Re: [p2pi] Refining the ALTO problem statement [W… Henning Schulzrinne
- Re: [p2pi] Refining the ALTO problem statement [W… Stanislav Shalunov
- Re: [p2pi] Refining the ALTO problem statement [W… Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Spencer Dawkins
- Re: [p2pi] Refining the ALTO problem statement John Leslie
- Re: [p2pi] Refining the ALTO problem statement Robert Snively
- Re: [p2pi] Refining the ALTO problem statement Stanislav Shalunov
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement stefano previdi
- Re: [p2pi] Refining the ALTO problem statement Stanislav Shalunov
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert