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

"Rolf Winter" <Rolf.Winter@nw.neclab.eu> Wed, 22 October 2008 09:49 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 8B7703A6BA0; Wed, 22 Oct 2008 02:49:11 -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 1F9FC3A6B80; Wed, 22 Oct 2008 02:49:10 -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=[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 LYX1XyL1pulV; Wed, 22 Oct 2008 02:49:09 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 885443A6B8F; Wed, 22 Oct 2008 02:49:08 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 973BB2C0012CA; Wed, 22 Oct 2008 11:50:24 +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 2t7wkaq2bBql; Wed, 22 Oct 2008 11:50:24 +0200 (CEST)
Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 66DE02C000359; Wed, 22 Oct 2008 11:49:59 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Oct 2008 11:49:53 +0200
Message-ID: <547F018265F92642B577B986577D671C3E03C0@VENUS.office>
In-Reply-To: <C5243C0E.132D9%rpenno@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tana] [tsv-area] TANA proposed charter
Thread-Index: Ack0IDFzKICC1YdMcEeFx9GSPrY0QwAAr9xAAADEhWsAAJZU8A==
References: <547F018265F92642B577B986577D671C3E039F@VENUS.office> <C5243C0E.132D9%rpenno@juniper.net>
From: "Rolf Winter" <Rolf.Winter@nw.neclab.eu>
To: "Reinaldo Penno" <rpenno@juniper.net>, "Michael Welzl" <michael.welzl@uibk.ac.at>, <tana@ietf.org>, <p2pi@ietf.org>, <tsv-area@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

Inline.

  
> >> 
> >> I'm not sure I'm reading the semantics of "Less than Best Effort" 
> >> like other folks.
> >> 
> >> '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'.
> > 
> > I read this point in the charter differently. My interpretation is 
> > that if there is something available that helps you to achieve 
> > less-than-best-effort then please make use of it. TANA is not 
> > chartered to promote the global adoption of DiffServ for 
> this purpose.
> 
> Let me ask it differently. Is a deliverable of the algorithm 
> to "desired feaures...where available, use explicit 
> congestion notification (ECN), active queue management (AQM), 
> and/or end-to-end differentiated services (DiffServ)." ?
> 
> In other words, beside the immediate deliverable to provide 
> an algorithm that is delay bound, are we also going to 
> specify how this new algorithm "use" those other features?
> 

How such a feature could be used is very likely already documented to a sufficient level of detail elsewhere. See e.g. the RFC Roland quoted earlier. I personally think TANA should focus on what can be achieved in the absence of these features. From a charter perspective, it would be wrong to neglect the existence of these features though. So if somebody feels that there is a significant gap that leaves a number of questions open on how TANA could make use of an existing technique then I believe there is room in the WG for that. DiffServ I personally feel might not meet that criteria. But it is a very good point you raise and maybe the charter could be made more explicit in that respect.

> It could go either way, I'm just looking for clarification on 
> the scope of the problem.
> > 
> >> 
> >> 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?
> >> 
> >> 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).
> > 
> > That is exactly the point. P2P should not "harm" inelastic 
> traffic. In 
> > order to do that, queues should not build up as a 
> consequence of the P2P traffic.
> > The charter according to my interpretation says that the 
> most suitable 
> > of the set of available means should be used or any 
> combination of it 
> > that makes sense.
> 
> Inelastic as is VoIP? In this case instead of making P2P as 
> less than best effort you can mark VoIP with EF. So, there is 
> no need for "less than best effort" in this case from a 
> Diffserv perspective, only from a algorithmic perspective.

Yes, if DiffServ is availabe you could do all sorts of things.

> 
> Thanks,
> 
> Reinaldo
> 
> > 
> >> 
> >> Thanks,
> >> 
> >> Reinaldo
> >> 
> >> 
> >> On 10/22/08 12:53 AM, "Michael Welzl"
> >> <michael.welzl@uibk.ac.at> wrote:
> >> 
> >>> I agree 100%, about both - charter and LETBET (which is 
> my favorite 
> >>> name proposal)
> >>> 
> >>> Cheers,
> >>> Michael
> >>> 
> >>> 
> >>> On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote:
> >>>> Hi,
> >>>> 
> >>>> I also think the charter is very well scoped.
> >>>> 
> >>>> However I'd like to see the *multiple connections* work item 
> >>>> elaborated and explained a little bit more!
> >>>> 
> >>>> about the name proposal both "LETBET (LEss Than Best Effort 
> >>>> Transport)" and "Scavenger Network Congestion Protocols"
> >> sound good proposal to me.
> >>>> 
> >>>> /sal
> >>>> 
> >>>> Michael Menth wrote:
> >>>>> Hi,
> >>>>> 
> >>>>> I also find the charter good and like Ingemar's name proposal 
> >>>>> "LETBET (LEss Than Best Effort Transport)"
> >>>>> 
> >>>>> Michael
> >>>>> 
> >>>>> Ingemar Johansson S wrote:
> >>>>>> Hi
> >>>>>> 
> >>>>>> Even though I understand that it is better to focus on
> >> the charter
> >>>>>> than in the name I too beleieve that TANA does not say much.
> >>>>>> 
> >>>>>> I believe that somewhere along the track and also in 
> the charter 
> >>>>>> the term "less than best effort transmission" was/is 
> mentioned A 
> >>>>>> possible name would then be LETBET (LEss Than Best Effort
> >>>>>> Transport)
> >>>>>> 
> >>>>>> That said... there are a whole bunch of WG names out
> >> there that at
> >>>>>> first glance does not say anything about the group.
> >>>>>> The charter looks OK from my perspective.
> >>>>>> 
> >>>>>> /Ingemar
> >>>>>> 
> >>>>>>  
> >>>>>>> -----Original Message-----
> >>>>>>> From: tsv-area-bounces@ietf.org
> >> [mailto:tsv-area-bounces@ietf.org]
> >>>>>>> On Behalf Of Ted Faber
> >>>>>>> Sent: den 21 oktober 2008 18:51
> >>>>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]
> >>>>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org
> >>>>>>> Subject: Re: [tsv-area] TANA proposed charter
> >>>>>>> 
> >>>>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M.
> >>>>>>> (GRC-RCN0)[VZ] wrote:
> >>>>>>>    
> >>>>>>>> But if nobody else has a problem with the TANA name,
> >> I'll keep my
> >>>>>>>> mouth shut so we don't waste time and energy.  There are
> >>>>>>> bigger fish to fry!
> >>>>>>> 
> >>>>>>> It should change.
> >>>>>>> 
> >>>>>>> I care about congestion control and nothing in the 
> expansion of 
> >>>>>>> TANA indicated it was about congestion (to me).
> >>>>>>> 


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi