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

"Rolf Winter" <Rolf.Winter@nw.neclab.eu> Thu, 23 October 2008 03:52 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 1D55E3A68A8; Wed, 22 Oct 2008 20:52:44 -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 F0CC53A68A8; Wed, 22 Oct 2008 20:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Dt+0bPCvYpZi; Wed, 22 Oct 2008 20:52:42 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B82D43A6358; Wed, 22 Oct 2008 20:52:41 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A325F2C0008DF; Thu, 23 Oct 2008 05:53:59 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-7LOD+3QWlc; Thu, 23 Oct 2008 05:53:59 +0200 (CEST)
Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 776F62C000359; Thu, 23 Oct 2008 05:53:34 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 23 Oct 2008 05:53:30 +0200
Message-ID: <547F018265F92642B577B986577D671C3E049E@VENUS.office>
In-Reply-To: <B8DDD0F9-ECC0-41D3-92AB-62F01682F003@icsi.berkeley.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tana] [tsv-area] TANA proposed charter
Thread-Index: Ack0WnLXii25mH7vQ/i0lZO4Fz16QAAX4m8g
References: <C524324B.132CE%rpenno@juniper.net> <48FEEFDB.6000801@tm.uka.de> <B8DDD0F9-ECC0-41D3-92AB-62F01682F003@icsi.berkeley.edu>
From: "Rolf Winter" <Rolf.Winter@nw.neclab.eu>
To: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>, "Roland Bless" <bless@tm.uka.de>
Cc: tsv-area@ietf.org, tana@ietf.org, 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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Nicholas,

I think in your Email below you are asking the right questions. That said, this is probably not about the charter any more but already doing the work (and this is very good as the new version of the charter looks fine - to me at least).

	Rolf

> -----Original Message-----
> From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On 
> Behalf Of Nicholas Weaver
> Sent: Thursday, October 23, 2008 12:25 AM
> To: Roland Bless
> Cc: p2pi@ietf.org; tsv-area@ietf.org; tana@ietf.org; Nicholas Weaver
> Subject: Re: [tana] [tsv-area] TANA proposed charter
> 
> 
> 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