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

"Das, Saumitra" <> Tue, 21 October 2008 21:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id A25B03A6BB8; Tue, 21 Oct 2008 14:49:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 818AF3A6BA4; Tue, 21 Oct 2008 14:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.695
X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1oa0ZH3r7A3S; Tue, 21 Oct 2008 14:49:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 406B43A657C; Tue, 21 Oct 2008 14:49:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1224625829; x=1256161829; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20<>|To: =20""=20<>|CC:=20" "=20<>,=20""=20<tsv-area@ie>|Date:=20Tue,=2021=20Oct=202008=2014:49:26=20-0700 |Subject:=20Re:=20[p2pi]=20[tsv-area]=20[tana]=20TANA=20p roposed=20charter|Thread-Topic:=20Re:=20[p2pi]=20[tsv-are a]=20[tana]=20TANA=20proposed=20charter|Thread-Index:=20A ckzxuMJVlalFty0Sjmg1UhH9UMnxA=3D=3D|Message-ID:=20<4A27D0>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D35 2FD30NASANEXMB04na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5411"=3B=20a=3D"11145210"; bh=TJhjloB0bSJU+f4DL1evDG2ppPgjG8cfjIInCfDloRo=; b=Q6mzTC7/FGuFnyXmiRulIE9FYSTSEmKb15wzYCk91d0/pkR/Tyq0YsuV TMWwQu/KgS2fr/z7942NQFxHCZ1ujTeo3ND0heKIeH+zZNQOykvyOAzYS WX2hF7fQM5qYQ0OL+QChkTT/48P6TfJltKuLDRwA5e4XC+o25UqegvBHT w=;
X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11145210"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 14:49:35 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m9LLnYkx030905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 14:49:35 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m9LLnYNN024558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 14:49:34 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 14:49:34 -0700
Received: from ([]) by ([]) with mapi; Tue, 21 Oct 2008 14:49:34 -0700
From: "Das, Saumitra" <>
To: "" <>
Date: Tue, 21 Oct 2008 14:49:26 -0700
Thread-Topic: Re: [p2pi] [tsv-area] [tana] TANA proposed charter
Thread-Index: AckzxuMJVlalFty0Sjmg1UhH9UMnxA==
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [p2pi] [tsv-area] [tana] TANA proposed charter
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1128606700=="

>>Murari Sridharan wrote:

>> Isn't the goal here to achieve lower than best-effort, so essentially

>> "Low Priority TCP",

> > assuming non-TCP traffic flows E2E we can make it more general and call it "Congestion control  > for low priority flows"


>> Murari


>A successful algorithm here would not necessarily "lower than"

>best-effort, because the "low priority' flow could actually achieve higher throughput than a conventional TCP flow.

>I believe that the key phrase in the proposed charter is very much on target -- that the "TANA flows" rapidly yield to conventional TCP.

>It is possible to both rapidly yield *and* to rapidly claim bandwidth that conventional TCP algorithms would have left unused.

>The extent to which a given algorithm can rapidly claim bandwidth without imperiling existing TCP traffic is of course something that the WG would have >o review. But given the charter objective of "saturation" it is important to understand that this is not necessarily "low priority" traffic. It is >ndoubtedly very jitter-tolerant traffic that can be quite elastic in its bandwidth utilization for any short period of time.


>Caitlin Bestler

><> -

I think the term low priority refers to yielding to a conventional TCP flow and in those terms TANA flows are low priority.

The fact that they could claim unused and available bandwidth doesn't change the fact that they are lower priority than conventional TCP.

I agree with your point that this could in fact rapidly claim bandwidth faster than conventional TCP depending on the design but the priority consideration with relation to conventional TCP still remains.

I was wondering how different or aligned the goals of TANA are with something like TCP-LP which also yields to conventional TCP but uses the available

Unused bandwidth. Are we differentiating it based on the fact that TANA would be more aggressive in reclaiming unused bandwidth to the point of being

higher throughput than a conventional TCP flow? Or is TCP-LP one of the solution points for consideration.



p2pi mailing list