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

[Enrico Marocco <[e-mail]>]

Lars Eggert wrote:
> I have a few comments about the kinds of information that the oracle
> might provide to the app.

Lars, thanks for your comments.

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

Ok.

> 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?

Sure.  This was one bullet point that was made in Prof. Schulzrinne's 
paper.  I quote the text from the paper:

    Cost-of-bandwidth information

    Relying on cooperative applications to be “nice” is probably
    insufficient unless there is an incentive. There are at least three
    possibilities, namely either volume limiting, rate limiting or
    volume-based charging. For example, a network could offer a tiered
    tariff that allows unlimited bandwidth within the same AS, 100 kb/s
    rate-limited but unlimited prioritized DiffServ to anywhere and
    volume-limited bulk traffic to any AS. There are several ways to
    convey this information to applications, allowing them to make
    appropriate trade-offs. For example, a network could provide an
    information service with a list of service descriptors, similar to
    the RSVP TSpec. Alternatively, a protocol such as GIST could discover
    the cost of particular destination.  The service classes may change
    over time. For example, a network may offer "midnight specials" when
    the network is idle during off-hours, encouraging bulk downloads
    during that time.

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

Yes, you are right in characterizing this as 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.

No, we are not suggesting that peers register with the oracle.  This is 
more along the point of trying to generate some discussion.  What if a 
peer is willing to publish its capabilities, either for other peers or 
for an oracle.  Is this something that is worth considering, if not for 
a standardization aspect, at least as a research problem?

>>  * Network policies;
> 
> Such as?

Along the same line as mentioned above in the "Cost-of-bandwidth" 
information.

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

Well, the use case I had in mind here was the selection of media relays 
in real-time communication systems, when the list of candidate peers may 
have hundreds or thousands of elements (think of Skype).  In such a 
case, provided the oracle can elaborate lists and not on single 
instances only, a one query would replace tons of RTT measurements.

On a side note, is it possible for RTT to be small on a high latency 
link one hop away when compared to a slightly higher RTT on low latency 
links six hops away?  That is, the time it takes for a peer to download 
a large content from the peer with the lower RTT is actually higher than 
the time it takes to do the same from the peer with higher RTT.

-- 
Ciao,
Enrico

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