Re: [p2pi] Refining the ALTO problem statement

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.

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?

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

----- Original Message -----
From: "Stanislav Shalunov" <shalunov@shlang.com>
To: "John Leslie" <john@jlc.net>
Cc: p2pi@ietf.org
Sent: Monday, June 23, 2008 7:58:39 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] Refining the ALTO problem statement

On Mon, Jun 23, 2008 at 9:45 AM, John Leslie <john@jlc.net> wrote:
>   P2P applications have good reason to want to know (instantaneous)
> congestion, and what the likelihood is that the congestion will get
> better or worse soon.

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.

--
Stanislav Shalunov
http://shlang.com/
_______________________________________________
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