Re: [p2pi] Refining the ALTO problem statement

Of the options that you lay out, I think that most p2p applications would want "look for another path (but the guidance was that this is the best path most of the time)".

The other options don't reflect the fact that p2p networks continually look for new p2p connections to establish and utilize. So even if you tell Lars that "this path is available on Saturday nights" his software should make lots of other p2p connections. Given a well connected p2p mesh (which is our goal), p2p applications will always shift data transfers away from congested sources to more available sources. Right now this decision is usually made based on observed throughput, though I personally hope that ECN and Re-ECN can help us make better informed decisions.

There's also a matter of timing. In the ALTO and P4P models proposed, the ISP guidance only affects which peers are introduced to each other. Once peers are connected, the data flow is managed by the p2p network. Since p2p connections can be very long lasting (often hours or even days), the ISP cannot really control the p2p network's real-time data flow.

Keep in mind, though, that the ISP guidance will not replace whatever else the P2P networks do to optimize performance. At most, the oracle will provide some guidance that is hopefully of mutual benefit. But there will always be additional sources of peers (e.g. random peers, peer exchange) and other sources of information (e.g. observed throughput, RTT's).

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Spencer Dawkins" <spencer@wonderhamster.org>
To: p2pi@ietf.org
Sent: Monday, June 16, 2008 9:31:04 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Refining the ALTO problem statement

I don't actually think I'm good at channeling ADs, but for what it's 
worth...

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.

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!),

- look for another path (but the guidance was that this is the best path 
most of the time), or

- 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 - 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")

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

Thanks,

Spencer 

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi