Re: [p2pi] Refining the ALTO problem statement

Lars Eggert <lars.eggert@nokia.com> wrote:
> On 2008-6-14, at 1:57, ext John Leslie wrote:
>> Lars Eggert <lars.eggert@nokia.com> wrote:
>> 
>>> it will be both very difficult and potentially problematic to share
>>> performance-related information that changes on short timescales
>>> in the same fashion.
>>
>> That's an implementation issue.
>> We should do protocol design before we do implementation.
>> Besides, it's only a couple orders of magnitude "difficult." It  
>> might be quite practical five years from now.
> 
> I think we're talking about two different things. I understood the  
> proposal for the oracle to maintain performance-related information to  
> be for actual, current load of a path (modulo quantization effects and  
> communication latency).

   I understood the proposal to be maintaining performance-related
information without specification of the time period it reflects.

> That has all sorts of timing- and accuracy-related issues.

   Either way, yes... except that some characteristics like maximum
bandwidth and minimum latency are pretty safe to report.

> If I understand your email correctly (based on the quoted section  
> below), you see the oracle as maintaining more coarse-grained,  
> statistical load data about paths.

   Actually, I was more concerned that a protocol should support
reporting such things, not wishing to get into how such information
might be divined.

> Things like "this path is half idle on Saturday night."

   (Actually, that's a bad example: while an oracle might be able to
divine that parts of a path are in fact idle from 1800 to 2400 GMT on
Saturdays, it couldn't reasonably say that about the _whole_ path.
It _could_ say "latency above N milliseconds" indicates congestion.")

> I agree that that information would be easier to provide. But I
> question whether such load data can be useful to applications
> (see below).
> 
>> The application isn't particularly interested in one instantaneous
>> snapshot: it's interested in what's likely to be the case over an
>> extended period (or how long it is likely to take to transfer a known
>> amount of data. Statistical summaries are much more useful: and the
>> oracle is in a good position to provide those.
> 
> Assuming for a moment we had an oracle that had such information, the  
> only benefit to apps would be to not even try to establish connections  
> to peers that had a projected low throughput.

   It's more a matter of which connection(s) to try _first_.

> (And if the aggregate traffic to such peers would conflict with ISP  
> interests, they'd rank the peer low in the oracle because of that  
> anyway, independent of traffic statistics)

   Oracles will not _only_ be maintained by ISPs. ISP oracles will be
used _only_ if the users perceive a benefit from using them.

>>> So this information is unlikely to be useful to an app;

   I don't believe you've made your case for that...

>>> and I can even construct cases where using this stale information
>>> leads to traffic oscillations, which is problematic.
>>
>> Traffic oscillations are indeed problematic. But can you construct
>> a case where statistical damping isn't sufficient to guard against
>> that?
> 
> Who would dampen what?

   Damping is inherent in statistical averaging.

> The apps are just using information provided by the oracle and see
> no oscillations. The oracle could observe that traffic shifts, but
> how does it differentiate if that is due to the information it
> provides or whether it is independent of that?

   It _should_ assume it is independent.

> And even if it could, what does it then do?

   Unless it's the ISPs oracle, it should do nothing different. If it
_is_ the ISPs oracle, we're getting pretty far into implementation...

> Longer statistical aggregation decreases the frequency of oscillations,
> but also means that the load data will be even less indicative of
> current loads.

   Yes. (For many reasons, the p2p applications are likely to be in a
better position to deal with instantaneous congestion.)

>> Because instantaneous delay isn't a good measure. An oracle will be
>> in a better position to know minimum latency, plus normal range for
>> minimal congestion.
> 
> Clarification: When you say "delay", it sounds you mean "projected  
> transmission time"? Because I think Enrico actually meant RTT.

   I was intentionally vague, but you guessed right: I think in terms
of one-direction latency. P2P applications _could keep good enough
clocks to make effective use of this.

--
John Leslie <john@jlc.net>
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi