Re: [p2pi] [tsv-area] TANA proposed charter

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Tue, 21 October 2008 17:40 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 F3FED28C162; Tue, 21 Oct 2008 10:40:37 -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 EDFF23A6AC1; Tue, 21 Oct 2008 10:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.54
X-Spam-Level:
X-Spam-Status: No, score=-5.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ym1k5k-bK06S; Tue, 21 Oct 2008 10:40:35 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2412C3A68E1; Tue, 21 Oct 2008 10:40:35 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LHfkrN004602; Tue, 21 Oct 2008 10:41:46 -0700 (PDT)
Message-Id: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Stanislav Shalunov <shalunov@shlang.com>
In-Reply-To: <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 10:41:46 -0700
References: <AE465507-305C-41A4-BE95-311BB628064B@shlang.com> <B5A5E01F9387F4409E67604C0257C71E660E5F@NDJSEVS25A.ndc.nasa.gov> <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com>
X-Mailer: Apple Mail (2.929.2)
Cc: tana@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, p2pi@ietf.org, TSV Area <tsv-area@ietf.org>, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

On Oct 21, 2008, at 10:06 AM, Stanislav Shalunov wrote:
>> Yet why would a bulk-data content provider want to USE it?
>
> This is a great question and it deserves a more detailed answer than  
> this, but let me try, briefly, to provide one reason to use it:
>
> Because the user wants to use the Internet while P2P app is doing  
> whatever it is doing.  Or the user will uninstall the app.
>
> The content provider serves at the leisure of the user.  The user is  
> willing to share uplink capacity as long as the sharing is largely  
> invisible.  The user will be upset by uploads that affect the user's  
> ability to use the network for interactive applications and web  
> browsing.
>
> (There are other scenarios, particularly with shared congestion and  
> traffic management, that generally push the content provider to be  
> nicer, so the above is just one example.)

However, the "Internet Not Working" effect is a subpiece of the  
overall problem:  It is buffer occupancy on end-user buffers where the  
buffers are on the order of 1+ RTT (often 1+ Second!).   Otherwise,  
the incentives are to be as UN-friendly as possible, as the  
externalities of congestion, EXCEPT at the access-link device, are  
applied to other users.

Thus the P2P application provider can use existing RTT-based  
congestion control techniques to look for a greater than .25 RTT  
increase in delay, and respond to it by shrinking window sizes until  
the RTT drops and at-that-point, call it good.

In fact, simply feed this into bandwidth estimation:  Do an initial  
uncongested bandwidth estimation on startup (packet-pair measurement)  
to other peers (eliminates the "select a bandwidth" checkbox, bonus!),  
attempt to allocate to the whole pipe-5% with your TCP flows, and do  
an immediate backoff/slow ramp-back when you see RTTs increasing to  
MULTIPLE peers.

Although a new class of congestion control that would do a true end-to- 
end job would be a better solution, the partial solution is complete  
from the P2P application provider's viewpoint: it fixes the "We break  
the net for everything else" effect on the user, while still keeping  
the very agressive (many-flow TCP) properties of P2P for the rest of  
the network.

Or at least until you bribe the NAT box vendors to implement some  
active queue management.

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