Re: [p2pi] Refining the ALTO problem statement

[Lars Eggert <[e-mail]>]

Hi,

sorry it took me a while to respond.

On 2008-6-16, at 20:39, ext John Leslie wrote:
> Spencer Dawkins <[e-mail]> wrote:
>>
>> My understanding of what Lars is concerned about, is the idea of  
>> using
>> an oracle to provide guidance about path characteristics on a  
>> timescale
>> of less than many, many RTTs. He's concerned that a transmitter can
>> respond to "good news" about a path from an oracle more quickly than
>> the oracle can recognize that a transmitter has rapidly ramped up its
>> transmit rate and start telling senders what it's seeing.

Spencer: sort of, yes. Basically, I'm concerned that this builds a  
high-layer control loop that acts on the same information on (as I  
understand it) roughly the same timescales. That's not necessarily  
problematic, but there's at least a ;arge potential for interactions.

>   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? Also, how would the oracle  
learn about the congestion levels of each router, and on what  
timescales is this information accurate?

>> My understanding of the discussion between John and Lars in this  
>> thread
>> is that one key question is whether guidance about path selection  
>> has any
>> relationship with congestion avoidance, detection, and recovery, or  
>> not.
>>
>> If I tell Lars "this path is usually uncongested on Saturday  
>> night", and
>> he starts a large transfer on Saturday night, what does he do when he
>> encounters congestion?
>>
>> - ignore it and keep transmitting as if the path was really  
>> uncongested
>>  (wrong answer!),
>
>   Agreed.
>
>> - look for another path (but the guidance was that this is the best  
>> path
>>  most of the time), or
>
>   Abandoning the path based on instantaneous congestion may be wrong.
> Trying an alternate as an additional option may be wise.
>
>> - stay on this path and do TCPish loss-based bandwidth probing  
>> (even if
>>  the problem is that Magnus ALSO saw "this path is usually  
>> uncongested
>>  on Saturday night" and also selected this path for a large transfer
>
>   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,  
why bother designing a mechanism to provide it? Apps will just ignore  
it then.

I question whether we actually can design an oracle that is right much  
more often than wrong with regards to performance-related information.  
Trying to answer this question as a research effort is very  
interesting, doing standardization around it is IMO premature.

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