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

Marshall Eubanks <tme@multicasttech.com> Wed, 22 October 2008 15:32 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 91DA428C17F; Wed, 22 Oct 2008 08:32:20 -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 7CDCC28C177; Wed, 22 Oct 2008 08:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.43
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shlLp05IIKUZ; Wed, 22 Oct 2008 08:32:12 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 4093128C162; Wed, 22 Oct 2008 08:32:11 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13478888; Wed, 22 Oct 2008 11:32:54 -0400
Message-Id: <9821BF99-1F8F-41BE-8E6C-28A9E6EE8427@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <B8DDD0F9-ECC0-41D3-92AB-62F01682F003@icsi.berkeley.edu>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 22 Oct 2008 11:32:52 -0400
References: <C524324B.132CE%rpenno@juniper.net> <48FEEFDB.6000801@tm.uka.de> <B8DDD0F9-ECC0-41D3-92AB-62F01682F003@icsi.berkeley.edu>
X-Mailer: Apple Mail (2.929.2)
Cc: tsv-area@ietf.org, tana@ietf.org, Roland Bless <bless@tm.uka.de>, p2pi@ietf.org
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 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 ?

Regards
Marshall


> 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
> tana@ietf.org
> https://www.ietf.org/mailman/listinfo/tana

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