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

"Robb Topolski" <robb@funchords.com> Mon, 27 October 2008 04: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 910743A6825; Sun, 26 Oct 2008 21:52:54 -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 C2F093A67DB for <p2pi@core3.amsl.com>; Sun, 26 Oct 2008 21:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.624
X-Spam-Level:
X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 hEYlIHfllCU0 for <p2pi@core3.amsl.com>; Sun, 26 Oct 2008 21:52:53 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 9D7CF3A6850 for <p2pi@ietf.org>; Sun, 26 Oct 2008 21:52:50 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1853607rvf.49 for <p2pi@ietf.org>; Sun, 26 Oct 2008 21:52:50 -0700 (PDT)
Received: by 10.140.127.20 with SMTP id z20mr2985414rvc.77.1225083169952; Sun, 26 Oct 2008 21:52:49 -0700 (PDT)
Received: by 10.141.69.3 with HTTP; Sun, 26 Oct 2008 21:52:49 -0700 (PDT)
Message-ID: <3efc39a60810262152t69b45422h8dcdf3797b47a164@mail.gmail.com>
Date: Sun, 26 Oct 2008 21:52:49 -0700
From: Robb Topolski <robb@funchords.com>
To: Stanislav Shalunov <shalunov@shlang.com>
In-Reply-To: <466D7202-630F-4F59-B0F7-3C0D32CFB49B@shlang.com>
MIME-Version: 1.0
References: <mailman.3860.1224623104.4981.p2pi@ietf.org> <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com> <466D7202-630F-4F59-B0F7-3C0D32CFB49B@shlang.com>
Cc: "p2pi@ietf.org" <p2pi@ietf.org>, "tana@ietf.org" <tana@ietf.org>, "Das, Saumitra" <saumitra@qualcomm.com>, "tsv-area@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: multipart/mixed; boundary="===============0096812619=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

For reasons I don't quite understand, my view of this conversation is very
fragmented.


On Tue, Oct 21, 2008 at 3:02 PM, Stanislav Shalunov <shalunov@shlang.com>wrote:

> The genesis of TANA was at the P2PI workshop.  A lot of people there were
> concerned about multiple connections used by P2P apps.  Some concerns are
> meritorious, others require mostly just information -- there, apparently,
> exists a belief that P2P apps are designed to open multiple TCP connections
> to the same destination to circumvent TCP fairness.  (I even have an inkling
> of how that one could get started.)
>

People also said that P2P applications filled up all available bandwidth,
with no explanation provided as to how these applications exceed the limits
programmatically imposed by the ISP.

Before anyone redefines fairness, we need data on the current situation.  We
need to ensure that redefining fairness isn't simply suppressing a market
choice.  One ISP is reportedly prioritizing HTTP above most other traffic.
If, 15 years ago, someone prioritized Gopher over all other traffic, then
probably never would have succeeded it.

Please let's not write this problem statement without data confirming the
problem and the size of the fairness bias (which probably does exist on
paper, but we have no data as to the extent given these applications at
ISP-subscriber speeds and P2P latencies).


Also, I think the name change is useful since there is not inkling that this
>> really is about congestion control. Scavenger Network Congestion Protocols
>> sounds good.
>>
>
> White ball noted.  That makes three.  Incidentally, does anyone *dislike*
> this name?
>
>
I worry about the idea of moving congestion management and packet handling
instructions up a layer in the network stack.   Worry is not fatal, but it
fogs up an area of clarity.  I also worry that the last two attempts to help
transit providers understand their customer's packets handling needs haven't
really been seriously trialled by ISPs as far as I know.

-- 
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi