From ledbat-bounces@ietf.org Tue Nov 11 10:30:03 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA3428C1BA; Tue, 11 Nov 2008 10:30:03 -0800 (PST) X-Original-To: ledbat@ietf.org Delivered-To: ledbat@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3D9CF28C18D; Tue, 11 Nov 2008 10:30:00 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20081111183001.3D9CF28C18D@core3.amsl.com> Date: Tue, 11 Nov 2008 10:30:01 -0800 (PST) Cc: ledbat@ietf.org Subject: [ledbat] WG Action: Low Extra Delay Background Transport (ledbat) X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Low Extra Delay Background Transport (ledbat) -------------------------------------------------------------- Current Status: Active Working Group Last Modified: 2008-11-06 Chair(s): * Stanislav Shalunov [shalunov@shlang.com] * Murari Sridhavan [muraris@microsoft.com] Transport Area Director(s): * Magnus Westerlund [magnus.westerlund@ericsson.com] * Lars Eggert [lars.eggert@nokia.com] Transport Area Advisor: * Lars Eggert [lars.eggert@nokia.com] Mailing Lists: General Discussion: ledbat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ledbat In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/ledbat/ Description of Working Group: The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck * eliminate long standing queues and thus keep delay low when no other traffic is present * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control * add little to the queueing delays induced by TCP traffic * operate well in networks with FIFO queueing with drop-tail discipline * be deployable for popular applications that currently comprise noticeable fractions of Internet traffic * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. Goals and Milestones: Oct 2009 Submit "Multiple Transport Connections in Applications Design" to the IESG for consideration as an Informational RFC Oct 2009 Submit "Low Extra Delay Background Transport (LEDBAT)" to the IESG for consideration as an Experimental RFC _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Tue Nov 11 10:36:27 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F63228C136; Tue, 11 Nov 2008 10:36:27 -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 A299D3A6851 for ; Tue, 11 Nov 2008 10:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 RNj2++Yf1ibJ for ; Tue, 11 Nov 2008 10:36:26 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id EC26F28C136 for ; Tue, 11 Nov 2008 10:36:22 -0800 (PST) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 11 Nov 2008 10:36:23 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.54.46.188]) with mapi; Tue, 11 Nov 2008 10:36:23 -0800 From: Murari Sridharan To: "ledbat@ietf.org" Date: Tue, 11 Nov 2008 10:36:19 -0800 Thread-Topic: Welcome to the LEBDAT WG Thread-Index: AclELGO6bLqCvtGlQm+Gx4gD52cwBg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [ledbat] Welcome to the LEBDAT WG X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017694825==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============2017694825== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFBC84B7CNAEXMSGC110re_" --_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFBC84B7CNAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Welcome to the LEBDAT WG. The charter looks exciting and we are going to ha= ve a lot of interesting discussions over the next year. Stas and I will syn= c up and send out a mail to discuss the agenda for the upcoming meeting @ M= inneapolis. Thanks --_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFBC84B7CNAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Welcome to the LEBDAT WG. The charter looks exciting a= nd we are going to have a lot of interesting discussions over the next year. Stas= and I will sync up and send out a mail to discuss the agenda for the upcoming meeting @ Minneapolis.

 

Thanks

--_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFBC84B7CNAEXMSGC110re_-- --===============2017694825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============2017694825==-- From ledbat-bounces@ietf.org Wed Nov 12 09:57:27 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942F53A6768; Wed, 12 Nov 2008 09:57:27 -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 CBEB53A6768 for ; Wed, 12 Nov 2008 09:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9DEjZ-JL+GqB for ; Wed, 12 Nov 2008 09:57:25 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 138C13A6407 for ; Wed, 12 Nov 2008 09:57:25 -0800 (PST) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 12 Nov 2008 09:57:25 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.88.96]) with mapi; Wed, 12 Nov 2008 09:57:24 -0800 From: Murari Sridharan To: "ledbat@ietf.org" Date: Wed, 12 Nov 2008 09:57:20 -0800 Thread-Topic: IETF 73 Meeting Agenda Thread-Index: AclE8BvmKLcaF37bQMyLBnktJmWTag== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [ledbat] IETF 73 Meeting Agenda X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1187822398==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============1187822398== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFC8406DFNAEXMSGC110re_" --_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFC8406DFNAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We're in the process of planning the agenda for the LEBDAT meeting in Minne= apolis. If you'd like to request a presentation slot or suggest topics, pl= ease let Stas and I know soon. (1) What the topic is (We should vote on some topics as well, what you woul= d consider intersting. ) (2) Who will present (3) How much time is requested. Ours is a 2 hour slot. For starters I think we should look at state-of-the-art in this area and I = think we should frame the problem both from sender and receiver-side contro= l as both of these offer interesting perspectives. Thanks --_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFC8406DFNAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We're in the process of planning the agenda for the LEBDAT meeting in Minneapolis= .  If you'd like to request a presentation slot or suggest topics, please let = Stas and I know soon.

 

(1) What the topic is (We should vote on some topics a= s well, what you would consider intersting. )

(2) Who will present

(3) How much time is requested. Ours is a 2 hour slot.

 

For starters I think we should look at state-of-the-ar= t in this area and I think we should frame the problem both from sender and rece= iver-side control as both of these offer interesting perspectives.

 

Thanks

--_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFC8406DFNAEXMSGC110re_-- --===============1187822398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============1187822398==-- From ledbat-bounces@ietf.org Thu Nov 13 03:03:32 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793283A68F6; Thu, 13 Nov 2008 03:03:32 -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 444E93A687E; Thu, 13 Nov 2008 03:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 Ub07RUq6qx8y; Thu, 13 Nov 2008 03:03:30 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 2C0BC3A6856; Thu, 13 Nov 2008 03:03:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mADB3Dk13506; Thu, 13 Nov 2008 12:03:13 +0100 (CET) Received: from [192.168.0.100] (ams3-vpn-dhcp5378.cisco.com [10.61.85.1]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mADB34G13306; Thu, 13 Nov 2008 12:03:06 +0100 (CET) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 13 Nov 2008 12:02:46 +0100 From: stefano previdi To: , , , , Message-ID: Thread-Topic: IRTF - P2P Research Group Thread-Index: AclFf1vLmi5mtLFyEd24OAAX8vOM8g== Mime-version: 1.0 Cc: Volker Hilt , Aaron Falk Subject: [ledbat] IRTF - P2P Research Group X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Following the new creation of IETF WGs scoped around issues of peer-to-peer applications (ALTO and LEDBAT) and considering the interest into a forum where research topics related to p2p can be discussed, we started an effort in order to re-activate the IRTF Peer-to-peer Research Group with the proposed (updated) charter below. The p2prg will of course interact with the IETF P2P WGs (P2PSIP, ALTO, LEDBAT). Any comments, feedback and suggestions are welcome. Thanks. s. --------------------------------------------------------------------- IRTF Peer-to-Peer Research Group (P2PRG) ----------------------------------- Chair(s): --------- TBD Mailing Lists: -------------- The email list is p2prg@irtf.org. You need not be a list member to send mail to the list. To subscribe, visit the P2PRG mail page (https://www.ietf.org/mailman/listinfo/p2prg) or send an email to p2prg-request@irtf.org. Website ------- Documents and members only discussion mailing list can be found at the P2Prg web site: http://trac.tools.ietf.org/group/irtf/trac/wiki/PeerToPeerResearchGroup Charter ------- Peer-to-Peer (P2P) is a way of structuring distributed applications such that the individual nodes have symmetric roles. Rather than being divided into clients and servers each with quite distinct roles (such as Web clients vs. Web servers), in P2P applications each node can act as both a client and a server. A key concept for P2P systems is therefore to permit any two peers to communicate with one another in such a way that either ought to be able to initiate the contact. P2P systems in general are highly distributed, highly scalable to large numbers of nodes and users, highly autonomous, and can lend themselves to anonymity. Some historical examples of P2P systems are USENET servers, built on top of NNTP, and inter-domain routing, built on top of BGP. More recent P2P systems are file sharing networks such as Gnutella, BitTorrent, eDonkey/eMule and voice-over-IP applications such as Skype. While P2P systems are deployed and used on a large scale, many research questions in the field of P2P remain open. For example, current P2P systems often form their overlay networks based on application layer information and ignore the structure and policies of the underlying network infrastructure. As a result, peers often connect to peers in a remote network even though an equivalent peer would be available in the local network. This can lead to the inefficient use of network resources and to conflicts between application- and network-level routing. Another problem arises from the fact that many different P2P systems are defined and deployed. It is desirable for users on one system to be able to reach users on other P2P systems without requiring applications to implement the mechanisms and protocols of all systems available. Mechanisms for interconnecting and interoperability between P2P systems are needed. Many P2P systems are based on distributed hash tables (DHTs), which implement a distributed storage for key-value pairs. While DHTs are effective in looking up a specific key, search and information retrieval in DHTs remain challenging problems. Peer nodes in a P2P network perform services for other peers. A challenge is therefore to protect a P2P network against malicious nodes which may try to alter the service or disable it. Finally, it is interesting to evaluate P2P systems that are deployed to better understand the performance of algorithms deployed and the behavior of user. Performance and usage data is an important foundation for the development of new P2P mechanisms and architectures. Mechanisms and tools that collect this information from existing p2p systems are highly desirable. Overall, the field of P2P technologies presents a number of interesting challenges which includes new methods for forming P2P application overlays, interconnecting distinct P2P application overlays, performing routing and peer selection decisions, managing traffic and discovering resources. Other challenges are related to storage, reliability, and information retrieval in P2P systems. Yet another challenging area for P2P is security, privacy, anonymity and trust. Finally, it is challenging to examine P2P systems that are deployed, for example, to measure, monitor and characterize P2P applications. The P2P RG will collaborate with academia and industry on making progress addressing these challenges. The IETF has formed working groups to address specific issues of P2P networking. During the development of standards for P2P networks in these working groups, new research topics may arise that exceed the working group charter and require a separate forum for discussion. The P2P RG will provide such a forum. The IETF has chartered working groups related to the following topics: - Peer-to-Peer SIP signaling (P2PSIP) - Application-Layer Traffic Optimization (ALTO) - Low Extra Delay Background Transport (LEDBAT) Organization ------------ The P2PRG will maintain a list of prioritized topics in order to organize the activity of the research group according to agreed importance and priority. The P2PRG will use an open mailing list (p2prg@irtf.org) as the main communication vehicle for the group. The P2PRG will encourage the organization of the work in smaller design teams focused on specific areas of research. The design teams will use the general mailing list in order to allow the broader community to follow the evolution of their topics. Most of the communication inside the P2PRG will be done through use of mailing lists, however, the group will hold regular physical meetings at least once a year in conjunction with IETF meetings. Additional meetings may be held at IETF or other venues, such as in conjunction with related academic conferences. The P2PRG will produce Informational and Experimental RFCs in order to document the activity of the group and to formalize the outcome of the research topics carried by the group. In addition, such documentation could become input to IETF working groups. Membership ---------- The RG operates in an open fashion (meetings & mailing list). _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 17 09:29:38 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AE028C1BC; Mon, 17 Nov 2008 09:29:38 -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 F10A43A6A58 for ; Fri, 14 Nov 2008 02:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[AWL=1.707, 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 LTRdnjzZxLRG for ; Fri, 14 Nov 2008 02:42:55 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 985A53A6A34 for ; Fri, 14 Nov 2008 02:42:55 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1L0w8b-0000Cl-C1 for ; Fri, 14 Nov 2008 11:42:54 +0100 Received: from i72ibm06.tm.uni-karlsruhe.de ([141.3.71.118]) by irams1.ira.uni-karlsruhe.de with esmtpsa for id 1L0w8b-0006zu-5X; Fri, 14 Nov 2008 11:42:53 +0100 Message-ID: <491D562A.3010500@gmail.com> Date: Fri, 14 Nov 2008 11:42:50 +0100 From: Christoph Werle User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: ledbat@ietf.org X-Mailman-Approved-At: Mon, 17 Nov 2008 09:29:36 -0800 Subject: [ledbat] (no subject) X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org subscribe _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 11:44:01 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BDD328C23B; Thu, 20 Nov 2008 11:44:01 -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 42BFA28C248 for ; Thu, 20 Nov 2008 11:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 g5EGfPPVPS5O for ; Thu, 20 Nov 2008 11:43:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6DAB628C23A for ; Thu, 20 Nov 2008 11:43:59 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKJhgbo025261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 11:43:44 -0800 (PST) Message-ID: <4925BDEE.6090101@isi.edu> Date: Thu, 20 Nov 2008 11:43:42 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ledbat@ietf.org X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Responding to the issue of reasons to need multiple connections, here are a few of mine (extended from those listed at the mic). This is not intended to be a complete list, but a reasonable place to start. The general point is that this is NOT always about hogging bandwidth, either intentionally or not. Joe - -------------------------------------- Reasons to use multiple concurrent TCP connections: - - get around head-of-line blocking this was an original reason for web browsers needing them - - demultiplexing related to HOL blocking but not requiring it, this uses TCP connections to demultiplex different streams, because TCP doesn't provide that labeling itself this was a reason for using different connections for FTP data and control, e.g. - - support different stream properties i.e., a single app may want different streams with Nagle enabled and disabled, or with different socket buffer sizes (to limit delay) - - support "CLOSE means EOF" semantics a reason for multiple connections in HTTP 1.0 - - support larger socket buffer sizes esp. without autotuning, but even with, more connections means more socket buffering is available - ------- One I forgot to note: - - different interaction with errors a single connection would keep restarting; multiple connections increases the possibility that one connection doesn't get hit with a short error burst - ---------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF =YmcT -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:06:07 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFF028C156; Thu, 20 Nov 2008 12:06:07 -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 6E57728C156 for ; Thu, 20 Nov 2008 12:06:06 -0800 (PST) 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 gVcCgSg2Irij for ; Thu, 20 Nov 2008 12:06:05 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 4BCEC28C0FD for ; Thu, 20 Nov 2008 12:06:05 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so589331rvf.49 for ; Thu, 20 Nov 2008 12:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=x7RaH97AxJuxStK9QM+QH42Pd9WkmXzkCia8sLHycb4=; b=wWpcxtoij/YvmW+UaosxUOq4DO46O9M2PgDDsEXT5fLDJj79ZNWvqypRah8K0ku6my qzK4uh9ne99bcyurrNeszzk/+Zgws6kF/NTSfAHi2BdyDas+6k0ZdupfGNjaQa4DdBg3 pQlvWvROtDopWnfbqj56YlfvNlwsUU0HYYOIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=N0WUfx5jjvNTzp7Ylw2C2ty9KgaR53BLd/Bv9+PryDJ42RzReFAjUqk+BG7Gi+qhyI bCibkWMW2g/0hwUC15tHZWeh0FYAxzNy7oP0FiUrK4qE3PPXSCbVry8JYCBJu8DlTWzw pZ4v4m3IyD7DDVW7RfxdDIvz+5jpB6IEhYsq8= Received: by 10.141.133.14 with SMTP id k14mr1407220rvn.270.1227211563529; Thu, 20 Nov 2008 12:06:03 -0800 (PST) Received: by 10.141.142.16 with HTTP; Thu, 20 Nov 2008 12:06:03 -0800 (PST) Message-ID: <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> Date: Thu, 20 Nov 2008 14:06:03 -0600 From: "Andrew G. Malis" To: "Joe Touch" In-Reply-To: <4925BDEE.6090101@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4925BDEE.6090101@isi.edu> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org As was mentioned in the IAB plenary yesterday, a reason to not use multiple TCP connections is the possible exhaustion of middlebox (read NAT) resources, such as state memory or port numbers. So if you are going to use multiple connections in parallel, you may wish to include a method for the user to control that behavior, and a way to detect that you're behind a NAT and adapt appropriately. Cheers, Andy On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Responding to the issue of reasons to need multiple connections, here > are a few of mine (extended from those listed at the mic). This is not > intended to be a complete list, but a reasonable place to start. The > general point is that this is NOT always about hogging bandwidth, either > intentionally or not. > > Joe > > - -------------------------------------- > Reasons to use multiple concurrent TCP connections: > > - - get around head-of-line blocking > this was an original reason for web browsers needing them > > - - demultiplexing > related to HOL blocking but not requiring it, > this uses TCP connections to demultiplex different > streams, because TCP doesn't provide that labeling itself > > this was a reason for using different connections for FTP > data and control, e.g. > > - - support different stream properties > i.e., a single app may want different streams with Nagle > enabled and disabled, or with different socket buffer > sizes (to limit delay) > > - - support "CLOSE means EOF" semantics > a reason for multiple connections in HTTP 1.0 > > - - support larger socket buffer sizes > esp. without autotuning, but even with, more connections > means more socket buffering is available > > - ------- > > One I forgot to note: > > - - different interaction with errors > a single connection would keep restarting; > multiple connections increases the possibility that > one connection doesn't get hit with a short error burst > > - ---------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 > HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF > =YmcT > -----END PGP SIGNATURE----- > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:07:55 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8773A6992; Thu, 20 Nov 2008 12:07:55 -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 562EE3A69A1 for ; Thu, 20 Nov 2008 12:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Tm8t4xDdvsE7 for ; Thu, 20 Nov 2008 12:07:53 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 53A633A677D for ; Thu, 20 Nov 2008 12:07:53 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKK7eLd002459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 12:07:43 -0800 (PST) Message-ID: <4925C38D.7010800@isi.edu> Date: Thu, 20 Nov 2008 12:07:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Andrew G. Malis" References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> In-Reply-To: <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Understood - it would be useful to collect additional items as to why NOT to use multiple TCP connections. The list below is just the reasons that apps DO use them. Joe Andrew G. Malis wrote: > As was mentioned in the IAB plenary yesterday, a reason to not use > multiple TCP connections is the possible exhaustion of middlebox (read > NAT) resources, such as state memory or port numbers. So if you are > going to use multiple connections in parallel, you may wish to include > a method for the user to control that behavior, and a way to detect > that you're behind a NAT and adapt appropriately. > > Cheers, > Andy > > On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch wrote: > Responding to the issue of reasons to need multiple connections, here > are a few of mine (extended from those listed at the mic). This is not > intended to be a complete list, but a reasonable place to start. The > general point is that this is NOT always about hogging bandwidth, either > intentionally or not. > > Joe > > -------------------------------------- > Reasons to use multiple concurrent TCP connections: > > - get around head-of-line blocking > this was an original reason for web browsers needing them > > - demultiplexing > related to HOL blocking but not requiring it, > this uses TCP connections to demultiplex different > streams, because TCP doesn't provide that labeling itself > > this was a reason for using different connections for FTP > data and control, e.g. > > - support different stream properties > i.e., a single app may want different streams with Nagle > enabled and disabled, or with different socket buffer > sizes (to limit delay) > > - support "CLOSE means EOF" semantics > a reason for multiple connections in HTTP 1.0 > > - support larger socket buffer sizes > esp. without autotuning, but even with, more connections > means more socket buffering is available > > ------- > > One I forgot to note: > > - different interaction with errors > a single connection would keep restarting; > multiple connections increases the possibility that > one connection doesn't get hit with a short error burst > > ---------------------------------------------- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklw40ACgkQE5f5cImnZrs/AQCeMMMGWJNU1IPMRyztmyFWLnLg TqcAoM1uZvnW3ckgM64l79Ei3gF65BI6 =xFon -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:22:14 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DD13A6A04; Thu, 20 Nov 2008 12:22:14 -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 5A83D3A6A04 for ; Thu, 20 Nov 2008 12:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 mYP2MCjrk1uE for ; Thu, 20 Nov 2008 12:22:12 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B44043A698B for ; Thu, 20 Nov 2008 12:22:11 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKKLr4D006214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 12:21:56 -0800 (PST) Message-ID: <4925C6E1.8070109@isi.edu> Date: Thu, 20 Nov 2008 12:21:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ledbat@ietf.org X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [ledbat] pointer to Lars' work on packet preemption issues in backgrounding X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, FYI, here's a pointer to the issue I was raising at the mic, that routers don't preempt packets as they're going out the door (nor do hosts; Bob Briscoe noted that there were modems that do this, though). Idletime Scheduling with Preemption Intervals. Lars Eggert and Joe Touch. Proc. 20th ACM Symposium on Operating Systems Principles (SOSP 2005), Brighton, United Kingdom, October 23-26, 2005, pp. 249-262. http://people.nokia.net/~lars/papers/f109-eggert.pdf Disclaimer: This was Lars' thesis work, and I was his advisor. It's of 'academic' interest IMO that it represents the floor of the best you can expect to reduce the impact of background traffic on foreground without 'extraordinary means' like either his thesis technique or true preemption. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklxuEACgkQE5f5cImnZrtCPwCeKmODAq4S897ymyrKnuGVNyNx ZqUAn018XF25eTINAJERj44f7t+Jdodk =16tv -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:28:16 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7833A685E; Thu, 20 Nov 2008 12:28:16 -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 1C4183A685E for ; Thu, 20 Nov 2008 12:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Il6cghUO2bfo for ; Thu, 20 Nov 2008 12:28:15 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 64FF53A677D for ; Thu, 20 Nov 2008 12:28:15 -0800 (PST) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id mAKKRXoq004231; Thu, 20 Nov 2008 12:28:13 -0800 (PST) Message-Id: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> From: Nicholas Weaver To: ledbat@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 14:27:32 -0600 X-Mailer: Apple Mail (2.929.2) Cc: Nicholas Weaver Subject: [ledbat] Note well on the BitTorrent problem on the example... X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org A network with only 128 Kbps uplink, >1.5 Mbps downlink (a 10-1 download/upload ratio) is not suitable for P2P anyway, it really should be "leech only", as it contributes nothing to the P2P system in practice. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:32:44 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1027C3A6939; Thu, 20 Nov 2008 12:32:44 -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 42AC23A6939 for ; Thu, 20 Nov 2008 12:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=2.181, 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 jBmwrLyVqZNN for ; Thu, 20 Nov 2008 12:32:42 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 6B1B33A677D for ; Thu, 20 Nov 2008 12:32:42 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so598771rvf.49 for ; Thu, 20 Nov 2008 12:32:40 -0800 (PST) Received: by 10.141.28.4 with SMTP id f4mr1431108rvj.164.1227213160570; Thu, 20 Nov 2008 12:32:40 -0800 (PST) Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 12:32:40 -0800 (PST) Message-ID: <3efc39a60811201232o6bd6da62p60e38f18d6b17446@mail.gmail.com> Date: Thu, 20 Nov 2008 12:32:40 -0800 From: "Robb Topolski" To: ledbat@ietf.org MIME-Version: 1.0 Subject: [ledbat] Suggestion re "How to deal with the modem buffer" X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1615417453==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============1615417453== Content-Type: multipart/alternative; boundary="----=_Part_93251_16593571.1227213160567" ------=_Part_93251_16593571.1227213160567 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Comment in response to Nick's VG presentation: Even if there is no silver bullet, as a "to do item" for the WG, in the recommendations and current practices paper, we ought to address the issue that Nick brings up on how to deal with large modem buffers. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_93251_16593571.1227213160567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Comment in response to Nick's VG presentation:  Even if there is no silver bullet, as a "to do item" for the WG, in the recommendations and current practices paper, we ought to address the issue that Nick brings up on how to deal with large modem buffers.


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
------=_Part_93251_16593571.1227213160567-- --===============1615417453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============1615417453==-- From ledbat-bounces@ietf.org Thu Nov 20 12:33:50 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B913A6A37; Thu, 20 Nov 2008 12:33:50 -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 C70B73A6A37 for ; Thu, 20 Nov 2008 12:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=1.091, 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 BThRO-lGK+PE for ; Thu, 20 Nov 2008 12:33:47 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 7F3473A6939 for ; Thu, 20 Nov 2008 12:33:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so599135rvf.49 for ; Thu, 20 Nov 2008 12:33:46 -0800 (PST) Received: by 10.141.137.3 with SMTP id p3mr1416434rvn.296.1227213226024; Thu, 20 Nov 2008 12:33:46 -0800 (PST) Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 12:33:45 -0800 (PST) Message-ID: <3efc39a60811201233n62b4265ar566228d4e4f60d12@mail.gmail.com> Date: Thu, 20 Nov 2008 12:33:45 -0800 From: "Robb Topolski" To: ledbat@ietf.org In-Reply-To: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> MIME-Version: 1.0 References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0564434152==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0564434152== Content-Type: multipart/alternative; boundary="----=_Part_93262_6767441.1227213226008" ------=_Part_93262_6767441.1227213226008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can you say more about this? On Thu, Nov 20, 2008 at 12:27 PM, Nicholas Weaver wrote: > A network with only 128 Kbps uplink, >1.5 Mbps downlink (a 10-1 > download/upload ratio) is not suitable for P2P anyway, it really should be > "leech only", as it contributes nothing to the P2P system in practice. > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_93262_6767441.1227213226008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can you say more about this?

On Thu, Nov 20, 2008 at 12:27 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
A network with only 128 Kbps uplink, >1.5 Mbps downlink (a 10-1 download/upload ratio) is not suitable for P2P anyway, it really should be "leech only", as it contributes nothing to the P2P system in practice.

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



--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
------=_Part_93262_6767441.1227213226008-- --===============0564434152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0564434152==-- From ledbat-bounces@ietf.org Thu Nov 20 12:38:04 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A769F3A6A09; Thu, 20 Nov 2008 12:38:04 -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 AED1B3A6A09 for ; Thu, 20 Nov 2008 12:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EdUYwKrSHWY1 for ; Thu, 20 Nov 2008 12:38:02 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1A9073A677D for ; Thu, 20 Nov 2008 12:38:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="198565011" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2008 20:38:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKc0Ne016005; Thu, 20 Nov 2008 12:38:00 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAKKc0Io014752; Thu, 20 Nov 2008 20:38:00 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 12:38:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 12:37:25 -0800 Message-ID: In-Reply-To: <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclLS3j/SumzUogCQa+SMw3VnZFokQAA5jFQ References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> From: "Kartik Chandrayana (karchand)" To: "Andrew G. Malis" , "Joe Touch" X-OriginalArrivalTime: 20 Nov 2008 20:38:00.0888 (UTC) FILETIME=[E129C380:01C94B4F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3685; t=1227213481; x=1228077481; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=karchand@cisco.com; z=From:=20=22Kartik=20Chandrayana=20(karchand)=22=20 |Subject:=20RE=3A=20[ledbat]=20list=20of=20reasons=20for=20 needing=20multiple=20TCP=20connections |Sender:=20; bh=HL6A1SpMbM2bm4wioE8DXuEMGHf+HZldRE/5AtoluE8=; b=Cezi46Pu/rHwfXQiVBZObK5QBQ03KA6P1z+0H4XI/qYJklQEkxKnHlFwW9 TKRy5rEqii2E75G6NRuPriprSil0SXr2mhRAN+7PIo+7UOQCQS5rtfs3aepD WwElcBWbNe; Authentication-Results: sj-dkim-4; header.From=karchand@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Andy, Joe: One reason I can think of using multiple TCP connections is to overcome the non-negotiation of window-scale parameter on most boxes. With default window scale parameters, i.e 0, the congestion window is limited to 64KB only and thus for any pipe with bandwidth-delay-product greater than 64KB, a single TCP connection cannot keep the pipe full. In such a case, it would be beneficial to have multiple TCP connections. Also, since TCP design was mostly with single cpu in mind, I think multiple TCP connections can harness the multi-cpu architectures better than a single lean fast TCP. Thanks, -Kartik -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Thursday, November 20, 2008 2:06 PM To: Joe Touch Cc: ledbat@ietf.org Subject: Re: [ledbat] list of reasons for needing multiple TCP connections As was mentioned in the IAB plenary yesterday, a reason to not use multiple TCP connections is the possible exhaustion of middlebox (read NAT) resources, such as state memory or port numbers. So if you are going to use multiple connections in parallel, you may wish to include a method for the user to control that behavior, and a way to detect that you're behind a NAT and adapt appropriately. Cheers, Andy On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Responding to the issue of reasons to need multiple connections, here > are a few of mine (extended from those listed at the mic). This is not > intended to be a complete list, but a reasonable place to start. The > general point is that this is NOT always about hogging bandwidth, > either intentionally or not. > > Joe > > - -------------------------------------- > Reasons to use multiple concurrent TCP connections: > > - - get around head-of-line blocking > this was an original reason for web browsers needing them > > - - demultiplexing > related to HOL blocking but not requiring it, > this uses TCP connections to demultiplex different > streams, because TCP doesn't provide that labeling itself > > this was a reason for using different connections for FTP > data and control, e.g. > > - - support different stream properties > i.e., a single app may want different streams with Nagle > enabled and disabled, or with different socket buffer > sizes (to limit delay) > > - - support "CLOSE means EOF" semantics > a reason for multiple connections in HTTP 1.0 > > - - support larger socket buffer sizes > esp. without autotuning, but even with, more connections > means more socket buffering is available > > - ------- > > One I forgot to note: > > - - different interaction with errors > a single connection would keep restarting; > multiple connections increases the possibility that > one connection doesn't get hit with a short error burst > > - ---------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 > HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF > =YmcT > -----END PGP SIGNATURE----- > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:44:45 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D813A6A2A; Thu, 20 Nov 2008 12:44:45 -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 60B9A28C234 for ; Thu, 20 Nov 2008 12:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 22j8hNMRufb0 for ; Thu, 20 Nov 2008 12:44:43 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AEBC928C156 for ; Thu, 20 Nov 2008 12:44:43 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKKiQbb012524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 12:44:29 -0800 (PST) Message-ID: <4925CC2A.9080606@isi.edu> Date: Thu, 20 Nov 2008 12:44:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Kartik Chandrayana (karchand)" References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kartik Chandrayana (karchand) wrote: > Andy, Joe: > > One reason I can think of using multiple TCP connections is to overcome > the non-negotiation of window-scale parameter on most boxes. With > default window scale parameters, i.e 0, the congestion window is limited > to 64KB only and thus for any pipe with bandwidth-delay-product greater > than 64KB, a single TCP connection cannot keep the pipe full. In such a > case, it would be beneficial to have multiple TCP connections. > > Also, since TCP design was mostly with single cpu in mind, I think > multiple TCP connections can harness the multi-cpu architectures better > than a single lean fast TCP. That presumes that the OS implements parallelization in the network code; I don't know if that's recently offered, but it has been the sticking point in the past. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklzCoACgkQE5f5cImnZrt8lQCcDHUECfyDkJFHy8kXSSSI5gPE tEEAnAhQv1XX45F/TfCqGXZgrDoo7ed9 =JSeb -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:49:42 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D016C3A6906; Thu, 20 Nov 2008 12:49:42 -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 20CA73A6906 for ; Thu, 20 Nov 2008 12:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 q0GHAfmZtpbK for ; Thu, 20 Nov 2008 12:49:40 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 690EC3A67F0 for ; Thu, 20 Nov 2008 12:49:40 -0800 (PST) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id mAKKms99006630; Thu, 20 Nov 2008 12:49:35 -0800 (PST) Message-Id: <7C1BD40A-C0F3-465E-A438-8C25DD66E1F8@icsi.berkeley.edu> From: Nicholas Weaver To: "Robb Topolski" In-Reply-To: <3efc39a60811201233n62b4265ar566228d4e4f60d12@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 14:48:54 -0600 References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> <3efc39a60811201233n62b4265ar566228d4e4f60d12@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ledbat@ietf.org, Nicholas Weaver Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 20, 2008, at 2:33 PM, Robb Topolski wrote: > Can you say more about this? In the aggregate, a bulk-data P2P system must upload as much as it downloads, and your performance becomes limited by uplink bandwidth. When you have a significant group of hosts with a near-zero uplink, these hosts contribute very little to the overall performance of the system. EG, if 1/2 of the systems are cable modems with 1 Mbps uplink, and 1/2 are behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every single bit of uplink from the DSL lines, you get 8x the uplink from the cable modem lines. At such a point, you might as well, from an aggregate system viewpoint, reduce the upload of the DSL hosts to 0: they are contributing so little, but experiencing a huge degredation of performance that MUST occur because of the minimum buffer size of a few packets. You can NEVER size a buffer for a DSL modem for normal TCP such that you will get good interactive behavior while a full rate upload occurs. In contrast, you can use an effectivev 100-150ms buffer on the cable modems, so they can get full rate TCP but at the same time, not step on their interactive traffic (subequent message coming on that). _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:50:08 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC453A6A51; Thu, 20 Nov 2008 12:50: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 05CEF3A6A51 for ; Thu, 20 Nov 2008 12:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.737, 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 FH+yqMg9GmgB for ; Thu, 20 Nov 2008 12:50:07 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0D4D13A6984 for ; Thu, 20 Nov 2008 12:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id mAKKnvB3002581; Thu, 20 Nov 2008 21:49:58 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 68F0B170441; Thu, 20 Nov 2008 21:49:57 +0100 (CET) Message-Id: From: Carsten Bormann To: Joe Touch In-Reply-To: <4925C6E1.8070109@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 14:49:55 -0600 References: <4925C6E1.8070109@isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: ledbat@ietf.org Subject: Re: [ledbat] pointer to Lars' work on packet preemption issues in backgrounding X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 20, 2008, at 14:21 , Joe Touch wrote: > routers don't preempt packets RFC 2686 http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftmmlppp.html Of course, this is irrelevant in the home. (Just wanted to fix the overgeneralization.) Gruesse, Carsten _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:51:22 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5503A6A51; Thu, 20 Nov 2008 12:51:22 -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 6441B3A6A51 for ; Thu, 20 Nov 2008 12:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JZM57+D4m3gT for ; Thu, 20 Nov 2008 12:51:20 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 5641A3A6A49 for ; Thu, 20 Nov 2008 12:51:20 -0800 (PST) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id mAKKoaBB006768; Thu, 20 Nov 2008 12:51:16 -0800 (PST) Message-Id: <93F81B4F-BC4A-4BF4-9805-09613A5BC5BE@icsi.berkeley.edu> From: Nicholas Weaver To: "Robb Topolski" In-Reply-To: <3efc39a60811201232o6bd6da62p60e38f18d6b17446@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 14:50:36 -0600 References: <3efc39a60811201232o6bd6da62p60e38f18d6b17446@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ledbat@ietf.org, Nicholas Weaver Subject: Re: [ledbat] Suggestion re "How to deal with the modem buffer" X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 20, 2008, at 2:32 PM, Robb Topolski wrote: > Comment in response to Nick's VG presentation: Even if there is no > silver bullet, as a "to do item" for the WG, in the recommendations > and current practices paper, we ought to address the issue that Nick > brings up on how to deal with large modem buffers. The big thing is it needs to be parameterizeable by the ISP, with exposure to whatever ISP control mechanisms are available. There needs to be a floor of a couple of packets for the DSL case, and nothing can really fix that. Thus a floor of probably 4 packets * 1500B MTU => ~8 kB as a floor. OTOH, uploads from a 128 Kbps DSL link are going to be painful, period. Once you shift to higher bandwidth networks, the buffering needs to be bandwidth * generic RTT. A good generic RTT for most uses is probably 150ms, which puts a bound on additional latency & jitter for realtime uses (VoIP, games, SYNs for web surfing) of 150ms regardless of the TCP flows going simultaneously, while ensuring that you can do a full rate TCP flow for any host <150ms away, and only lose throughput for hosts >150ms away. Thus for a 1 Mbps DOCSIS link, it should be ~20 kB, and at a 4 Mbps link, it should be ~80 kB. The key thing for the vendors is the following: It is ENCOURAGED to oversize the buffer (eg, 256 kB), but the ISP MUST be able to remotely configure the access device to use less than the full buffer capacity, as this way the device can be parameterized for the actual network, as the same modem is used for different service-tiers. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:53:26 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDFC3A6A47; Thu, 20 Nov 2008 12:53:26 -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 42DDF3A6A47 for ; Thu, 20 Nov 2008 12:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 zfNzVdtq9K6z for ; Thu, 20 Nov 2008 12:53:24 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 632823A6A38 for ; Thu, 20 Nov 2008 12:53:24 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKKrC8r015021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 12:53:15 -0800 (PST) Message-ID: <4925CE38.2030707@isi.edu> Date: Thu, 20 Nov 2008 12:53:12 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Carsten Bormann References: <4925C6E1.8070109@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ledbat@ietf.org Subject: Re: [ledbat] pointer to Lars' work on packet preemption issues in backgrounding X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carsten Bormann wrote: > On Nov 20, 2008, at 14:21 , Joe Touch wrote: > >> routers don't preempt packets > > RFC 2686 > > http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftmmlppp.html > > > Of course, this is irrelevant in the home. > (Just wanted to fix the overgeneralization.) > > Gruesse, Carsten Thanks - Dave pointed that out to me as well. I was not aware of it; it's certainly still reasonable that "most routers" don't support preemption. Ditto for hosts. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklzjgACgkQE5f5cImnZrtp/QCg90llatInJGOhS1Qah1Z+6Rc7 2q8An33q8JebugHaLLBiPwY3EJB/Zz73 =zGUC -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:54:13 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF533A6A38; Thu, 20 Nov 2008 12:54:13 -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 4C7053A6A5C for ; Thu, 20 Nov 2008 12:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 775fx04A-kTT for ; Thu, 20 Nov 2008 12:54:11 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8786C3A6984 for ; Thu, 20 Nov 2008 12:54:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="107390837" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 20 Nov 2008 20:54:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKsAbj014398; Thu, 20 Nov 2008 12:54:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKKsA24029836; Thu, 20 Nov 2008 20:54:10 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 12:54:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 12:53:29 -0800 Message-ID: In-Reply-To: <4925CC2A.9080606@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclLUNCyhNO8NpyaSS6a6rB7YJVFdQAAKXsA References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <4925CC2A.9080606@isi.edu> From: "Kartik Chandrayana (karchand)" To: "Joe Touch" X-OriginalArrivalTime: 20 Nov 2008 20:54:10.0229 (UTC) FILETIME=[22EF7650:01C94B52] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1799; t=1227214450; x=1228078450; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=karchand@cisco.com; z=From:=20=22Kartik=20Chandrayana=20(karchand)=22=20 |Subject:=20RE=3A=20[ledbat]=20list=20of=20reasons=20for=20 needing=20multiple=20TCP=20connections |Sender:=20; bh=r1rtNF9DLA+kQjRfkROKy5RY7eESuz0/T4ndB+KGR0w=; b=cog56RZovhlQPd3sLL3EGviGe48uKh4or/Aa30hG1vcebDdRRHFqsjZUwV Nw1vvto+SWhJWgdA+du+ROBleOWvTaB0o/4HD+Cagjf/XsvoFOgc/MeA0BI1 9iGsM+Yg41; Authentication-Results: sj-dkim-4; header.From=karchand@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Joe, I am also not aware if parallelization of network code is implemented in OSes. However, I think it would be reasonable to expect that tcpcb lookups are done in a centralized fashion and once that is done, multiple tcp's can be processed in different cpus. Even the lookups can be distributed as they are only a read operation. Thanks, -Kartik -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Thursday, November 20, 2008 2:44 PM To: Kartik Chandrayana (karchand) Cc: Andrew G. Malis; ledbat@ietf.org Subject: Re: [ledbat] list of reasons for needing multiple TCP connections -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kartik Chandrayana (karchand) wrote: > Andy, Joe: > > One reason I can think of using multiple TCP connections is to > overcome the non-negotiation of window-scale parameter on most boxes. > With default window scale parameters, i.e 0, the congestion window is > limited to 64KB only and thus for any pipe with > bandwidth-delay-product greater than 64KB, a single TCP connection > cannot keep the pipe full. In such a case, it would be beneficial to have multiple TCP connections. > > Also, since TCP design was mostly with single cpu in mind, I think > multiple TCP connections can harness the multi-cpu architectures > better than a single lean fast TCP. That presumes that the OS implements parallelization in the network code; I don't know if that's recently offered, but it has been the sticking point in the past. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklzCoACgkQE5f5cImnZrt8lQCcDHUECfyDkJFHy8kXSSSI5gPE tEEAnAhQv1XX45F/TfCqGXZgrDoo7ed9 =JSeb -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:57:36 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7AE3A6AD1; Thu, 20 Nov 2008 12:57:36 -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 416683A6A7A for ; Thu, 20 Nov 2008 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 jLMT9vLbTIRg for ; Thu, 20 Nov 2008 12:57:34 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5F7103A6A09 for ; Thu, 20 Nov 2008 12:57:34 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKKvHXQ016145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 12:57:19 -0800 (PST) Message-ID: <4925CF2D.4070908@isi.edu> Date: Thu, 20 Nov 2008 12:57:17 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Kartik Chandrayana (karchand)" References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <4925CC2A.9080606@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kartik Chandrayana (karchand) wrote: > Joe, > > I am also not aware if parallelization of network code is implemented > in OSes. However, I think it would be reasonable to expect that tcpcb > lookups are done in a centralized fashion and once that is done, > multiple tcp's can be processed in different cpus. Even the lookups can > be distributed as they are only a read operation. Parallelizing TCP includes dealing with not only the TCP code, but also the IP input queue access, timers, etc. I am not as sure that there's a one TCP per core mapping in current OS's - though I'd be glad to hear someone *confirm* it. Joe > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Thursday, November 20, 2008 2:44 PM > To: Kartik Chandrayana (karchand) > Cc: Andrew G. Malis; ledbat@ietf.org > Subject: Re: [ledbat] list of reasons for needing multiple TCP > connections > > > > Kartik Chandrayana (karchand) wrote: >> Andy, Joe: > >> One reason I can think of using multiple TCP connections is to >> overcome the non-negotiation of window-scale parameter on most boxes. >> With default window scale parameters, i.e 0, the congestion window is >> limited to 64KB only and thus for any pipe with >> bandwidth-delay-product greater than 64KB, a single TCP connection >> cannot keep the pipe full. In such a case, it would be beneficial to > have multiple TCP connections. >> Also, since TCP design was mostly with single cpu in mind, I think >> multiple TCP connections can harness the multi-cpu architectures >> better than a single lean fast TCP. > > That presumes that the OS implements parallelization in the network > code; I don't know if that's recently offered, but it has been the > sticking point in the past. > > Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklzy0ACgkQE5f5cImnZrtxIwCgw+uW7JxMRDZja1pTuixQUwS8 m5IAoPHHCB2ed20zXkkv15m09kF4q+mm =30jd -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 12:59:09 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9B53A6A80; Thu, 20 Nov 2008 12:59:09 -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 2DFBA3A67F0 for ; Thu, 20 Nov 2008 12:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1A0vZm2ce-IH for ; Thu, 20 Nov 2008 12:59:07 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6E30F3A6A38 for ; Thu, 20 Nov 2008 12:59:07 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAKKwXmO001689; Thu, 20 Nov 2008 14:59:03 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 22:58:53 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 22:58:52 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 22:58:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.11.137]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id mAKKwkCM008338; Thu, 20 Nov 2008 22:58:46 +0200 Received: from nok-db1mmbr-01.mgdnok.nokia.com ([65.54.11.136]) by NOK-DB1MHUB-01.mgdnok.nokia.com ([65.54.11.137]) with mapi; Thu, 20 Nov 2008 20:58:45 +0000 From: To: , Date: Thu, 20 Nov 2008 20:58:44 +0000 Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclLUNCyhNO8NpyaSS6a6rB7YJVFdQAAKXsAAABT3/s= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 20:58:47.0862 (UTC) FILETIME=[C86AE560:01C94B52] X-Nokia-AV: Clean 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0870145274==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0870145274== Content-Language: en Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3310037924_11336844" --B_3310037924_11336844 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 08-11-20 14:53, "ext Kartik Chandrayana (karchand)" wrote: > I am also not aware if parallelization of network code is implemented > in OSes. I believe Andre Opperman's recent work on the FreeBSD-7 stack was mostly about parallelization. Lars --B_3310037924_11336844 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIdAYJKoZIhvcNAQcCoIIIZTCCCGECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BkAwggL5MIICYqADAgECAhBIu1mzDCmthiyhaUA2jgUBMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODA4MjMxNzQz MzlaFw0wOTA4MjMxNzQzMzlaMFwxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEU MBIGA1UEAxMLTGFycyBFZ2dlcnQxJDAiBgkqhkiG9w0BCQEWFWxhcnMuZWdnZXJ0QG5va2lh LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJcEFZLSWQmPPYlOo3FtV52U DfmjIBdrrQlE9x92SgeSW3rdUg1rdJnf1ue9Wx48bZ/QnxCXaHITS95fX9VoiTXVWydfNuee y7cfUqI6rYaarQNIyhKqNoKq3/q2lI9XXppqNOqHLC6r9OOgq8InTqepNEQH75Cjy4Q+Dw/T ZN6Gmbsagc9cGOLvEPN4ljAKw3l4kMXzWZzgc+XA7Fb1Y044rZt1QDZGw9NrTZMJeQB8O4bX XuMh/ISMJX86rALRwRGodx8jr7PW/oB4NqRc/Xkvh7qLWGSsnAsHkbPDSl6AoPswJFWIt872 RB9lTrj5aTEDKwffny1oNlAbE3mfOuMCAwEAAaMyMDAwIAYDVR0RBBkwF4EVbGFycy5lZ2dl cnRAbm9raWEuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEATHVdlPq8lebd 57gRR9fVyn5aHTegXOtBgWBx2P2dPgpdPEO+as07dNiCCwYPv2FYf38oG+qRazptbBbSze3x DQX2ztlbaRYz9pRlIG101U+cRjOvjLamYgSOi6nsQHmOoLHf7WqFH8vX2RuNnXIgQPYEhpUI 41kMhvJm+R0fC/YwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNV BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJo dHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIB/DCCAfgCAQEwdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFp QDaOBQEwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQPDrcXRoMKH92DPMj8JaxO6Cfd 7TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODExMjAyMDU4 NDRaMA0GCSqGSIb3DQEBAQUABIIBAAD/8iPG0IZCO5ZsuJtKTgpx0OmWJLraG6v6/GfTauo0 nIiEYOuNT7hcIaKXERyJKPv6LFQ+ytXgs1Myo9XwrRoJbaQV+ArM+ALRflMrBHv4zusM3I1Y uy2L4LE9a8Nf4zfsMWclFaS0pjB+maa//YytWmGtXtxEnqwKUR8CVuwBoSwXAqwBgld9Dw28 UVEOaVJdbBSyaNeou9m60Xbjl0fgbAjRFqbOCuk4V3F0v3tzU3V4/UqfY+K6I5Z+8pWae3xy 10UKLaEdo/stf6dQBBDt0CwqS03eqNKsLBc+9Ee/7yd86K/tAB5HBQSN73Kg87MGDq/+ig4Q VGKWPtVn5bM= --B_3310037924_11336844-- --===============0870145274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0870145274==-- From ledbat-bounces@ietf.org Thu Nov 20 13:25:28 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F553A6A3F; Thu, 20 Nov 2008 13:25:28 -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 7F95E3A6A3F for ; Thu, 20 Nov 2008 13:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 qKrsHtcgiR2F for ; Thu, 20 Nov 2008 13:25:16 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BD8C43A68C5 for ; Thu, 20 Nov 2008 13:25:14 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKLP1uO024034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 13:25:03 -0800 (PST) Message-ID: <4925D5AC.3000708@isi.edu> Date: Thu, 20 Nov 2008 13:25:00 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ledbat@ietf.org X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [ledbat] FYI - Stanford router info X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I noted the Stanford PC card router. It's called NetFPGA, and it has 4 1-Gbps interfaces. It handles full line rate, and they claim 8Gbps, though I'm not sure how they're counting that (I figured 4 Gbps in, 4 out, and no reason to add the two numbers). Anywho, for $500 (academic, $1,000 industrial), IMO it demonstrates that line rate should not be that expensive. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkl1awACgkQE5f5cImnZrsGowCfRtbozzwxH4QXc1R8qJ+jr88Y m3IAnRwQMd/c//UJaptq/yBLZUnyUPcw =j287 -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 13:38:30 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60AED3A69DC; Thu, 20 Nov 2008 13:38:30 -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 7E3E93A69DC for ; Thu, 20 Nov 2008 13:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Z668DzKMwg+w for ; Thu, 20 Nov 2008 13:38:27 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 801B33A677D for ; Thu, 20 Nov 2008 13:38:27 -0800 (PST) Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.54.46.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 20 Nov 2008 13:38:26 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.54.46.185]) with mapi; Thu, 20 Nov 2008 13:38:25 -0800 From: Murari Sridharan To: "janardhan.iyengar@fandm.edu" Date: Thu, 20 Nov 2008 13:38:25 -0800 Thread-Topic: Feedback on LEDBAT presentation Thread-Index: AclLTPHnVAWh42FESbme8zgJFnsubQACd4uM Message-ID: References: <4925C5B1.7020207@fandm.edu> In-Reply-To: <4925C5B1.7020207@fandm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Feedback on LEDBAT presentation X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Thanks for your mail Jana, i have just uploaded all the presentations online. ________________________________________ From: Janardhan Iyengar [janardhan.iyengar@fandm.edu] Sent: Thursday, November 20, 2008 12:16 PM To: Murari Sridharan Subject: Feedback on LEDBAT presentation Hi Murari, I attended the session remotely, and did not see the slides since they were not on the IETF materials page. Can you put the slides for all the presentations out? The little bit that I could follow without the slides, this sounds interesting for sure. I wanted to point you to some work done by Manish Jain (you mentioned his work with Dovrolis from SIGCOMM 2002) called SOBAS which seems related: http://www.cc.gatech.edu/~jain/publications/sobas_grid.pdf On the same note, Manish is actually a postdoc at MSR in Seattle right now. Thanks, - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 13:40:44 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AD63A68F1; Thu, 20 Nov 2008 13:40:44 -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 18C333A68F1 for ; Thu, 20 Nov 2008 13:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 OxShBCrbPE5v for ; Thu, 20 Nov 2008 13:40:43 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 50D103A677D for ; Thu, 20 Nov 2008 13:40:43 -0800 (PST) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 20 Nov 2008 13:40:42 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Thu, 20 Nov 2008 13:40:41 -0800 From: Murari Sridharan To: "ledbat@ietf.org" Date: Thu, 20 Nov 2008 13:40:41 -0800 Thread-Topic: Presentations uploaded Thread-Index: AQHJS1iiG/0gjfm2ZkGX+dXI4YNwgQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [ledbat] Presentations uploaded X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0388242194==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0388242194== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFCBA54A3NAEXMSGC110re_" --_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFCBA54A3NAEXMSGC110re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All: We had a pretty interesting discussion today at the 1st meeting of this WG.= I have uploaded the presentations online. I will upload the minutes by tom= orrow. Special thanks to our jabber scribe and vijay for meeting minutes Thanks --_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFCBA54A3NAEXMSGC110re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All:
 
We had a pretty interesti= ng discussion today at the 1st meeting of this WG. I have uploaded the pres= entations online. I will upload the minutes by tomorrow.
 
Special thanks to our jab= ber scribe and vijay for meeting minutes
 
Thanks
--_000_FCA794787FDE0D4DBE9FFA11053ECEB61AFCBA54A3NAEXMSGC110re_-- --===============0388242194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0388242194==-- From ledbat-bounces@ietf.org Thu Nov 20 13:50:47 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C9A3A6A01; Thu, 20 Nov 2008 13:50:47 -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 A4C3128C1B9 for ; Thu, 20 Nov 2008 13:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 2YsP9RWm407e for ; Thu, 20 Nov 2008 13:50:45 -0800 (PST) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by core3.amsl.com (Postfix) with ESMTP id B777C3A69DC for ; Thu, 20 Nov 2008 13:50:45 -0800 (PST) Received: (qmail 29752 invoked from network); 20 Nov 2008 21:50:43 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Nov 2008 21:50:43 -0000 Message-ID: <4925DBB3.80509@asomi.com> Date: Thu, 20 Nov 2008 13:50:43 -0800 From: Caitlin Bestler User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Andrew G. Malis" References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> In-Reply-To: <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Andrew G. Malis wrote: > As was mentioned in the IAB plenary yesterday, a reason to not use > multiple TCP connections is the possible exhaustion of middlebox (read > NAT) resources, such as state memory or port numbers. So if you are > going to use multiple connections in parallel, you may wish to include > a method for the user to control that behavior, and a way to detect > that you're behind a NAT and adapt appropriately. > The gotcha here is that every item in the list Joe supplied is already solved by SCTP, and about the only legitimate reason for not using SCTP is the presence of middleboxes that do not support it. So the only time you have an excuse for using multiple TCP connections is exactly when there are resources that might be exhausted by the practice. Using multiple connections to solve a single problem inherently degrades the ability of the network to manage traffic effectively. I recognize that it isn't going to go away anytime soon, but there is no reason why we should *encourage* this anti-social behavior. -- Caitlin Bestler cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.html _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 13:54:57 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37553A6A09; Thu, 20 Nov 2008 13:54:57 -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 D08A328C0FF for ; Thu, 20 Nov 2008 13:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 hXZQvbOkRYXa for ; Thu, 20 Nov 2008 13:54:56 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 079AF3A677D for ; Thu, 20 Nov 2008 13:54:55 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKLsdNw003161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 13:54:41 -0800 (PST) Message-ID: <4925DC9F.6090403@isi.edu> Date: Thu, 20 Nov 2008 13:54:39 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Caitlin Bestler References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <4925DBB3.80509@asomi.com> In-Reply-To: <4925DBB3.80509@asomi.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Caitlin Bestler wrote: > Andrew G. Malis wrote: >> As was mentioned in the IAB plenary yesterday, a reason to not use >> multiple TCP connections is the possible exhaustion of middlebox (read >> NAT) resources, such as state memory or port numbers. So if you are >> going to use multiple connections in parallel, you may wish to include >> a method for the user to control that behavior, and a way to detect >> that you're behind a NAT and adapt appropriately. >> > > The gotcha here is that every item in the list Joe supplied is > already solved by SCTP, and about the only legitimate reason > for not using SCTP is the presence of middleboxes that do > not support it. SCTP doesn't address the need for different applications to have different connections (one variant of the demultiplexing issue). I.e., a single socket used by more than one application. SCTP also doesn't address the need to support endpoints that don't speak SCTP yet, or services that aren't defined over SCTP yet. FWIW, many of these issues were similarly addressed by HTTP 1.1, and in other applications as well. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkl3J4ACgkQE5f5cImnZrto8ACg3eVYF/VAU2hI6oKyYqLYJG1R oCcAn2XAWrtp6OhNValUHmF5DoL89oiu =4EpB -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 14:24:16 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8353A6898; Thu, 20 Nov 2008 14:24:16 -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 2A9D13A6898 for ; Thu, 20 Nov 2008 14:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=0.727, 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 2Aqh2P5130hB for ; Thu, 20 Nov 2008 14:24:14 -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 04FCD3A677D for ; Thu, 20 Nov 2008 14:24:13 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so636664rvf.49 for ; Thu, 20 Nov 2008 14:24:12 -0800 (PST) Received: by 10.140.192.9 with SMTP id p9mr1473719rvf.236.1227219852828; Thu, 20 Nov 2008 14:24:12 -0800 (PST) Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 14:24:12 -0800 (PST) Message-ID: <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> Date: Thu, 20 Nov 2008 14:24:12 -0800 From: "Robb Topolski" To: ledbat@ietf.org In-Reply-To: MIME-Version: 1.0 References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2069906022==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============2069906022== Content-Type: multipart/alternative; boundary="----=_Part_94983_10191784.1227219852812" ------=_Part_94983_10191784.1227219852812 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I want to eliminate the "bandwidth hogging" motive in using multiple P2P connections to get more traffic across a congested network. Neither the facts nor the personalities of the developers involved support that charge. It's a huge and false distraction from what may be good work at hand. P2P apps, users, protocols, developers do not use multiple connections to get an unfair "leg up" across any point of congestion... THAT TRICK WON'T WORK ON SPEED-CAPPED CONNECTIONS: While it's true that larger number of standard TCP connections can allow a greater share of bandwidth across any particular point in the network, getting that bandwidth depends on a lack of any other limiting factor. In our residential networks, however, the subscriber's broadband modem imposes relatively low ceilings. A single connection can get maximum speed either in or out. Therefore, any "bandwidth-hogging" benefit of running multiple connections on these broadband access networks is very temporary at worst (about the time it takes for the multiple streams to all get knocked down and find new equilibrium) and may actually work out to be nil (giving that all the streams will respond eventually in relatively proportionate ways). P2P DOESN'T USE THAT TRICK: The slot-and-choke (used by BitTorrent) or queue-list techniques (used by Gnutella or ED2K) and similar used by others tends to limit the number of connections actually in use vs. disconnected or occasionally sending tiny bits of mesh data. Just like any other sender of information, P2P uploads are overall faster and more efficient when they respond to congestion signals than they are when they ignore them. P2P AVOIDS CONGESTED ROUTES: Sources for data that are on congested routes are used less often and for shorter times than sources on routes that are free of congestion. BitTorrent does this by reserving all but one of its slots for the fastest reciprocating peers and by reserving one slot to hunt for even faster peers (the presumption being that slow peers indicate congested routes). In Gnutella and ED2K, peers are usually both time and data limited -- so if the clock expires before a chunk is fully transferred, the transfer is ended. This has the net effect of getting the most data from peers without such a constraint. USING MULTIPLE CONNECTIONS HAS NOTHING TO DO WITH BANDWIDTH CONSUMED: In one of the presentations, the speaker seemed to tie the use of multiple connections to bandwidth consumption. The consumption of bandwidth, however, has everything to do with the size of the object being transferred and nothing to do with the number of connections. Take the task of downloading and sharing the Knoppix DVD. If the multiple connections were replaced by single connections, the bandwidth consumed would be essentially the same (about 10 GB). The additional overhead is hardly worth mentioning. There is a related -- almost rhyming -- motive, but it's not an evil motive as far as the network is concerned. Some users observe that being connected to more peers results in faster downloads. This is -not- because anyone is ignoring congestion signals, it's simply because more connections gives a downloader access to a larger number of altruistic "seeders" (sources who will upload without an immediate expectation of reciprocation). These seeders are still operating under the same network rules as other nodes, uploading only on a very limited number of their connections and responding to signs of congestion control. (And most users don't realize that seeders have little motivation to transfer exclusively to them, so while that trick works, it doesn't work as well as many expect. Many users are disappointed in the download rates experienced within heavily seeded swarms.) There is room for improvement -- like any other network use, P2P file-sharers have shown that they are very interested in efficiency and are adaptive to technology or techniques that gets them there. P2P file sharing is not perfect, either socially or technologically. There are network cheaters and generally dumb ideas out there. While I'm speaking generally of typical P2P users, developers, and protocols -- there will always be the few exceptions. While nobody has targeted these exceptions as the biggest part of "the problem," I didn't want the above info to be interpreted as ignoring the fact that they exist here and there. ------=_Part_94983_10191784.1227219852812 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I want to eliminate the "bandwidth hogging" motive in using multi= ple P2P connections to get more traffic across a congested network.  N= either the facts nor the personalities of the developers involved support t= hat charge.  It's a huge and false distraction from what may be go= od work at hand.

P2P apps, users, protocols, developers do not use multiple connections = to get an unfair "leg up" across any point of congestion...
THAT TRICK WON'T WORK ON SPEED-CAPP= ED CONNECTIONS: While it's true that larger number of standard TCP conn= ections can allow a greater share of bandwidth across any particular point = in the network, getting that bandwidth depends on a lack of any other limit= ing factor.  In our residential networks, however, the subscriber'= s broadband modem imposes relatively low ceilings.  A single connectio= n can get maximum speed either in or out.  Therefore, any "bandwi= dth-hogging" benefit of running multiple connections on these broadban= d access networks is very temporary at worst (about the time it takes for t= he multiple streams to all get knocked down and find new equilibrium) and m= ay actually work out to be nil (giving that all the streams will respond ev= entually in relatively proportionate ways). 

P2P DOESN'T USE THAT TRICK: The slot-and-choke (used by BitTorrent)= or queue-list techniques (used by Gnutella or ED2K) and similar used by ot= hers tends to limit the number of connections actually in use vs. disconnec= ted or occasionally sending tiny bits of mesh data.  Just like any oth= er sender of information, P2P uploads are overall faster and more efficient= when they respond to congestion signals than they are when they ignore the= m.

P2P AVOIDS CONGESTED ROUTES: Sources for data that are on congested rou= tes are used less often and for shorter times than sources on routes that a= re free of congestion. BitTorrent does this by reserving all but one of its= slots for the fastest reciprocating peers and by reserving one slot to hun= t for even faster peers (the presumption being that slow peers indicate con= gested routes).  In Gnutella and ED2K, peers are usually both time and= data limited -- so if the clock expires before a chunk is fully transferre= d, the transfer is ended.  This has the net effect of getting the most= data from peers without such a constraint.

USING MULTIPLE CONNECTIONS HAS NOTHING TO DO WITH BANDWIDTH CONSUMED: I= n one of the presentations, the speaker seemed to tie the use of multiple c= onnections to bandwidth consumption.  The consumption of bandwidth, ho= wever, has everything to do with the size of the object being transferred a= nd nothing to do with the number of connections.  Take the task of dow= nloading and sharing the Knoppix DVD.  If the multiple connections wer= e replaced by single connections, the bandwidth consumed would be essential= ly the same (about 10 GB). The additional overhead is hardly worth mentioni= ng. 

There is a related -- almost rhyming -- motive, but it's not = an evil motive as far as the network is concerned.  Some users observe= that being connected to more peers results in faster downloads.  This= is -not- because anyone is ignoring congestion signals, it's simply be= cause more connections gives a downloader access to a larger number of altr= uistic "seeders" (sources who will upload without an immediate ex= pectation of reciprocation).  These seeders are still operating under = the same network rules as other nodes, uploading only on a very limited num= ber of their connections and responding to signs of congestion control.&nbs= p; (And most users don't realize that seeders have little motivation to= transfer exclusively to them, so while that trick works, it doesn't wo= rk as well as many expect. Many users are disappointed in the download rate= s experienced within heavily seeded swarms.)

There is room for improvement -- like any other network use, P2P file-sharers have shown that they are very interested in efficiency and are adaptive to technology or techniques that gets them there.  P2= P file sharing is not perfect, either socially or technologically.  Th= ere are network cheaters and generally dumb ideas out there.  While I&= #39;m speaking generally of typical P2P users, developers, and protocols --= there will always be the few exceptions.  While nobody has targeted t= hese exceptions as the biggest part of "the problem," I didn'= t want the above info to be interpreted as ignoring the fact that they exis= t here and there.
------=_Part_94983_10191784.1227219852812-- --===============2069906022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============2069906022==-- From ledbat-bounces@ietf.org Thu Nov 20 14:42:50 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4ED3A6876; Thu, 20 Nov 2008 14:42:50 -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 4C12A3A6806 for ; Thu, 20 Nov 2008 14:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.545, 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 kCwJheb01qB2 for ; Thu, 20 Nov 2008 14:42:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 1ECC53A677D for ; Thu, 20 Nov 2008 14:42:48 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id k40so659481rvb.1 for ; Thu, 20 Nov 2008 14:42:46 -0800 (PST) Received: by 10.141.96.21 with SMTP id y21mr1481303rvl.246.1227220966782; Thu, 20 Nov 2008 14:42:46 -0800 (PST) Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 14:42:46 -0800 (PST) Message-ID: <3efc39a60811201442o13b86ca5s93297afb2075e2c6@mail.gmail.com> Date: Thu, 20 Nov 2008 14:42:46 -0800 From: "Robb Topolski" To: "Nicholas Weaver" In-Reply-To: <93F81B4F-BC4A-4BF4-9805-09613A5BC5BE@icsi.berkeley.edu> MIME-Version: 1.0 References: <3efc39a60811201232o6bd6da62p60e38f18d6b17446@mail.gmail.com> <93F81B4F-BC4A-4BF4-9805-09613A5BC5BE@icsi.berkeley.edu> Cc: ledbat@ietf.org Subject: Re: [ledbat] Suggestion re "How to deal with the modem buffer" X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0349439934==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0349439934== Content-Type: multipart/alternative; boundary="----=_Part_95112_33259454.1227220966768" ------=_Part_95112_33259454.1227220966768 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks Nick, Big thing -- as in defining a new addressable hardware parameter? (Isn't that more of an IEEE thing?) Haven't we all been dealing with this for years? On the chance that we won't get anything from the ISP or hardware vendors soon (given the various modems and buffers out there), what can users do now? What can developers do to keep users from calling and saying, "The Internet is down?" that would still keep working if we did make progress on dealing with the buffer itself? Isn't avoiding the effects of the buffer why some VOIP uses a packet every 50 ms? Isn't the buffer's effects why my Ubicom QoS gateway dynamically fragments packets and delivers them upstream at a rate lower than my subscribed speeds? Couldn't we take these concepts and suggest a way for P2P programs to sense and adjust to the buffer's effects so that running torrents never fills the buffer (e.g. speed test, set upload limit to 25% of result, check RTT somewhere, addititive increase until RTT average starts to rise).? Robb On Thu, Nov 20, 2008 at 12:50 PM, Nicholas Weaver wrote: > > On Nov 20, 2008, at 2:32 PM, Robb Topolski wrote: > > Comment in response to Nick's VG presentation: Even if there is no silver >> bullet, as a "to do item" for the WG, in the recommendations and current >> practices paper, we ought to address the issue that Nick brings up on how to >> deal with large modem buffers. >> > > The big thing is it needs to be parameterizeable by the ISP, with exposure > to whatever ISP control mechanisms are available. > > There needs to be a floor of a couple of packets for the DSL case, and > nothing can really fix that. Thus a floor of probably 4 packets * 1500B MTU > => ~8 kB as a floor. OTOH, uploads from a 128 Kbps DSL link are going to be > painful, period. > > > Once you shift to higher bandwidth networks, the buffering needs to be > bandwidth * generic RTT. > > A good generic RTT for most uses is probably 150ms, which puts a bound on > additional latency & jitter for realtime uses (VoIP, games, SYNs for web > surfing) of 150ms regardless of the TCP flows going simultaneously, while > ensuring that you can do a full rate TCP flow for any host <150ms away, and > only lose throughput for hosts >150ms away. > > > Thus for a 1 Mbps DOCSIS link, it should be ~20 kB, and at a 4 Mbps link, > it should be ~80 kB. > > The key thing for the vendors is the following: It is ENCOURAGED to > oversize the buffer (eg, 256 kB), but the ISP MUST be able to remotely > configure the access device to use less than the full buffer capacity, as > this way the device can be parameterized for the actual network, as the same > modem is used for different service-tiers. > > -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_95112_33259454.1227220966768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks Nick,

Big thing -- as in defining a new addressable hardware parameter?  (Isn't that more of an IEEE thing?)

Haven't we all been dealing with this for years?  On the chance that we won't get anything from the ISP or hardware vendors soon (given the various modems and buffers out there), what can users do now?  What can developers do to keep users from calling and saying, "The Internet is down?" that would still keep working if we did make progress on dealing with the buffer itself?

Isn't avoiding the effects of the buffer why some VOIP uses a packet every 50 ms? Isn't the buffer's effects why my Ubicom QoS gateway dynamically fragments packets and delivers them upstream at a rate lower than my subscribed speeds?  Couldn't we take these concepts and suggest a way for P2P programs to sense and adjust to the buffer's effects so that running torrents never fills the buffer (e.g. speed test, set upload limit to 25% of result, check RTT somewhere, addititive increase until RTT average starts to rise).?

Robb

On Thu, Nov 20, 2008 at 12:50 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

On Nov 20, 2008, at 2:32 PM, Robb Topolski wrote:

Comment in response to Nick's VG presentation:  Even if there is no silver bullet, as a "to do item" for the WG, in the recommendations and current practices paper, we ought to address the issue that Nick brings up on how to deal with large modem buffers.

The big thing is it needs to be parameterizeable by the ISP, with exposure to whatever ISP control mechanisms are available.

There needs to be a floor of a couple of packets for the DSL case, and nothing can really fix that.  Thus a floor of probably 4 packets * 1500B MTU => ~8 kB as a floor.  OTOH, uploads from a 128 Kbps DSL link are going to be painful, period.


Once you shift to higher bandwidth networks, the buffering needs to be bandwidth * generic RTT.

A good generic RTT for most uses is probably 150ms, which puts a bound on additional latency & jitter for realtime uses (VoIP, games, SYNs for web surfing) of 150ms regardless of the TCP flows going simultaneously,  while ensuring that you can do a full rate TCP flow for any host <150ms away, and only lose throughput for hosts >150ms away.


Thus for a 1 Mbps DOCSIS link, it should be ~20 kB, and at a 4 Mbps link, it should be ~80 kB.

The key thing for the vendors is the following:  It is ENCOURAGED to oversize the buffer (eg, 256 kB), but the ISP MUST be able to remotely configure the access device to use less than the full buffer capacity, as this way the device can be parameterized for the actual network, as the same modem is used for different service-tiers.




--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
------=_Part_95112_33259454.1227220966768-- --===============0349439934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0349439934==-- From ledbat-bounces@ietf.org Thu Nov 20 14:43:31 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079143A6876; Thu, 20 Nov 2008 14:43:31 -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 9DA703A6876 for ; Thu, 20 Nov 2008 14:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 UdEcZqw94Ewi for ; Thu, 20 Nov 2008 14:43:28 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 93EA83A677D for ; Thu, 20 Nov 2008 14:43:28 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAKMhHXa016652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 14:43:20 -0800 (PST) Message-ID: <4925E805.1050801@isi.edu> Date: Thu, 20 Nov 2008 14:43:17 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Robb Topolski References: <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> In-Reply-To: <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Robb, Appreciating the following, this isn't intended as an application protocol, so we can't assume it would apply only to P2P. I.e., we need a solution that can be used for any application, and there are several applications that DO use multiple connections to increase bandwidth in the typical case. Joe Robb Topolski wrote: > I want to eliminate the "bandwidth hogging" motive in using multiple P2P > connections to get more traffic across a congested network. Neither the > facts nor the personalities of the developers involved support that > charge. It's a huge and false distraction from what may be good work at > hand. > > P2P apps, users, protocols, developers do not use multiple connections > to get an unfair "leg up" across any point of congestion... > > THAT TRICK WON'T WORK ON SPEED-CAPPED CONNECTIONS: While it's true that > larger number of standard TCP connections can allow a greater share of > bandwidth across any particular point in the network, getting that > bandwidth depends on a lack of any other limiting factor. In our > residential networks, however, the subscriber's broadband modem imposes > relatively low ceilings. A single connection can get maximum speed > either in or out. Therefore, any "bandwidth-hogging" benefit of running > multiple connections on these broadband access networks is very > temporary at worst (about the time it takes for the multiple streams to > all get knocked down and find new equilibrium) and may actually work out > to be nil (giving that all the streams will respond eventually in > relatively proportionate ways). > > P2P DOESN'T USE THAT TRICK: The slot-and-choke (used by BitTorrent) or > queue-list techniques (used by Gnutella or ED2K) and similar used by > others tends to limit the number of connections actually in use vs. > disconnected or occasionally sending tiny bits of mesh data. Just like > any other sender of information, P2P uploads are overall faster and more > efficient when they respond to congestion signals than they are when > they ignore them. > > P2P AVOIDS CONGESTED ROUTES: Sources for data that are on congested > routes are used less often and for shorter times than sources on routes > that are free of congestion. BitTorrent does this by reserving all but > one of its slots for the fastest reciprocating peers and by reserving > one slot to hunt for even faster peers (the presumption being that slow > peers indicate congested routes). In Gnutella and ED2K, peers are > usually both time and data limited -- so if the clock expires before a > chunk is fully transferred, the transfer is ended. This has the net > effect of getting the most data from peers without such a constraint. > > USING MULTIPLE CONNECTIONS HAS NOTHING TO DO WITH BANDWIDTH CONSUMED: In > one of the presentations, the speaker seemed to tie the use of multiple > connections to bandwidth consumption. The consumption of bandwidth, > however, has everything to do with the size of the object being > transferred and nothing to do with the number of connections. Take the > task of downloading and sharing the Knoppix DVD. If the multiple > connections were replaced by single connections, the bandwidth consumed > would be essentially the same (about 10 GB). The additional overhead is > hardly worth mentioning. > > There is a related -- almost rhyming -- motive, but it's not an evil > motive as far as the network is concerned. Some users observe that > being connected to more peers results in faster downloads. This is > -not- because anyone is ignoring congestion signals, it's simply because > more connections gives a downloader access to a larger number of > altruistic "seeders" (sources who will upload without an immediate > expectation of reciprocation). These seeders are still operating under > the same network rules as other nodes, uploading only on a very limited > number of their connections and responding to signs of congestion > control. (And most users don't realize that seeders have little > motivation to transfer exclusively to them, so while that trick works, > it doesn't work as well as many expect. Many users are disappointed in > the download rates experienced within heavily seeded swarms.) > > There is room for improvement -- like any other network use, P2P > file-sharers have shown that they are very interested in efficiency and > are adaptive to technology or techniques that gets them there. P2P file > sharing is not perfect, either socially or technologically. There are > network cheaters and generally dumb ideas out there. While I'm speaking > generally of typical P2P users, developers, and protocols -- there will > always be the few exceptions. While nobody has targeted these > exceptions as the biggest part of "the problem," I didn't want the above > info to be interpreted as ignoring the fact that they exist here and there. > > > ------------------------------------------------------------------------ > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkl6AUACgkQE5f5cImnZrsx2QCffCgD6jNC1hweFop6H/Kxt8dp iNUAoJV82/0MoswiovhlI6pLP+KgLWbD =xDqF -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 14:54:33 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4B13A69D8; Thu, 20 Nov 2008 14:54:33 -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 A45A73A6984 for ; Thu, 20 Nov 2008 14:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 CMg-1dAszmcO for ; Thu, 20 Nov 2008 14:54:31 -0800 (PST) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by core3.amsl.com (Postfix) with ESMTP id E19513A6806 for ; Thu, 20 Nov 2008 14:54:30 -0800 (PST) Received: (qmail 15469 invoked from network); 20 Nov 2008 22:54:29 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Nov 2008 22:54:29 -0000 Message-ID: <4925EAA5.9090107@asomi.com> Date: Thu, 20 Nov 2008 14:54:29 -0800 From: Caitlin Bestler User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Joe Touch References: <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> <4925E805.1050801@isi.edu> In-Reply-To: <4925E805.1050801@isi.edu> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Robb, > > Appreciating the following, this isn't intended as an application > protocol, so we can't assume it would apply only to P2P. I.e., we need a > solution that can be used for any application, and there are several > applications that DO use multiple connections to increase bandwidth in > the typical case. > As a point of reference, part of the justification for doing iSCSI over multiple TCP connections within a session was because "It might be impossible to achieve the full bandwidth capability of the underlying physical transport by using a single TCP connection." [http://storageconference.org/2003/papers/19-Meth-Design.pdf section 2.2] -- Caitlin Bestler cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.html _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Thu Nov 20 15:06:32 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404B73A6935; Thu, 20 Nov 2008 15:06:32 -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 CFB413A699A for ; Thu, 20 Nov 2008 15:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] 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 Ermik5OBTvBY for ; Thu, 20 Nov 2008 15:06:30 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 9A03B3A67F0 for ; Thu, 20 Nov 2008 15:06:30 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so650357rvf.49 for ; Thu, 20 Nov 2008 15:06:29 -0800 (PST) Received: by 10.141.212.5 with SMTP id o5mr1490301rvq.247.1227222389411; Thu, 20 Nov 2008 15:06:29 -0800 (PST) Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 15:06:29 -0800 (PST) Message-ID: <3efc39a60811201506s120a731dv50cb01d61c26ef59@mail.gmail.com> Date: Thu, 20 Nov 2008 15:06:29 -0800 From: "Robb Topolski" To: "Nicholas Weaver" In-Reply-To: <7C1BD40A-C0F3-465E-A438-8C25DD66E1F8@icsi.berkeley.edu> MIME-Version: 1.0 References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> <3efc39a60811201233n62b4265ar566228d4e4f60d12@mail.gmail.com> <7C1BD40A-C0F3-465E-A438-8C25DD66E1F8@icsi.berkeley.edu> Cc: ledbat@ietf.org Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1860956807==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============1860956807== Content-Type: multipart/alternative; boundary="----=_Part_95455_32172947.1227222389412" ------=_Part_95455_32172947.1227222389412 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Replies inline... On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver wrote: > > In the aggregate, a bulk-data P2P system must upload as much as it > downloads, and your performance becomes limited by uplink bandwidth. > We can start here, although I know it's not the crux of your point. "In the aggregate," true, but "your performance" is not in that context -- its yours alone. I think the value of 1:1 up:down participation on an individual basis is overrated if not unhealthy (if not unattainable). There will always be some last downloader in a swarm -- who is he going to upload to? How many swarms that should have died stay alive (and perform poorly) in a futile effort for someone to reach their 1:1 goal? Such goals forget that some people value getting their own interests out there, and are motivated to spend their energy (and bandwidth) in doing that (quickly/broadly/efficiently etc) and that activity is further skewed based on their preferences (linux, anime, porn, first-run movies, software, old music, amateur documentaries). > When you have a significant group of hosts with a near-zero uplink, these > hosts contribute very little to the overall performance of the system. > > EG, if 1/2 of the systems are cable modems with 1 Mbps uplink, and 1/2 are > behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every > single bit of uplink from the DSL lines, you get 8x the uplink from the > cable modem lines. > > At such a point, you might as well, from an aggregate system viewpoint, > reduce the upload of the DSL hosts to 0: they are contributing so little, > but experiencing a huge degredation of performance that MUST occur because > of the minimum buffer size of a few packets. > . > If two dial-up users are reciprocatively sharing chunks of files, that's two slots from the universe of other peer's uploading slots that they won't occupy. It's an efficient pairing. It would be inefficient for one of these dialup users to occupy the upload slot of a cablemodem user for any extended time. (Some clients will open an additional slot if this happens, but that enhanced behavior is optional, and an uploader still won't spend significant time servicing a slow downloader). Could those 128 Kb uploaders service ISDN or Satellite users? Or maybe pair up with a dial-up user (slow but better than 1 Mbps transferring to dial-up)? > You can NEVER size a buffer for a DSL modem for normal TCP such that you > will get good interactive behavior while a full rate upload occurs. > This is the part that got my attention. These aren't like the old phone modems with flow control, so that's why they have this problem? (This isn't really a P2P-related problem, is it?) > In contrast, you can use an effectivev 100-150ms buffer on the cable > modems, so they can get full rate TCP but at the same time, not step on > their interactive traffic (subequent message coming on that). > > I'll watch for it. I wasn't aware that one had less of a problem than the other. Thanks Nick! Robb -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_95455_32172947.1227222389412 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Replies inline...

On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

In the aggregate, a bulk-data P2P system must upload as much as it downloads, and your performance becomes limited by uplink bandwidth.

We can start here, although I know it's not the crux of your point. 

"In the aggregate," true, but "your performance" is not in that context -- its yours alone. 

I think the value of 1:1 up:down participation on an individual basis is overrated if not unhealthy (if not unattainable).  There will always be some last downloader in a swarm -- who is he going to upload to?  How many swarms that should have died stay alive (and perform poorly) in a futile effort for someone to reach their 1:1 goal? 

Such goals forget that some people value getting their own interests out there, and are motivated to spend their energy (and bandwidth) in doing that (quickly/broadly/efficiently etc) and that activity is further skewed based on their preferences (linux, anime, porn, first-run movies, software, old music, amateur documentaries).

 
When you have a significant group of hosts with a near-zero uplink, these hosts contribute very little to the overall performance of the system.
 
EG, if 1/2 of the systems are cable modems with 1 Mbps uplink, and 1/2 are behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every single bit of uplink from the DSL lines, you get 8x the uplink from the cable modem lines.

At such a point, you might as well, from an aggregate system viewpoint, reduce the upload of the DSL hosts to 0: they are contributing so little, but experiencing a huge degredation of performance that MUST occur because of the minimum buffer size of a few packets.
.
 

If two dial-up users are reciprocatively sharing chunks of files, that's two slots from the universe of other peer's uploading slots that they won't occupy.  It's an efficient pairing.  It would be inefficient for one of these dialup users to occupy the upload slot of a cablemodem user for any extended time.  (Some clients will open an additional slot if this happens, but that enhanced behavior is optional, and an uploader still won't spend significant time servicing a slow downloader).

Could those 128 Kb uploaders service ISDN or Satellite users?  Or maybe pair up with a dial-up user (slow but better than 1 Mbps transferring to dial-up)?




You can NEVER size a buffer for a DSL modem for normal TCP such that you will get good interactive behavior while a full rate upload occurs.

This is the part that got my attention.  These aren't like the old phone modems with flow control, so that's why they have this problem?  (This isn't really a P2P-related problem, is it?)

 
In contrast, you can use an effectivev 100-150ms buffer on the cable modems, so they can get full rate TCP but at the same time, not step on their interactive traffic (subequent message coming on that).


I'll watch for it.  I wasn't aware that one had less of a problem than the other. 

Thanks Nick!

Robb


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
------=_Part_95455_32172947.1227222389412-- --===============1860956807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============1860956807==-- From ledbat-bounces@ietf.org Thu Nov 20 15:11:51 2008 Return-Path: X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6A33A67F0; Thu, 20 Nov 2008 15:11:51 -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 0AF3A3A67F0 for ; Thu, 20 Nov 2008 15:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 KpzJhH-8razf for ; Thu, 20 Nov 2008 15:11:50 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 8C26F3A677D for ; Thu, 20 Nov 2008 15:11:48 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSSXusgN2YtAK39kp8hsvm22Kaqdh0xDP@postini.com; Thu, 20 Nov 2008 15:11:49 PST Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 15:11:02 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 15:11:02 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:11:01 -0500 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Nov 2008 23:11:00 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 20 Nov 2008 15:10:44 -0800 From: Reinaldo Penno To: Robb Topolski , Message-ID: Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclLZTbNKWbSVUvTeUyCkjPI01h6Bg== In-Reply-To: <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 23:11:01.0447 (UTC) FILETIME=[4133E570:01C94B65] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427027328==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1427027328== Content-type: multipart/alternative; boundary="B_3310038644_12367244" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3310038644_12367244 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Robb, 10GB is not a measure of bandwidth. It is a measure of file size or volume if you will. Bw is a measure of how many bis you can transfer per second. There is a time scale involved. Thanks, Reinaldo On 11/20/08 2:24 PM, "Robb Topolski" wrote: > the bandwidth consumed would be essentially the same (about 10 GB). --B_3310038644_12367244 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [ledbat] list of reasons for needing multiple TCP connections</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Robb,<BR> <BR> 10GB is not a measure of bandwidth. It is a measure of file size or volume = if you will.  Bw is a measure of how many bis you can transfer per seco= nd. There is a time scale involved.<BR> <BR> Thanks,<BR> <BR> Reinaldo<BR> <BR> <BR> On 11/20/08 2:24 PM, "Robb Topolski" <<a href=3D"robb@funchords.= com">robb@funchords.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>the bandwidth consumed would be essentially the = same (about 10 GB).<BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3310038644_12367244-- --===============1427027328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============1427027328==-- From ledbat-bounces@ietf.org Thu Nov 20 15:23:34 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D9A28C158; Thu, 20 Nov 2008 15:23:33 -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 26DBB28C158 for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 15:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.413, 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 9Uluv7ekpd7i for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 15:23:32 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 57F4228C155 for <ledbat@ietf.org>; Thu, 20 Nov 2008 15:23:32 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so656297rvf.49 for <ledbat@ietf.org>; Thu, 20 Nov 2008 15:23:31 -0800 (PST) Received: by 10.141.86.14 with SMTP id o14mr1500742rvl.233.1227223410966; Thu, 20 Nov 2008 15:23:30 -0800 (PST) Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 15:23:30 -0800 (PST) Message-ID: <3efc39a60811201523w5cc95b21ya43b1224477c9c1d@mail.gmail.com> Date: Thu, 20 Nov 2008 15:23:30 -0800 From: "Robb Topolski" <robb@funchords.com> To: "Caitlin Bestler" <cait@asomi.com> In-Reply-To: <4925EAA5.9090107@asomi.com> MIME-Version: 1.0 References: <A0988C2F192F124FAFE3D70264C04587077A130C@xmb-sjc-231.amer.cisco.com> <C54B2BA4.3B85%lars.eggert@nokia.com> <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> <4925E805.1050801@isi.edu> <4925EAA5.9090107@asomi.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="===============0766221561==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0766221561== Content-Type: multipart/alternative; boundary="----=_Part_95745_21726176.1227223410961" ------=_Part_95745_21726176.1227223410961 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Nov 20, 2008 at 2:54 PM, Caitlin Bestler <cait@asomi.com> wrote: > As a point of reference, part of the justification for doing iSCSI > over multiple TCP connections within a session was because "It > might be impossible to achieve the full bandwidth capability > of the underlying physical transport by using a single TCP > connection." > > [http://storageconference.org/2003/papers/19-Meth-Design.pdf > section 2.2] > > Good stuff there, the relevant reasoning that might be sucked into a LEDBAT paper include: It might be impossible to achieve the full bandwidth capa- bility of the underlying physical transport by using a sin- gle TCP connection (possibly due to the TCP window size and the round-trip-time of TCP acknowledgements over long distances). Some protocols, like SCTP, auto- matically and transparently distribute their traffic over a number of connections in order to achieve the full band- width. There may also be several physical interconnects (i.e. separate cables) connecting the initiator and target, and it would be most desirable to aggregate and simulta- neously utilize all such existing physical connections. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_95745_21726176.1227223410961 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <br><br><div class="gmail_quote">On Thu, Nov 20, 2008 at 2:54 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:cait@asomi.com">cait@asomi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> As a point of reference, part of the justification for doing iSCSI<br> over multiple TCP connections within a session was because "It<br> might be impossible to achieve the full bandwidth capability<br> of the underlying physical transport by using a single TCP<br> connection."<br> <br> [<a href="http://storageconference.org/2003/papers/19-Meth-Design.pdf" target="_blank">http://storageconference.org/2003/papers/19-Meth-Design.pdf</a><br> section 2.2]<div><div></div><div class="Wj3C7c"><br> </div></div></blockquote><div><br>Good stuff there, the relevant reasoning that might be sucked into a LEDBAT paper include:<br><br>              It might be impossible to achieve the full bandwidth capa-<br>              bility of the underlying physical transport by using a sin-<br>               gle TCP connection (possibly due to the TCP window<br>              size and the round-trip-time of TCP acknowledgements<br>              over long distances). Some protocols, like SCTP, auto-<br>              matically and transparently distribute their traffic over a<br>               number of connections in order to achieve the full band-<br>              width. There may also be several physical interconnects<br>              (i.e. separate cables) connecting the initiator and target,<br>               and it would be most desirable to aggregate and simulta-<br>              neously utilize all such existing physical connections.<br> <br></div></div><br clear="all"><br>-- <br>Robb Topolski (<a href="mailto:robb@funchords.com">robb@funchords.com</a>)<br> Hillsboro, Oregon USA<br><a href="http://www.funchords.com/">http://www.funchords.com/</a><br> ------=_Part_95745_21726176.1227223410961-- --===============0766221561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0766221561==-- From ledbat-bounces@ietf.org Thu Nov 20 15:55:39 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E8E3A6A48; Thu, 20 Nov 2008 15:55:39 -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 68FC63A6984 for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 15:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.664 X-Spam-Level: X-Spam-Status: No, score=-9.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6] 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 AeAPcOUf6YvZ for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 15:55:37 -0800 (PST) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D64FD3A6A35 for <ledbat@ietf.org>; Thu, 20 Nov 2008 15:55:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id E0EF5E10B24; Thu, 20 Nov 2008 18:55:32 -0500 (EST) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IarckIPxwu1; Thu, 20 Nov 2008 18:55:19 -0500 (EST) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 9E9B9E10B17; Thu, 20 Nov 2008 18:55:19 -0500 (EST) Date: Thu, 20 Nov 2008 18:55:19 -0500 (EST) From: Laird Popkin <laird@pando.com> To: Robb Topolski <robb@funchords.com> Message-ID: <570928620.115911227225319609.JavaMail.root@dkny.pando.com> In-Reply-To: <1460863631.115891227225138256.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: ledbat@ietf.org Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... 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="===============0660984679==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0660984679== Content-Type: multipart/alternative; boundary="----=_Part_4978_132023653.1227225319608" ------=_Part_4978_132023653.1227225319608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This is a good point. Keep in mind that tit-for-tat (i.e. sending as much as you receive with each peer) is only enforced between downloaders - anyone who has completed downloading contributes freely and does not get anything in return. Even between downloaders, tit-for-tat is not enforced absolutely, but only very approximately. Also keep in mind that not all p2p networks use tit-for-tat. So while it's certainly useful to think about the BitTorrent case, there are many other kinds of p2p network (e.g. live streaming) that care more about other attributes (e.g. latency) rather than fairness between peers. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Robb Topolski" <robb@funchords.com> To: "Nicholas Weaver" <nweaver@icsi.berkeley.edu> Cc: ledbat@ietf.org Sent: Thursday, November 20, 2008 6:06:29 PM (GMT-0500) America/New_York Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... Replies inline... On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver < nweaver@icsi.berkeley.edu > wrote: In the aggregate, a bulk-data P2P system must upload as much as it downloads, and your performance becomes limited by uplink bandwidth. We can start here, although I know it's not the crux of your point. "In the aggregate," true, but "your performance" is not in that context -- its yours alone. I think the value of 1:1 up:down participation on an individual basis is overrated if not unhealthy (if not unattainable). There will always be some last downloader in a swarm -- who is he going to upload to? How many swarms that should have died stay alive (and perform poorly) in a futile effort for someone to reach their 1:1 goal? Such goals forget that some people value getting their own interests out there, and are motivated to spend their energy (and bandwidth) in doing that (quickly/broadly/efficiently etc) and that activity is further skewed based on their preferences (linux, anime, porn, first-run movies, software, old music, amateur documentaries). When you have a significant group of hosts with a near-zero uplink, these hosts contribute very little to the overall performance of the system. EG, if 1/2 of the systems are cable modems with 1 Mbps uplink, and 1/2 are behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every single bit of uplink from the DSL lines, you get 8x the uplink from the cable modem lines. At such a point, you might as well, from an aggregate system viewpoint, reduce the upload of the DSL hosts to 0: they are contributing so little, but experiencing a huge degredation of performance that MUST occur because of the minimum buffer size of a few packets. . If two dial-up users are reciprocatively sharing chunks of files, that's two slots from the universe of other peer's uploading slots that they won't occupy. It's an efficient pairing. It would be inefficient for one of these dialup users to occupy the upload slot of a cablemodem user for any extended time. (Some clients will open an additional slot if this happens, but that enhanced behavior is optional, and an uploader still won't spend significant time servicing a slow downloader). Could those 128 Kb uploaders service ISDN or Satellite users? Or maybe pair up with a dial-up user (slow but better than 1 Mbps transferring to dial-up)? You can NEVER size a buffer for a DSL modem for normal TCP such that you will get good interactive behavior while a full rate upload occurs. This is the part that got my attention. These aren't like the old phone modems with flow control, so that's why they have this problem? (This isn't really a P2P-related problem, is it?) In contrast, you can use an effectivev 100-150ms buffer on the cable modems, so they can get full rate TCP but at the same time, not step on their interactive traffic (subequent message coming on that). I'll watch for it. I wasn't aware that one had less of a problem than the other. Thanks Nick! Robb -- 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 ------=_Part_4978_132023653.1227225319608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style><style type=3D= 'text/css'>body { font-family: 'Times New Roman'; font-size: 12pt; color: #= 000000}</style></head><body>This is a good point.<br><br>Keep in mind that = tit-for-tat (i.e. sending as much as you receive with each peer) is only en= forced between downloaders - anyone who has completed downloading contribut= es freely and does not get anything in return. Even between downloaders, ti= t-for-tat is not enforced absolutely, but only very approximately.<br><br>A= lso keep in mind that not all p2p networks use tit-for-tat. So while it's c= ertainly useful to think about the BitTorrent case, there are many other ki= nds of p2p network (e.g. live streaming) that care more about other attribu= tes (e.g. latency) rather than fairness between peers.<br><br>- Laird&= nbsp;Popkin, CTO, Pando Networks<br>  mobile: = ;646/465-0570<br><br>----- Original Message -----<br>From: "Robb Topolski" = <robb@funchords.com><br>To: "Nicholas Weaver" <nweaver@icsi.berkel= ey.edu><br>Cc: ledbat@ietf.org<br>Sent: Thursday, November 20, 2008 6:06= :29 PM (GMT-0500) America/New_York<br>Subject: Re: [ledbat] Note well on th= e BitTorrent problem on the example...<br><br>Replies inline...<br><br><div= class=3D"gmail_quote">On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver <s= pan dir=3D"ltr"><<a href=3D"mailto:nweaver@icsi.berkeley.edu" target=3D"= _blank">nweaver@icsi.berkeley.edu</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margi= n: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class=3D"Ih2E3d"><br>In the aggregate, a bulk-data P2P system must upl= oad as much as it downloads, and your performance becomes limited by uplink= bandwidth.</div></blockquote><div><br>We can start here, although I know i= t's not the crux of your point.  <br> <br>"In the aggregate," true, but "your performance" is not in that context= -- its yours alone.  <br><br>I think the value of 1:1 up:down partici= pation on an individual basis is overrated if not unhealthy (if not unattai= nable).  There will always be some last downloader in a swarm -- who i= s he going to upload to?  How many swarms that should have died stay a= live (and perform poorly) in a futile effort for someone to reach their 1:1= goal?  <br> <br>Such goals forget that some people value getting their own interests ou= t there, and are motivated to spend their energy (and bandwidth) in doing t= hat (quickly/broadly/efficiently etc) and that activity is further skewed b= ased on their preferences (linux, anime, porn, first-run movies, software, = old music, amateur documentaries). <br> <br> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px= solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><= div class=3D"Ih2E3d">When you have a significant group of hosts with a near= -zero uplink, these hosts contribute very little to the overall performance= of the system. </div> </blockquote><div> </div><blockquote class=3D"gmail_quote" style=3D"bo= rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding= -left: 1ex;"><div class=3D"Ih2E3d">EG, if 1/2 of the systems are cable mode= ms with 1 Mbps uplink, and 1/2 are behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every single bit of uplink from the DSL lines, you get 8x the uplink from the cable modem lines.<br> <br> At such a point, you might as well, from an aggregate system viewpoint, reduce the upload of the DSL hosts to 0: they are contributing so little, but experiencing a huge degredation of performance that MUST occur because of the minimum buffer size of a few packets.<br> .</div></blockquote><div> </div><div><br>If two dial-up users are reci= procatively sharing chunks of files, that's two slots from the universe of = other peer's uploading slots that they won't occupy.  It's an efficien= t pairing.  It would be inefficient for one of these dialup users to o= ccupy the upload slot of a cablemodem user for any extended time.  (So= me clients will open an additional slot if this happens, but that enhanced = behavior is optional, and an uploader still won't spend significant time se= rvicing a slow downloader).<br> <br>Could those 128 Kb uploaders service ISDN or Satellite users?  Or = maybe pair up with a dial-up user (slow but better than 1 Mbps transferring= to dial-up)?<br><br><br><br></div><blockquote class=3D"gmail_quote" style= =3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p= adding-left: 1ex;"> <br> You can NEVER size a buffer for a DSL modem for normal TCP such that you wi= ll get good interactive behavior while a full rate upload occurs.<br> </blockquote><div><br>This is the part that got my attention.  These a= ren't like the old phone modems with flow control, so that's why they have = this problem?  (This isn't really a P2P-related problem, is it?)<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px= solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I= n contrast, you can use an effectivev 100-150ms buffer on the cable modems,= so they can get full rate TCP but at the same time, not step on their inte= ractive traffic (subequent message coming on that).<br> <br> </blockquote></div><br>I'll watch for it.  I wasn't aware that one had= less of a problem than the other.  <br><br>Thanks Nick!<br><br>Robb<b= r><br clear=3D"all"><br>-- <br>Robb Topolski (<a href=3D"mailto:robb@funcho= rds.com" target=3D"_blank">robb@funchords.com</a>)<br> Hillsboro, Oregon USA<br><a href=3D"http://www.funchords.com/" target=3D"_b= lank">http://www.funchords.com/</a><br> <br>_______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat </body></html> ------=_Part_4978_132023653.1227225319608-- --===============0660984679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0660984679==-- From ledbat-bounces@ietf.org Thu Nov 20 16:28:33 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610A73A6801; Thu, 20 Nov 2008 16:28:33 -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 2632B3A6801 for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 16:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] 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 0tNuXIQ2-q22 for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 16:28:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2D5653A67F0 for <ledbat@ietf.org>; Thu, 20 Nov 2008 16:28:31 -0800 (PST) Received: from [130.129.94.243] ([130.129.94.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAL0SEet014991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 16:28:17 -0800 (PST) Message-ID: <4926009E.2090103@isi.edu> Date: Thu, 20 Nov 2008 16:28:14 -0800 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Robb Topolski <robb@funchords.com> References: <A0988C2F192F124FAFE3D70264C04587077A130C@xmb-sjc-231.amer.cisco.com> <C54B2BA4.3B85%lars.eggert@nokia.com> <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> <4925E805.1050801@isi.edu> <4925EAA5.9090107@asomi.com> <3efc39a60811201523w5cc95b21ya43b1224477c9c1d@mail.gmail.com> In-Reply-To: <3efc39a60811201523w5cc95b21ya43b1224477c9c1d@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, It's useful to differentiate between TCP not getting full BW because it uses only a single path, vs. TCP not getting full BW because its window doesn't open fast enough. SCTP addresses the former, not the latter; the two have the same problem in the latter case. There are a variety of extensions to TCP's windowing mechanism to address high BW*delay product environments which apply equally well to SCTP in those cases. Joe Robb Topolski wrote: > > > On Thu, Nov 20, 2008 at 2:54 PM, Caitlin Bestler <cait@asomi.com > <mailto:cait@asomi.com>> wrote: > > As a point of reference, part of the justification for doing iSCSI > over multiple TCP connections within a session was because "It > might be impossible to achieve the full bandwidth capability > of the underlying physical transport by using a single TCP > connection." > > [http://storageconference.org/2003/papers/19-Meth-Design.pdf > section 2.2] > > > Good stuff there, the relevant reasoning that might be sucked into a > LEDBAT paper include: > > It might be impossible to achieve the full bandwidth capa- > bility of the underlying physical transport by using a sin- > gle TCP connection (possibly due to the TCP window > size and the round-trip-time of TCP acknowledgements > over long distances). Some protocols, like SCTP, auto- > matically and transparently distribute their traffic over a > number of connections in order to achieve the full band- > width. There may also be several physical interconnects > (i.e. separate cables) connecting the initiator and target, > and it would be most desirable to aggregate and simulta- > neously utilize all such existing physical connections. > > > > -- > Robb Topolski (robb@funchords.com <mailto:robb@funchords.com>) > Hillsboro, Oregon USA > http://www.funchords.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkmAJ4ACgkQE5f5cImnZrs6VACfZ/dvo9SUC8UWzKZHJTx0NGah ATQAoIbqSiD8KCzZ1W3JDg10v5qevxqL =AHaI -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Fri Nov 21 05:33:34 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A87A3A6935; Fri, 21 Nov 2008 05:33:34 -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 DF7E93A6935 for <ledbat@core3.amsl.com>; Fri, 21 Nov 2008 05:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 qIF-m9CaflmC for <ledbat@core3.amsl.com>; Fri, 21 Nov 2008 05:33:31 -0800 (PST) Received: from hera.mpi-sb.mpg.de (hera.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id 9EEB43A6919 for <ledbat@ietf.org>; Fri, 21 Nov 2008 05:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Cc:Message-Id:From:To: In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version: Subject:Date:References; bh=E4TGdGoVCyWjt261EseRxmUBZRs5OaZWlNJq o5Zr4lc=; b=T1uQFwlqw8B2YL2qio9ZD+nfVP27MCYRWrWIsDi/ntuOE+Y1L2oe 7kuBsju7L8ShKIDhE0P4k5hxENnL2ppKusQ9Rd4IxujG1rCBV9romsnmvBb0416Q r31+uzICmXe4XrjR4QkR9HaITE9hQBCaenDq7564l9HnUIt5fQGp+ZU= Received: from newzak.mpi-sb.mpg.de ([139.19.1.28]:44215) by hera.mpi-sb.mpg.de (envelope-from <baford@mpi-sws.org>) with esmtp (Exim 4.69) id 1L3W8Q-0003jS-W8; Fri, 21 Nov 2008 14:33:27 +0100 Received: from [75.146.152.44] (port=62192 helo=[10.71.0.213]) by newzak.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <baford@mpi-sws.org>) id 1L3W8Q-0007jF-8P; Fri, 21 Nov 2008 14:33:22 +0100 Message-Id: <615CAD34-0761-4266-9CA9-4BDD98C6DC60@mpi-sws.org> From: Bryan Ford <baford@mpi-sws.org> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <4925DC9F.6090403@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 07:33:19 -0600 References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <4925DBB3.80509@asomi.com> <4925DC9F.6090403@isi.edu> X-Mailer: Apple Mail (2.929.2) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 20, 2008, at 3:54 PM, Joe Touch wrote: > Caitlin Bestler wrote: >> Andrew G. Malis wrote: >>> As was mentioned in the IAB plenary yesterday, a reason to not use >>> multiple TCP connections is the possible exhaustion of middlebox >>> (read >>> NAT) resources, such as state memory or port numbers. So if you are >>> going to use multiple connections in parallel, you may wish to >>> include >>> a method for the user to control that behavior, and a way to detect >>> that you're behind a NAT and adapt appropriately. >>> >> >> The gotcha here is that every item in the list Joe supplied is >> already solved by SCTP, and about the only legitimate reason >> for not using SCTP is the presence of middleboxes that do >> not support it. > > SCTP doesn't address the need for different applications to have > different connections (one variant of the demultiplexing issue). > I.e., a > single socket used by more than one application. > > SCTP also doesn't address the need to support endpoints that don't > speak > SCTP yet, or services that aren't defined over SCTP yet. Just to fill this out, a third issue is that the multiple logical streams sharing an SCTP connection have no independent flow control: SCTP provides flow control only for the connection as a whole. Thus, the receive side of any connection has to accept data on all the streams at whatever (relative) rates the sending side is sending data on those streams, and can't "push back" on one stream while allowing another to flow, unless the application implements some additional higher-level windowing and flow control mechanism. If a web browser is downloading two HTTP objects at once using two SCTP streams sharing one connection, for example, and one is a file downloading to a fast disk but the other is an mp3 or avi file that the browser is streaming to a constant-rate audio/video frame, then the browser has no direct way to limit the download rate of the a/v stream to the output rate without also holding back the file download. (Granted, this particular example doesn't typically happen with current browsers, since browser plug-ins typically handle media streams, using completely separate connections to the server.) Bryan _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Fri Nov 21 11:44:08 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AB13A67A7; Fri, 21 Nov 2008 11:44: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 D505B3A6975 for <ledbat@core3.amsl.com>; Fri, 21 Nov 2008 11:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xS2fC2qopwsn for <ledbat@core3.amsl.com>; Fri, 21 Nov 2008 11:44:06 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E9A053A67A7 for <ledbat@ietf.org>; Fri, 21 Nov 2008 11:44:05 -0800 (PST) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 21 Nov 2008 11:44:04 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.54.46.188]) with mapi; Fri, 21 Nov 2008 11:44:04 -0800 From: Murari Sridharan <muraris@microsoft.com> To: Murari Sridharan <muraris@microsoft.com>, "janardhan.iyengar@fandm.edu" <janardhan.iyengar@fandm.edu> Date: Fri, 21 Nov 2008 11:44:03 -0800 Thread-Topic: Feedback on LEDBAT presentation Thread-Index: AclLTPHnVAWh42FESbme8zgJFnsubQACd4uMAC6n1RA= Message-ID: <FCA794787FDE0D4DBE9FFA11053ECEB61AFCE545C4@NA-EXMSG-C110.redmond.corp.microsoft.com> References: <4925C5B1.7020207@fandm.edu> <FCA794787FDE0D4DBE9FFA11053ECEB61AFCBA54A2@NA-EXMSG-C110.redmond.corp.microsoft.com> In-Reply-To: <FCA794787FDE0D4DBE9FFA11053ECEB61AFCBA54A2@NA-EXMSG-C110.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ledbat@ietf.org" <ledbat@ietf.org> Subject: Re: [ledbat] Feedback on LEDBAT presentation 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Interesting paper below. We did some of this work on socket buffer autotuning in windows as well. I'll read in detail, thanks for the pointer. -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Murari Sridharan Sent: Thursday, November 20, 2008 1:38 PM To: janardhan.iyengar@fandm.edu Cc: ledbat@ietf.org Subject: Re: [ledbat] Feedback on LEDBAT presentation Thanks for your mail Jana, i have just uploaded all the presentations online. ________________________________________ From: Janardhan Iyengar [janardhan.iyengar@fandm.edu] Sent: Thursday, November 20, 2008 12:16 PM To: Murari Sridharan Subject: Feedback on LEDBAT presentation Hi Murari, I attended the session remotely, and did not see the slides since they were not on the IETF materials page. Can you put the slides for all the presentations out? The little bit that I could follow without the slides, this sounds interesting for sure. I wanted to point you to some work done by Manish Jain (you mentioned his work with Dovrolis from SIGCOMM 2002) called SOBAS which seems related: http://www.cc.gatech.edu/~jain/publications/sobas_grid.pdf On the same note, Manish is actually a postdoc at MSR in Seattle right now. Thanks, - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Sat Nov 22 19:41:15 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1F73A67DF; Sat, 22 Nov 2008 19:41:15 -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 108E03A67DF for <ledbat@core3.amsl.com>; Sat, 22 Nov 2008 19:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 RQ21nXMwufEY for <ledbat@core3.amsl.com>; Sat, 22 Nov 2008 19:41:13 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 72DE63A67A3 for <ledbat@ietf.org>; Sat, 22 Nov 2008 19:41:13 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1748130wfd.31 for <ledbat@ietf.org>; Sat, 22 Nov 2008 19:41:11 -0800 (PST) Received: by 10.142.144.16 with SMTP id r16mr1023855wfd.77.1227411671711; Sat, 22 Nov 2008 19:41:11 -0800 (PST) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 30sm4986036wfd.24.2008.11.22.19.41.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 22 Nov 2008 19:41:10 -0800 (PST) Message-Id: <80ECA117-243B-49E0-954D-1EF9434E6965@shlang.com> From: Stanislav Shalunov <shalunov@shlang.com> To: ledbat@ietf.org In-Reply-To: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 22 Nov 2008 19:41:08 -0800 References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> X-Mailer: Apple Mail (2.929.2) Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org My example was about running a single uploading TCP connection, not about running BitTorrent. Running BitTorrent is somewhat harder to analyze because of multiple connections and an aggregate macro-scale rate limit. On Nov 20, 2008, at 12:27 PM, Nicholas Weaver wrote: > A network with only 128 Kbps uplink, >1.5 Mbps downlink (a 10-1 > download/upload ratio) is not suitable for P2P anyway, Incorrect. The typical cheapest broadband connection is suitable for running P2P. BitTorrent works fine on it, with the expected speeds. The 10:1 down:up ratio is typical for home connections. More expensive connections can often have even higher ratios. > it really should be "leech only", "Should"? It clearly gets higher download rate for young swarms with uploading. Even in the most selfish interpretation it shouldn't be leeching only. > as it contributes nothing to the P2P system in practice. Incorrect. It contributes close to 128 kb/s, which is not nothing. -- Stanislav Shalunov _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Sun Nov 23 08:12:57 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980463A6837; Sun, 23 Nov 2008 08:12:57 -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 9F10B3A6837 for <ledbat@core3.amsl.com>; Sun, 23 Nov 2008 08:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CJlm6t4e+jU7 for <ledbat@core3.amsl.com>; Sun, 23 Nov 2008 08:12:54 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DBE6B3A67DB for <ledbat@ietf.org>; Sun, 23 Nov 2008 08:12:54 -0800 (PST) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id mANGCBTu023579; Sun, 23 Nov 2008 08:12:51 -0800 (PST) Message-Id: <DC8385BC-9899-48B1-861F-14D94CCB105E@icsi.berkeley.edu> From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> To: Stanislav Shalunov <shalunov@shlang.com> In-Reply-To: <80ECA117-243B-49E0-954D-1EF9434E6965@shlang.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 23 Nov 2008 08:12:11 -0800 References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> <80ECA117-243B-49E0-954D-1EF9434E6965@shlang.com> X-Mailer: Apple Mail (2.929.2) Cc: ledbat@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org I know your example is about a single full-rate TCP flow, not BitTorrent. But your all about the "bad queue" congestion problem, with occurs ALMOST exclusively for people in such situations when doing P2P activity over web-surfing. I'd guess that part of the reason we have gotten away with such grossly asymmetric links is that, outside P2P usage, I'd guess that most users are grossly asymmetric in usage. I know I was, the 3-s uplink buffer on my DSL line only bothered me when I was uploading photos or synchronizing work. On Nov 22, 2008, at 7:41 PM, Stanislav Shalunov wrote: >> it really should be "leech only", > > "Should"? It clearly gets higher download rate for young swarms > with uploading. Even in the most selfish interpretation it > shouldn't be leeching only. > >> as it contributes nothing to the P2P system in practice. > > Incorrect. It contributes close to 128 kb/s, which is not nothing. Its Amdahl's law-related: It really IS close to nothing, and enough that if you care about user performance because you are experiencing head of line blocking issues, that reducing it to 0 is fine. EG. You have 1/2 the peers behind cable-modems, with 1 Mbps uplinks. And you have 1/2 the peers behind slow DSL links, with 128 kbps uplinks. The P2P performance becomes limited by the uplinks in aggregate. And the cable modems contribute 8x the aggregate bandwidth that the DSL links do. In this case, putting ALL the DSL links to 0 upload will have a remarkably low effect on aggregate performance: a degradation of total system upload bandwidth of only 11%. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Sun Nov 23 08:26:36 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9D03A6837; Sun, 23 Nov 2008 08:26:36 -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 774D33A6837 for <ledbat@core3.amsl.com>; Sun, 23 Nov 2008 08:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 KhOXdASdpPMX for <ledbat@core3.amsl.com>; Sun, 23 Nov 2008 08:26:35 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id D64D83A67DB for <ledbat@ietf.org>; Sun, 23 Nov 2008 08:26:35 -0800 (PST) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id mANGPrrH025168; Sun, 23 Nov 2008 08:26:33 -0800 (PST) Message-Id: <ADDE3DF9-A645-4540-AEED-6BB779BCB19C@ICSI.Berkeley.EDU> From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> In-Reply-To: <DC8385BC-9899-48B1-861F-14D94CCB105E@icsi.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 23 Nov 2008 08:25:53 -0800 References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> <80ECA117-243B-49E0-954D-1EF9434E6965@shlang.com> <DC8385BC-9899-48B1-861F-14D94CCB105E@icsi.berkeley.edu> X-Mailer: Apple Mail (2.929.2) Cc: ledbat@ietf.org Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 23, 2008, at 8:12 AM, Nicholas Weaver wrote: > I know your example is about a single full-rate TCP flow, not > BitTorrent. But your all about the "bad queue" congestion problem, > with occurs ALMOST exclusively for people in such situations when > doing P2P activity over web-surfing. Well, there is backup like applications and photo uploading, but backup/synchronization over the WAN still seems to be a niche market (iDisk I think is the biggest player). But in those cases, the activity can easily be time-shifted away from usage, rather than an integral part of getting content. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 24 00:26:00 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112C83A6B8F; Mon, 24 Nov 2008 00:26:00 -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 938863A6B8F for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 00:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-4] 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 QEcRucJaYtu3 for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 00:25:58 -0800 (PST) Received: from smtp.uibk.ac.at (lmr1.uibk.ac.at [138.232.1.142]) by core3.amsl.com (Postfix) with ESMTP id 81E8A3A67D8 for <ledbat@ietf.org>; Mon, 24 Nov 2008 00:25:58 -0800 (PST) Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id mAO8Pspf017700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ledbat@ietf.org>; Mon, 24 Nov 2008 09:25:54 +0100 From: Michael Welzl <michael.welzl@uibk.ac.at> To: ledbat@ietf.org In-Reply-To: <4925EAA5.9090107@asomi.com> References: <A0988C2F192F124FAFE3D70264C04587077A130C@xmb-sjc-231.amer.cisco.com> <C54B2BA4.3B85%lars.eggert@nokia.com> <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> <4925E805.1050801@isi.edu> <4925EAA5.9090107@asomi.com> Organization: University of Innsbruck Date: Mon, 24 Nov 2008 09:25:54 +0100 Message-Id: <1227515154.3731.48.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Hi, On Thu, 2008-11-20 at 14:54 -0800, Caitlin Bestler wrote: > Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, Robb, > > > > Appreciating the following, this isn't intended as an application > > protocol, so we can't assume it would apply only to P2P. I.e., we need a > > solution that can be used for any application, and there are several > > applications that DO use multiple connections to increase bandwidth in > > the typical case. > > > > As a point of reference, part of the justification for doing iSCSI > over multiple TCP connections within a session was because "It > might be impossible to achieve the full bandwidth capability > of the underlying physical transport by using a single TCP > connection." > > [http://storageconference.org/2003/papers/19-Meth-Design.pdf > section 2.2] > I'd like to add GridFTP to this, as another example. cf.: http://www.globus.org/toolkit/docs/3.2/gridftp/ which points to: http://www.globus.org/alliance/publications/papers/dataMgmt.pdf where it says, on page 7: "Parallel data transfer: On wide-area links, using multiple TCP streams in parallel (even between the same source and destination) can improve aggregate bandwidth over using a single TCP stream [10]. GridFTP supports parallel data transfer through FTP command extensions and data channel extensions." Cheers, Michael _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 24 15:28:38 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5733A6B88; Mon, 24 Nov 2008 15:28:38 -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 1D6D13A6B88 for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:28:37 -0800 (PST) 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 dyKCIESeyxUN for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:28:36 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.234]) by core3.amsl.com (Postfix) with ESMTP id E71023A68DC for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:28:35 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id f17so2327943qba.41 for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:28:33 -0800 (PST) Received: by 10.140.203.9 with SMTP id a9mr2118426rvg.64.1227569312578; Mon, 24 Nov 2008 15:28:32 -0800 (PST) Received: from ?10.0.1.234? (ip-208-72-192-23.bittorrent.com [208.72.192.23]) by mx.google.com with ESMTPS id l31sm13708275rvb.2.2008.11.24.15.28.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 15:28:31 -0800 (PST) Message-Id: <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> From: Stanislav Shalunov <shalunov@shlang.com> To: "Andrew G. Malis" <agmalis@gmail.com> In-Reply-To: <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 15:28:17 -0800 References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org We do need to cover the impact on middleboxes in the document -- it's in the charter. Popular applications are made to work with existing middleboxes. Middleboxes are made to work with existing popular apps which do open couple hundred of (mostly idle) TCP connections. Home NATs ("routers") don't generally crash when you run BitTorrent. The "mostly idle" part doesn't matter for state consumption, naturally. Thousands and tens of thousands of connections (UDP state counts) is another matter. Making one DNS request per every swarm member you learn about will overwhelm a few common devices for large enough swarms. (There are client behavior extensions that use DNS requests to learn about locations of peers.) In general, scanning-type behavior is problematic. -- Stas On Nov 20, 2008, at 12:06 PM, Andrew G. Malis wrote: > As was mentioned in the IAB plenary yesterday, a reason to not use > multiple TCP connections is the possible exhaustion of middlebox (read > NAT) resources, such as state memory or port numbers. So if you are > going to use multiple connections in parallel, you may wish to include > a method for the user to control that behavior, and a way to detect > that you're behind a NAT and adapt appropriately. > > Cheers, > Andy > > On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch <touch@isi.edu> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Responding to the issue of reasons to need multiple connections, here >> are a few of mine (extended from those listed at the mic). This is >> not >> intended to be a complete list, but a reasonable place to start. The >> general point is that this is NOT always about hogging bandwidth, >> either >> intentionally or not. >> >> Joe >> >> - -------------------------------------- >> Reasons to use multiple concurrent TCP connections: >> >> - - get around head-of-line blocking >> this was an original reason for web browsers needing them >> >> - - demultiplexing >> related to HOL blocking but not requiring it, >> this uses TCP connections to demultiplex different >> streams, because TCP doesn't provide that labeling itself >> >> this was a reason for using different connections for FTP >> data and control, e.g. >> >> - - support different stream properties >> i.e., a single app may want different streams with Nagle >> enabled and disabled, or with different socket buffer >> sizes (to limit delay) >> >> - - support "CLOSE means EOF" semantics >> a reason for multiple connections in HTTP 1.0 >> >> - - support larger socket buffer sizes >> esp. without autotuning, but even with, more connections >> means more socket buffering is available >> >> - ------- >> >> One I forgot to note: >> >> - - different interaction with errors >> a single connection would keep restarting; >> multiple connections increases the possibility that >> one connection doesn't get hit with a short error burst >> >> - ---------------------------------------------- >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 >> HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF >> =YmcT >> -----END PGP SIGNATURE----- >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat >> > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat -- Stanislav Shalunov _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 24 15:46:09 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092653A682C; Mon, 24 Nov 2008 15:46:09 -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 9CF543A67FC for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:46:07 -0800 (PST) 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 WwkCKZbsQjsm for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:46:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id EBC7D3A6826 for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:46:06 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2249431rvf.49 for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:46:04 -0800 (PST) Received: by 10.140.178.17 with SMTP id a17mr2108369rvf.186.1227570364069; Mon, 24 Nov 2008 15:46:04 -0800 (PST) Received: from ?10.0.1.234? (ip-208-72-192-23.bittorrent.com [208.72.192.23]) by mx.google.com with ESMTPS id k2sm13614095rvb.1.2008.11.24.15.46.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 15:46:02 -0800 (PST) Message-Id: <C3EDD25A-A005-4D01-AB86-D41E22194C5D@shlang.com> From: Stanislav Shalunov <shalunov@shlang.com> To: Caitlin Bestler <cait@asomi.com> In-Reply-To: <4925DBB3.80509@asomi.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 15:46:00 -0800 References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <4925DBB3.80509@asomi.com> X-Mailer: Apple Mail (2.929.2) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 20, 2008, at 1:50 PM, Caitlin Bestler wrote: > Using multiple connections to solve a single problem inherently > degrades the ability of the network to manage traffic effectively. > I recognize that it isn't going to go away anytime soon, but there > is no reason why we should *encourage* this anti-social behavior. The list of applications that open multiple TCP connections to the same destinations includes: * Email (MTAs) * FTP (data+control) * Web (all common browsers since Mosaic) In addition, P2P apps open multiple connections to multiple destinations. This is pretty much the list of Internet killer apps minus IM. It would be counterproductive for us to label this practice anti-social. The multiple connections document needs to provide a lot of facts and a little guidance grounded in facts, not the other way. Can you expand on how multiple connections impede the provider's ability to manage traffic? -- Stanislav Shalunov _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 24 15:52:17 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0443A6B90; Mon, 24 Nov 2008 15:52:17 -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 461793A6B90 for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:52:16 -0800 (PST) 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 dQsLMJIdBxJs for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:52:15 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 69E2C3A6BAC for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:52:15 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2251376rvf.49 for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:52:12 -0800 (PST) Received: by 10.141.115.20 with SMTP id s20mr2127337rvm.70.1227570731800; Mon, 24 Nov 2008 15:52:11 -0800 (PST) Received: from ?10.0.1.234? (ip-208-72-192-23.bittorrent.com [208.72.192.23]) by mx.google.com with ESMTPS id b8sm13619159rvf.3.2008.11.24.15.52.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 15:52:10 -0800 (PST) Message-Id: <B3C85DED-661E-40AD-87B5-799D386552DE@shlang.com> From: Stanislav Shalunov <shalunov@shlang.com> To: Caitlin Bestler <cait@asomi.com> In-Reply-To: <4925EAA5.9090107@asomi.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 15:52:09 -0800 References: <A0988C2F192F124FAFE3D70264C04587077A130C@xmb-sjc-231.amer.cisco.com> <C54B2BA4.3B85%lars.eggert@nokia.com> <3efc39a60811201424l5fc9f1d1keab7e811b5a8bca8@mail.gmail.com> <4925E805.1050801@isi.edu> <4925EAA5.9090107@asomi.com> X-Mailer: Apple Mail (2.929.2) Cc: ledbat@ietf.org, Joe Touch <touch@ISI.EDU> 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Right. Also, of course, GridFTP and probably before it bbcp, popular in high-energy physics community, use multiple connections to go faster -- mainly to get around default buffer size, but also likely to benefit from the reduced deviation in throughput with multiple connections. On Nov 20, 2008, at 2:54 PM, Caitlin Bestler wrote: > Joe Touch wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Hi, Robb, >> Appreciating the following, this isn't intended as an application >> protocol, so we can't assume it would apply only to P2P. I.e., we >> need a >> solution that can be used for any application, and there are several >> applications that DO use multiple connections to increase bandwidth >> in >> the typical case. > > As a point of reference, part of the justification for doing iSCSI > over multiple TCP connections within a session was because "It > might be impossible to achieve the full bandwidth capability > of the underlying physical transport by using a single TCP > connection." > > [http://storageconference.org/2003/papers/19-Meth-Design.pdf > section 2.2] > > > > > -- > Caitlin Bestler > cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.html > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat -- Stanislav Shalunov _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 24 15:59:23 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B296D3A6B03; Mon, 24 Nov 2008 15:59:23 -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 0BC4E3A6B03 for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hUKmsCKXXSEh for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 15:59:21 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 96B773A6A96 for <ledbat@ietf.org>; Mon, 24 Nov 2008 15:59:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSSs/1Pg8qK2+a4iJIovrVH++HB/rWLoo@postini.com; Mon, 24 Nov 2008 15:59:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 24 Nov 2008 15:55:32 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 15:55:32 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 15:55:32 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 18:55:31 -0500 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Nov 2008 23:55:30 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 24 Nov 2008 15:55:17 -0800 From: Reinaldo Penno <rpenno@juniper.net> To: Stanislav Shalunov <shalunov@shlang.com>, "Andrew G. Malis" <agmalis@gmail.com> Message-ID: <C5507EE5.16A89%rpenno@juniper.net> Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclOkBmw5uhpWMyG5EqWK9p9i6ZyOA== In-Reply-To: <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2008 23:55:31.0310 (UTC) FILETIME=[2237A8E0:01C94E90] 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org Hello Stas, On 11/24/08 3:28 PM, "Stanislav Shalunov" <shalunov@shlang.com> wrote: > We do need to cover the impact on middleboxes in the document -- it's > in the charter. > > Popular applications are made to work with existing middleboxes. > Middleboxes are made to work with existing popular apps which do open > couple hundred of (mostly idle) TCP connections. Home NATs > ("routers") don't generally crash when you run BitTorrent. The > "mostly idle" part doesn't matter for state consumption, naturally. Why not? A middlebox that offers NAT/FW has to keep track of all connections irrespective if they are mostly idle. > > Thousands and tens of thousands of connections (UDP state counts) is > another matter. Making one DNS request per every swarm member you > learn about will overwhelm a few common devices for large enough > swarms. (There are client behavior extensions that use DNS requests > to learn about locations of peers.) In general, scanning-type > behavior is problematic. Interesting, but usually middleboxes age UDP entries very quickly (specially quickly if they have ALGs). So, TCP and UDP have the dealt differently. > > -- Stas > > > On Nov 20, 2008, at 12:06 PM, Andrew G. Malis wrote: > >> As was mentioned in the IAB plenary yesterday, a reason to not use >> multiple TCP connections is the possible exhaustion of middlebox (read >> NAT) resources, such as state memory or port numbers. So if you are >> going to use multiple connections in parallel, you may wish to include >> a method for the user to control that behavior, and a way to detect >> that you're behind a NAT and adapt appropriately. >> >> Cheers, >> Andy >> >> On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch <touch@isi.edu> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Responding to the issue of reasons to need multiple connections, here >>> are a few of mine (extended from those listed at the mic). This is >>> not >>> intended to be a complete list, but a reasonable place to start. The >>> general point is that this is NOT always about hogging bandwidth, >>> either >>> intentionally or not. >>> >>> Joe >>> >>> - -------------------------------------- >>> Reasons to use multiple concurrent TCP connections: >>> >>> - - get around head-of-line blocking >>> this was an original reason for web browsers needing them >>> >>> - - demultiplexing >>> related to HOL blocking but not requiring it, >>> this uses TCP connections to demultiplex different >>> streams, because TCP doesn't provide that labeling itself >>> >>> this was a reason for using different connections for FTP >>> data and control, e.g. >>> >>> - - support different stream properties >>> i.e., a single app may want different streams with Nagle >>> enabled and disabled, or with different socket buffer >>> sizes (to limit delay) >>> >>> - - support "CLOSE means EOF" semantics >>> a reason for multiple connections in HTTP 1.0 >>> >>> - - support larger socket buffer sizes >>> esp. without autotuning, but even with, more connections >>> means more socket buffering is available >>> >>> - ------- >>> >>> One I forgot to note: >>> >>> - - different interaction with errors >>> a single connection would keep restarting; >>> multiple connections increases the possibility that >>> one connection doesn't get hit with a short error burst >>> >>> - ---------------------------------------------- >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 >>> HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF >>> =YmcT >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> ledbat mailing list >>> ledbat@ietf.org >>> https://www.ietf.org/mailman/listinfo/ledbat >>> >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat > > -- > Stanislav Shalunov > > > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Mon Nov 24 16:40:34 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB023A6B74; Mon, 24 Nov 2008 16:40:34 -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 4675E3A6B74 for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 16:40:33 -0800 (PST) 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=[AWL=0.000, 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 mBmLDR47juVS for <ledbat@core3.amsl.com>; Mon, 24 Nov 2008 16:40:31 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id B5D133A677E for <ledbat@ietf.org>; Mon, 24 Nov 2008 16:40:31 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2266404rvf.49 for <ledbat@ietf.org>; Mon, 24 Nov 2008 16:40:29 -0800 (PST) Received: by 10.141.197.21 with SMTP id z21mr2140832rvp.107.1227573629318; Mon, 24 Nov 2008 16:40:29 -0800 (PST) Received: from ?10.0.1.234? (ip-208-72-192-23.bittorrent.com [208.72.192.23]) by mx.google.com with ESMTPS id b8sm13670627rvf.3.2008.11.24.16.40.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 16:40:28 -0800 (PST) Message-Id: <B75B73E7-A976-4251-9757-49F2192402A1@shlang.com> From: Stanislav Shalunov <shalunov@shlang.com> To: Reinaldo Penno <rpenno@juniper.net> In-Reply-To: <C5507EE5.16A89%rpenno@juniper.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 16:40:26 -0800 References: <C5507EE5.16A89%rpenno@juniper.net> X-Mailer: Apple Mail (2.929.2) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 24, 2008, at 3:55 PM, Reinaldo Penno wrote: >> Popular applications are made to work with existing middleboxes. >> Middleboxes are made to work with existing popular apps which do open >> couple hundred of (mostly idle) TCP connections. Home NATs >> ("routers") don't generally crash when you run BitTorrent. The >> "mostly idle" part doesn't matter for state consumption, naturally. > > Why not? A middlebox that offers NAT/FW has to keep track of all > connections > irrespective if they are mostly idle. Exactly. The fact that BitTorrent connections are mostly idle doesn't matter for how much state is consumed on a NAT. >> Thousands and tens of thousands of connections (UDP state counts) is >> another matter. Making one DNS request per every swarm member you >> learn about will overwhelm a few common devices for large enough >> swarms. (There are client behavior extensions that use DNS requests >> to learn about locations of peers.) In general, scanning-type >> behavior is problematic. > > Interesting, but usually middleboxes age UDP entries very quickly > (specially > quickly if they have ALGs). So, TCP and UDP have the dealt > differently. > >> >> -- Stas >> >> >> On Nov 20, 2008, at 12:06 PM, Andrew G. Malis wrote: >> >>> As was mentioned in the IAB plenary yesterday, a reason to not use >>> multiple TCP connections is the possible exhaustion of middlebox >>> (read >>> NAT) resources, such as state memory or port numbers. So if you are >>> going to use multiple connections in parallel, you may wish to >>> include >>> a method for the user to control that behavior, and a way to detect >>> that you're behind a NAT and adapt appropriately. >>> >>> Cheers, >>> Andy >>> >>> On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch <touch@isi.edu> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Responding to the issue of reasons to need multiple connections, >>>> here >>>> are a few of mine (extended from those listed at the mic). This is >>>> not >>>> intended to be a complete list, but a reasonable place to start. >>>> The >>>> general point is that this is NOT always about hogging bandwidth, >>>> either >>>> intentionally or not. >>>> >>>> Joe >>>> >>>> - -------------------------------------- >>>> Reasons to use multiple concurrent TCP connections: >>>> >>>> - - get around head-of-line blocking >>>> this was an original reason for web browsers needing them >>>> >>>> - - demultiplexing >>>> related to HOL blocking but not requiring it, >>>> this uses TCP connections to demultiplex different >>>> streams, because TCP doesn't provide that labeling itself >>>> >>>> this was a reason for using different connections for FTP >>>> data and control, e.g. >>>> >>>> - - support different stream properties >>>> i.e., a single app may want different streams with Nagle >>>> enabled and disabled, or with different socket buffer >>>> sizes (to limit delay) >>>> >>>> - - support "CLOSE means EOF" semantics >>>> a reason for multiple connections in HTTP 1.0 >>>> >>>> - - support larger socket buffer sizes >>>> esp. without autotuning, but even with, more connections >>>> means more socket buffering is available >>>> >>>> - ------- >>>> >>>> One I forgot to note: >>>> >>>> - - different interaction with errors >>>> a single connection would keep restarting; >>>> multiple connections increases the possibility that >>>> one connection doesn't get hit with a short error burst >>>> >>>> - ---------------------------------------------- >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.9 (MingW32) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>>> >>>> iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 >>>> HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF >>>> =YmcT >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> ledbat mailing list >>>> ledbat@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ledbat >>>> >>> _______________________________________________ >>> ledbat mailing list >>> ledbat@ietf.org >>> https://www.ietf.org/mailman/listinfo/ledbat >> >> -- >> Stanislav Shalunov >> >> >> >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat > -- Stanislav Shalunov _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Tue Nov 25 13:04:24 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333A63A6C64; Tue, 25 Nov 2008 13:04:24 -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 905BD3A6C64 for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 13:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 agEEJN24v2Hr for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 13:04:21 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 602493A6C62 for <ledbat@ietf.org>; Tue, 25 Nov 2008 13:04:21 -0800 (PST) Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 25 Nov 2008 13:04:18 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk5-exmlt-c102.redmond.corp.microsoft.com ([157.54.24.67]) with mapi; Tue, 25 Nov 2008 13:04:18 -0800 From: Murari Sridharan <muraris@microsoft.com> To: Reinaldo Penno <rpenno@juniper.net>, Stanislav Shalunov <shalunov@shlang.com>, "Andrew G. Malis" <agmalis@gmail.com> Date: Tue, 25 Nov 2008 13:04:01 -0800 Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclOkBmw5uhpWMyG5EqWK9p9i6ZyOAAsPNSQ Message-ID: <FCA794787FDE0D4DBE9FFA11053ECEB61AFFFAE532@NA-EXMSG-C110.redmond.corp.microsoft.com> References: <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> <C5507EE5.16A89%rpenno@juniper.net> In-Reply-To: <C5507EE5.16A89%rpenno@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ledbat@ietf.org" <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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Reinaldo Penno Sent: Monday, November 24, 2008 3:55 PM To: Stanislav Shalunov; Andrew G. Malis Cc: ledbat@ietf.org Subject: Re: [ledbat] list of reasons for needing multiple TCP connections Hello Stas, On 11/24/08 3:28 PM, "Stanislav Shalunov" <shalunov@shlang.com> wrote: > We do need to cover the impact on middleboxes in the document -- it's > in the charter. > > Popular applications are made to work with existing middleboxes. > Middleboxes are made to work with existing popular apps which do open > couple hundred of (mostly idle) TCP connections. Home NATs > ("routers") don't generally crash when you run BitTorrent. The > "mostly idle" part doesn't matter for state consumption, naturally. Why not? A middlebox that offers NAT/FW has to keep track of all connections irrespective if they are mostly idle. [MS] I think most NATs aggressively reuse stale mappings and if your protocol relies on this mapping for connectivity, it would fail, we routinely see this with Teredo where the address/ external port would change unless you keep a periodic bubble to keep the mapping up. > > Thousands and tens of thousands of connections (UDP state counts) is > another matter. Making one DNS request per every swarm member you > learn about will overwhelm a few common devices for large enough > swarms. (There are client behavior extensions that use DNS requests > to learn about locations of peers.) In general, scanning-type > behavior is problematic. Interesting, but usually middleboxes age UDP entries very quickly (specially quickly if they have ALGs). So, TCP and UDP have the dealt differently. > > -- Stas > > > On Nov 20, 2008, at 12:06 PM, Andrew G. Malis wrote: > >> As was mentioned in the IAB plenary yesterday, a reason to not use >> multiple TCP connections is the possible exhaustion of middlebox (read >> NAT) resources, such as state memory or port numbers. So if you are >> going to use multiple connections in parallel, you may wish to include >> a method for the user to control that behavior, and a way to detect >> that you're behind a NAT and adapt appropriately. >> >> Cheers, >> Andy >> >> On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch <touch@isi.edu> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Responding to the issue of reasons to need multiple connections, here >>> are a few of mine (extended from those listed at the mic). This is >>> not >>> intended to be a complete list, but a reasonable place to start. The >>> general point is that this is NOT always about hogging bandwidth, >>> either >>> intentionally or not. >>> >>> Joe >>> >>> - -------------------------------------- >>> Reasons to use multiple concurrent TCP connections: >>> >>> - - get around head-of-line blocking >>> this was an original reason for web browsers needing them >>> >>> - - demultiplexing >>> related to HOL blocking but not requiring it, >>> this uses TCP connections to demultiplex different >>> streams, because TCP doesn't provide that labeling itself >>> >>> this was a reason for using different connections for FTP >>> data and control, e.g. >>> >>> - - support different stream properties >>> i.e., a single app may want different streams with Nagle >>> enabled and disabled, or with different socket buffer >>> sizes (to limit delay) >>> >>> - - support "CLOSE means EOF" semantics >>> a reason for multiple connections in HTTP 1.0 >>> >>> - - support larger socket buffer sizes >>> esp. without autotuning, but even with, more connections >>> means more socket buffering is available >>> >>> - ------- >>> >>> One I forgot to note: >>> >>> - - different interaction with errors >>> a single connection would keep restarting; >>> multiple connections increases the possibility that >>> one connection doesn't get hit with a short error burst >>> >>> - ---------------------------------------------- >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3 >>> HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF >>> =YmcT >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> ledbat mailing list >>> ledbat@ietf.org >>> https://www.ietf.org/mailman/listinfo/ledbat >>> >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat > > -- > Stanislav Shalunov > > > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Tue Nov 25 13:23:45 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C026D28C1AD; Tue, 25 Nov 2008 13:23:45 -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 8B7B728C1AD for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 13:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 q7IzsLLeo7Q8 for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 13:23:43 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id DD92128C150 for <ledbat@ietf.org>; Tue, 25 Nov 2008 13:23:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSSxs0EI31uHzjEkirlDvPiH8cieM+cKz@postini.com; Tue, 25 Nov 2008 13:23:41 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 25 Nov 2008 13:20:29 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 13:20:28 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 13:20:28 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2008 16:20:26 -0500 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Nov 2008 21:20:25 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 25 Nov 2008 13:20:13 -0800 From: Reinaldo Penno <rpenno@juniper.net> To: Michael Welzl <michael.welzl@uibk.ac.at>, <ledbat@ietf.org> Message-ID: <C551AC0D.16CB7%rpenno@juniper.net> Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclPQ5p87fnHt507kU2Cfc7HIuSJww== In-Reply-To: <1227515154.3731.48.camel@pc105-c703.uibk.ac.at> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2008 21:20:26.0299 (UTC) FILETIME=[A26968B0:01C94F43] 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org I will be updating the draft on recommendations based on all the great references sent and surely a new section on multiple TCP connections and performance will be added. Thanks, Reinaldo On 11/24/08 12:25 AM, "Michael Welzl" <michael.welzl@uibk.ac.at> wrote: > Hi, > > On Thu, 2008-11-20 at 14:54 -0800, Caitlin Bestler wrote: >> Joe Touch wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi, Robb, >>> >>> Appreciating the following, this isn't intended as an application >>> protocol, so we can't assume it would apply only to P2P. I.e., we need a >>> solution that can be used for any application, and there are several >>> applications that DO use multiple connections to increase bandwidth in >>> the typical case. >>> >> >> As a point of reference, part of the justification for doing iSCSI >> over multiple TCP connections within a session was because "It >> might be impossible to achieve the full bandwidth capability >> of the underlying physical transport by using a single TCP >> connection." >> >> [http://storageconference.org/2003/papers/19-Meth-Design.pdf >> section 2.2] >> > > I'd like to add GridFTP to this, as another example. cf.: > http://www.globus.org/toolkit/docs/3.2/gridftp/ > > which points to: > http://www.globus.org/alliance/publications/papers/dataMgmt.pdf > where it says, on page 7: > > "Parallel data transfer: On wide-area links, using multiple TCP streams > in parallel (even between the same source and destination) can improve > aggregate bandwidth over using a single TCP stream [10]. GridFTP > supports parallel data transfer through FTP command extensions and data > channel extensions." > > Cheers, > Michael > > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Tue Nov 25 15:43:51 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DDEC28C1FB; Tue, 25 Nov 2008 15:43:51 -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 7561E28C1FF for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 15:43:50 -0800 (PST) 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 f+PoBzhMFHOJ for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 15:43:49 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id C934528C1FB for <ledbat@ietf.org>; Tue, 25 Nov 2008 15:43:49 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so169213rvf.49 for <ledbat@ietf.org>; Tue, 25 Nov 2008 15:43:46 -0800 (PST) Received: by 10.141.179.5 with SMTP id g5mr2617571rvp.220.1227656626427; Tue, 25 Nov 2008 15:43:46 -0800 (PST) Received: from ?10.0.1.234? (ip-208-72-192-23.bittorrent.com [208.72.192.23]) by mx.google.com with ESMTPS id l31sm16349317rvb.2.2008.11.25.15.43.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Nov 2008 15:43:45 -0800 (PST) Message-Id: <ED900FCE-9E54-442E-8401-FF657B1CF654@shlang.com> From: Stanislav Shalunov <shalunov@shlang.com> To: Murari Sridharan <muraris@microsoft.com> In-Reply-To: <FCA794787FDE0D4DBE9FFA11053ECEB61AFFFAE532@NA-EXMSG-C110.redmond.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 15:43:43 -0800 References: <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> <C5507EE5.16A89%rpenno@juniper.net> <FCA794787FDE0D4DBE9FFA11053ECEB61AFFFAE532@NA-EXMSG-C110.redmond.corp.microsoft.com> X-Mailer: Apple Mail (2.929.2) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org On Nov 25, 2008, at 1:04 PM, Murari Sridharan wrote: > [MS] I think most NATs aggressively reuse stale mappings and if your > protocol relies on this mapping for connectivity, it would fail, we > routinely see this with Teredo where the address/ external port > would change unless you keep a periodic bubble to keep the mapping up. To clarify the context -- "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. -- Stanislav Shalunov _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Tue Nov 25 16:55:44 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5269328C222; Tue, 25 Nov 2008 16:55:44 -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 2CB2128C21F for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 16:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bmUQEiS7IpNs for <ledbat@core3.amsl.com>; Tue, 25 Nov 2008 16:55:42 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 2F76828C223 for <ledbat@ietf.org>; Tue, 25 Nov 2008 16:55:42 -0800 (PST) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 25 Nov 2008 16:55:39 -0800 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Tue, 25 Nov 2008 16:55:38 -0800 From: Murari Sridharan <muraris@microsoft.com> To: Joe Touch <touch@ISI.EDU>, "Kartik Chandrayana (karchand)" <karchand@cisco.com> Date: Tue, 25 Nov 2008 16:55:21 -0800 Thread-Topic: [ledbat] list of reasons for needing multiple TCP connections Thread-Index: AclLUqo0EoV9uKrPS469Bx2rJPHC2wEDf6QA Message-ID: <FCA794787FDE0D4DBE9FFA11053ECEB61AFFFAE6F0@NA-EXMSG-C110.redmond.corp.microsoft.com> References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <A0988C2F192F124FAFE3D70264C04587077A12EC@xmb-sjc-231.amer.cisco.com> <4925CC2A.9080606@isi.edu> <A0988C2F192F124FAFE3D70264C04587077A130C@xmb-sjc-231.amer.cisco.com> <4925CF2D.4070908@isi.edu> In-Reply-To: <4925CF2D.4070908@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ledbat@ietf.org" <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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org I am not sure I get the entire context of Kartik's comment but Windows Server supports a feature called Receive-side scaling which essentially distributes receive processing and tries to spread TCP connections across multiple cores and tries to keep all processing for a connection aligned on one specific CPU (to the extent that apps cooperate) starting with packet indication all the way to deliver to the app. Connections can get moved around depending on load but in steady state they should remain pinned with the some caveats. Some links http://download.microsoft.com/download/a/d/f/adf1347d-08dc-41a4-9084-623b1194d4b2/RSS_Server2008.docx http://msdn.microsoft.com/en-us/library/ms795616.aspx Thanks -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Joe Touch Sent: Thursday, November 20, 2008 12:57 PM To: Kartik Chandrayana (karchand) Cc: ledbat@ietf.org Subject: Re: [ledbat] list of reasons for needing multiple TCP connections -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kartik Chandrayana (karchand) wrote: > Joe, > > I am also not aware if parallelization of network code is implemented > in OSes. However, I think it would be reasonable to expect that tcpcb > lookups are done in a centralized fashion and once that is done, > multiple tcp's can be processed in different cpus. Even the lookups can > be distributed as they are only a read operation. Parallelizing TCP includes dealing with not only the TCP code, but also the IP input queue access, timers, etc. I am not as sure that there's a one TCP per core mapping in current OS's - though I'd be glad to hear someone *confirm* it. Joe > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Thursday, November 20, 2008 2:44 PM > To: Kartik Chandrayana (karchand) > Cc: Andrew G. Malis; ledbat@ietf.org > Subject: Re: [ledbat] list of reasons for needing multiple TCP > connections > > > > Kartik Chandrayana (karchand) wrote: >> Andy, Joe: > >> One reason I can think of using multiple TCP connections is to >> overcome the non-negotiation of window-scale parameter on most boxes. >> With default window scale parameters, i.e 0, the congestion window is >> limited to 64KB only and thus for any pipe with >> bandwidth-delay-product greater than 64KB, a single TCP connection >> cannot keep the pipe full. In such a case, it would be beneficial to > have multiple TCP connections. >> Also, since TCP design was mostly with single cpu in mind, I think >> multiple TCP connections can harness the multi-cpu architectures >> better than a single lean fast TCP. > > That presumes that the OS implements parallelization in the network > code; I don't know if that's recently offered, but it has been the > sticking point in the past. > > Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklzy0ACgkQE5f5cImnZrtxIwCgw+uW7JxMRDZja1pTuixQUwS8 m5IAoPHHCB2ed20zXkkv15m09kF4q+mm =30jd -----END PGP SIGNATURE----- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From ledbat-bounces@ietf.org Tue Nov 25 17:12:08 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-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 --===============1330628882== Content-Type: multipart/alternative; boundary="----=_Part_13169_15988928.1227661922471" ------=_Part_13169_15988928.1227661922471 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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/ ------=_Part_13169_15988928.1227661922471 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.<br> <br><div class="gmail_quote">On Tue, Nov 25, 2008 at 3:43 PM, Stanislav Shalunov <span dir="ltr"><<a href="mailto:shalunov@shlang.com">shalunov@shlang.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> "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.<br> <br> This is generally not a problem for the number of connections BitTorrent maintains.<div><div></div><br></div></blockquote></div><br>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.  <br> <br>From a middlebox perspective, they probably take as many bytes in a table as TCP connections do.  <br><br><br><br clear="all"><br>-- <br>Robb Topolski (<a href="mailto:robb@funchords.com">robb@funchords.com</a>)<br>Hillsboro, Oregon USA<br> <a href="http://www.funchords.com/">http://www.funchords.com/</a><br> ------=_Part_13169_15988928.1227661922471-- --===============1330628882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============1330628882==-- From ledbat-bounces@ietf.org Thu Nov 27 07:03:07 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178373A68CC; Thu, 27 Nov 2008 07:03:07 -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 689EC3A68CC for <ledbat@core3.amsl.com>; Thu, 27 Nov 2008 07:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 lfUZRx-bCJqD for <ledbat@core3.amsl.com>; Thu, 27 Nov 2008 07:03:04 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 964623A683A for <ledbat@ietf.org>; Thu, 27 Nov 2008 07:03:04 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mARF2sq8079139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 27 Nov 2008 17:02:55 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <C3E8A5B2-16BE-47FD-9DD9-5AFCBA6BEBED@nokia.com> From: Lars Eggert <lars.eggert@nokia.com> To: Stanislav Shalunov <shalunov@shlang.com> In-Reply-To: <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 17:02:47 +0200 References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8687/Thu Nov 27 14:32:31 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Thu, 27 Nov 2008 17:02:57 +0200 (EET) Cc: "ledbat@ietf.org" <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="===============0268747888==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0268747888== Content-Type: multipart/signed; boundary=Apple-Mail-8-382864421; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-8-382864421 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2008-11-25, at 1:28, Stanislav Shalunov wrote: > Home NATs > ("routers") don't generally crash when you run BitTorrent. The > "mostly idle" part doesn't matter for state consumption, naturally. > > Thousands and tens of thousands of connections (UDP state counts) is > another matter. Yes. As a datapoint, my home NAT reboots when I nmap through it, but has no issue with BitTorrent. Lars --Apple-Mail-8-382864421 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODExMjcxNTAyNDdaMCMGCSqGSIb3DQEJBDEWBBQhm/RfRufyqh+9 t4uWMhJBFNPnJDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEACT5QthPxPFvVba0OEj0vbmnKoiq0dZq+IQymsgjzLH6fNXSqSXkh g/pYr0XWusJrgH0S4XP1wzxHvoRayIt+FbyJlsVVvLRLtuBqdw0tEYKfK/RT7sAGeozedWscQqvY trQ99b4HXN5HRnIL5ALIP6toe0gNHtMwNX9llalvc9SqXbRI1ZF2Af+omBy2LU7PnftXpYmEJyWI b9Am8E10oCMEO7vLpgUkGVcnUgsT67x2gFYcYs/gamyXhSWcdwwiQXARVpDTVn8KLrARrs/ppQgP TGm6ylAdzd3EPC/6gc4KPMPPmAd9F6/5AqjzV+91CDPwLCwmHSU3Psq3f2ysxAAAAAAAAA== --Apple-Mail-8-382864421-- --===============0268747888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0268747888==-- From ledbat-bounces@ietf.org Thu Nov 27 15:06:35 2008 Return-Path: <ledbat-bounces@ietf.org> X-Original-To: ledbat-archive@ietf.org Delivered-To: ietfarch-ledbat-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10333A6A71; Thu, 27 Nov 2008 15:06:35 -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 939CE3A6A71 for <ledbat@core3.amsl.com>; Thu, 27 Nov 2008 15:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.607 X-Spam-Level: * X-Spam-Status: No, score=1.607 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457] 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 p63zDSP6zG-p for <ledbat@core3.amsl.com>; Thu, 27 Nov 2008 15:06:33 -0800 (PST) Received: from outbound-mail-112.bluehost.com (outbound-mail-112.bluehost.com [69.89.24.2]) by core3.amsl.com (Postfix) with SMTP id D9EF13A6809 for <ledbat@ietf.org>; Thu, 27 Nov 2008 15:06:33 -0800 (PST) Received: (qmail 11329 invoked by uid 0); 27 Nov 2008 23:06:28 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy3.bluehost.com with SMTP; 27 Nov 2008 23:06:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=FFKbKc8D4xhNs4CgqIOyZl9+XWowYuKlpL/haY9E8md9c1vL+3Jk8QXyFaP4xn58xEZkeyKuL/BuTt8U7zOmwKDWNMmuhfo8pWAgHwRnSTqCdJ0OjaT+I3YUAixaV3Ko; Received: from c-24-5-203-48.hsd1.ca.comcast.net ([24.5.203.48] helo=[192.168.1.101]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <richard@bennett.com>) id 1L5pwK-0004nf-36; Thu, 27 Nov 2008 16:06:28 -0700 Message-ID: <492F27F3.3020309@bennett.com> Date: Thu, 27 Nov 2008 15:06:27 -0800 From: Richard Bennett <richard@bennett.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Lars Eggert <lars.eggert@nokia.com> References: <4925BDEE.6090101@isi.edu> <8c99930d0811201206yb0ef259v28c361438cb14773@mail.gmail.com> <DC2CEB0C-4C70-42CD-8ADE-AFF4E45B1915@shlang.com> <C3E8A5B2-16BE-47FD-9DD9-5AFCBA6BEBED@nokia.com> In-Reply-To: <C3E8A5B2-16BE-47FD-9DD9-5AFCBA6BEBED@nokia.com> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.203.48 authed with richard@bennett.com} Cc: "ledbat@ietf.org" <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="===============0425094090==" Sender: ledbat-bounces@ietf.org Errors-To: ledbat-bounces@ietf.org --===============0425094090== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title> Most home "routers" have all been modified by now not to crash when BitTorrent has opened thousands of TCP connections. These connections consume mapping table resources and were a problem until it they were garbage-collected.

RB

Lars Eggert wrote:
On 2008-11-25, at 1:28, Stanislav Shalunov wrote:
Home NATs
("routers") don't generally crash when you run BitTorrent.  The
"mostly idle" part doesn't matter for state consumption, naturally.

Thousands and tens of thousands of connections (UDP state counts) is
another matter.

Yes. As a datapoint, my home NAT reboots when I nmap through it, but has no issue with BitTorrent.

Lars

_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat
--===============0425094090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat --===============0425094090==--