Re: [p2pi] Refining the ALTO problem statement

One thing I have not seen directly addressed is that congestion
is only a second-order symptom of the demand profile.  It indicates what
managed to get into the network, not what people really wanted to pass
through the network.  How do we address that broader question?

Bob

-----Original Message-----
From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of
John Leslie
Sent: Monday, June 23, 2008 9:45 AM
To: Lars Eggert
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Refining the ALTO problem statement

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 mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi