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

Salman Abdul Baset <sa2086@columbia.edu> Tue, 21 October 2008 17:20 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 D2AAC3A6B7F; Tue, 21 Oct 2008 10:20:00 -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 729AA3A6B74; Tue, 21 Oct 2008 10:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 1RDC-L+0E4Ld; Tue, 21 Oct 2008 10:19:58 -0700 (PDT)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id A31E33A6953; Tue, 21 Oct 2008 10:19:58 -0700 (PDT)
Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9LHKgUn019027; Tue, 21 Oct 2008 13:20:42 -0400 (EDT)
Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9LHKg5B025191; Tue, 21 Oct 2008 13:20:42 -0400 (EDT)
Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m9LHKgWu025188; Tue, 21 Oct 2008 13:20:42 -0400 (EDT)
X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs
Date: Tue, 21 Oct 2008 13:20:42 -0400 (EDT)
From: Salman Abdul Baset <sa2086@columbia.edu>
To: Stanislav Shalunov <shalunov@shlang.com>
In-Reply-To: <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com>
Message-ID: <alpine.SOC.1.00.0810211311280.23756@banana.cc.columbia.edu>
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>
User-Agent: Alpine 1.00 (SOC 882 2007-12-20)
MIME-Version: 1.0
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6
Cc: p2pi@ietf.org, TSV Area <tsv-area@ietf.org>, tana@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, "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"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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

To add:

Some traffic is more important than others. A rough ordering is:
VoIP > interactive > video-streaming > file-transfer > p2p

The general recommendation by VoIP providers is to manually shutdown the 
p2p application(s) so as not to affect the calls. This manual shutdown is 
quite annoying for a user.

-s


> 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.)
>
> -- Stas
>
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi