Re: [p2pi] Refining the ALTO problem statement

Lars Eggert <lars.eggert@nokia.com> wrote:
> 
> I have a few comments about the kinds of information that the oracle  
> might provide to the app.
> 
> The high level bit is that I believe that although it will be possible  
> to provide information that changes on relatively large timescales  
> (such as information about topological proximity), 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.

> On 2008-6-12, at 21:33, ext Enrico Marocco wrote:
> 
>>  * Given a list of peer candidate IP addresses, sort them according to
>>    preferences (topological proximity, bandwidth constraints, etc.)  
>>    and return to querying application;
>>  * Ability for an application to determine its network location and
>>    proximity to other nodes;
> 
> These are all OK, except for the bit about "bandwidth constraints".  
> The available bandwidth along a path changes very rapidly, on  
> timescales roughly O(RTT), because bandwidth consumption is regulated  
> by the congestion control loops of the flows sharing a path.

   Absolutely true.

> This pretty much guarantees that any such information an oracle could  
> maintain will be stale by the time that an oracle can provide it to an  
> application.

   Not as true.

   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.

> So this information is unlikely to be useful to an app;  
> 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?

> I'm MUCH less convinced of the usefulness of the shopping list of  
> things in the following bullets. For a lot of the things below, it's  
> unclear to me why an application would want them and where an oracle  
> would get them from. I don't think they should be part of any  
> standardization effort at this time.

   We should be standardizing a protocol, not an implementation.

>>  * Support for cost and charging information for application so that
>>    applications can make appropriate trade-offs;

   Clearly, applications have every reason to consider cost/charging
information provided by the supplier the user will have to pay.

> Can you be a bit more explicit about whose costs this is about? Who is  
> paying whom, on what timescales and based on what resources?

   I'm not sure we can answer any of those, but it would be good for
the protocol to carry the answers to those questions.

>>  * Capabilities and characteristics of peers (i.e., last hop  
>>    bandwidth, etc.);
> 
> The bandwidth example is IMO again problematic (and it's not a peer  
> characteristic, it's a path characteristic.) Also, why would an oracle  
> know anything about the capabilities or characteristics of the peers?  
> Are the peers supposed to register with the oracle? That goes far  
> beyond what I thought this BOF was about.

   The peer might impose its own limits, beyond the limits of the path.
It might (or might not) be appropriate to standardize a way of
advertising these.

>>  * Network policies;
> 
> Such as?

   Good question: I can imagine several, but don't know if we could
define a good set of metrics.

>> + Type(s) of information that is provided to the oracle for  
>>   rendering an equitable decision:
>>  * List of peer candidate IP addresses;
>>  * Parameter to optimize (cost, delay, ...);
> 
> Why is it useful to query the oracle for delay?

   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.

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