Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin]

[Lars Eggert <[e-mail]>]

Hi,

On 2008-6-12, at 21:33, ext Enrico Marocco wrote:
> + Type(s) of information that are likely provided by the oracle (note
>  that a third-party oracle may not have access to some of this
>  information):

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.

>  * 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. 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. 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.

Modulo this concern about stuff that varies on short timescales, a  
simple mechanism that lets an app query an oracle about the things in  
the two bullets above would be useful.

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. (Looking at them from a research  
perspective is fine.)

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

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?

>  * 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.

>  * Network policies;

Such as?

> + 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? An app can get a  
relatively accurate and more importantly timely RTT sample by sending  
a few packets to a peer. That practice causes no issues for operators,  
since the traffic volume is so low.

Lars
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi