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

Roland Bless <bless@tm.uka.de> Wed, 22 October 2008 15:05 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 F36DF28C177; Wed, 22 Oct 2008 08:05:27 -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 CBCA83A69E9; Wed, 22 Oct 2008 02:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 NLH4ifpZDx3C; Wed, 22 Oct 2008 02:17:28 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id B8B113A693A; Wed, 22 Oct 2008 02:17:27 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1KsZrE-0002Km-SI; Wed, 22 Oct 2008 11:18:26 +0200
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1KsZrE-0005vF-P9; Wed, 22 Oct 2008 11:18:24 +0200
Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A0E7B2FC04F; Wed, 22 Oct 2008 11:18:24 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id AC7FE10390; Wed, 22 Oct 2008 11:18:21 +0200 (CEST)
Message-ID: <48FEEFDB.6000801@tm.uka.de>
Date: Wed, 22 Oct 2008 11:18:19 +0200
From: Roland Bless <bless@tm.uka.de>
Organization: Institute of Telematics, University of Karlsruhe
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Reinaldo Penno <rpenno@juniper.net>
References: <C524324B.132CE%rpenno@juniper.net>
In-Reply-To: <C524324B.132CE%rpenno@juniper.net>
X-Enigmail-Version: 0.95.0
X-Mailman-Approved-At: Wed, 22 Oct 2008 08:05:26 -0700
Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org, Michael Welzl <michael.welzl@uibk.ac.at>
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

Hi Reinaldo,

Reinaldo Penno wrote:
> I'm not sure I'm reading the semantics of "Less than Best Effort" like other
> folks. 

Maybe RFC 3662 defines this more clearly.

> 'Best Effort' has a well-defined semantics in the scope of Diffserv,
> including a code point of its own. Less than best effort seems we are
> defining a code point for such applications. Are we? The charter talks about
> 'end-to-end Diffserv'.

See RFC 3662

> End-to-end diffserv is a challenge on its own given ISP policies, etc.
> 
> If the link is not saturated, are such application also treated as 'less
> than best effort' by still being DSCP marked and treated differently within
> routers? 

Usually lower effort (LE) packets will go into a different queue
and served only if no other BE packets are waiting. So if
the BE queue is empty, LE packets will get the same treatment as BE
packets. Only in case of congestion, LE packets will be treated
differently.

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

Regards,
 Roland

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