Re: [ledbat] list of reasons for needing multiple TCP connections

"Robb Topolski" <robb@funchords.com> Wed, 26 November 2008 01:12 UTC

Return-Path: <ledbat-bounces@ietf.org>
X-Original-To: tana-archive@ietf.org
Delivered-To: ietfarch-tana-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBFC3A6AF8; Tue, 25 Nov 2008 17:12:08 -0800 (PST)
X-Original-To: ledbat@core3.amsl.com
Delivered-To: ledbat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3C63A6953 for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 17:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, 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 YDrD0knh94uD for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 17:12:06 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 24A553A6859 for <ledbat@ietf.org>; Tue, 25 Nov 2008 17:12:05 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so198935rvf.49 for <ledbat@ietf.org>; Tue, 25 Nov 2008 17:12:02 -0800 (PST)
Received: by 10.141.106.14 with SMTP id i14mr2655489rvm.143.1227661922478; Tue, 25 Nov 2008 17:12:02 -0800 (PST)
Received: by 10.141.69.3 with HTTP; Tue, 25 Nov 2008 17:12:02 -0800 (PST)
Message-ID: <3efc39a60811251712x1e2e8b64jf7e8e37ca9305b33@mail.gmail.com>
Date: Tue, 25 Nov 2008 17:12:02 -0800
From: Robb Topolski <robb@funchords.com>
To: Stanislav Shalunov <shalunov@shlang.com>
In-Reply-To: <ED900FCE-9E54-442E-8401-FF657B1CF654@shlang.com>
MIME-Version: 1.0
References: <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> <C5507EE5.16A89%rpenno@juniper.net> <FCA794787FDE0D4DBE9FFA11053ECEB61AFFFAE532@NA-EXMSG-C110.redmond.corp.microsoft.com> <ED900FCE-9E54-442E-8401-FF657B1CF654@shlang.com>
Cc: ledbat@ietf.org
Subject: Re: [ledbat] list of reasons for needing multiple TCP connections
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1330628882=="
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

If Skype hasn't made the list, it's a multiple connection user and I think
some nodes are given additional mesh responsibilties depending upon their
connectivity.  Consider data of the "well I heard" quality.  Although I have
noticed the multiple connections, I haven't done any great work to profile
it.

On Tue, Nov 25, 2008 at 3:43 PM, Stanislav Shalunov <shalunov@shlang.com>wrote:

> "Mostly idle" BitTorrent connections periodically exchange small messages
> (haves and, failing that, keepalives).  They will consume the NAT slots,
> even though they mostly don't matter for other purposes.
>
> This is generally not a problem for the number of connections BitTorrent
> maintains.
>
>
A common issue with P2P file-sharing users of NATs isn't limited to the TCP
connections created for the mainstream functions of the network but the UDP
table entries created by their various DHT networks.

>From a middlebox perspective, they probably take as many bytes in a table as
TCP connections do.




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