Subject: Re: [p2pi] Refining the ALTO problem statement

From: Laird Popkin <[email-masked]>
Date: Mon, 16 Jun 2008 13:47:40 -0400 (EDT)

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" <[email-masked]>
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Laird Popkin <[email-masked]>
Date: Thu, 26 Jun 2008 14:55:46 -0400 (EDT)

----- Original Message -----
From: "stefano previdi" <[email-masked]>
To: "Laird Popkin" <[email-masked]>, "Stanislav Shalunov" <[email-masked]>
Cc: [email-masked]
Sent: Thursday, June 26, 2008 2:16:02 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] Refining the ALTO problem statement

> From: Laird Popkin <[email-masked]>
> 
> I agree with Stanislav's main point (ALTO should focus on providing new
> information). We've had extensive email chains listing such opportunities, so
> no need to repeat them here.
> 
> That being said, there's some value in knowing about congestion more precisely
> than we do now. In particular, it would be good to know when:
> 
> 1) The user's internet connection is saturated (and in which direction) so
> that the application as a whole can reduce bandwidth to de-saturate the link.
> Many p2p apps do this now, but the techniques for attempting to indirectly
> detect 'edge' link saturation are inconsistent in their effectiveness. If the
> edge router could tell app's the precise situation, that would help app's
> avoid saturating links while maximizing performance.

it's a matter of trade-off in terms of complexity for retrieving the
information at that granularity level you need it and the improved
correctness/usefulness of it. IOW: what you get now may be good enough
already.

LP: The techniques for detecting edge link saturation are pretty inconsistent. For example, if you ping a router near the edge, the ping times might vary due to link saturation, or due to the router being busy doing more important things than responding to a ping (e.g. routing other traffic, router reconfiguration), etc. So (unless I've missed some fantastic technique that I'd love to know about) the current strategies aren't very good, so there's room for improvement. At any rate, the RTT time numbers for users behind saturated home/edge routers that Stanislav presented at the P2Pi Workshop were alarming enough to me that I think we should think about ways to alleviate this issue.

> 2) A specific TCP stream to a specific peer is saturated, in which case we
> should slow down that stream and pull more data from elsewhere. Re-ECN looks
> like it'll address the latter scenario. What's the relationship (if any)
> between Re-ECN and ALTO?

I wonder if we have a granularity problem here. A given app/p2p client may
be interested into path characteristics for the flow is going to
originate/receive.

However, the provider infrastructure may not (easily/consistently) deliver
this level of visibility (measuring the impact of a few Mb flow over a
multi-Gb backbone).

LP: Re-ECN (http://www.cs.ucl.ac.uk/staff/bbriscoe/projects/refb/) doesn't predict anything, and (unless I misread the doc's) has no global knowledge - it's a mechanism allowing routers to report to the endpoints of a TCP stream that the stream is currently dropping packets due to congestion. This is useful because p2p apps could then differentiate between a slow but reliable stream that should continue as-is and a congested link where we may want to 'back off' so that the congestion can potentially be alleviated. This could (for example) allow downloaders to request less data from uploaders with saturated links, making them (and potentially their neighbors) happier. Admittedly the saturation could occur anywhere in the stream, but as long as there are a sufficient number of peer data sources, pulling less data from saturated streams seems like it's good for everyone. Certainly having the information exposed so that applications could at least have the potential to alleviate congestion seems like a good idea.
 
> From: "Stanislav Shalunov" <[email-masked]>
> 
> This is the function of transport.  P2P apps, by doing e2e
> measurements, already have pretty decent information about state of
> congestion, and use it just the way you'd expect.
> 
> What P2P apps don't have, and what ALTO should provide, is new
> information -- not whether a path is congested, but whether a path is
> preferred by the ISP.  Some simple notion of cost or preferred ASes or
> IP prefixes or whatnot.
> 
> This is information that the routing layer has and that the overlay
> routing in P2P has no access to.

I definitely subscribe to this.

s.

> --
> Stanislav Shalunov
> http://shlang.com/