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