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

Marshall Eubanks <> Wed, 22 October 2008 15:32 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 91DA428C17F; Wed, 22 Oct 2008 08:32:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CDCC28C177; Wed, 22 Oct 2008 08:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.43
X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id shlLp05IIKUZ; Wed, 22 Oct 2008 08:32:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4093128C162; Wed, 22 Oct 2008 08:32:11 -0700 (PDT)
Received: from [] (account marshall_eubanks HELO [IPv6:::1]) by (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13478888; Wed, 22 Oct 2008 11:32:54 -0400
Message-Id: <>
From: Marshall Eubanks <>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 22 Oct 2008 11:32:52 -0400
References: <> <> <>
X-Mailer: Apple Mail (2.929.2)
Cc:,, Roland Bless <>,
Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

On Oct 22, 2008, at 11:25 AM, Nicholas Weaver wrote:

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

If the network doesn't support QOS, how would it know ? If I am  
ignoring code points, how do I know what the
code point is ?


> 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?
> _______________________________________________
> tana mailing list

p2pi mailing list