Re: [p2pi] Refining the ALTO problem statement

Spencer Dawkins <spencer@wonderhamster.org> 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.

   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.

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

   (An ISPs oracle could, in principle, downgrade a recommendation after
it has been issued to some number of customers. However, that is an
implementation detail, and I don't mean to recommend it.)

>   - and this is even funnier if Magnus was congesting all the other
>   paths LAST Saturday night, and decided to switch to this path
>   "because it was uncongested")

   The world is, indeed, stranger than we _can_ imagine...

> It seems helpful to discuss what the strategy is before we get very far
> into how the strategy might work...

   P2P applications need not all use the same strategy for identifying
congestion, nor even for responding to it. However, it is arguably
"TCP-friendly" to switch half your bandwidth to an alternate path when
congestion is experienced...

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