Re: [p2pi] Refining the ALTO problem statement

> From: Laird Popkin <laird@pando.com>
> 
> 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.

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

> From: "Stanislav Shalunov" <shalunov@shlang.com>
> 
> 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/
> _______________________________________________
> 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

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