Re: [p2pi] Refining the ALTO problem statement
Laird Popkin <laird@pando.com> Thu, 26 June 2008 18:56 UTC
Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F963A6802; Thu, 26 Jun 2008 11:56:07 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B0F3A6937 for <p2pi@core3.amsl.com>; Thu, 26 Jun 2008 11:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.265
X-Spam-Level:
X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMrp3jBbwVpT for <p2pi@core3.amsl.com>; Thu, 26 Jun 2008 11:56:04 -0700 (PDT)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id BBF2C3A6802 for <p2pi@ietf.org>; Thu, 26 Jun 2008 11:56:03 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id AC4ABE10C3A; Thu, 26 Jun 2008 14:56:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zj0dEHaYMU1; Thu, 26 Jun 2008 14:55:46 -0400 (EDT)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 6350FE10C2A; Thu, 26 Jun 2008 14:55:46 -0400 (EDT)
Date: Thu, 26 Jun 2008 14:55:46 -0400
From: Laird Popkin <laird@pando.com>
To: stefano previdi <sprevidi@cisco.com>
Message-ID: <1919377032.439661214506546365.JavaMail.root@dkny.pando.com>
In-Reply-To: <868806184.439611214506011794.JavaMail.root@dkny.pando.com>
MIME-Version: 1.0
X-Originating-IP: [71.187.207.81]
Cc: p2pi@ietf.org, Stanislav Shalunov <shalunov@shlang.com>
Subject: Re: [p2pi] Refining the ALTO problem statement
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org
- Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "stefano previdi" <sprevidi@cisco.com> To: "Laird Popkin" <laird@pando.com>, "Stanislav Shalunov" <shalunov@shlang.com> Cc: p2pi@ietf.org 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 <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. 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" <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
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Stanislav Shalunov