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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Wed, 22 October 2008 15:24 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 0970328C13D; Wed, 22 Oct 2008 08:24:13 -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 7740328C118; Wed, 22 Oct 2008 08:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Level:
X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=0.891, 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 iVeYBX1qDIDD; Wed, 22 Oct 2008 08:24:10 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6655328C11C; Wed, 22 Oct 2008 08:24:10 -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 m9MFP7x3010650; Wed, 22 Oct 2008 08:25:12 -0700 (PDT)
Message-Id: <B8DDD0F9-ECC0-41D3-92AB-62F01682F003@icsi.berkeley.edu>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Roland Bless <bless@tm.uka.de>
In-Reply-To: <48FEEFDB.6000801@tm.uka.de>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 22 Oct 2008 08:25:06 -0700
References: <C524324B.132CE%rpenno@juniper.net> <48FEEFDB.6000801@tm.uka.de>
X-Mailer: Apple Mail (2.929.2)
Cc: p2pi@ietf.org, tsv-area@ietf.org, tana@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [p2pi] [tana] [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 22, 2008, at 2:18 AM, Roland Bless wrote:
>> I would like if possible to decouple the 'less than best effort',  
>> as in
>> diffserv, from the algorithm per se.
>>
>> Besides, there are ISPs that are worried about the effect that P2P  
>> have on
>> other applications when the link is saturated, but otherwise they  
>> do not
>> care. P2P would be treated like best effort in non-saturated  
>> situations (a
>> more ECN type approach).
>
> Yes, and that's exactly where LE helps: an ISP can be sure that
> LE traffic will not harm other BE traffic at any time. In case
> of congestion BE traffic will preempt LE traffic. If the
> link is not saturated, LE will be treated like BE.

This is also roughly how Comcast is implementing fairness on their  
network:  Any user identified as being above a threshold of usage  
(averaged over ~15 minutes) is placed into a lower QoS category.  And  
as long as there is at least some capacity headroom left over, the  
heavy users aren't starved out, the light users don't notice, and the  
heavy users traffic just negotiates between itself.


However, this brings up a question:

Should a scavenger service be true LE, if the network does not support  
QoS?  In such a case, the service can't yield instantly anyway, so the  
question is what is the equilibrium it goes to relative to other flows.

Should it actually yield completely to other TCP flows on the network?

Or should it instead have some equilibrium position thats a stated  
fraction of what a normal TCP flow would achieve under the  
circumstances?


EG, a "Scavenger App" has N flows, on a congested link shared with a  
significant number of normal TCP flows.

Given x is the equilibrium transfer rate of a single TCP flow.

If the scavenger app's flows were normal TCP, the equilibrium point in  
congestion with others would be Nx

Should the goal be to have the equilibrium value be X?  (No matter the  
# of peers, the app behaves like a single TCP flow for equilibrium  
purposes)

Should the goal be to have the equilibrium be some fraction of X?  Zero?

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