From owner-tcp-impl@lerc.nasa.gov Thu Mar 1 01:21:12 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14122 for ; Thu, 1 Mar 2001 01:21:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA03082 for tcp-impl-outgoing; Wed, 28 Feb 2001 23:01:16 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA03061 for ; Wed, 28 Feb 2001 23:01:14 -0500 (EST) From: b4h443@arabia.com Received: by seraph3.lerc.nasa.gov; id XAA25117; Wed, 28 Feb 2001 23:01:12 -0500 Received: from unknown(210.77.147.148) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025089; Wed, 28 Feb 01 23:01:08 -0500 Received: (qmail 8880 invoked from network); 1 Mar 2001 02:44:26 -0000 Received: from 2cust57.tnt25.dfw9.da.uu.net (HELO mailer.ug.eds.com) (63.22.6.185) by 210.77.147.146 with SMTP; 1 Mar 2001 02:44:26 -0000 Message-ID: <00000961309e$000021cb$000047f6@mailer.ug.eds.com> To: <4r6jjiio@euronet.be> Subject: Brand New E-Mail pager for FR-EE! Date: Wed, 28 Feb 2001 20:18:41 -0600 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology From owner-tcp-impl@lerc.nasa.gov Sun Mar 4 08:05:59 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10343 for ; Sun, 4 Mar 2001 08:05:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA12263 for tcp-impl-outgoing; Sun, 4 Mar 2001 03:41:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA12246; Sun, 4 Mar 2001 03:41:14 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA00303; Sun, 4 Mar 2001 03:41:13 -0500 Received: from chopin.cti.depaul.edu(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000285; Sun, 4 Mar 01 03:40:53 -0500 Received: from ehab2000 ([64.254.195.22]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.1600); Sun, 4 Mar 2001 02:40:42 -0600 Message-ID: <016001c0a486$f10ba8e0$44c3fe40@cti.depaul.edu> From: "Ehab Al-Shaer" To: "MMNS2001" Subject: MMNS 2001 Call For Papers Date: Sun, 4 Mar 2001 02:41:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 04 Mar 2001 08:40:42.0567 (UTC) FILETIME=[CC3FA570:01C0A486] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001 Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 Conference: October 29 to Nov 1, 2001 The IFIP/IEEE MMNS is the premier IEEE/IFIP conferences focusing on management of multimedia networks and services. The conference is known for its high-quality papers from various research communities. Selected papers will also be considered for publication as a special issue of the Journal of High Speed Networking and Journal of Networks and Information Systems. MMNS 2001 will provide Travel and Conference Scholarships for students. Topics of interest include, but are not limited to, the following: Distributed multimedia service management Integration of network control and management Network management models and architectures Distributed event correlation Monitoring QoS management Multimedia traffic management Resource, performance and fault management for broadband networks Configuration management of edge and core services for enabling multimedia traffic management Multi-point and multicast services management Resource management in wireless multimedia Wireless and mobile network management Mobility management Management of ad-hoc networks Multimedia content protection Deployment of multimedia services Active network management Network programmability for multimedia services Middleware support for management Multimedia session management Packet scheduling and dropping techniques Multimedia service Engineering Billing and security for broadband networks Policy-based management for multimedia service PAPER SUBMISSION See . Ehab Al-Shaer, Ph.D. Assistant Professor, School of Computer Science, Telecommunications and Information Systems, DePaul University, Chicago, IL 60604 ehab@cs.depaul.edu From owner-tcp-impl@lerc.nasa.gov Mon Mar 5 22:57:49 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17800 for ; Mon, 5 Mar 2001 22:57:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA01283 for tcp-impl-outgoing; Mon, 5 Mar 2001 20:43:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA01277 for ; Mon, 5 Mar 2001 20:43:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA06039; Mon, 5 Mar 2001 20:43:18 -0500 Received: from farc.ikami.com(204.29.203.67) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006020; Mon, 5 Mar 01 20:42:58 -0500 Received: by farc.ikami.com (Postfix, from userid 1002) id 57B6CDA30; Mon, 5 Mar 2001 19:42:52 -0600 (CST) Date: Mon, 5 Mar 2001 19:42:52 -0600 From: foo To: end2end-interest@ISI.EDU, tcp-impl@lerc.nasa.gov Subject: TEAR. Message-ID: <20010305194252.L33489@eek.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Does anyone have any experience with or thoughts about TEAR (TCP Emulation at Receivers) developed by Injong Rhee at NCSU? http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/ -Brian From owner-tcp-impl@lerc.nasa.gov Tue Mar 6 01:11:43 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19999 for ; Tue, 6 Mar 2001 01:11:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA11073 for tcp-impl-outgoing; Mon, 5 Mar 2001 23:18:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA11057 for ; Mon, 5 Mar 2001 23:18:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id XAA19845; Mon, 5 Mar 2001 23:18:01 -0500 Received: from aswan.csres.utexas.edu(128.83.143.38) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019817; Mon, 5 Mar 01 23:17:52 -0500 Received: (from minskim@localhost) by aswan.csres.utexas.edu (8.11.0/8.11.0) id f264JsK06195; Mon, 5 Mar 2001 22:19:54 -0600 Date: Mon, 5 Mar 2001 22:19:54 -0600 From: Min Sik Kim To: foo Cc: end2end-interest@ISI.EDU, tcp-impl@lerc.nasa.gov Subject: Re: [e2e] TEAR. Message-ID: <20010305221953.A6112@cs.utexas.edu> Mail-Followup-To: foo , end2end-interest@ISI.EDU, tcp-impl@lerc.nasa.gov References: <20010305194252.L33489@eek.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010305194252.L33489@eek.org>; from foo@eek.org on Mon, Mar 05, 2001 at 07:42:52PM -0600 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk * foo [20010305 19:55 CST]: > Does anyone have any experience with or thoughts about TEAR (TCP Emulation > at Receivers) developed by Injong Rhee at NCSU? > > http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/ TEAR is one of the four protocols whose transient behaviors we studied in our infocom 2001 paper. Yang, Kim, and Lam, Transient behaviors of TCP-friendly congestion control protocols, in Proc. of INFOCOM 2001. http://infocom.ucsd.edu/papers/529-3648348157.pdf -- Min Sik Kim http://www.cs.utexas.edu/users/minskim/ From owner-tcp-impl@lerc.nasa.gov Tue Mar 6 13:47:44 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21536 for ; Tue, 6 Mar 2001 13:47:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA16873 for tcp-impl-outgoing; Tue, 6 Mar 2001 11:12:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA16819 for ; Tue, 6 Mar 2001 11:12:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA27963; Tue, 6 Mar 2001 11:12:18 -0500 Received: from gateway.sask.trlabs.ca(192.139.19.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027912; Tue, 6 Mar 01 11:11:24 -0500 Received: from salph1.sask.trlabs.ca ([192.168.129.106]:39952 "EHLO salph1.sask.trlabs.ca") by gateway.sask.trlabs.ca with ESMTP id ; Tue, 6 Mar 2001 10:22:18 -0600 Received: from [192.168.129.114] ([192.168.129.114] EHLO kuang.sask.trlabs.ca ident: IDENT-NOT-QUERIED [port 1029]) by funnel.sask.trlabs.ca with ESMTP id <11361-755>; Tue, 6 Mar 2001 10:11:34 -0600 Date: Sat, 3 Mar 2001 17:55:01 -0600 (CST) From: Tianbo kuang To: foo cc: end2end-interest@ISI.EDU, tcp-impl@lerc.nasa.gov, end2end-interest@postel.org Subject: Re: [e2e] TEAR. In-Reply-To: <20010305194252.L33489@eek.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hi, I was just about to ask a question about TEAR. It seems unclear to me how TEAR calculates RTT in the technical report (TEAR: TCP emulation at receivers - flow control for multimedia streaming). Does the sender calculate it and send it to the receiver, or does the receiver calculate it (and how?)? In section 3.5, it does mention under the title _timeout_ that, "this information is embedded in the packet header by the sender". What does "this information" refer to? Cheers, --Tianbo ------------------------------------------------------ Kuang Tianbo TRlabs 111-116 Research Drive Saskatoon, Saskatchewan S7N 3R3 Tel: (306) 668-9325(office) (306) 343-9747 (home) kuang@sask.trlabs.ca ------------------------------------------------------ On Mon, 5 Mar 2001, foo wrote: > Date: Mon, 5 Mar 2001 19:42:52 -0600 > From: foo > To: end2end-interest@ISI.EDU, tcp-impl@lerc.nasa.gov > Subject: [e2e] TEAR. > Resent-Date: Mon, 5 Mar 2001 19:48:05 -0600 > Resent-From: foo@eek.org > Resent-To: end2end-interest@postel.org > > Does anyone have any experience with or thoughts about TEAR (TCP Emulation > at Receivers) developed by Injong Rhee at NCSU? > > http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/ > > -Brian > From owner-tcp-impl@lerc.nasa.gov Tue Mar 6 14:16:54 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23218 for ; Tue, 6 Mar 2001 14:16:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA28323 for tcp-impl-outgoing; Tue, 6 Mar 2001 12:00:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA28271 for ; Tue, 6 Mar 2001 12:00:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA06264; Tue, 6 Mar 2001 12:00:52 -0500 Received: from unknown(207.59.130.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006173; Tue, 6 Mar 01 12:00:29 -0500 Received: from rhee (207.59.130.3 [207.59.130.3]) by appserver.edcncstate.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FKHBF8YN; Tue, 6 Mar 2001 11:57:17 -0500 From: "Injong Rhee" To: "Tianbo kuang" , "foo" Cc: , , Subject: RE: [e2e] TEAR. Date: Tue, 6 Mar 2001 12:01:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I can't help overhearing, and want to drop a few lines. The RTT calculation can be done by the sender through receiving the receiver report about the rate. The receiver sends back the time stamp of the last packet received to the sender with the sequence number which will be used by the sender to compute the RTT. This is one way to do it, and there are many other ways. For instance, you can use the same way that RTP does or use GPS to synchronize the clocks and measure the one-way time. Then use the one-way trip time in place of RTT -- I know in this case that TCP-friendliness may suffer, but it can at least give some bounded fairness. In fact this removes back-channel concerns completely from flow control scuh as losses and delays in the back channels. Some of nice things about TEAR are that (1) it does not use back channels much so sutiable for wireless comm; (2) rate control is very smooth; (3) TCP-friendly over various ranges of bandwidth --- TFRC has some prblems under very low bandwidth cases. We have improved TEAR quite bit from the initial work and TEAR is incorporated into an MPEG-4 stream player and stream server, and it seems to give pretty good performance over other existing streaming solutions. Other areas of exploration are multicast and wireless communication. Sorry I have not kept you guys up to date about the progress. I got tired of writing papers and have been digging into writing codes.....Maybe its time to come out and see the light :-) Injong > -----Original Message----- > From: end2end-interest-admin@postel.org > [mailto:end2end-interest-admin@postel.org]On Behalf Of Tianbo kuang > Sent: Saturday, March 03, 2001 6:55 PM > To: foo > Cc: end2end-interest@ISI.EDU; tcp-impl@lerc.nasa.gov; > end2end-interest@postel.org > Subject: Re: [e2e] TEAR. > > > Hi, > > I was just about to ask a question about TEAR. It seems unclear to me how > TEAR calculates RTT in the technical report (TEAR: TCP emulation at > receivers - flow control for multimedia streaming). Does the sender > calculate it and send it to the receiver, or does the receiver calculate > it (and how?)? In section 3.5, it does mention under the title _timeout_ > that, "this information is embedded in the packet header by the sender". > What does "this information" refer to? > > Cheers, > > --Tianbo > > ------------------------------------------------------ > Kuang Tianbo > TRlabs > 111-116 Research Drive > Saskatoon, Saskatchewan S7N 3R3 > Tel: (306) 668-9325(office) (306) 343-9747 (home) > > kuang@sask.trlabs.ca > ------------------------------------------------------ > On Mon, 5 Mar 2001, foo wrote: > > > Date: Mon, 5 Mar 2001 19:42:52 -0600 > > From: foo > > To: end2end-interest@ISI.EDU, tcp-impl@lerc.nasa.gov > > Subject: [e2e] TEAR. > > Resent-Date: Mon, 5 Mar 2001 19:48:05 -0600 > > Resent-From: foo@eek.org > > Resent-To: end2end-interest@postel.org > > > > Does anyone have any experience with or thoughts about TEAR > (TCP Emulation > > at Receivers) developed by Injong Rhee at NCSU? > > > > http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/ > > > > -Brian > > > > From owner-tcp-impl@lerc.nasa.gov Wed Mar 7 04:11:47 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28442 for ; Wed, 7 Mar 2001 04:11:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA28986 for tcp-impl-outgoing; Wed, 7 Mar 2001 02:08:15 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA28972; Wed, 7 Mar 2001 02:08:12 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA08989; Wed, 7 Mar 2001 02:08:10 -0500 Received: from chopin.cti.depaul.edu(140.192.32.73) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008963; Wed, 7 Mar 01 02:07:26 -0500 Received: from ehab2000 ([64.254.195.85]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.1600); Wed, 7 Mar 2001 01:07:23 -0600 Message-ID: <025c01c0a6d5$68e31010$63c3fe40@cti.depaul.edu> Reply-To: "MMNS'2001" From: "MMNS'2001" To: "MMNS2001" Subject: CFP for Special Sessions in MMNS'2001 Date: Wed, 7 Mar 2001 01:08:24 -0600 Organization: DePaul University, MNLAB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 07 Mar 2001 07:07:23.0745 (UTC) FILETIME=[42547510:01C0A6D5] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS for Special Sessions in the Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001, Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 MMNS has identified a number ``focus topics'' that are of particular relevance and importance to the field of multimedia network and service management. MMNS plans to conduct special sessions to address such hot issues. Papers submitted to these special sessions will go through the normal submission and review procedure. The goal is to build special sessions of exceptional papers all dealing with a closely related theme. The set of focus topics include the following: * INTERNET TRAFFIC MONITORING: The focus of this special session is on techniques and methodologies for collecting Internet traffic statistics, descriptions of collection systems implemented and deployed in the Internet, results from these systems, and analyses of these results describing how multimedia networks and services can be better managed. For questions about this special session, contact Kevin Almeroth (almeroth@cs.ucsb.edu). * Multimedia in AD-HOC NETWORKS: Networks of the future are envisioned to integrate the Internet with wireless mobile embedded devices and ad-hoc networks. Ad-hoc networks are collections of wireless mobile nodes that can be deployed rapidly without pre-existing or centralized communication infrastructure. These networks should support various types of multimedia traffic, including audio, video, TC-based data, and sensory data. Due to the nature of ad-hoc networks, number of new challenges must be addressed in order to facilitate seamless services of Ad-hoc networks. This includes unicast and multicast routing protocols, power-aware protocols in almost all layers of the network stack, quality and guarantee of service provisioning for multimedia traffic, self-configuring hierarchies and architectures, address allocation and naming, data dissemination techniques, efficient mobility support, fault and performance management tools, performance analysis of end-to-end protocols such as TCP and reliable multicast over ad-hoc networks. For questions about this special session, contact Ahmed Helmy (helmy@ceng.usc.edu) * RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA: Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS Internet wireless multimedia. The session is looking for original contributions in this demanding area that address related issues. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques that consider the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. For questions about this special session, contact Raouf Boutaba(rboutaba@bbcr.uwaterloo.ca). * MOBILE AGENT-BASED NETWORK MANAGEMENT: Research and development on various forms of agents and mobile agents is continuing to grow in a staggering fashion in recent years. Agent-based telecommunication applications and services such as active networks, Qos and bandwidth brokers, E-commerce, information gathering on Internet, and feature interactions are becoming increasingly popular and are largely contributing to the development and to the success of distributed multimedia technology. This session will focus on research and development activities related to the field of agents in the area of active networks, and QoS agent-based architectures for managing multimedia networks and distributed services. The objective is to provide the audiences with a clear background into the opportunities and the challenges that the mobile agent emerging paradigm brings about For questions about this special session, contact Ahmed Karmouch (karmouch@site.uottawa.ca), Nazism Agoulmine (nazim@rp.lip6.fr) or Allan Marshall (a.marshall@ee.qub.ac) From owner-tcp-impl@lerc.nasa.gov Wed Mar 7 04:22:12 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28514 for ; Wed, 7 Mar 2001 04:22:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA28763 for tcp-impl-outgoing; Wed, 7 Mar 2001 02:03:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA28752; Wed, 7 Mar 2001 02:03:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA08638; Wed, 7 Mar 2001 02:03:09 -0500 Received: from chopin.cti.depaul.edu(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008614; Wed, 7 Mar 01 02:02:52 -0500 Received: from ehab2000 ([64.254.195.85]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.1600); Wed, 7 Mar 2001 01:02:43 -0600 Message-ID: <024801c0a6d4$c2242480$63c3fe40@cti.depaul.edu> Reply-To: "MMNS'2001" From: "MMNS'2001" To: "MMNS2001" Subject: CFP for Special Sessions in MMNS'2001 Date: Wed, 7 Mar 2001 01:03:46 -0600 Organization: DePaul University, MNLAB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 07 Mar 2001 07:02:43.0983 (UTC) FILETIME=[9B9429F0:01C0A6D4] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS for Special Sessions in the Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001, Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 MMNS has identified a number ``focus topics'' that are of particular relevance and importance to the field of multimedia network and service management. MMNS plans to conduct special sessions to address such hot issues. Papers submitted to these special sessions will go through the normal submission and review procedure. The goal is to build special sessions of exceptional papers all dealing with a closely related theme. The set of focus topics include the following: * INTERNET TRAFFIC MONITORING: The focus of this special session is on techniques and methodologies for collecting Internet traffic statistics, descriptions of collection systems implemented and deployed in the Internet, results from these systems, and analyses of these results describing how multimedia networks and services can be better managed. For questions about this special session, contact Kevin Almeroth (almeroth@cs.ucsb.edu). * Multimedia in AD-HOC NETWORKS: Networks of the future are envisioned to integrate the Internet with wireless mobile embedded devices and ad-hoc networks. Ad-hoc networks are collections of wireless mobile nodes that can be deployed rapidly without pre-existing or centralized communication infrastructure. These networks should support various types of multimedia traffic, including audio, video, TC-based data, and sensory data. Due to the nature of ad-hoc networks, number of new challenges must be addressed in order to facilitate seamless services of Ad-hoc networks. This includes unicast and multicast routing protocols, power-aware protocols in almost all layers of the network stack, quality and guarantee of service provisioning for multimedia traffic, self-configuring hierarchies and architectures, address allocation and naming, data dissemination techniques, efficient mobility support, fault and performance management tools, performance analysis of end-to-end protocols such as TCP and reliable multicast over ad-hoc networks. For questions about this special session, contact Ahmed Helmy (helmy@ceng.usc.edu) * RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA: Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS Internet wireless multimedia. The session is looking for original contributions in this demanding area that address related issues. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques that consider the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. For questions about this special session, contact Raouf Boutaba(rboutaba@bbcr.uwaterloo.ca). * MOBILE AGENT-BASED NETWORK MANAGEMENT: Research and development on various forms of agents and mobile agents is continuing to grow in a staggering fashion in recent years. Agent-based telecommunication applications and services such as active networks, Qos and bandwidth brokers, E-commerce, information gathering on Internet, and feature interactions are becoming increasingly popular and are largely contributing to the development and to the success of distributed multimedia technology. This session will focus on research and development activities related to the field of agents in the area of active networks, and QoS agent-based architectures for managing multimedia networks and distributed services. The objective is to provide the audiences with a clear background into the opportunities and the challenges that the mobile agent emerging paradigm brings about For questions about this special session, contact Ahmed Karmouch (karmouch@site.uottawa.ca), Nazism Agoulmine (nazim@rp.lip6.fr) or Allan Marshall (a.marshall@ee.qub.ac) From owner-tcp-impl@lerc.nasa.gov Sun Mar 11 14:21:48 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13307 for ; Sun, 11 Mar 2001 14:21:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA07816 for tcp-impl-outgoing; Sun, 11 Mar 2001 12:26:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA07795; Sun, 11 Mar 2001 12:26:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA13758; Sun, 11 Mar 2001 12:26:04 -0500 Received: from ddi.digital.net(198.69.104.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xmaa13580; Sun, 11 Mar 01 12:25:29 -0500 Received: from danpesta (216-53-218-176.ppp.mpinet.net [216.53.218.176]) by ddi.digital.net (8.9.3/05.21.76) with SMTP id MAA06963; Sun, 11 Mar 2001 12:05:19 -0500 (EST) Message-ID: <010701c0aa67$36803860$cbda35d8@danpesta> From: "Dan Pestana" To: Subject: PLEASE Consider this Simple, yet Profound Gyroscope Microgravity Concept Date: Sun, 11 Mar 2001 12:09:07 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0103_01C0AA24.134F90E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0103_01C0AA24.134F90E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0104_01C0AA24.13573200" ------=_NextPart_001_0104_01C0AA24.13573200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.prowsales.com/gyrospoke/gyrospoke.html Welcome to Dan Pestana's "Gyrospoke Hovercraft" Disclosure Webpage This email has been created to showcase my=20 invention called the "Gyrospoke." =20 The device consists of 2 sets of 4 levers, strategically and = symmetrically connected at 8 hinged fulcrums which are fixed pivot = points. These fulcrums support the load surface and are connected to 2 = hub planes supporting the 2 sets of spoke levers. Each of the 8 spoke = levers is equipped with its own motorized gyroscope on the outer end of = the rimless spoke.=20 Each spoke is supported midway by a hinged fulcrum leg extending = from the payload surface above (or below) the levers. The center of the = device is comprised of 2 hub planes driven together and apart by a = symmetrical one piston high torque engine. The 2 hubs are connected to = the load surface by only these fulcrum hinges. Four hub ends of the = spoke levers are connected to the upper hub plane. The other set of 4 = hub ends of the spoke levers are connected to the lower hub plane. (The = hub planes are pushed and pulled apart and together by the = electronically cycled stroke one piston engine mentioned above.) As the gyroscope motors on the outer end of the spokes spin their = corresponding gyroscopes, an effort or resistance to change is = introduced at the hinged fulcrums. This effort or force is transmitted = to the load surface by the supporting hinged legs. An inertial force is = created by the hub engine's independently self-contained opposition to = the centrifugal or inertial effort of the 2 sets of four gyroscopes also = working against each other. The inertial force created is harnessed and = transmitted to the load. The central opposition is then leveraged by the = corresponding and relative resistance to the gyroscope's inertial force = at the fulcrum. The independent hub stroke effort also leverages the 2 = sets of opposing centrifugal forces at the shared fulcrum hinges. A = neutral microgravity is expected which will allow the Gyrospoke to = maintain a levitation or buoyancy on any vertical plane it is located at = or placed in. This efficient interpretation of inertial force will also = be useful for a number of other devices needing independent gravity = (i.e.: braking mechanisms, propulsion and powers supplies). I have been working on this concept for 15 years and have many = notes and several prototypes to support my ownership of its inception. I = have never able to get past what I thought would be the simplest part of = the device, that is the construction of the interacting levers between = the two hub planes. My homemade gyroscopes seemed to work okay, but = without the two hub planes pushing and pulling symmetrically against = each other the prototypes are rendered useless. I hope to experiment with the direction and speed of the = gyroscopes' spin once my final prototype is finished. I presume that for = the sake of stability, it will be wise to the have gyroscopes adjacent = to each other have symmetrically opposite spins to neutralize their = inclination to tilt when a load is applied. I welcome any person's constructive input. I hereby authorize the construction of this device by any person = wishing to test my theory. Should you build a working device and wish to = profit financially from its construction, I would be happy to entertain = a nominal bid for sale of usage to you or your company. Dan Pestana 8002 N. Packwood Ave. Tampa, FL 33604-3815 (813) 931-8036 danp@digital.net =20 =20 ------=_NextPart_001_0104_01C0AA24.13573200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
http://www.pro= wsales.com/gyrospoke/gyrospoke.html
 

Welcome to Dan Pestana's
"Gyrospoke=20 Hovercraft"
Disclosure Webpage

This email has been created to showcase my =
invention=20 called the "Gyrospoke."


The device = consists of 2=20 sets of 4 levers, strategically and symmetrically connected at 8 = hinged=20 fulcrums which are fixed pivot points. These fulcrums support the = load=20 surface and are connected to 2 hub planes supporting the 2 sets of = spoke=20 levers. Each of the 8 spoke levers is equipped with its own = motorized=20 gyroscope on the outer end of the rimless spoke.=20

Each spoke is supported midway = by a hinged=20 fulcrum leg extending from the payload surface above (or below) = the=20 levers. The center of the device is comprised of 2 hub planes = driven=20 together and apart by a symmetrical one piston high torque engine. = The 2=20 hubs are connected to the load surface by only these fulcrum = hinges. Four=20 hub ends of the spoke levers are connected to the upper hub plane. = The=20 other set of 4 hub ends of the spoke levers are connected to the = lower hub=20 plane. (The hub planes are pushed and pulled apart and together by = the=20 electronically cycled stroke one piston engine mentioned=20 above.)

As the gyroscope motors on the = outer end=20 of the spokes spin their corresponding gyroscopes, an effort or = resistance=20 to change is introduced at the hinged fulcrums. This effort or = force is=20 transmitted to the load surface by the supporting hinged legs. An = inertial=20 force is created by the hub engine's independently self-contained=20 opposition to the centrifugal or inertial effort of the 2 sets of = four=20 gyroscopes also working against each other. The inertial force = created is=20 harnessed and transmitted to the load. The central opposition is = then=20 leveraged by the corresponding and relative resistance to the = gyroscope's=20 inertial force at the fulcrum. The independent hub stroke effort = also=20 leverages the 2 sets of opposing centrifugal forces at the shared = fulcrum=20 hinges. A neutral microgravity is expected which will allow the = Gyrospoke=20 to maintain a levitation or buoyancy on any vertical plane it is = located=20 at or placed in. This efficient interpretation of inertial force = will also=20 be useful for a number of other devices needing independent = gravity (i.e.:=20 braking mechanisms, propulsion and powers supplies).

I have been working on this = concept for 15=20 years and have many notes and several prototypes to support my = ownership=20 of its inception. I have never able to get past what I thought = would be=20 the simplest part of the device, that is the construction of the=20 interacting levers between the two hub planes. My homemade = gyroscopes=20 seemed to work okay, but without the two hub planes pushing and = pulling=20 symmetrically against each other the prototypes are rendered=20 useless.

I hope to experiment with the = direction=20 and speed of the gyroscopes' spin once my final prototype is = finished. I=20 presume that for the sake of stability, it will be wise to the = have=20 gyroscopes adjacent to each other have symmetrically opposite = spins to=20 neutralize their inclination to tilt when a load is = applied.

I welcome any person's = constructive=20 input.

I hereby authorize the = construction of=20 this device by any person wishing to test my theory. Should you = build a=20 working device and wish to profit financially from its = construction, I=20 would be happy to entertain a nominal bid for sale of usage to you = or your=20 company.

Dan Pestana
8002 N. Packwood=20 Ave.
Tampa, FL 33604-3815
(813) 931-8036
danp@digital.net

 

 

------=_NextPart_001_0104_01C0AA24.13573200-- ------=_NextPart_000_0103_01C0AA24.134F90E0 Content-Type: image/jpeg; name="gyrospoke-sm.jpg" Content-Transfer-Encoding: base64 Content-Location: http://www.prowsales.com/gyrospoke/gyrospoke-sm.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCABwAJYDASIA AhEBAxEB/8QAHQAAAQUBAQEBAAAAAAAAAAAABQADBAYHAggBCf/EAD0QAAIBAwMCAwYDBgUDBQAA AAECAwQFEQASIQYxE0FRBxQiYXGBMpGhCCNCsdHwFRZSYsEXguEkQ2OSsv/EABsBAAICAwEAAAAA AAAAAAAAAAUGAwQAAQIH/8QAMhEAAQMDAwEHAgYCAwAAAAAAAQIDEQAEBSExQRIGIlFhcYGhE/AU IzKRwdEVsUJi4f/aAAwDAQACEQMRAD8A2COqbf24+WnZ6/w4iwJJA7DXMlOM7l40Nr1bYy5xpsCU qIpJUtaBUaSuqKubwwSoz+Wi1vtnAkecNxk8aD0KJG4bwyzfM6L+9iCMvNIkUYHmcakfIQIGgqG3 SXDKtTUyro0MRxt589CJoFUFVz+WhN063oqZ9kCmYDjg4BP1/pqtV/W10qYz7jDDDuXOWG4j8+35 aGnIIRoNaLf41Tmp0q6pBK/IjYj1xpL7ismyetjRh6nj89ZVc+oblUTrHcLnO25hsUPhfpgcaHyy yZDwxjY5O4N8JB9ceedQqyjqv0gCpk4lpP6iTW1tW2BXxJc4dy//ACLx+umKzqXpiJVhlvFJGWO1 fizk/bWMbSXYGYsj42qDjB+R0pYPEKkRFiCeduAD66gN+9uTU6cextFa1JXUYbfS3OklHosy5/no xaq+ZgMsHHqrA6wySOpVgGKBSoBX/cdOxQASIYzIdvwnPrjUpyThEKANQjFtAygkVv8APWDaCTkn tpqnneSTGsho7jdqeMPBWyxbVyV3bwD5Yzx+mptH1lc6fZ++jdzwMgc475H28sa23kBspNbcxypl Kq3W0yhACx76P008YQDWH2r2mRrsW60W1DwZIQcj/tP9daH07daW7Qie11cdTF57Gzt+RHcH665U UO6g1IgrZ0Iq11c8e300Au0u4kr5DXNY0vi4fOmSAV5GpGm+nWo3nSvSglRUOshUeWlp+phVnIxj nS0SEUHUlU04cdtRK6NHQ5wDqVLuzkDWXe1HqGtWt/wihfMaYFYFOGO4ZCZ8hjk+uRqJx0NJ6jVk Ml1YQK6v/UywVb01tfeUyHmz8G4eQ9frqr3K5V0+56mqMgyT4YbuMf8Ajvoa7AAHxgqngxgYB/57 a7pQC4RY2Cle59NBX31vqlR9qM29u3bp6UD3r5FVvOG8FGDKAyl84bjt9dfGY53PKRlSrIPwn/nU ippoktVZXySlUpkTKp3Ys6qBnPHcn7aHXW5Wyjq7dTo8ckU9KrzyhiSrl2xn6KF40OdvWG1htR1o i3ZvOp60jSpklN4iKyQ7gOQT258/rxrmWOZAC8wChfiX799EYgqIBJLlTjGD/TUd9kcjSRQjgYEh 44z21ZCjNV+kRXKUoEoZUY7eDk8amSxOac5k24UHaMd8+R1Fat3weJC28DLgIM5H9dNGdjIrbAVP 4t7ZIIxjjWETW5inY/dw/wAIMu5tx3HIBHp6adlqkjKqSqAjjcec9zqDVRyymMhm3I2cIMDI8v11 9KuzeEIgvxbtxOe/JOt1omnWqmd3Vllcodw5K7vln+uo9U8qyxmIpEoYFvmNSaaFzKN5LA8DA4xj vp2eHY3CRo5Xjec/TWSBWAE61BkZJgYTvlYSZwfI/L6alWiqudDXLUWyslt064HiRHBbzwR2YfIg 9tdqkOx3dmKkZwOPyOujUQRSqNqjc3cnn7DWTG1aitS9n/tBe6VUdl6mNPBcX4pamMFI6rH8OD+G Tvx2I7eY1emPGNeZ700dXSuJUMqkY2KCuSOxB7gg8g/fWp+xzqqvuNFJZb3VLU1tHGrxVDfjniPH xj/WpwCfPIPfOr1s8T3VVTuWQB1CrvNjefrpa6kJZsgDGlomKGGodfUiCklm4JRCwUnvgZ1gqGep qJJ6qQ1MkrmSRsY3MSSfl38ta/e3lNtqY0G92hYAevGsherZFLIDIo/hUYIH31SyIKekVcxiwvqP NOzUuIsxpGqjHcZ1yrU8aF2kO1ASScAev01GkqGyCZFGew7t9Pnqpe06WZrRTRK7or1H7zy3KATj 6ZI/LQ9pouLCBzRu3Z/EOpbG5o7crpSXSne30zOYcgmSN8KSDxx5+ehtXaoRbmjVGecOGWXdjAx2 xqhRXGthAENS8YH+njUiO/XdDn32Rvk/I01t4fCKRD7JUo/8p1/3XrGOt8Ta24ZcaKj4z/7Vppb5 U2231kM5aR4YGeGNh+IgE7c+hOj/AEvXLebdHUFQsnCMGOcN3IHrweNZzLeZKhf36DeOzLq5dB36 2CgajhpXp5zKMu0gcO2MNgbRjJwRz8vnpZyGPTj1j6S5aOgncHgH+DSfncVbtdTtvJn48asfu2z4 I3Zef4Fwvr39NPpSIAjPtDf7jnJ1y9Q8zEEHIGO/l28tM7qjwWWQPnzZVxj0PPyGq2vNKBip8hQw 8OzlccDgaie90tPvL7VEaFyTliB3PP118hidplLqeRgnJOf7zpm+U2y3VTHljAx+I4H4T6fTOuFd 0E1I2nrUAfEU5TXJ6uhSpjUoJdxUMcZwxHP5a7kaSWMnGS3IOM4zof0kaWfpmjY7F2l1zjk/GW8/ qdFnniMZjQZYHHPl58gahtHVOspWdzVrI26ba6W0nYVDSOoEYgdWclSpLN3+2noKaQSKpA2jyAx/ Y0qepVHYBBH8XoADx318FRUSlEzh8g8ZIxqzrVAAc0/UxKhC4QMB/G2pnT1StpvlLcYiFkWVVYFc blPDD58H88aF1MLOAjNtGRnHB7/LT9JSzzVUasneUbQPM9vPXSDCgQa04JBEVvqyqwyDxpaFsZIv hOQfTS0yhuaVzckU/UCGOocykbQeB66yLqW0f4fepQMinlZnhyeCpPb7dtbHUUMbH4cfI6gX3pqn vlpahnG1u8cq8FG9dVLtpLrem4q3aOLac1GhrGJ2pgMBgCSOOFBPp/froR1RQQ3i3GjaMpIrBo5Q M7T28/11Y+ounqyx1hpavII5Rx2ceo1BV6eNdu5mP6j5Z50GSVNqkbimJp5SFBaDBGtZHdOn7vb4 /Gno5Gp84E8Y3Rn7jt99CxyM69HwmWn6WeTaSrpkLnPDN/Q5xqpz0dJPIxltlLI2ACTTqSfuQNZh u0675LhcQO6opBB3ine8ywsvppWmSpIJ96xwnVz6erJ6OwUgip6SIeI8yTNTqxZ+V+IsDnHl5Dg9 9TfaNSxUHTY8KCCNJquIARxhcHOfIf7dE+m7dDP0pRpVOuHQsCO6nceRqPNXjl8n6DXdjX18qqv5 RD1uHVJ06o+N6d6avEc2YaldtUn+ngMPXReadWYvFGNwHY8nP1+3pqj3qJbPIkkzkjxFEcwBKjvy 3pyAPvq42250U1OJKJjKPwuWABJHfIBOD59/56GY25ccBbdHeFAr+0SiHW/0qp41FQxQYK5HIIPI +vGuJIZZ6OZTuzsI5HOMfLUmjhrZ6qKKjgDvJ+FRjJOP7/LR2l6M6jrFV2SKGMsVO+dTjkg5xnV1 65aaELUB71SZZcUoFKSazHp6vtts6XaouNZHTQpUMh38kkBcbQOT59tCqz2nUMUjLbrdJUjPEk77 B8uBk/y1m3Wk1QOoqulkf4Kd/DRc8DHf89DoUi7zSZHpnTt2PwNq5boVcDqkTqrpSAddTvVjMvfV vFqTprH7aVo//Um57+KK3BOMKVb+YbRW1+1GEzpHcbfHApYZmiYkL9QecfQ6ycyUQXAVf/rqLjfO I4Qzb+AF9dOGaxuGbt+lDKJPKFEkf3QtsLUrmvWVLY7/AHPZLR0FQ6HBL7cKR9TgatvQPRl1TqSm rLrCkMVOpYJ4qtlvLt8+ftqsWf2iXeHp620cVPTLLBSRRyySISxcKA3AbHf+xo30x7SZKWtD3mCa VWO3fARhQSOSvHb6nXljOCzxUh1TACJ111jxj7NPNx2IvhYl9CCokSBpP7b/AM1pd5gWOUAYLeeN LTVNLQXenWuoKtKmFyRuRs4I7j5HS0YEJEK3ryh62WlwgogjihnUvXPRnTU3gXy/0tJUBQxg3F5A PLKqCdR7T7YPZfUqAnVVHFzj9/HJH/8ApRryt+0jY7zY/afW191qI2pru7VNK8ZyfDGFCkdwRgDW dh02giaUD1I4/lpxxXZvG5C2ClOqCudUj4OsetEkNAAEV+iuelOrrayU9bbLvSnuYJlk2/PIOVOs 46q9m81H4lTaJ1qoMHELkCQfQnhv0140o7pX2uqSttlfLT1EZyssEhRwfqDr0/0D7T75cuhbW1Zu qL3KPAnlmhKqyBnCsNpyWIK54GlftB2fcsZFv+ZAngQPEmSI96NYfFXORfDTA8z5DxNGq+kq5bLT UtBTzVMuxQ6IuQoC45++BzpVPR17morakaU9LNvZ5WZlBPwnAO3J8/Ty0csM8PvkNuq673aeqJSE FCfEZeSOMYIxrqKnrLj1bNQf4lUpHHTysScOpO9APhbIGMH5868Uw7N2q2YCEx9RalJM7kAzPl7U 3Zj6TT7i1zCUAHTgmNPfSsg9unTdTZ+mqB6qthmkmrVXw4xnGEc5z9vTVw6VsnSlu6QstTebhP4t VSxyFclc5UEhQFJbuPPVW/aVtlZaxYYprsalJp55ApXZtCoBnA4/jA++p1x6cvNH0RbqqrSPwClG C28FkDPGMEfftplXZ3yiQtcKSJMDihYurP8ACNhKZSpRAk86U1V1NthdxLSGspnyNpyFOeACSPQk caF2mrs9n3Lb7BRU4qpip+OdtzKAxAJk8gy9vUat1R05exuD0VQxz/7agg/lrmfpmsezxUktmqfF 8eV9pTDEMkYLZ7/wgax7EXK+8XFTHmNart5m3kpCQB5EcfzQ623SsWtWupglIkbZjdiTz5gA47ZH r3GisXVF5Wo31F0eXv8ABjbGfnhcfXvqkXLpm/dOnFXHUwwvG3gmp5DJ5r27qMEfID5avNq6duN4 tctxtuyWkiIw5QhjzjO3vjgnny51DZWbLpLbyO8neZqa/vXwlK23JSdoArDLt0dJf5LtV0u9rjHK WRRwknxHjnscdtUattNytNVHDdLbVU0sgzEskRG8eq+v1GtyQVdkvl0llj8aGaQiOWJwY3YHj4vp 3HfUO63N6+SkFwmjXwlPu4ZOVB77eMnRTH9rX8V0oCQvpJ0PA4+/Cp73Ht3ThcBiQDp481n1k6Mu t9jkiEQpH8F5IlkHxOVQttx5ZxjnU9uh6jpempLzNW0lcS5jlWANtgkIBVdxA3EjdyOBjudXSwVk 8V7gqKWEYiLHEysWk8iAi/Fnk+h88Y1s/sl6Vrovez1HZaZrXVRrthrCrM2OQfDwQO/mQR6aIDtj msrfpW+kEaTAAgffjrVdDdnjSl+f07eZrzU3UFz27Yp/CX0Uf86+26bqK5VYgt8lxqp2PEcO9yfs Ne0E6K9niYb/ACbYiw8/co/6aIqLVRU4gttvpqOIH8EESoP0Gmg5R5emv71bue3KumUyT5q/qs99 g3Tt/sPS1QnUfwVFVUeOsOQWjG0D4scZOO3lpav6NvYkDv8ALS1SccUpRKt6Qbu6cu3lPr3UZNAe sum7P1TbWt14t1HWxlGEbTRBmiYjG5T3B+h1hNV+zVWIhFH1hG+cbBNbyo+eSHOt8u9DDUS7gxSQ DAdcBh9/voe9vqpEIa7XIAqFA95baPnj6cf+c6Gh7tFZvrcx9x0JOw0+ZFELTIY1tpLbyCTyfs1m HRP7PPTVujgqupKytrropYsKWULThsnYVyoYkDB5OM/LXUXshu9q6jpLlRX019FTTK5hmVkkwPLg lT+mtSl9/SKFYbjsEWMhoQ2766F3e6XK3E1VItJLJKwDJJGVD4B7svP38vQ6DZG97Qot3V3JHSQe o6aA77Hz8KP4jLWiXw1aOKBUdvH4/mqv1P0D1J1LcrfLR3OG2UlOP3ni7llBJDZUAdwPmOdXLoyO R+orpNLA8TCmgClwRuy8pbv37L+enaO43OtEdZLTUiU6FmKxO+7ABGOTg8fQfLUi0XKouy1Jp7Y7 NBL4bb5FVc7VYYzk9mHP9NLlncXVt+EQlrqDaVFIHIVzz4/NEslci+aebddgAhJ/6kGY96xv9rvC 3rpKNm+HwawvzxyYR/wdab1xazD7PqWKP4ts1Am084Ani1jv7Tys3Xtkhq4jGYrduaPdkYaVuQ3/ AGnWoL7UOhbrFFSm8xPFGQzxMrEjZhgRjJIBGc4PbR5eRuSh50Mq7yYMCQneJoeMW2GbUBYISon1 1G1SvaJNdqGttEFoqDFVTzbFVjhHJKgBs8eeq/1lcbrNSVlBUTwFI6qWCQBQA6qikAeffOPpoN1L 1q1+pUrmuVEKeMHwZmjj2hScA4kUjnjkjVFud468fwLlS3CS72iWramkjEEbIdv+oBQuCp4PHnqF 3IuvuO9E9J4JiIEHTWpWMILdLJV0ynnx1mJq7W/rRovZvVWO53GW4XAqoopVTmNGjRgWY+aksue/ GqpHeJ5xPRzVVWkla0SSslQxUhRjdImCW488j6aZt9lvdfVyGrgpKOKfOyNJM7Gz2JA7fIfnrUYf ZDa5N0dVWVcka4DRRN4MbNyT2GSO3cnQouquHQl5wJAEazt661aWx+DbMIJBJOkb+Q0rOIrPNXXc Wahu1NVqVZkjppiz7xjuHACZz351duk/ZnEl5RLvWxrtTdItPJ8WNpIDSNyB8gB276CPQrYfbzT0 tJGkcIFPGiKxwsYiQffhdah1j0+eovfbZIZIKeupDTyVMfxNESCM44z5a2tu3bKVJUDDiR6onUwe P9Vt0OQlJSQFNqM+CuB60NEPSFNVNSdMPapXhVjV+7yrIy893YEn17ny0YsfXXSlVcIbHH1BSf4m CITTuSjGQcbRuABOfIaxn2adBdUdG9W3a33Okc0NVTSLT1sbq6TBJABkKTsJBzg4Pfvor0T7JKu7 +2Kp6kuLCKzUNUksTRTbZJqhVjccYOUDE5OR2+um3HM4y27S3jaHZQptKkxGp0EREbk/3QXI25dw rClkylSh56ya3whycZI0kpnDbjk/XUiqQrLkeupMJyo3jPqDo8XNJFJYbBVFRAxTgMPtpaVxEQkz HwPTGlrpKQoSa0pfSYoFJO+4nBJ89MVNSwQntotLSLg4GONC6unPIA+2p0FJ3qg4laRFDZKuRjwe NA6m+W2qbC1SyeHI8RAVuHDYIz24wdWEUg/ibVfregOma2SaZrdIkkrl3MNTLFlick/Cw7knVDP4 9eTslWjSgnq3J8JnT72q/gL5vHXqbp9JV07ARvtrRuku9NJaaunpZUkliTaynupbtkfPUKilu0vQ 3UjdPyJFdppplpH3AASLGkYIJyOCh+40O/yxcrIhi6Wo6doZ0HvDVNU5k3jsdzZJGNGekKC70dJL TXGKCNPEaRAsm8lnZmfJwOMnjQGzxrrOQbStPdQ10SNpn+gPemC6yDS7Bxbah1Lc6+k7xHPv8VkN 8oeublWxVXUHs+q7vUU0IiNU1ygfcgycDJ7ZJOPmdV6y9L1UpllbpqO3Gqro1o4ZkXxYiV4w2M7W 5wN2OCRr1DTIFlVsY1XvaJUTGvtMEdruE6UdbHWSPFTM6MoR12ggHkFgftqa8xqLJhwtOKAUIIkm fapsfnLi8WltxKYG2gEVSLT7LJ663x0/UdynWk4LUcDcYznBJHw888ZzrSrQlps1tW20Nsp6alT8 KRxqoJxjJAHc+upVJUCpoo6kwzQGQZCTIVcc+YPbUKtjOCVOPPjRnH4+1t0w0N+eaW8jk7x9UOK2 44FCurBb6i21rRW+mWbwHKyBAGztOORoVIlWnStRUWMEXN6HxKX48q0+zKNhjtPOO/Gneoagw0jQ NS1U4qI3UGGFnC8Y52gkd/0Ou+kXzaKSFqaqjNNEkUglhZCSqgZAIGRrHLe0cvFNLSDKRx5nmImt Iu7xFil5KyIX48QOJmJFZi0/X9VcYLpcuhbtW3hAA1b48CtuHAxhsAa0bom69Y+8ueo0lt5n2CCC YRSttAw2WUHnJ4yc8nVzo1jOGw+PXGgN/p+q6i5ubfaaKanhb/00rTbSykKTuB89wPby0rZjs201 bldoklyRHOkid/KmvFdpn7t4N3akhuDxHGke8VK6jq6aFEpai6U61Dt4scQwjnBwWAByQM899d9K 3qkidqSOrhaRpCUUAgtlc8Z+h/XTFd0TTdSQ0dZ1JTtHcIEdA1JVyRbVY9tyMM9hpzp/2cdN2OtS tooKzx0yVaaumlC5GOzuR2J8tdN9m0IyaL5oBKQB3TM+vr8VEvPFWOVZOklcnvCI8h6fNWJrgS3x D9dPR3H4cA65kt6OOD5eem1oNpxuGnDuGlH85NM1VQ7Pnk6Wpi0qAeulrsKArgtrJmv/2Q== ------=_NextPart_000_0103_01C0AA24.134F90E0-- From owner-tcp-impl@lerc.nasa.gov Sun Mar 11 14:38:53 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13306 for ; Sun, 11 Mar 2001 14:21:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA07922 for tcp-impl-outgoing; Sun, 11 Mar 2001 12:28:07 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA07910; Sun, 11 Mar 2001 12:28:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA13864; Sun, 11 Mar 2001 12:28:05 -0500 Received: from ddi.digital.net(198.69.104.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xmaa13791; Sun, 11 Mar 01 12:27:05 -0500 Received: from danpesta (216-53-218-176.ppp.mpinet.net [216.53.218.176]) by ddi.digital.net (8.9.3/05.21.76) with SMTP id MAA07458; Sun, 11 Mar 2001 12:08:43 -0500 (EST) Message-ID: <007b01c0aa67$ac30b300$b0da35d8@danpesta> From: "Dan Pestana" To: Subject: PLEASE Consider this Simple, yet Profound Gyroscope Microgravity Concept Date: Sun, 11 Mar 2001 12:12:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Welcome to Dan Pestana's "Gyrospoke Hovercraft" Disclosure Webpage This email has been created to showcase my invention called the "Gyrospoke." http://www.prowsales.com/gyrospoke/gyrospoke.html The device consists of 2 sets of 4 levers, strategically and symmetrically connected at 8 hinged fulcrums which are fixed pivot points. These fulcrums support the load surface and are connected to 2 hub planes supporting the 2 sets of spoke levers. Each of the 8 spoke levers is equipped with its own motorized gyroscope on the outer end of the rimless spoke. Each spoke is supported midway by a hinged fulcrum leg extending from the payload surface above (or below) the levers. The center of the device is comprised of 2 hub planes driven together and apart by a symmetrical one piston high torque engine. The 2 hubs are connected to the load surface by only these fulcrum hinges. Four hub ends of the spoke levers are connected to the upper hub plane. The other set of 4 hub ends of the spoke levers are connected to the lower hub plane. (The hub planes are pushed and pulled apart and together by the electronically cycled stroke one piston engine mentioned above.) As the gyroscope motors on the outer end of the spokes spin their corresponding gyroscopes, an effort or resistance to change is introduced at the hinged fulcrums. This effort or force is transmitted to the load surface by the supporting hinged legs. An inertial force is created by the hub engine's independently self-contained opposition to the centrifugal or inertial effort of the 2 sets of four gyroscopes also working against each other. The inertial force created is harnessed and transmitted to the load. The central opposition is then leveraged by the corresponding and relative resistance to the gyroscope's inertial force at the fulcrum. The independent hub stroke effort also leverages the 2 sets of opposing centrifugal forces at the shared fulcrum hinges. A neutral microgravity is expected which will allow the Gyrospoke to maintain a levitation or buoyancy on any vertical plane it is located at or placed in. This efficient interpretation of inertial force will also be useful for a number of other devices needing independent gravity (i.e.: braking mechanisms, propulsion and powers supplies). I have been working on this concept for 15 years and have many notes and several prototypes to support my ownership of its inception. I have never able to get past what I thought would be the simplest part of the device, that is the construction of the interacting levers between the two hub planes. My homemade gyroscopes seemed to work okay, but without the two hub planes pushing and pulling symmetrically against each other the prototypes are rendered useless. I hope to experiment with the direction and speed of the gyroscopes' spin once my final prototype is finished. I presume that for the sake of stability, it will be wise to the have gyroscopes adjacent to each other have symmetrically opposite spins to neutralize their inclination to tilt when a load is applied. I welcome any person's constructive input. I hereby authorize the construction of this device by any person wishing to test my theory. Should you build a working device and wish to profit financially from its construction, I would be happy to entertain a nominal bid for sale of usage to you or your company. Dan Pestana 8002 N. Packwood Ave. Tampa, FL 33604-3815 (813) 931-8036 danp@digital.net From owner-tcp-impl@lerc.nasa.gov Mon Mar 12 07:45:13 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07417 for ; Mon, 12 Mar 2001 07:45:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA23563 for tcp-impl-outgoing; Mon, 12 Mar 2001 05:41:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA23555 for ; Mon, 12 Mar 2001 05:41:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA27871; Mon, 12 Mar 2001 05:41:20 -0500 Received: from isis.hol.gr(194.30.192.21) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027702; Mon, 12 Mar 01 05:40:49 -0500 Received: (qmail 7448 invoked from network); 12 Mar 2001 10:33:19 -0000 Received: from vdp051.ath06.cas.hol.gr (HELO groupmail.com) (195.97.121.52) by isis.hol.gr with SMTP; 12 Mar 2001 10:33:19 -0000 Message-ID: <3AABFCFF.2757704A@groupmail.com> Date: Mon, 12 Mar 2001 00:32:31 +0200 From: Kostas Ioannou X-Mailer: Mozilla 4.6 [en-gb] (Win98; I) X-Accept-Language: el,en,en-GB MIME-Version: 1.0 CC: alg , amlist@takilab.k.dendai.ac.jp, cfp@mmlab.snu.ac.kr, comm-theory , comswtc@comsoc.org, comswtc@ieee.org, conferences@iao.fhg.de, Conferencesa , cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, Cost264@lip6.fr, ctc-members@tinac.com, enternet@bbn.com, fokus-user@fokus.gmd.de, f-troup@CODEX.CIS.upenn.edu, giga@tele.pitt.edu, Globecom , GU-NET , ieee_rtc_list@cs.tamu.edu, ieeetcpc@listserv.utoronto.ca, info-confs@comsoc.org, ipgroup@sprintlabs.com, iscc2000@infres.enst.fr, itc@ieee.org, iwqos@comsoc.org, lists-mbone-eu-op-out@lists.ripe.net, Mail-distributor@KOM.th-darmstadt.de, mbone-eu-op@ripe.net, news-announce-conferences@uunet.uu.net, owner-globecom@comsoc.org, performance@haven.epm.ornl.gov, request-datacom@comsoc.org, reres@laas.fr, RHDM@lip6.fr, rm@mash.cs.berkeley.edu, seminar@cse.cuhk.edu.hk, spects02@comp.leeds.ac.uk, tccc@ieee.org, tcgn@ieee.org, tci-announce@computer.org, tcp-impl@lerc.nasa.gov, tcpsat@lerc.nasa.gov, terena list , webrepl@cs.utk.edu, xtp-relay@cs.concordia.ca, tfiw-announce@akalice.research.att.com Subject: (no subject) References: <00ee01c0795d$dd406c00$38072ac2@cs.ucy.ac.cy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit 5th WSES/IEEE WORLD MULTICONFERENCE ON Circuits, Systems, Communications & Computers (CSCC 2001) Location: Rethymnon, CRETE (GREECE) JULY 8-15, 2001 (The Island of Crete has FREQUENT DIRECT Connection with all European Capitals and big cities in Summer!). * 5th World Conference on Circuits, * 5th World Conference on Systems, * 5th World Conference on Communications, * 5th World Conference on Computers, jointly with the WSES/IEEE CONFERENCE ON Signal Processing, Multidimensional Systems, Computational Geometry and Artificial Vision (organized by Prof. G.Antoniou) jointly with the WSES/IEEE CONFERENCE ON Neural, Fuzzy and Evolutionary Computation (organized by Prof. V.Mladenov) jointly with the WSES/IEEE CONFERENCE ON Multirate Systems and Wavelets Analysis (organized by Prof. B.Suter) jointly with the WSES/IEEE CONFERENCE ON Software and Hardware Engineering (organized by Prof. O.Panfilov) jointly with the WSES/IEEE CONFERENCE ON Power Engineering (organized by Prof. L.A.Pecorelli) jointly with the WSES CONFERENCE ON Mathematics and Computers in Physics (organized by Prof. L.J.Wang) jointly with the WSES CONFERENCE ON Mathematics and Computers in Mechanical Engineerig (organized by Prof. F.Koumboulis and G.Stavroulakis) WEB: http://www.worldses.org [PLEASE, FOLLOW APPROPRIATE LINK] See also the impressions from the previous conference in 2000. ALL THE ACCEPTED PAPERS will be published: 1)in the CD-ROM Proceedings (with Search Facilities and Page Numbering) as well as 2)in the Electrical and Computer Engineering International Reference Book Series of WSES PRESS as Post-Conference Books (Hard cover, velvet paper, international circulation). These will be different International Editions (with different ISBN). This material will be ready at the opening of the Multiconference and will be distributed to the participants. Also SPECIAL ISSUES have been scheduled for the journals : (These special issues will contain only selected papers, not all the papers) INTERNATIONAL JOURNAL OF COMPUTER RESEARCH (IJCR) INFORMATICA INTERNATIONAL JOURNAL OF COMMUNICATIONS AND NETWORKING More informations: Send a message to me or send a message to mbetini@italymail.com or to cscc@worldses.org About Crete: CRETE is a Unique Place in the World: In this magic island, so richly endowed by Nature and History, everything is in abundance: blond beaches with palm-trees, cool gorges, serene coves, palm-forests, mysterious caves, minoan palaces, paleochristian churches, byzantine churches, islamic mosques, and of course modern cosmopolitan life. Crete lies in the crossroads of the three ancient continents: Europe-Asia-Africa and the Cretan Civilization borrowed elements from european, asian and african world. Also, Crete, in the minoan era, gave birth to the first civilization in the west-european sense. Here, Zeus, the father and king of ancient greek Gods was born. Many famous Artists and Politicians like El-Greco, Venizelos, Kazantzakis and Kornaros were born in Crete. EXTENSION OF THE DEADLINE FOR PAPER SUBMISSION UNTIL MARCH 20, 2001 - - - - - - - - - - - - - - - - - - - - - - - - From owner-tcp-impl@lerc.nasa.gov Tue Mar 13 07:01:09 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18427 for ; Tue, 13 Mar 2001 07:01:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA25702 for tcp-impl-outgoing; Tue, 13 Mar 2001 04:44:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA25275; Tue, 13 Mar 2001 04:33:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA27453; Tue, 13 Mar 2001 04:33:26 -0500 Received: from ada.cs.ucy.ac.cy(194.42.7.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027426; Tue, 13 Mar 01 04:32:30 -0500 Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id LAA48148; Tue, 13 Mar 2001 11:26:52 +0200 Message-ID: <063f01c0ab9f$c87b08b0$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: "alg" , , , , , , "comm-theory" , , , , , "Conferencesa" , , , , , , , , , , , , , "GU-NET" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , "terena list" , , Subject: INFOCOM 2001, Anchorage Alaska, 22-26 April 2001 --> Call for participation Date: Tue, 13 Mar 2001 11:26:05 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_063C_01C0ABB0.646AAB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_063C_01C0ABB0.646AAB80 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit !!! PLEASE ACCEPT OUR SICNERE APOLOGIES FOR MULTIPLE COPIES. !!! C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska TRAIN CHARTER: This year we are chartering a train for our welcome reception. This train ride will take you through the Kenai fjords and will include food and drinks. April 24, 6-11 pm. Seats are limited, and will be given out on the basis of registration date. CONFERENCE REGISTRATION: The deadline for advance registration is April 2, 2001 (5pm Eastern Standard Time). Please register early to ensure that you have a seat in the train charter. On-line registration is possible at our website at http://www.ieee-infocom.org/2001 and then clicking on "Registration Information". Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001. HOTEL REGISTRATION: Please book your hotel room early at the Hilton. Rooms are filling up fast. If the Hilton gets filled up, the Marriott is our alternative hotel for the conference (same room rate as the Hilton). TOURS: Several tours of Alaska's natural treasures are planned. Please visit our website at http://www.ieee-infocom.org/2001 and look for "On-line tour registration". AIRLINE TICKETS: Please book your flights to Anchorage early, so that you can get reasonably priced tickets. TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications Quality of Service (QoS) Support for Broadband Wireless Networks Traffic Engineering in IP/MPLS Networks TCP Congestion Controls: Algorithms and Models Video Over IP Bluetooth and Pervasive Wireless Networking Control and Management for Optical Networks: An IP-Centric Approach Principles of Multicast Protocols and Services PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model ------=_NextPart_000_063C_01C0ABB0.646AAB80 Content-Type: text/plain; name="cfpart.txt" Content-Disposition: attachment; filename="cfpart.txt" Content-Transfer-Encoding: quoted-printable C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska TRAIN CHARTER: This year we are chartering a train for our welcome reception. This train ride will take you through the Kenai fjords and will include food and drinks. April 24, 6-11 pm. Seats are limited, and will be given out on the basis of registration date. CONFERENCE REGISTRATION: The deadline for advance registration=20 is April 2, 2001 (5pm Eastern Standard Time).=20 Please register early to ensure that you have a seat in the train charter. On-line registration is possible at our=20 website at http://www.ieee-infocom.org/2001 and then clicking on "Registration Information". Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001.=20 HOTEL REGISTRATION: Please book your hotel room early at the Hilton. Rooms are filling up fast. If the Hilton gets filled up, the Marriott is our alternative hotel for the conference (same room rate as the = Hilton). TOURS: Several tours of Alaska's natural treasures are planned. Please = visit our website at http://www.ieee-infocom.org/2001 and look for "On-line tour registration". AIRLINE TICKETS: Please book your flights to Anchorage early, so that you can get reasonably priced tickets. TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications=20 Quality of Service (QoS) Support for Broadband Wireless Networks=20 Traffic Engineering in IP/MPLS Networks=20 TCP Congestion Controls: Algorithms and Models=20 Video Over IP=20 Bluetooth and Pervasive Wireless Networking=20 Control and Management for Optical Networks: An IP-Centric Approach=20 Principles of Multicast Protocols and Services=20 PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model ------=_NextPart_000_063C_01C0ABB0.646AAB80-- From owner-tcp-impl@lerc.nasa.gov Thu Mar 15 18:15:00 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10151 for ; Thu, 15 Mar 2001 18:14:59 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id SAA20124; Thu, 15 Mar 2001 18:15:00 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma019570; Thu, 15 Mar 01 18:14:09 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA26410 for tcp-impl-outgoing; Thu, 15 Mar 2001 17:57:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA26365; Thu, 15 Mar 2001 17:57:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA29826; Thu, 15 Mar 2001 17:57:42 -0500 Received: from by.genie.uottawa.ca(137.122.20.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029765; Thu, 15 Mar 01 17:56:49 -0500 Received: from mobstar ([137.122.107.157]) by by.genie.uottawa.ca (8.9.1/8.9.1) with SMTP id RAA29593; Thu, 15 Mar 2001 17:56:28 -0500 (EST) Reply-To: From: "Ahmed Karmouch" To: "karmouch" Subject: IEEE/ACM Workshop on Mobile Software Agents- MATA 2001- Deadline-April 1. Date: Thu, 15 Mar 2001 08:49:25 -0500 Message-ID: <001f01c0ad2a$7563cb80$9d6b7a89@uottawa.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-UIDL: ae345eaa9c07da9d4d3b9ea7fdaf9c90 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MIME-Autoconverted: from 8bit to quoted-printable by by.genie.uottawa.ca id RAA29593 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id RAB26384 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id RAA26410 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA10151 [My apologies if you receive this more than once] ====================================================== MATA'2001 Third International Workshop on Mobile Agents for Telecommunication Applications August 14-16, 2001, Montréal, CANADA Co-sponsored by IEEE and ACM http://www.congresbcu.com/mata01/ CALL FOR PAPERS ================ Technical papers (4500 words maximum) describing previously unpublished, completed research or work in progress, not currently under review by another journal or conference, are solicited on the following topics: Mobile Agent Architecture and Models Agent Identification, Tracking and Persistence Agent-based Mobility Management in Mobile Networks Web Agent Systems Agent Integration with CORBA and TINA Active Networks and Mobile Agents Feature Interaction and Agents Mobile Agents Communication Language Security in Mobile Agent Systems Interactive Multimedia Presentation Agents Agent-based Electronic Commerce Agent-based Access to Legacy Services Managing QoS with agents Information Discovery and Gathering using agents Data Mining Agents Network Management Agents Policy-based Management using Mobile Agents Education and Applications of Mobile Agents Prototypes and Experience with Mobile Agents Seamless Messaging and Mobile Agents Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in IEEE Network Magazine. All paper submissions should have a cover page containing the title, names, email address and complete postal addresses (including telephone and fax numbers) for all authors. Please indicate the main author for the purpose of correspondence. The cover page should also provide an abstract (150 words maximum), and a list of keywords. Please include a statement stating that "when accepted, one of the authors will attend the Workshop to present the paper". Submissions should be sent by email to the program chair: Roch Glitho Ericcson Research Canada 8400, boul. Décarie Ville Mont-Royal, Québec, Canada, H4P 2N2 email: roch.glitho@lmc.ericsson.se Tel.: (514) 345-7000 ext. 2266 IMPORTANT DATES FOR PAPER SUBMISSION Full paper submission due April 1, 2001 Notification of acceptance May 15, 2001 Final paper due June 15, 2001 ======================================= From owner-tcp-impl@lerc.nasa.gov Mon Mar 26 07:32:35 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06305 for ; Mon, 26 Mar 2001 07:32:34 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id HAA21418; Mon, 26 Mar 2001 07:32:31 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma020275; Mon, 26 Mar 01 07:31:36 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA28937 for tcp-impl-outgoing; Mon, 26 Mar 2001 07:13:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA28914 for ; Mon, 26 Mar 2001 07:13:11 -0500 (EST) From: rajiv.chakravorty@philips.com Received: by seraph3.lerc.nasa.gov; id HAA22907; Mon, 26 Mar 2001 07:13:09 -0500 Received: from gw-nl4.philips.com(212.153.190.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022875; Mon, 26 Mar 01 07:12:35 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA21706 for ; Mon, 26 Mar 2001 14:12:32 +0200 (MEST) (envelope-from rajiv.chakravorty@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma021699; Mon, 26 Mar 01 14:12:33 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA01676 for ; Mon, 26 Mar 2001 14:12:28 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA00586 for ; Mon, 26 Mar 2001 14:12:28 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890024992624; Mon, 26 Mar 2001 14:14:02 +0200 To: Subject: query: using two write() calls in succession Message-ID: <0056890024992624000002L942*@MHS> Date: Mon, 26 Mar 2001 14:14:02 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=0056890024992624" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --Boundary=_0.0_=0056890024992624 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/26/01 13:09:56" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=20 This problem is regarding use of two write() call in succession. Let m= e explain the=20 problem. In one of the blocking socket implementations, I have used two= write calls mainly=20 to detect the state of the TCP connection. I can expect that if the TCP= connection has=20 been closed (FIN) by the http server (due to http/1.1 timeout), the us= e of two write calls in sequence=20 at the client side should detect if the connection was closed. As norma= lly expected, when I=20 make the first write() call, the server would ackowledge the client wit= h a RST since=20 the connection was already closed. Now, when I make my second write() = call, in=20 succession, the presence of RST at the client TCP should prompt the sec= ond write()=20 to fail and return with errno to ECONNRESET. I wrote a small code to ch= eck this behaviour. I ran this code in linux 2.2.16 to retrive the index.html page from an= intranet web server. In this code, I made a TCP connection to send and retrieve the index.ht= ml file normally and=20 then slept for about 20 seconds allowing the web server to timeout. Af= ter 20 seconds, after the web server had timed-out and closed the connection, I again called the = two writes (breaking the request) with the same GET HTTP/1.1 request in succession.=20 I have some observations: 1. The second write() call in succession does not fail. However, if I = sleep for 1 second in between the two writes, the second write() call fails and returns er= rno with ECONNRESET. I checked this behaviour running it in Linux2.2.16/ SunOS _5.5.1/ 5.8 a= nd the behavior remains same. However, in Sun OS 5.7, second write() call does not fail at all even = after giving this delay. (I tried to increase the delay, but without any result). In VxWorks 5.2, we could = detect the error in the second=20 write call without any delay at all. Q.1.1 Why do we need some delay for the second write() call to fail in= most of the systems?? Q.2 .1 Why do we see such inconsistencies in various TCP implementation= s? (maybe I am missing=20 something)... 2. I checked the tcpdump output of Linux 2.2.16 and I find that when I = make the second write call and after the client has received RST from the first write , the client= TCP generates it own RST to be=20 sent to the server. I do think that this is not the expected behaviour = from the TCP. I checked the tcpdump output running the same code in SunOS 5.7 and I dont find any RST being= returned from the client to=20 the server, after it itself has received the RST. This is the normal ex= pected behavior of TCP, which=20 is somehow not evident in Linux (I have included the tcpdump file; linu= xdump.txt) Q.2.1 Is there some problems in the 2.2.16 TCP stack of Linux that prom= pts it to return RST for an RST=20 when the second write() call is made ?? Maybe I am missing something important or my interpretation of the prob= lem.=20 Would really appreciate your comments. Regds, Rajiv Chakravorty=20 Philips Advanced Systems and Applications Labs (ASA-Labs) Eindhoven, The Netherlands rajiv.chakravorty@philips.com ps: appended, please find the tcpdump(linuxdump.txt) for linux and the sampe code (testsock2.cpp) code used in this process. for compilation and final executable: g++ testsock2.cpp -o testsock -l= nsl -lsocket for accessing the server use: testsock = --Boundary=_0.0_=0056890024992624 Content-Type: application/octet-stream; name=linuxdump.txt Content-Disposition: attachment; filename=linuxdump.txt Content-Transfer-Encoding: base64 MTM6NTM6NDMuNDA5MTk3IGV0aDAgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4x MTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzogUyAzODMzMDA3Mjc6MzgzMzAwNzI3KDAp IHdpbiAzMjEyMCA8bXNzIDE0NjAsc2Fja09LLHRpbWVzdGFtcCAxMDMxMzYzMjUgMCxub3Asd3Nj YWxlIDA+IChERikKMTM6NTM6NDMuNDA5NjY4IGV0aDAgPCBhc2FlaHYuY2UucGhpbGlwcy5jb20u d3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20uMTE2MDogUyA3NzY1NzY0Njk6 Nzc2NTc2NDY5KDApIGFjayAzODMzMDA3Mjggd2luIDg3NjAgPG1zcyAxNDYwPiAoREYpCjEzOjUz OjQzLjQwOTc2MyBldGgwID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20uMTE2MCA+ IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3c6IC4gMToxKDApIGFjayAxIHdpbiAzMjEyMCAoREYp CjEzOjUzOjQzLjQxMDcyOCBldGgwID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20u MTE2MCA+IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3c6IFAgMToyKDEpIGFjayAxIHdpbiAzMjEy MCAoREYpCjEzOjUzOjQzLjQ1NjUwMCBldGgwIDwgYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dyA+ IHdzYXNhMzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjA6IC4gMToxKDApIGFjayAyIHdp biA4NzYwIChERikKMTM6NTM6NDMuNDU2NTUxIGV0aDAgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5w aGlsaXBzLmNvbS4xMTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzogUCAyOjM0KDMyKSBh Y2sgMSB3aW4gMzIxMjAgKERGKQoxMzo1Mzo0My40NzA4NDAgZXRoMCA8IGFzYWVodi5jZS5waGls aXBzLmNvbS53d3cgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4xMTYwOiBQIDE6 MTQ2MSgxNDYwKSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1Mzo0My40NzA5MTEgZXRoMCA+IHdz YXNhMzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjAgPiBhc2FlaHYuY2UucGhpbGlwcy5j b20ud3d3OiAuIDM0OjM0KDApIGFjayAxNDYxIHdpbiAzMDY2MCAoREYpCjEzOjUzOjQzLjQ3Mjgy MSBldGgwIDwgYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dyA+IHdzYXNhMzAwNS5hc2EtZWh2LmNl LnBoaWxpcHMuY29tLjExNjA6IC4gMTQ2MToyOTIxKDE0NjApIGFjayAzNCB3aW4gODc2MCAoREYp CjEzOjUzOjQzLjQ3NDA2NCBldGgwIDwgYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dyA+IHdzYXNh MzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjA6IFAgMjkyMTo0MjQzKDEzMjIpIGFjayAz NCB3aW4gODc2MCAoREYpCjEzOjUzOjQzLjQ4MDAzMiBldGgwID4gd3Nhc2EzMDA1LmFzYS1laHYu Y2UucGhpbGlwcy5jb20uMTE2MCA+IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3c6IC4gMzQ6MzQo MCkgYWNrIDQyNDMgd2luIDI5MjAwIChERikKMTM6NTM6NDMuNDgxOTM4IGV0aDAgPCBhc2FlaHYu Y2UucGhpbGlwcy5jb20ud3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20uMTE2 MDogLiA0MjQzOjU3MDMoMTQ2MCkgYWNrIDM0IHdpbiA4NzYwIChERikKMTM6NTM6NDMuNDgzMTcw IGV0aDAgPCBhc2FlaHYuY2UucGhpbGlwcy5jb20ud3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2Uu cGhpbGlwcy5jb20uMTE2MDogLiA1NzAzOjcxNjMoMTQ2MCkgYWNrIDM0IHdpbiA4NzYwIChERikK MTM6NTM6NDMuNDgzMjMyIGV0aDAgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4x MTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzogLiAzNDozNCgwKSBhY2sgNzE2MyB3aW4g Mjc3NDAgKERGKQoxMzo1Mzo0My40ODQxNzEgZXRoMCA8IGFzYWVodi5jZS5waGlsaXBzLmNvbS53 d3cgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4xMTYwOiBQIDcxNjM6ODM0Nygx MTg0KSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1Mzo0My40ODYwMTMgZXRoMCA8IGFzYWVodi5j ZS5waGlsaXBzLmNvbS53d3cgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4xMTYw OiAuIDgzNDc6OTgwNygxNDYwKSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1Mzo0My40ODcyNDMg ZXRoMCA8IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3cgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5w aGlsaXBzLmNvbS4xMTYwOiAuIDk4MDc6MTEyNjcoMTQ2MCkgYWNrIDM0IHdpbiA4NzYwIChERikK MTM6NTM6NDMuNDg3MzA4IGV0aDAgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4x MTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzogLiAzNDozNCgwKSBhY2sgMTEyNjcgd2lu IDI2MjgwIChERikKMTM6NTM6NDMuNDg4MjQzIGV0aDAgPCBhc2FlaHYuY2UucGhpbGlwcy5jb20u d3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20uMTE2MDogLiAxMTI2NzoxMjQ1 MSgxMTg0KSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1Mzo0My40OTAwMzUgZXRoMCA+IHdzYXNh MzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjAgPiBhc2FlaHYuY2UucGhpbGlwcy5jb20u d3d3OiAuIDM0OjM0KDApIGFjayAxMjQ1MSB3aW4gMjUwOTYgKERGKQoxMzo1Mzo0My40OTAwNTgg ZXRoMCA8IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3cgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5w aGlsaXBzLmNvbS4xMTYwOiAuIDEyNDUxOjEzOTExKDE0NjApIGFjayAzNCB3aW4gODc2MCAoREYp CjEzOjUzOjQzLjQ5MTI4OSBldGgwIDwgYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dyA+IHdzYXNh MzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjA6IC4gMTM5MTE6MTUzNzEoMTQ2MCkgYWNr IDM0IHdpbiA4NzYwIChERikKMTM6NTM6NDMuNDkxMzQ5IGV0aDAgPiB3c2FzYTMwMDUuYXNhLWVo di5jZS5waGlsaXBzLmNvbS4xMTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzogLiAzNDoz NCgwKSBhY2sgMTUzNzEgd2luIDIzMzYwIChERikKMTM6NTM6NDMuNDkyNjEwIGV0aDAgPCBhc2Fl aHYuY2UucGhpbGlwcy5jb20ud3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20u MTE2MDogUCAxNTM3MToxNjgzMSgxNDYwKSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1Mzo0My40 OTM1NTggZXRoMCA8IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3cgPiB3c2FzYTMwMDUuYXNhLWVo di5jZS5waGlsaXBzLmNvbS4xMTYwOiBQIDE2ODMxOjE3ODc0KDEwNDMpIGFjayAzNCB3aW4gODc2 MCAoREYpCjEzOjUzOjQzLjQ5NTQwMCBldGgwIDwgYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dyA+ IHdzYXNhMzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjA6IC4gMTc4NzQ6MTkzMzQoMTQ2 MCkgYWNrIDM0IHdpbiA4NzYwIChERikKMTM6NTM6NDMuNDk1NDY5IGV0aDAgPiB3c2FzYTMwMDUu YXNhLWVodi5jZS5waGlsaXBzLmNvbS4xMTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzog LiAzNDozNCgwKSBhY2sgMTkzMzQgd2luIDIxOTAwIChERikKMTM6NTM6NDMuNDk2NjI3IGV0aDAg PCBhc2FlaHYuY2UucGhpbGlwcy5jb20ud3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlw cy5jb20uMTE2MDogLiAxOTMzNDoyMDc5NCgxNDYwKSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1 Mzo0My40OTcyOTAgZXRoMCA8IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3cgPiB3c2FzYTMwMDUu YXNhLWVodi5jZS5waGlsaXBzLmNvbS4xMTYwOiBQIDIwNzk0OjIxNDY1KDY3MSkgYWNrIDM0IHdp biA4NzYwIChERikKMTM6NTM6NDMuNTAwMDI5IGV0aDAgPiB3c2FzYTMwMDUuYXNhLWVodi5jZS5w aGlsaXBzLmNvbS4xMTYwID4gYXNhZWh2LmNlLnBoaWxpcHMuY29tLnd3dzogLiAzNDozNCgwKSBh Y2sgMjE0NjUgd2luIDE5NzY5IChERikKMTM6NTM6NTguOTQ4MTA4IGV0aDAgPCBhc2FlaHYuY2Uu cGhpbGlwcy5jb20ud3d3ID4gd3Nhc2EzMDA1LmFzYS1laHYuY2UucGhpbGlwcy5jb20uMTE2MDog RiAyMTQ2NToyMTQ2NSgwKSBhY2sgMzQgd2luIDg3NjAgKERGKQoxMzo1Mzo1OC45NDgxNjMgZXRo MCA+IHdzYXNhMzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjAgPiBhc2FlaHYuY2UucGhp bGlwcy5jb20ud3d3OiAuIDM0OjM0KDApIGFjayAyMTQ2NiB3aW4gMTk3NjggKERGKQoxMzo1NDow My40ODAwNjQgZXRoMCA+IHdzYXNhMzAwNS5hc2EtZWh2LmNlLnBoaWxpcHMuY29tLjExNjAgPiBh c2FlaHYuY2UucGhpbGlwcy5jb20ud3d3OiBQIDM0OjM5KDUpIGFjayAyMTQ2NiB3aW4gMTk3Njgg KERGKQoxMzo1NDowMy40ODA0MDkgZXRoMCA8IGFzYWVodi5jZS5waGlsaXBzLmNvbS53d3cgPiB3 c2FzYTMwMDUuYXNhLWVodi5jZS5waGlsaXBzLmNvbS4xMTYwOiBSIDc3NjU5NzkzNTo3NzY1OTc5 MzUoMCkgd2luIDg3NjAgKERGKQoxMzo1NDowNC40OTEwMDkgZXRoMCA+IHdzYXNhMzAwNS5hc2Et ZWh2LmNlLnBoaWxpcHMuY29tLjExNjAgPiBhc2FlaHYuY2UucGhpbGlwcy5jb20ud3d3OiBSIDM5 OjM5KDApIGFjayAyMTQ2NiB3aW4gMzIxMjAgKERGKQo= --Boundary=_0.0_=0056890024992624 Content-Type: application/octet-stream; name=testsock2.cpp Content-Disposition: attachment; filename=testsock2.cpp Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8 bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8YXJwYS9pbmV0Lmg+DQojaW5jbHVkZSA8bmV0aW5ldC90 Y3AuaD4KI2luY2x1ZGUgPG5ldGRiLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN0 ZGlvLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHN0cmluZ3MuaD4KI2luY2x1ZGUg PHNpZ25hbC5oPgojaW5jbHVkZSA8ZXJybm8uaD4NCiNpbmNsdWRlIDxzdHJpbmc+DQoNCnR5cGVk ZWYgc3RyaW5nIFN0cmluZzsKCnZvaWQgc2lnaGFuZGxlcihpbnQpOwoKaW50Cm1haW4oaW50IGFy Z2MsIGNoYXIgKmFyZ3ZbXSkKewoJaW50CWk7CglpbnQJc29ja2ZkOyBpbnQgc2V0dmFsID0gMTsK CXN0cnVjdAlzb2NrYWRkcl9pbiBzZXJ2YWRkcjsKCXN0cnVjdAlob3N0ZW50ICpocDsgCgljaGFy CXJlcXVlc3RbMTAwMF07CgljaGFyCXJlc3BvbnNlWzEwMDAwMDBdOwoJc3NpemVfdCBuOw0KDQoJ Ly9hZGRlZCB2YXJpYWJsZXMNCglTdHJpbmcgcmV0Ow0KCWNoYXIgKnJlY0J1ZjsNCglyZWNCdWYg PSBuZXcgY2hhclsxMDI0XTsNCglpbnQgblJldCA9IDA7DQoKCglpZiAoYXJnYyAhPSAzKSB7CgkJ ZnByaW50ZihzdGRlcnIsICJ1c2FnZTogJXMgPGhvc3RuYW1lPiA8cGF0aD5cbiIsIGFyZ3ZbMF0p OwoJCWV4aXQoMSk7Cgl9CgoJc2lnbmFsKFNJR1BJUEUsIHNpZ2hhbmRsZXIpOwoNCgkvL2hvc3Rl bnQgcmV0cmlldmFsIGZyb20gaG9zdG5hbWUKCWlmICggKGhwID0gZ2V0aG9zdGJ5bmFtZShhcmd2 WzFdKSkgPT0gMCkgewoJCWZwcmludGYoc3RkZXJyLCAiJXM6IHVua25vd24gaG9zdFxuIiwgYXJn dlswXSk7CgkJZXhpdCgxKTsKCX0KDQoJLy9nZXQgc29ja2V0IGRlc2NyaXB0b3IKCWlmICggKHNv Y2tmZCA9IHNvY2tldChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCkpIDwgMCkgewoJCWZwcmludGYo c3RkZXJyLCAic29ja2V0IGVycm9yXG4iKTsKCQlleGl0KDIpOwoJfQ0KDQoJYnplcm8oJnNlcnZh ZGRyLCBzaXplb2Yoc2VydmFkZHIpKTsKCWJjb3B5KGhwLT5oX2FkZHIsICZzZXJ2YWRkci5zaW5f YWRkciwgaHAtPmhfbGVuZ3RoKTsKCXNlcnZhZGRyLnNpbl9mYW1pbHkgPSBBRl9JTkVUOwoJc2Vy dmFkZHIuc2luX3BvcnQgPSBodG9ucyg4MCk7Cg0KCS8vY29ubmVjdCB0byB0aGUgc2VydmVyCglp ZiAoY29ubmVjdChzb2NrZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKikmc2VydmFkZHIsIHNpemVvZihz ZXJ2YWRkcikpIDwgMCkgewoJCWZwcmludGYoc3RkZXJyLCAiQ2Fubm90IGNvbm5lY3QgdG8gc3Ry ZWFtIHNvY2tldFxuIik7CgkJZXhpdCgzKTsKCX0KDQoJLy9wcmVwYXJlIGEgR0VUIHJlcXVlc3QK CXNwcmludGYocmVxdWVzdCwgIkdFVCAlcyBIVFRQLzEuMVxyXG5ob3N0OiAlc1xyXG5cclxuIiwg YXJndlsyXSwgYXJndlsxXSk7DQoNCgkvL3NlbmQgdGhlIHJlcXVlc3QgYnkgYnJlYWtpbmcgaXQg aW50byB0d28NCglpZiAoIChuID0gd3JpdGUoc29ja2ZkLCByZXF1ZXN0LCAxKSkgPCAwKSB7DQoJ CWZwcmludGYoc3RkZXJyLCAiQ2Fubm90IHNlbmQgZmlyc3QgcmVxdWVzdFxuRXJyb3I6ICVzXG4i LCBzdHJlcnJvcihlcnJubykpOw0KCQlleGl0KDQpOw0KCX0NCgoJaWYgKCAobiA9IHdyaXRlKHNv Y2tmZCwgcmVxdWVzdCArIDEsIHN0cmxlbihyZXF1ZXN0KSAtIDEpKSA8IDApIHsNCgkJZnByaW50 ZihzdGRlcnIsICJDYW5ub3Qgc2VuZCBzZWNvbmQgcmVxdWVzdFxuRXJyb3I6ICVzXG4iLCBzdHJl cnJvcihlcnJubykpOw0KCQlleGl0KDQpOw0KCX0NCg0KLyoKCWlmICggKG4gPSByZWFkKHNvY2tm ZCwgcmVzcG9uc2UsIDE0NjAgKyAxODYpKSA+IDApIHsKCQlyZXNwb25zZVtuXSA9ICdcMCc7CgkJ cHJpbnRmKCIlc1xuIiwgcmVzcG9uc2UpOwoJCWZwcmludGYoc3RkZXJyLCAiPj4+IG4gPSAlZFxu XG4iLCBuKTsKCX0KKi8NCgkJLy9SZWNlaXZlIHRoZSByZXNwb25zZSB1bnRpbCAiXHJcblxyXG4i IGlzIGVuY291bnRlcmVkDQoJCXdoaWxlKHRydWUpIA0KCQl7DQoJCQkvL3JlY3YgZm9yIHRoZSBy ZXF1ZXN0IA0KCQkJaWYgKChuUmV0PXJlY3Yoc29ja2ZkLCByZWNCdWYsIDEwMjQsIDApKSA8IDAp IA0KCQkJew0KCQkJCWZwcmludGYoc3RkZXJyLCAicmVjdiBmYWlsZWQuLi4gJXNcbiIsIHN0cmVy cm9yKGVycm5vKSk7DQoJCQkJY2xvc2Uoc29ja2ZkKTsJCQ0KCQkJCWRlbGV0ZSByZWNCdWY7DQoJ CQkJcmVjQnVmPU5VTEw7DQoJCQkJZXhpdCg0KTsJCQ0KCQkJfQ0KCQkJDQoJCQlpZihuUmV0PjAp DQoJCQkJcmV0LmFwcGVuZChyZWNCdWYsblJldCk7DQoNCgkJCWlmIChuUmV0ID09IDApIHsNCgkJ CS8vY291dCA8PCAiXG5CeXRlcyByZWNlaXZlZDogIiA8PCByZXQubGVuZ3RoKCkgPDwgIiBIZWFk ZXIgbGVuZ3RoOiAiIDw8IHJldC5maW5kKCJcclxuXHJcbiIpKzQgPDxlbmRsOw0KCQkJLy9jb3V0 IDw8IHJldC5zdWJzdHIoMCxyZXQuZmluZCgiXHJcblxyXG4iKSs0KSA8PCBlbmRsOw0KCQkJYnJl YWs7DQoJCQl9DQoJCQkNCgkNCgkJCWlmKHJldC5maW5kKCJcclxuXHJcbiIpICAhPSBTdHJpbmc6 Om5wb3MpIHsNCgkJCS8vY291dCA8PCAiXG5CeXRlcyByZWNlaXZlZDogIiA8PCByZXQubGVuZ3Ro KCkgPDwgIkhlYWRlciBsZW5ndGg6ICIgPDwgcmV0LmZpbmQoIlxyXG5cclxuIikrNCA8PGVuZGw7 DQoJCQkvL2NvdXQgPDwgcmV0LnN1YnN0cigwLHJldC5maW5kKCJcclxuXHJcbiIpKzQpIDw8IGVu ZGw7DQoJCQkvL2NvdXQ8PCJlbmQgb2YgaGVhZGVyIGZvdW5kLS0gcmV0cmVhdGluZyI8PGVuZGw7 DQoJCQlicmVhazsNCgkJCX0NCg0KCQl9DQoJCQ0KCQkvL2RlbGV0ZSB0aGUgYnVmZmVyDQoJCWRl bGV0ZSByZWNCdWY7DQoJCXJlY0J1Zj1OVUxMOw0KCQ0KCQkvL3ByaW50IHRoZSByZXNwb25zZQ0K CQljb3V0PDwiUmVzcG9uc2UgZGF0YToiPDxlbmRsPDxyZXQ8PGVuZGw7DQoJDQoJCS8vc3RhcnQg c2xlZXBpbmcgZm9yIDIwIHNlY29uZHMsIHRvIGxldCBzZXJ2ZXIgdGltZW91dA0KCQlmcHJpbnRm KHN0ZG91dCwgIlN0YXJ0IHNsZWVwaW5nIC4uLlxuIik7DQoJCXNsZWVwKDIwKTsKCQ0KIA0KCS8v YXR0ZW1wdCB0aGUgZmlyc3Qgd3JpdGUNCglpZiAoIChuID0gd3JpdGUoc29ja2ZkLCByZXF1ZXN0 LCA1KSkgPCAwKSB7CgkJZnByaW50ZihzdGRlcnIsICJDYW5ub3Qgc2VuZCBmaXJzdCByZXF1ZXN0 XG5FcnJvcjogJXNcbiIsIHN0cmVycm9yKGVycm5vKSk7CgkJZXhpdCg0KTsKCX0NCg0KCS8vc2xl ZXAgYmV0d2VlbiB0aGUgdHdvIHdyaXRlcwojaWZkZWYgU0xFRVANCglzbGVlcCgxKTsNCiNlbmRp ZgkKCQ0KCS8vYXR0ZW1wdCB0aGUgc2Vjb25kIHdyaXRlCglpZiAoIChuID0gd3JpdGUoc29ja2Zk LCByZXF1ZXN0ICsgNSwgc3RybGVuKHJlcXVlc3QpIC0gNSkpIDwgMCkgewoJCWZwcmludGYoc3Rk ZXJyLCAiQ2Fubm90IHNlbmQgc2Vjb25kIHJlcXVlc3RcbkVycm9yOiAlc1xuIiwgc3RyZXJyb3Io ZXJybm8pKTsKCQlleGl0KDQpOwoJfQoKCWZwcmludGYoc3Rkb3V0LCAiV3JpdHRlbiAlZCBjaGFy YWN0ZXJzXG4iLCBuKTsKCn0KCnZvaWQgc2lnaGFuZGxlcihpbnQgc2lnbm8pCnsKCXNpZ25hbChT SUdQSVBFLCBTSUdfSUdOKTsKCWZwcmludGYoc3RkZXJyLCAiU0lHUElQRSBjYXVnaHRcbiIpOwoJ cmV0dXJuOwp9Cg== --Boundary=_0.0_=0056890024992624-- From owner-tcp-impl@lerc.nasa.gov Mon Mar 26 10:26:02 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08758 for ; Mon, 26 Mar 2001 10:26:01 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id KAA12142; Mon, 26 Mar 2001 10:26:01 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma011346; Mon, 26 Mar 01 10:25:11 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA01081 for tcp-impl-outgoing; Mon, 26 Mar 2001 10:13:15 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA00978 for ; Mon, 26 Mar 2001 10:13:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA15946; Mon, 26 Mar 2001 10:13:11 -0500 Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015858; Mon, 26 Mar 01 10:12:44 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA26283; Mon, 26 Mar 2001 10:12:26 -0500 (EST) Date: Mon, 26 Mar 2001 10:12:26 -0500 (EST) From: der Mouse Message-Id: <200103261512.KAA26283@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: rajiv.chakravorty@philips.com Cc: tcp-impl@grc.nasa.gov Subject: Re: query: using two write() calls in succession Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > 1. The second write() call in succession does not fail. However, if I = > sleep for 1 second > in between the two writes, the second write() call fails and returns er= > rno with ECONNRESET. This doesn't surprise me. Without the delay, the first write() generates an outgoing segment, sure, which draws an RST segment in response from the peer - but the second write() occurs well before the RST is received by the sending host. Even on a fast LAN, this usually takes at least a millisecond or so, and it's the rare machine that's so slow as to be unable to do back-to-back writes in less than that. The rest of your questions I can't help with. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Mon Mar 26 11:25:17 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11320 for ; Mon, 26 Mar 2001 11:25:16 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id LAA22402; Mon, 26 Mar 2001 11:25:16 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma021532; Mon, 26 Mar 01 11:24:10 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA16065 for tcp-impl-outgoing; Mon, 26 Mar 2001 11:14:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA16027 for ; Mon, 26 Mar 2001 11:14:35 -0500 (EST) From: rajiv.chakravorty@philips.com Received: by seraph3.lerc.nasa.gov; id LAA26075; Mon, 26 Mar 2001 11:14:33 -0500 Received: from gw-nl4.philips.com(212.153.190.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026038; Mon, 26 Mar 01 11:14:29 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id SAA02543; Mon, 26 Mar 2001 18:14:21 +0200 (MEST) (envelope-from rajiv.chakravorty@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma002537; Mon, 26 Mar 01 18:14:21 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA02129; Mon, 26 Mar 2001 18:14:19 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA16166; Mon, 26 Mar 2001 18:14:19 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890025022472; Mon, 26 Mar 2001 18:15:53 +0200 To: Cc: Subject: Re: query: using two write() calls in succession Message-ID: <0056890025022472000002L922*@MHS> Date: Mon, 26 Mar 2001 18:15:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/26/01 17:12:04" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id LAA16058 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Please find my comments appended. Regards, Rajiv Chakravorty >This doesn't surprise me. Without the delay, the first write() >generates an outgoing segment, sure, which draws an RST segment in >response from the peer - but the second write() occurs well before the >RST is received by the sending host. Even on a fast LAN, this usually >takes at least a millisecond or so, and it's the rare machine that's so >slow as to be unable to do back-to-back writes in less than that. Yes, this was my first guess. But it doesnt happen this way. Actually, I think I am receiving the RST well before I perform the second write. Here's the tcpdump output when the code is run on (Linux 2.2.16) without 1 sec sleep between two writes (sorry for not enabling the relative time option): client: wsasa3005 www/server: asaehv.ce.philips.com 17:31:17.185481 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: S 1292046262:1292046262(0) win 32120 (DF) 17:31:17.185986 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: S 3010001540:3010001540(0) ack 1292046263 win 8760 (DF) 17:31:17.186090 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 1:1(0) ack 1 win 32120 (DF) 17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) 17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) 17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) 17:31:17.247262 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 1:1461(1460) ack 34 win 8760 (DF) 17:31:17.247337 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 1461 win 30660 (DF) 17:31:17.249255 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1461:2921(1460) ack 34 win 8760 (DF) 17:31:17.250033 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 2921 win 30660 (DF) 17:31:17.250391 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 2921:4243(1322) ack 34 win 8760 (DF) 17:31:17.253254 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 4243:5703(1460) ack 34 win 8760 (DF) 17:31:17.254483 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 5703:7163(1460) ack 34 win 8760 (DF) 17:31:17.254546 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 7163 win 27740 (DF) 17:31:17.256139 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 7163:8347(1184) ack 34 win 8760 (DF) 17:31:17.257379 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 8347:9807(1460) ack 34 win 8760 (DF) 17:31:17.258604 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 9807:11267(1460) ack 34 win 8760 (DF) 17:31:17.258670 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 11267 win 26280 (DF) 17:31:17.259607 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 11267:12451(1184) ack 34 win 8760 (DF) 17:31:17.260026 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 12451 win 25096 (DF) 17:31:17.261449 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 12451:13911(1460) ack 34 win 8760 (DF) 17:31:17.262677 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 13911:15371(1460) ack 34 win 8760 (DF) 17:31:17.262741 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 15371 win 23360 (DF) 17:31:17.263905 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 15371:16831(1460) ack 34 win 8760 (DF) 17:31:17.264875 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 16831:17865(1034) ack 34 win 8760 (DF) 17:31:17.266120 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 17865:19325(1460) ack 34 win 8760 (DF) 17:31:17.266203 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 19325 win 21900 (DF) 17:31:17.267351 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 19325:20785(1460) ack 34 win 8760 (DF) 17:31:17.268485 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: P 20785:21835(1050) ack 34 win 8760 (DF) 17:31:17.270034 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 21835 win 19390 (DF) 17:31:33.748842 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: F 21835:21835(0) ack 34 win 8760 (DF) 17:31:33.748906 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: . 34:34(0) ack 21836 win 19389 (DF) 17:31:37.250061 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 34:39(5) ack 21836 win 19389 (DF) 17:31:37.250450 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: R 3010023376:3010023376(0) win 8760 (DF) 17:31:37.251146 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: R 67:67(0) ack 21836 win 32120 (DF) As you can see, the client TCP receives the RST (450-061) = 389 microsecs after making the first write. I believe this time is sufficient enough for the client TCP to fail on the second write() call, that was made probably after it had received the RST. Or is it not ??? The other inconsistent behavior that I was talking about is that you can also see the client also generating an RST and sending it back to the server after it had received an RST, when the second write() call was made slightly probably before 17:31:37.251146. Please comment. From owner-tcp-impl@lerc.nasa.gov Mon Mar 26 13:51:00 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14100 for ; Mon, 26 Mar 2001 13:50:59 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id NAA09833; Mon, 26 Mar 2001 13:50:58 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma009753; Mon, 26 Mar 01 13:50:42 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19030 for tcp-impl-outgoing; Mon, 26 Mar 2001 13:41:02 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA18986 for ; Mon, 26 Mar 2001 13:41:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA18375; Mon, 26 Mar 2001 13:40:58 -0500 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018310; Mon, 26 Mar 01 13:40:46 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 192C6726; Mon, 26 Mar 2001 10:40:45 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA27758; Mon, 26 Mar 2001 10:40:44 -0800 (PST) Message-ID: <3ABF8D2C.8E059133@cup.hp.com> Date: Mon, 26 Mar 2001 10:40:44 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: rajiv.chakravorty@philips.com Cc: tcp-impl@grc.nasa.gov Subject: Re: query: using two write() calls in succession References: <0056890024992624000002L942*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit rajiv.chakravorty@philips.com wrote: > > Hi, > > This problem is regarding use of two write() call in succession. Let me explain the > problem. In one of the blocking socket implementations, I have used two write calls > mainly to detect the state of the TCP connection. I can expect that if the TCP > connection has been closed (FIN) by the http server (due to http/1.1 timeout), the Um, isn't the remote's sending of a FIN supposed to generate a zero-length read to inform the other side that there was at least a partial shutdown? > use of two write calls in sequence at the client side should detect if the connection > was closed. As normally expected, when I make the first write() call, the server > would ackowledge the client with a RST since the connection was already closed. Now, > when I make my second write() call, in succession, the presence of RST at the client > TCP should prompt the second write() to fail and return with errno to ECONNRESET. I > wrote a small code to check this behaviour. I ran this code in linux 2.2.16 to > retrive the index.html page from an intranet web server. In this code, I made a TCP > connection to send and retrieve the index.html file normally and then slept for about > 20 seconds allowing the web server to timeout. After 20 seconds, after the web > server had timed-out and closed the connection, I again called the two writes > (breaking the request) with the same GET HTTP/1.1 request in succession. > I have some observations: > > 1. The second write() call in succession does not fail. However, if I sleep for 1 > second in between the two writes, the second write() call fails and returns errno > with ECONNRESET. I checked this behaviour running it in Linux2.2.16/ SunOS _5.5.1/ > 5.8 and the behavior remains same. However, in Sun OS 5.7, second write() call does > not fail at all even after giving this delay. (I tried to increase the delay, but > without any result). In VxWorks 5.2, we could detect the error in the second write > call without any delay at all. As derMouse pointed-out, once you send the first segment, there is arace between the other side getting the RST to the sending TCP, and the sending app getting the second write into TCP. As for why no delay was required in VxWorks, I'll hazard the guess that the system running VxWorks was slow enough that the RST arrived before the second segment could be sent by the app. As for why SunOS5.7 never got the ECONNRESET, probably a bug in 5.7. I still think that paying attention to the zero-length read to detect remote (graceful) close is best. doing things that elicit RST's is not such a hot idea. rick jones -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Tue Mar 27 14:35:49 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27337 for ; Tue, 27 Mar 2001 14:35:48 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id OAA07218; Tue, 27 Mar 2001 14:35:47 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma005515; Tue, 27 Mar 01 14:34:07 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA16709 for tcp-impl-outgoing; Tue, 27 Mar 2001 14:16:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA16649 for ; Tue, 27 Mar 2001 14:16:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA02741; Tue, 27 Mar 2001 14:16:18 -0500 Received: from mail.cs.umn.edu(128.101.32.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002681; Tue, 27 Mar 01 14:15:48 -0500 Received: from kepler.cs.umn.edu (zhzhang@kepler.cs.umn.edu [128.101.34.78]) by mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id NAA21037 for ; Tue, 27 Mar 2001 13:15:47 -0600 (CST) From: Zhi-Li Zhang Received: (from zhzhang@localhost) by kepler.cs.umn.edu (8.9.1/8.9.0) id NAA05833 for tcp-impl@lerc.nasa.gov; Tue, 27 Mar 2001 13:15:47 -0600 (CST) Date: Tue, 27 Mar 2001 13:15:47 -0600 (CST) Message-Id: <200103271915.NAA05833@kepler.cs.umn.edu> Content-Type: text Apparently-To: Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk We apologize if you receive multiple copies. ============================================== CALL FOR PAPERS HOT INTERCONNECTS 9 A Symposium on High Performance Interconnects Memorial Auditorium, Stanford University, Aug. 22-24, 2001 (Sponsored by the IEEE Computer Society) http://www.hoti.org Hot Interconnects is an international symposium focusing on the hardware and software architecture and implementation of high-performance interconnects of all scales. Its themes include cross-cutting issues spanning computer systems and networking technologies for providing universal services over packet networks. Examples of relevant topics include network-attached storage, transport of voice and video over packet networks, high-performance network interfaces, novel switching and routing technologies capable of providing differentiated services, plug-and-play network interfaces, and active network architectures. The conference is directed particularly at new and exciting product and technology innovations in these areas. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. In addition to those subscribing to the main theme of the conference, contributions are also solicited on the following topics: - Gb/sec and Tb/sec switching and routing technologies - High-speed packet processing engines - Serial link technologies - xDSL, HFC, and wireless access technologies - Mobility-enabling technologies - Seamless appliance interconnectivity - Network-attached storage devices and interfaces - Video and voice over packet networks - Wireless and mobile network interfaces - Network security - Next-generation networking chip sets - Network protocols on a chip - Low-power networking and interconnect technologies - Network appliance technologies - Optical Interconnects Submission Guidelines: --------------------------------- Submissions must be in the form of extended summaries and should not exceed 5 pages (double-column format). The summary should have sufficient technical detail to judge its quality and suitability for presentation at the conference. Guidelines for submission are available at http://www.hoti.org. Inquires about the conference should be directed to the TPC chairs. Important Dates: ----------------------- - Submission deadline: April 15, 2001. - Notification of acceptance: May 15, 2001. - Camera-ready due: July 1, 2001. Organizing Committee: --------------------------------- - General Chair: Fred Bauer, Nokia (fred@iprg.nokia.com) - Technical Program Chairs: - Marwan Krunz, University of Arizona (krunz@ece.arizona.edu) - John Lockwood, Washington University in St. Louis (lockwood@arl.wustl.edu) - Tutorial/Panel: Ibrahim Matta, Boston University (matta@cs.bu.edu) - Treasurer: Melanie Swan, MS Financial Consulting (melanie.swan@wharton.upenn.edu) - Registration: Bob Wedig, Wedig Consulting (bob@wedig.com) - Webmaster: Raymond Lee, IP Dynamics (raymondl@ipdynamics.com) - Local arrangements: Liz Rogers, Liz Rogers Design (liz@lizrogersdesign.com) - Publicity: Zhi-Li Zhang, University of Minnesota (zhzhang@cs.umn.edu) Technical Program Committee: Anujan Varma, University of California Santa Cruz Balaji Prabhakar, Stanford University Dan Pitt, Nortel Networks Ian Akyildiz, Georgia Institute of Technology James Yee, Pacific Broadband Peter Newman, Ensim Zhi-Li Zhang, University of Minnesota Nina Taft, Sprint Labs Christopher Diot, Sprint Labs George Apostolopoulos, Reback Networks Andrew Cambell, Columbia University Parameswaran Ramanathan, University of Wisconsin Mohan Kumar, University of Texas at Arlington Ron Srodawa, Oakland University James P.G. Sterbenz, BBN Edward Knightly, Rice University From owner-tcp-impl@lerc.nasa.gov Wed Mar 28 06:34:48 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23045 for ; Wed, 28 Mar 2001 06:34:47 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id GAA09757; Wed, 28 Mar 2001 06:34:44 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma009015; Wed, 28 Mar 01 06:33:50 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA17727 for tcp-impl-outgoing; Wed, 28 Mar 2001 06:20:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA17710 for ; Wed, 28 Mar 2001 06:20:44 -0500 (EST) From: rajiv.chakravorty@philips.com Received: by seraph3.lerc.nasa.gov; id GAA10906; Wed, 28 Mar 2001 06:20:42 -0500 Received: from gw-nl4.philips.com(212.153.190.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010892; Wed, 28 Mar 01 06:20:17 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id NAA21257 for ; Wed, 28 Mar 2001 13:20:15 +0200 (MEST) (envelope-from rajiv.chakravorty@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma021255; Wed, 28 Mar 01 13:20:15 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA04870 for ; Wed, 28 Mar 2001 13:20:13 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA07425 for ; Wed, 28 Mar 2001 13:20:12 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890025220977; Wed, 28 Mar 2001 13:21:47 +0200 To: Subject: Re: query: using two write() calls in succession Message-ID: <0056890025220977000002L972*@MHS> Date: Wed, 28 Mar 2001 13:21:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/28/01 12:18:03" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id GAA17714 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Rick and der Mouse, I have some doubts regarding your interpretation of the problem. I was under the impression that a blocking write (or send) call would block until it has received an ACK or an RST for data sent and then perform the 2nd write. I have noticed that this happens even when I had made two write calls by breaking the request (1+32) while making the first normal request to the server. (check the previous linuxdump.txt file). I have appended relevant parts of it here: 17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) 17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) 17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) As you can see, when I make my first write call by sending 1 byte of data, it waits until it receives the ACK and then proceed with the second write. That means, in this case write call blocks until the server or peer TCP ackowledges the data. (unless using non-blocking sockets, or using MSG_DONTWAIT option if used with send() call). Also, in this case, I have not disabled Nagle's algoritm. Ofcourse, my linux client is a dual P-II terminal. After, looking into all this, is it possible that RST can be received even after the application has already come out from the first write call ?? ...or its actually the tcp stack that's still not able to detect the RST just before sending the request data for the second write (as you can see it still detects if some delay is given). Maybe something to do with silly window syndrome since I am writing small amount of data... ?? Please enlighten me with comments and/or pointers. Regards, Rajiv Chakravorty From owner-tcp-impl@lerc.nasa.gov Wed Mar 28 08:44:32 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27390 for ; Wed, 28 Mar 2001 08:44:31 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id IAA22737; Wed, 28 Mar 2001 08:44:29 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma021560; Wed, 28 Mar 01 08:42:03 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA02426 for tcp-impl-outgoing; Wed, 28 Mar 2001 08:30:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA02389 for ; Wed, 28 Mar 2001 08:30:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA24021; Wed, 28 Mar 2001 08:30:02 -0500 Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023714; Wed, 28 Mar 01 08:29:02 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id IAA02478; Wed, 28 Mar 2001 08:28:44 -0500 (EST) Date: Wed, 28 Mar 2001 08:28:44 -0500 (EST) From: der Mouse Message-Id: <200103281328.IAA02478@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: rajiv.chakravorty@philips.com Cc: tcp-impl@grc.nasa.gov Subject: Re: query: using two write() calls in succession Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > I was under the impression that a blocking write (or send) call would > block until it has received an ACK or an RST for data sent and then > perform the 2nd write. This is not the way any implementation I've used works (unless the first write is larger than the buffering capacity of the socket). > I have noticed that this happens even when I had made two write calls > by breaking the request (1+32) while making the first normal request > to the server. (check the previous linuxdump.txt file). I have > appended relevant parts of it here: > 17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) > 17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) > 17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) > As you can see, when I make my first write call by sending 1 byte of > data, it waits until it receives the ACK and then proceed with the > second write. You are confusing the timing of the write() calls with the timing of the data actually going out onto the wire. > That means, in this case write call blocks until the server or peer > TCP ackowledges the data. No, it means that the TCP does not send the data until then. It says nothing about when the write calls complete (except, of course, that the first write must have completed before the second write's data goes out). der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Wed Mar 28 10:16:57 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00649 for ; Wed, 28 Mar 2001 10:16:56 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id KAA05422; Wed, 28 Mar 2001 10:16:56 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma004532; Wed, 28 Mar 01 10:15:27 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA23739 for tcp-impl-outgoing; Wed, 28 Mar 2001 10:05:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA23705 for ; Wed, 28 Mar 2001 10:05:09 -0500 (EST) From: rajiv.chakravorty@philips.com Received: by seraph3.lerc.nasa.gov; id KAA08416; Wed, 28 Mar 2001 10:05:08 -0500 Received: from gw-nl4.philips.com(212.153.190.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008327; Wed, 28 Mar 01 10:05:00 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA09170; Wed, 28 Mar 2001 17:04:57 +0200 (MEST) (envelope-from rajiv.chakravorty@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma009166; Wed, 28 Mar 01 17:04:58 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA11363; Wed, 28 Mar 2001 17:04:57 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA28225; Wed, 28 Mar 2001 17:04:56 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890025250620; Wed, 28 Mar 2001 17:06:31 +0200 To: Cc: Subject: Re: query: using two write() calls in succession Message-ID: <0056890025250620000002L902*@MHS> Date: Wed, 28 Mar 2001 17:06:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/28/01 16:02:37" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id KAA23725 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit der Mouse and all, As indicated by der Mouse, I performed two writes by making two connections to the server. I did find that data with the second write call made through the second connection appeared on the wire before I could receive the RST from the first write (made from the first connection). This clarifies der Mouse's point. Thanks, Rajiv mouse@Rodents.Montreal.QC.CA@SMTP@lerc.nasa.gov on 03-28-2001 03:49:40 PM Sent by: owner-tcp-impl@lerc.nasa.gov To: Rajiv Chakravorty/EHV/CE/PHILIPS@EMEA3 cc: tcp-impl@grc.nasa.gov@SMTP Subject: Re: query: using two write() calls in succession Classification: > I was under the impression that a blocking write (or send) call would > block until it has received an ACK or an RST for data sent and then > perform the 2nd write. This is not the way any implementation I've used works (unless the first write is larger than the buffering capacity of the socket). > I have noticed that this happens even when I had made two write calls > by breaking the request (1+32) while making the first normal request > to the server. (check the previous linuxdump.txt file). I have > appended relevant parts of it here: > 17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) > 17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) > 17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) > As you can see, when I make my first write call by sending 1 byte of > data, it waits until it receives the ACK and then proceed with the > second write. You are confusing the timing of the write() calls with the timing of the data actually going out onto the wire. > That means, in this case write call blocks until the server or peer > TCP ackowledges the data. No, it means that the TCP does not send the data until then. It says nothing about when the write calls complete (except, of course, that the first write must have completed before the second write's data goes out). der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Wed Mar 28 15:00:04 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09884 for ; Wed, 28 Mar 2001 15:00:03 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id NAA29808; Wed, 28 Mar 2001 13:19:53 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma029070; Wed, 28 Mar 01 13:19:01 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA05637 for tcp-impl-outgoing; Wed, 28 Mar 2001 13:07:01 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA05594 for ; Wed, 28 Mar 2001 13:06:59 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA08092; Wed, 28 Mar 2001 13:06:57 -0500 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008011; Wed, 28 Mar 01 13:06:38 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 04E38113A; Wed, 28 Mar 2001 10:06:36 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA14921; Wed, 28 Mar 2001 10:06:36 -0800 (PST) Message-ID: <3AC2282C.BAED34BE@cup.hp.com> Date: Wed, 28 Mar 2001 10:06:36 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: rajiv.chakravorty@philips.com Cc: tcp-impl@grc.nasa.gov Subject: Re: query: using two write() calls in succession References: <0056890025220977000002L972*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit rajiv.chakravorty@philips.com wrote: > > Rick and der Mouse, > > I have some doubts regarding your interpretation of the problem. I was > under the impression that a blocking write (or send) call would block > until it has received an ACK or an RST for data sent and then perform > the 2nd write. I am afraid your impression, while perhaps natual to the untainted :), is incorrect. As often as not, a send/write call to a socket will complete once the data has been copied into the stack. This is well before it is ACKnowledged by the remote, or even sent out the wire. > I have noticed that this happens even when I had made two write calls > by breaking the request (1+32) while making the first normal request > to the server. (check the previous linuxdump.txt file). I have > appended relevant parts of it here: > > 17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) > 17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) > 17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) > > As you can see, when I make my first write call by sending 1 byte of > data, it waits until it receives the ACK and then proceed with the > second write. That means, in this case write call blocks until the > server or peer TCP ackowledges the data. (unless using non-blocking > sockets, or using MSG_DONTWAIT option if used with send() call). Also, > in this case, I have not disabled Nagle's algoritm. Ofcourse, my linux > client is a dual P-II terminal. What you are seeing in that trace is the Nagle algorithm, implying nothing about the completion semantics of the write() call against a socket. I suspect that if you were to run a system call trace on your program at the same time, you would find that the second write() call happened before the ACK. > After, looking into all this, is it possible that RST can be received > even after the application has already come out from the first write > call ?? ...or its actually the tcp stack that's still not able to > detect the RST just before sending the request data for the second > write (as you can see it still detects if some delay is given). Maybe > something to do with silly window syndrome since I am writing small > amount of data... ?? Even on a "blocking socket" a send/write completes once the data is written into the socket buffer. This is independent of the decisions TCP makes about when to send data onto the wire. If the socket buffer is full, the write() call will block, but only until enough space is freed via ACK's or _prior_ writes to allow the data of this write() into the buffer. I guess the fancier way to say it is that writing data into the connection is asynchronous from that data being send on the wire. All splitting writes will do is cause your app lication to run afoul of the nagle algorithm and take more CPU cycles on the system than it should. If you want to detect remote connection close (via FIN) use the zero-bytes on a recv/read semantic. If you want to detect remote connection death, implement a keepalive handshake in your app. rick jones -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Wed Mar 28 17:27:25 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13994 for ; Wed, 28 Mar 2001 17:27:19 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id RAA26576; Wed, 28 Mar 2001 17:27:18 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma025704; Wed, 28 Mar 01 17:26:23 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA25360 for tcp-impl-outgoing; Wed, 28 Mar 2001 17:09:23 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA25333 for ; Wed, 28 Mar 2001 17:09:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA16001; Wed, 28 Mar 2001 17:09:19 -0500 Received: from smtp015.mail.yahoo.com(216.136.173.59) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015771; Wed, 28 Mar 01 17:09:02 -0500 Received: from unknown (HELO centaur) (203.135.14.130) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Mar 2001 22:08:57 -0000 X-Apparently-From: Message-ID: <002a01c0b7d3$a0a934c0$0f02000a@centaur> From: "Khurram Saeed" To: "der Mouse" , Cc: References: <200103281328.IAA02478@Twig.Rodents.Montreal.QC.CA> Subject: Re: query: using two write() calls in succession Date: Thu, 29 Mar 2001 03:08:23 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I unlisted my self from this list long ago, but I still receive mails from this list every now and then. May I please be removed Thanks ----- Original Message ----- From: "der Mouse" To: Cc: Sent: Wednesday, March 28, 2001 6:28 PM Subject: Re: query: using two write() calls in succession > > I was under the impression that a blocking write (or send) call would > > block until it has received an ACK or an RST for data sent and then > > perform the 2nd write. > > This is not the way any implementation I've used works (unless the > first write is larger than the buffering capacity of the socket). > > > I have noticed that this happens even when I had made two write calls > > by breaking the request (1+32) while making the first normal request > > to the server. (check the previous linuxdump.txt file). I have > > appended relevant parts of it here: > > > 17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) > > 17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) > > 17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) > > > As you can see, when I make my first write call by sending 1 byte of > > data, it waits until it receives the ACK and then proceed with the > > second write. > > You are confusing the timing of the write() calls with the timing of > the data actually going out onto the wire. > > > That means, in this case write call blocks until the server or peer > > TCP ackowledges the data. > > No, it means that the TCP does not send the data until then. It says > nothing about when the write calls complete (except, of course, that > the first write must have completed before the second write's data goes > out). > > der Mouse > > mouse@rodents.montreal.qc.ca > 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 04:50:26 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01409 for ; Thu, 29 Mar 2001 04:50:25 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id EAA05528; Thu, 29 Mar 2001 04:50:24 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma004254; Thu, 29 Mar 01 04:49:05 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA13929 for tcp-impl-outgoing; Thu, 29 Mar 2001 04:33:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA13917; Thu, 29 Mar 2001 04:33:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA19271; Thu, 29 Mar 2001 04:33:31 -0500 Received: from chopin.cti.depaul.edu(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019259; Thu, 29 Mar 01 04:33:27 -0500 Received: from ehab2000 ([64.254.195.5]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.2345); Thu, 29 Mar 2001 03:33:13 -0600 Message-ID: <002101c0b833$76a372c0$05c3fe40@cti.depaul.edu> Reply-To: "MMNS'2001" From: "MMNS'2001" To: "MMNS2001" Subject: CFP for Special Sessions in MMNS'2001 Date: Thu, 29 Mar 2001 03:34:32 -0600 Organization: DePaul University, MNLAB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 29 Mar 2001 09:33:13.0824 (UTC) FILETIME=[46DF0E00:01C0B833] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS for Special Sessions in the Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001, Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 MMNS has identified a number ``focus topics'' that are of particular relevance and importance to the field of multimedia network and service management. MMNS plans to conduct special sessions to address such hot issues. Papers submitted to these special sessions will go through the normal submission and review procedure. The goal is to build special sessions of exceptional papers all dealing with a closely related theme. The set of focus topics include the following: * INTERNET TRAFFIC MONITORING: The focus of this special session is on techniques and methodologies for collecting Internet traffic statistics, descriptions of collection systems implemented and deployed in the Internet, results from these systems, and analyses of these results describing how multimedia networks and services can be better managed. For questions about this special session, contact Kevin Almeroth (almeroth@cs.ucsb.edu). * Multimedia in AD-HOC NETWORKS: Networks of the future are envisioned to integrate the Internet with wireless mobile embedded devices and ad-hoc networks. Ad-hoc networks are collections of wireless mobile nodes that can be deployed rapidly without pre-existing or centralized communication infrastructure. These networks should support various types of multimedia traffic, including audio, video, TC-based data, and sensory data. Due to the nature of ad-hoc networks, number of new challenges must be addressed in order to facilitate seamless services of Ad-hoc networks. This includes unicast and multicast routing protocols, power-aware protocols in almost all layers of the network stack, quality and guarantee of service provisioning for multimedia traffic, self-configuring hierarchies and architectures, address allocation and naming, data dissemination techniques, efficient mobility support, fault and performance management tools, performance analysis of end-to-end protocols such as TCP and reliable multicast over ad-hoc networks. For questions about this special session, contact Ahmed Helmy (helmy@ceng.usc.edu) * RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA: Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS Internet wireless multimedia. The session is looking for original contributions in this demanding area that address related issues. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques that consider the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. For questions about this special session, contact Raouf Boutaba(rboutaba@bbcr.uwaterloo.ca). * MOBILE AGENT-BASED NETWORK MANAGEMENT: Research and development on various forms of agents and mobile agents is continuing to grow in a staggering fashion in recent years. Agent-based telecommunication applications and services such as active networks, Qos and bandwidth brokers, E-commerce, information gathering on Internet, and feature interactions are becoming increasingly popular and are largely contributing to the development and to the success of distributed multimedia technology. This session will focus on research and development activities related to the field of agents in the area of active networks, and QoS agent-based architectures for managing multimedia networks and distributed services. The objective is to provide the audiences with a clear background into the opportunities and the challenges that the mobile agent emerging paradigm brings about For questions about this special session, contact Ahmed Karmouch (karmouch@site.uottawa.ca), Nazism Agoulmine (nazim@rp.lip6.fr) or Allan Marshall (a.marshall@ee.qub.ac) Ehab Al-Shaer, Ph.D. Assistant Professor, School of Computer Science, Telecommunications and Information Systems, DePaul University, Chicago, IL 60604 ehab@cs.depaul.edu From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 04:52:40 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01582 for ; Thu, 29 Mar 2001 04:52:39 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id EAA07216; Thu, 29 Mar 2001 04:52:38 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma005083; Thu, 29 Mar 01 04:49:59 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA14014 for tcp-impl-outgoing; Thu, 29 Mar 2001 04:37:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA14002; Thu, 29 Mar 2001 04:37:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA19569; Thu, 29 Mar 2001 04:37:32 -0500 Received: from chopin.cti.depaul.edu(140.192.32.73) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019546; Thu, 29 Mar 01 04:36:47 -0500 Received: from ehab2000 ([64.254.195.5]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.2345); Thu, 29 Mar 2001 03:36:39 -0600 Message-ID: <002d01c0b833$f0fc66d0$05c3fe40@cti.depaul.edu> Reply-To: "MMNS'2001" From: "MMNS'2001" To: "MMNS2001" Cc: "MMNS2001" Subject: CFP MMNS'2001 Date: Thu, 29 Mar 2001 03:37:57 -0600 Organization: DePaul University, MNLAB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 29 Mar 2001 09:36:39.0089 (UTC) FILETIME=[C1380210:01C0B833] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001 Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 Conference: October 29 to Nov 1, 2001 The IFIP/IEEE MMNS is the premier IEEE/IFIP conferences focusing on management of multimedia networks and services. The conference is known for its high-quality papers from various research communities. Selected papers will also be considered for publication as a special issue of the Journal of High Speed Networking and Journal of Networks and Information Systems. MMNS 2001 will provide Travel and Conference Scholarships for students. Topics of interest include, but are not limited to, the following: Distributed multimedia service management Integration of network control and management Network management models and architectures Distributed event correlation Monitoring QoS management Multimedia traffic management Resource, performance and fault management for broadband networks Configuration management of edge and core services for enabling multimedia traffic management Multi-point and multicast services management Resource management in wireless multimedia Wireless and mobile network management Mobility management Management of ad-hoc networks Multimedia content protection Deployment of multimedia services Active network management Network programmability for multimedia services Middleware support for management Multimedia session management Packet scheduling and dropping techniques Multimedia service Engineering Billing and security for broadband networks Policy-based management for multimedia service PAPER SUBMISSION PROCEDURE See . From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 06:40:49 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08890 for ; Thu, 29 Mar 2001 06:40:48 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id GAA21147; Thu, 29 Mar 2001 06:40:45 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma020173; Thu, 29 Mar 01 06:38:56 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA22297 for tcp-impl-outgoing; Thu, 29 Mar 2001 06:27:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA22276 for ; Thu, 29 Mar 2001 06:27:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA29126; Thu, 29 Mar 2001 06:27:24 -0500 Received: from unknown(203.199.199.225) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029075; Thu, 29 Mar 01 06:26:24 -0500 Received: from netlab.hcltech.com (arun [192.168.201.67]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id QAA02900 for ; Thu, 29 Mar 2001 16:20:36 +0530 Message-ID: <3AC310CF.EDBCEC26@netlab.hcltech.com> Date: Thu, 29 Mar 2001 16:09:11 +0530 From: arun X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: initial window size References: <0056890025220977000002L972*@MHS> <3AC2282C.BAED34BE@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit hi Iam new to this. My doubt is this. With what criteria the intial window for TCP is calculated and set. From the tcp code of linux, I can interpret that the allowable receive buffer is set to a value 32767. The initial window should be less than this value. Can any one of u explain me why the initial window is chosen less than 32767 and how is that calculation go. Thanks -arun From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 07:01:57 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10175 for ; Thu, 29 Mar 2001 07:01:56 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id HAA24837; Thu, 29 Mar 2001 07:01:53 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma023994; Thu, 29 Mar 01 07:00:28 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA24578 for tcp-impl-outgoing; Thu, 29 Mar 2001 06:50:41 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA24572 for ; Thu, 29 Mar 2001 06:50:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA01717; Thu, 29 Mar 2001 06:50:39 -0500 Received: from jack.see.plymouth.ac.uk(141.163.49.98) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001713; Thu, 29 Mar 01 06:50:36 -0500 Received: from jack.see.plym.ac.uk (bogdan@sfres1.see.plym.ac.uk [141.163.49.101]) by jack.see.plym.ac.uk (8.9.3/8.9.3) with ESMTP id MAA20089; Thu, 29 Mar 2001 12:43:06 +0100 Message-ID: <3AC32220.584EFFDD@jack.see.plym.ac.uk> Date: Thu, 29 Mar 2001 12:53:04 +0100 From: Bogdan Ghita X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: arun CC: tcp-impl@grc.nasa.gov Subject: Re: initial window size References: <0056890025220977000002L972*@MHS> <3AC2282C.BAED34BE@cup.hp.com> <3AC310CF.EDBCEC26@netlab.hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello arun, The purpose of a small value for TCP initial window is to limit the inital 'train' of packets. It is up to each TCP sender to decide the value, but the higher this value the higher the possibility to end up with a congestion, because the sender would transmit, without 'probing' the network, all these packets back-to-back. The main problem is usually not the TCP receiver not being able to cope with the data, but the path betwen the sender and the receiver being congested. This is why the initial window has, preferably, a low value Bogdan arun wrote: > > hi > Iam new to this. My doubt is this. With what criteria the intial window for TCP is calculated and set. From the tcp code of > linux, I can interpret that the allowable receive buffer is set to a value 32767. The initial window should be less than this > value. Can any one of u explain me why the initial window is chosen less than 32767 and how is that calculation go. > > Thanks > -arun From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 13:16:56 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29604 for ; Thu, 29 Mar 2001 13:16:55 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id NAA04465; Thu, 29 Mar 2001 13:16:52 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma003871; Thu, 29 Mar 01 13:15:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA03307 for tcp-impl-outgoing; Thu, 29 Mar 2001 13:02:18 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA03276 for ; Thu, 29 Mar 2001 13:02:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA21243; Thu, 29 Mar 2001 13:02:16 -0500 Received: from hs-img-rel-1.compuserve.com(149.174.177.156) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021202; Thu, 29 Mar 01 13:01:36 -0500 Received: (from mailgate@localhost) by sphmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id NAA09614 for tcp-impl@grc.nasa.gov; Thu, 29 Mar 2001 13:01:15 -0500 (EST) Received: from RedCross (mid-tgn-ngl-vty6.as.wcom.net [216.192.84.6]) by sphmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with SMTP id NAA09568 for ; Thu, 29 Mar 2001 13:01:03 -0500 (EST) Message-ID: <004d01c0b87a$38a78f00$0654c0d8@crans1.ri.home.com> Reply-To: "David St. Germain" From: "David St. Germain" To: References: <0056890025220977000002L972*@MHS> <3AC2282C.BAED34BE@cup.hp.com> <3AC310CF.EDBCEC26@netlab.hcltech.com> <3AC32220.584EFFDD@jack.see.plym.ac.uk> Subject: Re: initial window size Date: Thu, 29 Mar 2001 13:01:01 -0500 Organization: St. Germain Consulting Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit It's always been my understanding that the default initial window size is 512K for purposes of flow control (avoiding the overflow of sender's and receiver's buffers) and to avoid fragmentation of the TCP PDU until the MTU - and max receive window - can be negotiated. Dave. ----- Original Message ----- From: "Bogdan Ghita" To: "arun" Cc: Sent: Thursday, March 29, 2001 6:53 AM Subject: Re: initial window size > Hello arun, > > The purpose of a small value for TCP initial window is to limit the > inital 'train' of packets. It is up to each TCP sender to decide the > value, but the higher this value the higher the possibility to end up > with a congestion, because the sender would transmit, without 'probing' > the network, all these packets back-to-back. The main problem is usually > not the TCP receiver not being able to cope with the data, but the path > betwen the sender and the receiver being congested. > This is why the initial window has, preferably, a low value > > Bogdan > > > arun wrote: > > > > hi > > Iam new to this. My doubt is this. With what criteria the intial window for TCP is calculated and set. From the tcp code of > > linux, I can interpret that the allowable receive buffer is set to a value 32767. The initial window should be less than this > > value. Can any one of u explain me why the initial window is chosen less than 32767 and how is that calculation go. > > > > Thanks > > -arun > From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 16:08:59 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10977 for ; Thu, 29 Mar 2001 16:08:59 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id QAA23003; Thu, 29 Mar 2001 16:08:57 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma021662; Thu, 29 Mar 01 16:07:06 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA08322 for tcp-impl-outgoing; Thu, 29 Mar 2001 15:55:36 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA08226 for ; Thu, 29 Mar 2001 15:55:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA17066; Thu, 29 Mar 2001 15:55:26 -0500 Received: from unknown(209.208.255.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016947; Thu, 29 Mar 01 15:55:17 -0500 Received: from oleglaptop ([216.75.71.92]) by polaris.inforocket.com (Netscape Messaging Server 4.15) with SMTP id GAZ8HH00.JIY; Thu, 29 Mar 2001 15:48:53 -0500 From: "Oleg Vishnepolsky" To: "David St. Germain" , Subject: RE: initial window size Date: Thu, 29 Mar 2001 15:51:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <004d01c0b87a$38a78f00$0654c0d8@crans1.ri.home.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit 512K is a bit much for initial size, to say the least. In fact 512 bytes (not kbytes) is what is used by a lot of tcp stacks when establishing connection with non-local hosts. 512 is really conservative IMHO. Days when backbone MTUs were that small are gone long time ago. For hosts on the local net, mileage varies depending on the stack. I used 8K in my stacks (OS/2 circa 1990, FlexOS circa 93). I found that given prevalent MTUs back then of 1460, 8k gave me best performance. Oleg Vishnepolsky -----Original Message----- From: owner-tcp-impl@lerc.nasa.gov [mailto:owner-tcp-impl@lerc.nasa.gov]On Behalf Of David St. Germain Sent: Thursday, March 29, 2001 1:01 PM To: tcp-impl@grc.nasa.gov Subject: Re: initial window size It's always been my understanding that the default initial window size is 512K for purposes of flow control (avoiding the overflow of sender's and receiver's buffers) and to avoid fragmentation of the TCP PDU until the MTU - and max receive window - can be negotiated. Dave. ----- Original Message ----- From: "Bogdan Ghita" To: "arun" Cc: Sent: Thursday, March 29, 2001 6:53 AM Subject: Re: initial window size > Hello arun, > > The purpose of a small value for TCP initial window is to limit the > inital 'train' of packets. It is up to each TCP sender to decide the > value, but the higher this value the higher the possibility to end up > with a congestion, because the sender would transmit, without 'probing' > the network, all these packets back-to-back. The main problem is usually > not the TCP receiver not being able to cope with the data, but the path > betwen the sender and the receiver being congested. > This is why the initial window has, preferably, a low value > > Bogdan > > > arun wrote: > > > > hi > > Iam new to this. My doubt is this. With what criteria the intial window for TCP is calculated and set. From the tcp code of > > linux, I can interpret that the allowable receive buffer is set to a value 32767. The initial window should be less than this > > value. Can any one of u explain me why the initial window is chosen less than 32767 and how is that calculation go. > > > > Thanks > > -arun > From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 16:23:41 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11669 for ; Thu, 29 Mar 2001 16:23:41 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id QAA26650; Thu, 29 Mar 2001 16:23:39 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma025761; Thu, 29 Mar 01 16:22:29 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA12355 for tcp-impl-outgoing; Thu, 29 Mar 2001 16:15:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA12315 for ; Thu, 29 Mar 2001 16:15:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20323; Thu, 29 Mar 2001 16:15:17 -0500 Received: from hopper.math.uwaterloo.ca(129.97.78.132) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020235; Thu, 29 Mar 01 16:14:43 -0500 Received: from localhost (mmcsween@localhost) by hopper.math.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id QAA26777; Thu, 29 Mar 2001 16:14:04 -0500 (EST) Date: Thu, 29 Mar 2001 16:14:04 -0500 (EST) From: Martin McSweeney To: Oleg Vishnepolsky cc: "David St. Germain" , tcp-impl@grc.nasa.gov Subject: RE: initial window size In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hmmm... "a bit much", isn't 512K an extremely large window given any circumstances? -martin Martin McSweeney mmcsween@styx.uwaterloo.ca On Thu, 29 Mar 2001, Oleg Vishnepolsky wrote: > 512K is a bit much for initial size, to say the least. In fact 512 bytes (not kbytes) is what is used by a lot of > tcp stacks when establishing connection with non-local hosts. 512 is really conservative IMHO. > Days when backbone MTUs were that small are gone long time ago. > For hosts on the local net, mileage varies depending on the stack. I used 8K in my stacks > (OS/2 circa 1990, FlexOS circa 93). I found that given prevalent MTUs back then of 1460, > 8k gave me best performance. > > Oleg Vishnepolsky > -----Original Message----- > From: owner-tcp-impl@lerc.nasa.gov > [mailto:owner-tcp-impl@lerc.nasa.gov]On Behalf Of David St. Germain > Sent: Thursday, March 29, 2001 1:01 PM > To: tcp-impl@grc.nasa.gov > Subject: Re: initial window size > > > It's always been my understanding that the default initial window size is > 512K for purposes of flow control (avoiding the overflow of sender's and > receiver's buffers) and to avoid fragmentation of the TCP PDU until the > MTU - and max receive window - can be negotiated. > > > Dave. > > > > ----- Original Message ----- > From: "Bogdan Ghita" > To: "arun" > Cc: > Sent: Thursday, March 29, 2001 6:53 AM > Subject: Re: initial window size > > > > Hello arun, > > > > The purpose of a small value for TCP initial window is to limit the > > inital 'train' of packets. It is up to each TCP sender to decide the > > value, but the higher this value the higher the possibility to end up > > with a congestion, because the sender would transmit, without 'probing' > > the network, all these packets back-to-back. The main problem is usually > > not the TCP receiver not being able to cope with the data, but the path > > betwen the sender and the receiver being congested. > > This is why the initial window has, preferably, a low value > > > > Bogdan > > > > > > arun wrote: > > > > > > hi > > > Iam new to this. My doubt is this. With what criteria the intial window > for TCP is calculated and set. From the tcp code of > > > linux, I can interpret that the allowable receive buffer is set to a > value 32767. The initial window should be less than this > > > value. Can any one of u explain me why the initial window is chosen less > than 32767 and how is that calculation go. > > > > > > Thanks > > > -arun > > > > From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 16:28:41 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12035 for ; Thu, 29 Mar 2001 16:28:41 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id QAA29482; Thu, 29 Mar 2001 16:28:40 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma028472; Thu, 29 Mar 01 16:27:20 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA13595 for tcp-impl-outgoing; Thu, 29 Mar 2001 16:20:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA13528 for ; Thu, 29 Mar 2001 16:20:26 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA21011; Thu, 29 Mar 2001 16:20:24 -0500 Received: from xd84b4756.ip.ggn.net(216.75.71.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020904; Thu, 29 Mar 01 16:19:44 -0500 Received: from oleglaptop (dhcp115.inforocket.org [10.2.1.115]) by onyx.inforocket.org (8.9.3/8.9.3) with SMTP id QAA08305; Thu, 29 Mar 2001 16:19:07 -0500 From: "Oleg Vishnepolsky" To: "Martin McSweeney" Cc: "David St. Germain" , Subject: RE: initial window size Date: Thu, 29 Mar 2001 16:15:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I said "to say the least". Gush, my sense of humor failed me ... Next time I will be dead serious. Oleg Vishnepolsky -----Original Message----- From: Martin McSweeney [mailto:mmcsween@hopper.math.uwaterloo.ca] Sent: Thursday, March 29, 2001 4:14 PM To: Oleg Vishnepolsky Cc: David St. Germain; tcp-impl@grc.nasa.gov Subject: RE: initial window size Hmmm... "a bit much", isn't 512K an extremely large window given any circumstances? -martin Martin McSweeney mmcsween@styx.uwaterloo.ca On Thu, 29 Mar 2001, Oleg Vishnepolsky wrote: > 512K is a bit much for initial size, to say the least. In fact 512 bytes (not kbytes) is what is used by a lot of > tcp stacks when establishing connection with non-local hosts. 512 is really conservative IMHO. > Days when backbone MTUs were that small are gone long time ago. > For hosts on the local net, mileage varies depending on the stack. I used 8K in my stacks > (OS/2 circa 1990, FlexOS circa 93). I found that given prevalent MTUs back then of 1460, > 8k gave me best performance. > > Oleg Vishnepolsky > -----Original Message----- > From: owner-tcp-impl@lerc.nasa.gov > [mailto:owner-tcp-impl@lerc.nasa.gov]On Behalf Of David St. Germain > Sent: Thursday, March 29, 2001 1:01 PM > To: tcp-impl@grc.nasa.gov > Subject: Re: initial window size > > > It's always been my understanding that the default initial window size is > 512K for purposes of flow control (avoiding the overflow of sender's and > receiver's buffers) and to avoid fragmentation of the TCP PDU until the > MTU - and max receive window - can be negotiated. > > > Dave. > > > > ----- Original Message ----- > From: "Bogdan Ghita" > To: "arun" > Cc: > Sent: Thursday, March 29, 2001 6:53 AM > Subject: Re: initial window size > > > > Hello arun, > > > > The purpose of a small value for TCP initial window is to limit the > > inital 'train' of packets. It is up to each TCP sender to decide the > > value, but the higher this value the higher the possibility to end up > > with a congestion, because the sender would transmit, without 'probing' > > the network, all these packets back-to-back. The main problem is usually > > not the TCP receiver not being able to cope with the data, but the path > > betwen the sender and the receiver being congested. > > This is why the initial window has, preferably, a low value > > > > Bogdan > > > > > > arun wrote: > > > > > > hi > > > Iam new to this. My doubt is this. With what criteria the intial window > for TCP is calculated and set. From the tcp code of > > > linux, I can interpret that the allowable receive buffer is set to a > value 32767. The initial window should be less than this > > > value. Can any one of u explain me why the initial window is chosen less > than 32767 and how is that calculation go. > > > > > > Thanks > > > -arun > > > > From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 16:58:32 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13241 for ; Thu, 29 Mar 2001 16:58:31 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id QAA06013; Thu, 29 Mar 2001 16:58:29 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma004054; Thu, 29 Mar 01 16:56:30 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA19500 for tcp-impl-outgoing; Thu, 29 Mar 2001 16:48:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA19475 for ; Thu, 29 Mar 2001 16:48:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA25354; Thu, 29 Mar 2001 16:48:27 -0500 Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025270; Thu, 29 Mar 01 16:47:59 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2TLluJ08719 for tcp-impl@grc.nasa.gov env-from ; Thu, 29 Mar 2001 14:47:56 -0700 (MST) Date: Thu, 29 Mar 2001 14:47:56 -0700 (MST) From: Vernon Schryver Message-Id: <200103292147.f2TLluJ08719@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: RE: initial window size Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Martin McSweeney > Hmmm... "a bit much", isn't 512K an extremely large window given any > circumstances? No, it is not so very large if we are not talking about the initial window size and if you care about going fast. 512 KBytes is only 4 Mbits and a 45 Mbit/sec pipe for only 100 ms. A 5,000 mile wire has an RTT of 100 ms. from the speed of light alone. Assuming zero delay from routers or other bottlenecks, you cannot reach full speed with a window of only 512K on a 5,000 mile T3. Even in a 100 Mbit/sec local area network, a window of 512K is not very large, since 40 ms is not a lot to cover the delays added by a few routers or bridges and the scheduling and other delays in the hosts at the ends of a TCP connection. You almost certainly don't want a tiny 8K window on a 100 Mbit/sec or faster network, since 8KBytes occupies a 100 Mbit/sec wire for only 640 microseconds. There are networks that are fast that 512K might be reasonable even for an initial congestion window. For example, what is the right initial congestion window for a 10G Ethernet? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 16:58:34 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13252 for ; Thu, 29 Mar 2001 16:58:33 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id QAA06007; Thu, 29 Mar 2001 16:58:32 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma004059; Thu, 29 Mar 01 16:56:31 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA19501 for tcp-impl-outgoing; Thu, 29 Mar 2001 16:48:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA19451 for ; Thu, 29 Mar 2001 16:48:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA25325; Thu, 29 Mar 2001 16:48:26 -0500 Received: from tc058.bbn.com(128.33.238.58) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025260; Thu, 29 Mar 01 16:47:40 -0500 Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id QAA01376; Thu, 29 Mar 2001 16:46:31 -0500 Message-Id: <200103292146.QAA01376@lawyers.grc.nasa.gov> To: arun From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcp-impl@grc.nasa.gov Subject: Re: initial window size Organization: BBN Technologies/NASA GRC Song-of-the-Day: Sweet Emotion Date: Thu, 29 Mar 2001 16:46:31 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Iam new to this. My doubt is this. With what criteria the intial > window for TCP is calculated and set. From the tcp code of linux, > I can interpret that the allowable receive buffer is set to a > value 32767. The initial window should be less than this > value. Can any one of u explain me why the initial window is > chosen less than 32767 and how is that calculation go. See RFC 2581: The initial window should be 1 or 2 segments (each up to an MSS). (This document also provides the spec. for the congestion control algorithms used to increase the window size). See RFC 2414: The initial window may be 3 or 4 segments, depending on the size of the segments (basically as long as the 3 or 4 segments do not exceed 4380 bytes). 2581 is a proposed standard; 2414 is experimental. allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 17:21:53 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14346 for ; Thu, 29 Mar 2001 17:21:52 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id RAA11064; Thu, 29 Mar 2001 17:21:51 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma010452; Thu, 29 Mar 01 17:20:36 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA24203 for tcp-impl-outgoing; Thu, 29 Mar 2001 17:11:23 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA24171 for ; Thu, 29 Mar 2001 17:11:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA29012; Thu, 29 Mar 2001 17:11:19 -0500 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028985; Thu, 29 Mar 01 17:11:02 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2TMAv529916; Thu, 29 Mar 2001 14:10:57 -0800 (PST) Message-ID: <3AC3B2E8.6C59C446@isi.edu> Date: Thu, 29 Mar 2001 14:10:48 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver CC: tcp-impl@grc.nasa.gov Subject: Re: initial window size References: <200103292147.f2TLluJ08719@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > > From: Martin McSweeney > > > Hmmm... "a bit much", isn't 512K an extremely large window given any > > circumstances? > > No, it is not so very large if we are not talking about the initial window > size and if you care about going fast. > > 512 KBytes is only 4 Mbits and a 45 Mbit/sec pipe for only 100 ms. > A 5,000 mile wire has an RTT of 100 ms. from the speed of light alone. > Assuming zero delay from routers or other bottlenecks, you cannot reach > full speed with a window of only 512K on a 5,000 mile T3. > > Even in a 100 Mbit/sec local area network, a window of 512K is not very > large, since 40 ms is not a lot to cover the delays added by a few routers > or bridges and the scheduling and other delays in the hosts at the ends > of a TCP connection. > > You almost certainly don't want a tiny 8K window on a 100 Mbit/sec or > faster network, since 8KBytes occupies a 100 Mbit/sec wire for only > 640 microseconds. > > There are networks that are fast that 512K might be reasonable even > for an initial congestion window. For example, what is the right > initial congestion window for a 10G Ethernet? That might depend on whether the connection is local or not. Local connections (same subnet as an attached interface) ignore the congestion window in some TCP implementations. Joe From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 18:12:31 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16935 for ; Thu, 29 Mar 2001 18:12:30 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id SAA16972; Thu, 29 Mar 2001 18:12:30 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma016157; Thu, 29 Mar 01 18:11:25 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA00832 for tcp-impl-outgoing; Thu, 29 Mar 2001 18:02:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA00802 for ; Thu, 29 Mar 2001 18:02:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA05488; Thu, 29 Mar 2001 18:02:26 -0500 Received: from unknown(209.208.255.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005418; Thu, 29 Mar 01 18:01:46 -0500 Received: from oleglaptop ([216.75.71.92]) by polaris.inforocket.com (Netscape Messaging Server 4.15) with SMTP id GAZEC200.IJ5; Thu, 29 Mar 2001 17:55:14 -0500 From: "Oleg Vishnepolsky" To: "Vernon Schryver" , Subject: RE: initial window size Date: Thu, 29 Mar 2001 17:58:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200103292147.f2TLluJ08719@calcite.rhyolite.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Since TCP stack does not have direct knowledge of the speed, the MTU gives a good starting point. A while back the reasonable ratio was for the window to be about 6-8 times the MTU size for the local connections (slow start algorithm for non-local). Is it still the case these days ? Oleg Vishnepolsky -----Original Message----- From: owner-tcp-impl@lerc.nasa.gov [mailto:owner-tcp-impl@lerc.nasa.gov]On Behalf Of Vernon Schryver Sent: Thursday, March 29, 2001 4:48 PM To: tcp-impl@grc.nasa.gov Subject: RE: initial window size Even in a 100 Mbit/sec local area network, a window of 512K is not very large, since 40 ms is not a lot to cover the delays added by a few routers or bridges and the scheduling and other delays in the hosts at the ends of a TCP connection. You almost certainly don't want a tiny 8K window on a 100 Mbit/sec or faster network, since 8KBytes occupies a 100 Mbit/sec wire for only 640 microseconds. There are networks that are fast that 512K might be reasonable even for an initial congestion window. For example, what is the right initial congestion window for a 10G Ethernet? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 18:18:07 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17194 for ; Thu, 29 Mar 2001 18:18:06 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id SAA19970; Thu, 29 Mar 2001 18:18:05 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma018919; Thu, 29 Mar 01 18:16:36 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA01580 for tcp-impl-outgoing; Thu, 29 Mar 2001 18:09:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA01551 for ; Thu, 29 Mar 2001 18:09:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA06383; Thu, 29 Mar 2001 18:09:31 -0500 Received: from ds-img-rel-1.compuserve.com(149.174.206.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006329; Thu, 29 Mar 01 18:09:23 -0500 Received: (from mailgate@localhost) by spdmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id SAA18009 for tcp-impl@grc.nasa.gov; Thu, 29 Mar 2001 18:09:22 -0500 (EST) Received: from RedCross (hil-qbu-ppu-vty35.as.wcom.net [209.154.55.35]) by spdmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with SMTP id SAA17893 for ; Thu, 29 Mar 2001 18:09:08 -0500 (EST) Message-ID: <001c01c0b8a5$412c22a0$23379ad1@crans1.ri.home.com> Reply-To: "David St. Germain" From: "David St. Germain" To: References: Subject: Re: initial window size Date: Thu, 29 Mar 2001 18:09:04 -0500 Organization: St. Germain Consulting Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit You are quite right of course, I meant 512 is what most OS's default to. Dave. ----- Original Message ----- From: "Oleg Vishnepolsky" To: "David St. Germain" ; Sent: Thursday, March 29, 2001 3:51 PM Subject: RE: initial window size > 512K is a bit much for initial size, to say the least. In fact 512 bytes (not kbytes) is what is used by a lot of > tcp stacks when establishing connection with non-local hosts. 512 is really conservative IMHO. > Days when backbone MTUs were that small are gone long time ago. > For hosts on the local net, mileage varies depending on the stack. I used 8K in my stacks > (OS/2 circa 1990, FlexOS circa 93). I found that given prevalent MTUs back then of 1460, > 8k gave me best performance. > > Oleg Vishnepolsky > -----Original Message----- > From: owner-tcp-impl@lerc.nasa.gov > [mailto:owner-tcp-impl@lerc.nasa.gov]On Behalf Of David St. Germain > Sent: Thursday, March 29, 2001 1:01 PM > To: tcp-impl@grc.nasa.gov > Subject: Re: initial window size > > > It's always been my understanding that the default initial window size is > 512K for purposes of flow control (avoiding the overflow of sender's and > receiver's buffers) and to avoid fragmentation of the TCP PDU until the > MTU - and max receive window - can be negotiated. > > > Dave. > > > > ----- Original Message ----- > From: "Bogdan Ghita" > To: "arun" > Cc: > Sent: Thursday, March 29, 2001 6:53 AM > Subject: Re: initial window size > > > > Hello arun, > > > > The purpose of a small value for TCP initial window is to limit the > > inital 'train' of packets. It is up to each TCP sender to decide the > > value, but the higher this value the higher the possibility to end up > > with a congestion, because the sender would transmit, without 'probing' > > the network, all these packets back-to-back. The main problem is usually > > not the TCP receiver not being able to cope with the data, but the path > > betwen the sender and the receiver being congested. > > This is why the initial window has, preferably, a low value > > > > Bogdan > > > > > > arun wrote: > > > > > > hi > > > Iam new to this. My doubt is this. With what criteria the intial window > for TCP is calculated and set. From the tcp code of > > > linux, I can interpret that the allowable receive buffer is set to a > value 32767. The initial window should be less than this > > > value. Can any one of u explain me why the initial window is chosen less > than 32767 and how is that calculation go. > > > > > > Thanks > > > -arun > > > > From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 18:38:30 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18191 for ; Thu, 29 Mar 2001 18:38:28 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id SAA25306; Thu, 29 Mar 2001 18:38:27 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma022517; Thu, 29 Mar 01 18:35:00 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03678 for tcp-impl-outgoing; Thu, 29 Mar 2001 18:27:02 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA03658 for ; Thu, 29 Mar 2001 18:27:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA08670; Thu, 29 Mar 2001 18:26:59 -0500 Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008630; Thu, 29 Mar 01 18:26:38 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2TNQaH10763 for tcp-impl@grc.nasa.gov env-from ; Thu, 29 Mar 2001 16:26:36 -0700 (MST) Date: Thu, 29 Mar 2001 16:26:36 -0700 (MST) From: Vernon Schryver Message-Id: <200103292326.f2TNQaH10763@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: RE: initial window size Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "Oleg Vishnepolsky" > Since TCP stack does not have direct knowledge of the speed As Joe Touch implied, that may be often true, but it is not always true. > the MTU gives a good starting point. I don't see what the MTU has to do with link speed. Yes, I know by heart a bunch of MTU's for various links, but ... > A while back the reasonable ratio was for the window to be about 6-8 times the MTU size for the > local connections (slow start algorithm for non-local). > Is it still the case these days ? I doubt it was ever true that 6-8 times the interface MTU was the right window size. TCP stacks I've touched have not used anything that tiny since the mid-1980's, when I jacked up one UNIX vendor's default windows size to 30K, and that was partly because 32K or more hit sign-bit bugs in some other vendors' systems. At the time, my UNIX employer had real support for only 10 MHz Ethernet. Disclaimer: my definition of "right" has long been tainted by "goes fastest according to various benchmarks." Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 18:40:10 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18192 for ; Thu, 29 Mar 2001 18:38:28 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id SAA25309; Thu, 29 Mar 2001 18:38:27 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma022518; Thu, 29 Mar 01 18:35:00 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03685 for tcp-impl-outgoing; Thu, 29 Mar 2001 18:27:03 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA03663 for ; Thu, 29 Mar 2001 18:27:01 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA08654; Thu, 29 Mar 2001 18:26:59 -0500 Received: from ds-img-rel-1.compuserve.com(149.174.206.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008624; Thu, 29 Mar 01 18:26:25 -0500 Received: (from mailgate@localhost) by spdmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id SAA27310 for tcp-impl@grc.nasa.gov; Thu, 29 Mar 2001 18:26:25 -0500 (EST) Received: from RedCross (hil-qbu-ppu-vty35.as.wcom.net [209.154.55.35]) by spdmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with SMTP id SAA27246 for ; Thu, 29 Mar 2001 18:26:16 -0500 (EST) Message-ID: <007901c0b8a7$a169f960$23379ad1@crans1.ri.home.com> Reply-To: "David St. Germain" From: "David St. Germain" To: References: <200103292147.f2TLluJ08719@calcite.rhyolite.com> <3AC3B2E8.6C59C446@isi.edu> Subject: Re: initial window size Date: Thu, 29 Mar 2001 18:26:05 -0500 Organization: St. Germain Consulting Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Although I agree with you that this is how one would tweak the window size, the OS still has to default to something. With Windows NT 4.0, I know the default upon installation is 512 (I just recently saw that statistic), I'm not sure what the other OS's default to upon installation, but I believe the original RFC recommendation was to start with a default of 512 and use the slow start algorithm to ramp up. Dave. ----- Original Message ----- From: "Joe Touch" To: "Vernon Schryver" Cc: Sent: Thursday, March 29, 2001 5:10 PM Subject: Re: initial window size > > > Vernon Schryver wrote: > > > > > From: Martin McSweeney > > > > > Hmmm... "a bit much", isn't 512K an extremely large window given any > > > circumstances? > > > > No, it is not so very large if we are not talking about the initial window > > size and if you care about going fast. > > > > 512 KBytes is only 4 Mbits and a 45 Mbit/sec pipe for only 100 ms. > > A 5,000 mile wire has an RTT of 100 ms. from the speed of light alone. > > Assuming zero delay from routers or other bottlenecks, you cannot reach > > full speed with a window of only 512K on a 5,000 mile T3. > > > > Even in a 100 Mbit/sec local area network, a window of 512K is not very > > large, since 40 ms is not a lot to cover the delays added by a few routers > > or bridges and the scheduling and other delays in the hosts at the ends > > of a TCP connection. > > > > You almost certainly don't want a tiny 8K window on a 100 Mbit/sec or > > faster network, since 8KBytes occupies a 100 Mbit/sec wire for only > > 640 microseconds. > > > > There are networks that are fast that 512K might be reasonable even > > for an initial congestion window. For example, what is the right > > initial congestion window for a 10G Ethernet? > > That might depend on whether the connection is local or not. Local > connections (same subnet as an attached interface) ignore the congestion > window in some TCP implementations. > > Joe > From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 19:01:53 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19372 for ; Thu, 29 Mar 2001 19:01:53 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id TAA29599; Thu, 29 Mar 2001 19:01:50 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma028754; Thu, 29 Mar 01 19:00:03 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA07879 for tcp-impl-outgoing; Thu, 29 Mar 2001 18:52:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA07862 for ; Thu, 29 Mar 2001 18:52:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA11951; Thu, 29 Mar 2001 18:52:38 -0500 Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011925; Thu, 29 Mar 01 18:51:56 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2TNprZ11283 env-from ; Thu, 29 Mar 2001 16:51:53 -0700 (MST) Date: Thu, 29 Mar 2001 16:51:53 -0700 (MST) From: Vernon Schryver Message-Id: <200103292351.f2TNprZ11283@calcite.rhyolite.com> To: David@StGermain.com, tcp-impl@grc.nasa.gov Subject: Re: initial window size Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "David St. Germain" > Although I agree with you that this is how one would tweak the window size, > the OS still has to default to something. With Windows NT 4.0, I know the > default upon installation is 512 (I just recently saw that statistic), I'm > not sure what the other OS's default to upon installation, but I believe the > original RFC recommendation was to start with a default of 512 and use the > slow start algorithm to ramp up. Please consider the difference between initial congestion window size and window size. One of the biggest differences is that one is used by the sender and the other is used by the receiver. Please also consider RFC 2414. In other words, I doubt that even NT 4.0 had a default window size of 512, although I wouldn't be surprised if NT 4.0 used a initial congestion window of 1 segment. Isn't the NT 4.0 initial window size controled by the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize value? http://www.winguides.com/registry/display.php/268/ claims the default is 8760, which is about what I vaguely recall seeing in the registries of a few Windows boxes. My recollections put the parameter in a slightly different registry "hive," "path," or whatever, but I'm probably wrong. Stevens' "TCP/IP Illustrated Volume 1" has a good description of what might be meant by "use the slow start algorithm to ramp up," athough it is to instead of from the configured or default TCP window size. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 19:40:59 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21333 for ; Thu, 29 Mar 2001 19:40:58 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id TAA04174; Thu, 29 Mar 2001 19:40:56 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma003857; Thu, 29 Mar 01 19:40:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA11400 for tcp-impl-outgoing; Thu, 29 Mar 2001 19:30:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA11361 for ; Thu, 29 Mar 2001 19:30:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA16124; Thu, 29 Mar 2001 19:30:06 -0500 Received: from unknown(209.208.255.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016051; Thu, 29 Mar 01 19:29:43 -0500 Received: from oleglaptop ([216.75.71.92]) by polaris.inforocket.com (Netscape Messaging Server 4.15) with SMTP id GAZIEU00.BJ4; Thu, 29 Mar 2001 19:23:18 -0500 From: "Oleg Vishnepolsky" To: "Vernon Schryver" , Subject: RE: initial window size Date: Thu, 29 Mar 2001 19:26:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200103292326.f2TNQaH10763@calcite.rhyolite.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The stack has to determine the initial window size, and all it has is the address of the other host, and MSS derived from MTU. Practically speaking, most stacks use a hard-wired default (32k or 8k or whatever). They could a better job taking MSS into account. To your other point, MTU definitely has to do with the speed and memory on the adaptor. That's why you will see higher MTUs with higher speeds. As far as 6-8 times the MTU being from mid 80s is not correct either. In fact, BSD 4.3 Reno had 2k windows for local communications, which is even less than that ratio. 6-8 figure is based on my own experiments and measurements done in the early 90s. -----Original Message----- From: owner-tcp-impl@lerc.nasa.gov [mailto:owner-tcp-impl@lerc.nasa.gov]On Behalf Of Vernon Schryver Sent: Thursday, March 29, 2001 6:27 PM To: tcp-impl@grc.nasa.gov Subject: RE: initial window size > From: "Oleg Vishnepolsky" > Since TCP stack does not have direct knowledge of the speed As Joe Touch implied, that may be often true, but it is not always true. > the MTU gives a good starting point. I don't see what the MTU has to do with link speed. Yes, I know by heart a bunch of MTU's for various links, but ... > A while back the reasonable ratio was for the window to be about 6-8 times the MTU size for the > local connections (slow start algorithm for non-local). > Is it still the case these days ? I doubt it was ever true that 6-8 times the interface MTU was the right window size. TCP stacks I've touched have not used anything that tiny since the mid-1980's, when I jacked up one UNIX vendor's default windows size to 30K, and that was partly because 32K or more hit sign-bit bugs in some other vendors' systems. At the time, my UNIX employer had real support for only 10 MHz Ethernet. Disclaimer: my definition of "right" has long been tainted by "goes fastest according to various benchmarks." Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 20:10:28 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22564 for ; Thu, 29 Mar 2001 20:10:28 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id UAA08137; Thu, 29 Mar 2001 20:10:25 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma007549; Thu, 29 Mar 01 20:09:39 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA16811 for tcp-impl-outgoing; Thu, 29 Mar 2001 20:01:38 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA16797 for ; Thu, 29 Mar 2001 20:01:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA19701; Thu, 29 Mar 2001 20:01:35 -0500 Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019681; Thu, 29 Mar 01 20:01:26 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2U11PK13483 for tcp-impl@grc.nasa.gov env-from ; Thu, 29 Mar 2001 18:01:25 -0700 (MST) Date: Thu, 29 Mar 2001 18:01:25 -0700 (MST) From: Vernon Schryver Message-Id: <200103300101.f2U11PK13483@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: RE: initial window size Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "Oleg Vishnepolsky" > The stack has to determine the initial window size, and all it > has is the address of the other host, and MSS derived from MTU. On the contrary, "the stack" is just code. BSD-style code could follow the if pointers to find the interface speed as easily as it now finds the interface MTU to generate the MSS option. > Practically speaking, most stacks use a hard-wired default (32k > or 8k or whatever). They could a better job taking MSS into account. agreed. > To your other point, MTU definitely has to do with the speed > and memory on the adaptor. That's why > you will see higher MTUs with higher speeds. It is true that as the years have passed, media have become faster as MTU's generally have grown longer. However, Ethernet is a rather important counter example. > As far as 6-8 times the MTU being from mid 80s is not correct either. > In fact, BSD 4.3 Reno had 2k windows > for local communications, which is even less than that ratio. > 6-8 figure is based on my own experiments and measurements done > in the early 90s. So in about 1986 I did not change the default TCP window shipped by one of the major commercial UNIX vendors to 30K? And in about 1988 I didn't change it to 60K? That's interesting, because I didn't think I'd become so senile that I'd invent such recollections. (Note that I don't mean that I changed it from the default that someone at the factory set. I mean that according to those false recollections of mine, I was that someone at the factory.) Yes, as a reasult of my enthusiasm for better`ttcp` numbers to give to my employer's sales people (and my own bosses), I also saw some bug reports of interoperability problems. Some were related to bugs in other vendors' systems uncovered by large mismatches in window sizes. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 22:33:40 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03884 for ; Thu, 29 Mar 2001 22:33:39 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id WAA18198; Thu, 29 Mar 2001 22:33:38 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma018067; Thu, 29 Mar 01 22:33:22 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA26247 for tcp-impl-outgoing; Thu, 29 Mar 2001 22:13:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA26238 for ; Thu, 29 Mar 2001 22:13:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA02325; Thu, 29 Mar 2001 22:13:41 -0500 Received: from unknown(203.199.199.225) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002300; Thu, 29 Mar 01 22:12:51 -0500 Received: from netlab.hcltech.com (arun [192.168.201.67]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id IAA18659; Fri, 30 Mar 2001 08:54:30 +0530 Message-ID: <3AC3F9C1.7423592C@netlab.hcltech.com> Date: Fri, 30 Mar 2001 08:43:05 +0530 From: arun X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver CC: tcp-impl@grc.nasa.gov Subject: Re: initial window size References: <200103300101.f2U11PK13483@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit wow! that was a nice discussion. I got cleared up with many of my doubts. But whatever discussion which went about this is abou the Congestion window (cwnd). But my basic doubt is the selection of the send window ( snd.wnd) or in other terms it is the peer's receive window which is advertised to the sender . Selecting this receive window might be implementation dependent , but I like to know what will be criteria and what all parameters affect this selection. I hope atleast this time Iam clear .. Thanks -arun Vernon Schryver wrote: > > From: "Oleg Vishnepolsky" > > > The stack has to determine the initial window size, and all it > > has is the address of the other host, and MSS derived from MTU. > > On the contrary, "the stack" is just code. BSD-style code could > follow the if pointers to find the interface speed as easily > as it now finds the interface MTU to generate the MSS option. > > > Practically speaking, most stacks use a hard-wired default (32k > > or 8k or whatever). They could a better job taking MSS into account. > > agreed. > > > To your other point, MTU definitely has to do with the speed > > and memory on the adaptor. That's why > > you will see higher MTUs with higher speeds. > > It is true that as the years have passed, media have become faster > as MTU's generally have grown longer. However, Ethernet is a rather > important counter example. > > > As far as 6-8 times the MTU being from mid 80s is not correct either. > > In fact, BSD 4.3 Reno had 2k windows > > for local communications, which is even less than that ratio. > > 6-8 figure is based on my own experiments and measurements done > > in the early 90s. > > So in about 1986 I did not change the default TCP window shipped by one of > the major commercial UNIX vendors to 30K? And in about 1988 I didn't > change it to 60K? That's interesting, because I didn't think I'd become > so senile that I'd invent such recollections. (Note that I don't mean > that I changed it from the default that someone at the factory set. I > mean that according to those false recollections of mine, I was that > someone at the factory.) > > Yes, as a reasult of my enthusiasm for better`ttcp` numbers to give to my > employer's sales people (and my own bosses), I also saw some bug reports > of interoperability problems. Some were related to bugs in other vendors' > systems uncovered by large mismatches in window sizes. > > Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 29 22:56:39 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07266 for ; Thu, 29 Mar 2001 22:56:38 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id WAA21704; Thu, 29 Mar 2001 22:56:37 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma021527; Thu, 29 Mar 01 22:56:07 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA28897 for tcp-impl-outgoing; Thu, 29 Mar 2001 22:46:03 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA28890 for ; Thu, 29 Mar 2001 22:46:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA05620; Thu, 29 Mar 2001 22:46:01 -0500 Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005595; Thu, 29 Mar 01 22:45:26 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2U3jOP16512 for tcp-impl@grc.nasa.gov env-from ; Thu, 29 Mar 2001 20:45:24 -0700 (MST) Date: Thu, 29 Mar 2001 20:45:24 -0700 (MST) From: Vernon Schryver Message-Id: <200103300345.f2U3jOP16512@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: initial window size Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: arun > wow! that was a nice discussion. I got cleared up with many of my doubts. > But whatever discussion which went about this is abou the Congestion window > (cwnd). But my basic doubt is the selection of the send window ( snd.wnd) or > in other terms it is the peer's receive window which is advertised to the > sender . Selecting this receive window might be implementation dependent , but > I like to know what will be criteria and what all parameters affect this > selection. I hope atleast this time Iam clear .. "All of the parameters" covering the initial send or congestion window cover a lot of ground. Didn't someone else point out RFC 2414? What about RFC 2416? RFC 2001 says "initialization for a given connection sets cwnd to one segment." If they're not clear, then about what looking for the string snd_cwnd in the files netinet/tcp_output.c and netinet/tcp_input.c in the nearest stash of BSD kernel source? The NetBSD and FreeBSD source can be found on the net, at URL's like http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/netinet/ Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Fri Mar 30 09:01:48 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15858 for ; Fri, 30 Mar 2001 09:01:47 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id JAA01504; Fri, 30 Mar 2001 09:01:44 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma000411; Fri, 30 Mar 01 09:00:54 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA12570 for tcp-impl-outgoing; Fri, 30 Mar 2001 08:49:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA12523; Fri, 30 Mar 2001 08:49:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA27296; Fri, 30 Mar 2001 08:49:16 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027264; Fri, 30 Mar 01 08:48:31 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14izGN-00065R-00; Fri, 30 Mar 2001 14:48:27 +0100 Date: Fri, 30 Mar 2001 14:48:27 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Mark Allman cc: arun , tcp-impl@grc.nasa.gov Subject: Re: initial window size In-Reply-To: <200103292146.QAA01376@lawyers.grc.nasa.gov> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *14izGN-00065R-00*xi4cWBZNx3s* Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Thu, 29 Mar 2001, Mark Allman wrote: > See RFC 2581: > > The initial window should be 1 or 2 segments (each up to an > MSS). (This document also provides the spec. for the congestion > control algorithms used to increase the window size). > > See RFC 2414: > > The initial window may be 3 or 4 segments, depending on the size > of the segments (basically as long as the 3 or 4 segments do not > exceed 4380 bytes). > > 2581 is a proposed standard; 2414 is experimental. Am I right in thinking that we can blame the existence of this on: a. the MTU of edge system (good old ethernet) not scaling upward? b. TCP's back-to-back busrtiness behaviour? Fix either one of those, and an initial window of more than one segment looks less compelling. L. PGP From owner-tcp-impl@lerc.nasa.gov Fri Mar 30 09:32:20 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17376 for ; Fri, 30 Mar 2001 09:32:19 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id JAA09094; Fri, 30 Mar 2001 09:32:17 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma006593; Fri, 30 Mar 01 09:29:07 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA18912 for tcp-impl-outgoing; Fri, 30 Mar 2001 09:19:01 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA18904; Fri, 30 Mar 2001 09:18:59 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA13874; Fri, 30 Mar 2001 09:19:42 -0500 (EST) Message-Id: <200103301419.JAA13874@guns.lerc.nasa.gov> To: L.Wood@eim.surrey.ac.uk From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: arun , tcp-impl@grc.nasa.gov Subject: Re: initial window size Organization: BBN Technologies/NASA GRC Song-of-the-Day: Eight Days a Week Date: Fri, 30 Mar 2001 09:19:42 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Am I right in thinking that we can blame the existence of this on: > a. the MTU of edge system (good old ethernet) not scaling upward? > b. TCP's back-to-back busrtiness behaviour? > > Fix either one of those, and an initial window of more than one > segment looks less compelling. I do not follow. See RFC 2414 for (what I believe are) a number of good reasons to use an initial cwnd of more than 1 segment. allman From owner-tcp-impl@lerc.nasa.gov Fri Mar 30 09:32:43 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17397 for ; Fri, 30 Mar 2001 09:32:43 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id JAA09001; Fri, 30 Mar 2001 09:32:40 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma006551; Fri, 30 Mar 01 09:29:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA18880 for tcp-impl-outgoing; Fri, 30 Mar 2001 09:18:54 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA18853; Fri, 30 Mar 2001 09:18:49 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA13867; Fri, 30 Mar 2001 09:19:32 -0500 (EST) Message-Id: <200103301419.JAA13867@guns.lerc.nasa.gov> To: "Oleg Vishnepolsky" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "Vernon Schryver" , tcp-impl@grc.nasa.gov Subject: Re: initial window size Organization: BBN Technologies/NASA GRC Song-of-the-Day: Eight Days a Week Date: Fri, 30 Mar 2001 09:19:32 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A couple of comments.... Oleg Vishnapolsky said: > > Practically speaking, most stacks use a hard-wired default (32k or > 8k or whatever). Yep. In a study of our web server traffic last year we found that the median advertised window size was roughly 8KB and the average was about 18KB in web clients. These numbers were essentially invariant over the 18 months of data we examined (I really should crunch the data since the paper, but haven't found the cycles yet). Further, for transfers that sent enough data to open their cwnd to the advertised window we found that 70% were likely performance limited by the advertised window. So, I agree with Vernon -- crank those default socket buffers up (or, use something like autotuned socket buffers). More details in: Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000. http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps Vernon Schryver said: > > RFC 2001 says "initialization for a given connection sets cwnd to > one segment." RFC 2001 is obsoleted by RFC 2581 -- which allows an initial congestion window of up to 2 segments (up to MSS bytes in each). Sally Floyd and Jitu Padhye have been using tbit to determine what initial cwnd web servers are really using. You can see their results at: http://www.aciri.org/tbit/ allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Fri Mar 30 09:58:58 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18948 for ; Fri, 30 Mar 2001 09:58:57 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id JAA15427; Fri, 30 Mar 2001 09:58:54 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma014192; Fri, 30 Mar 01 09:57:11 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA25691 for tcp-impl-outgoing; Fri, 30 Mar 2001 09:47:02 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA25665; Fri, 30 Mar 2001 09:46:59 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA06095; Fri, 30 Mar 2001 09:46:57 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006052; Fri, 30 Mar 01 09:46:40 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14j0Ad-0007St-00; Fri, 30 Mar 2001 15:46:35 +0100 Date: Fri, 30 Mar 2001 15:46:35 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Mark Allman cc: arun , tcp-impl@grc.nasa.gov Subject: Re: initial window size In-Reply-To: <200103301419.JAA13874@guns.lerc.nasa.gov> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *14j0Ad-0007St-00*X3nbFbBRonc* Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Fri, 30 Mar 2001, Mark Allman wrote: > > Am I right in thinking that we can blame the existence of this on: > > a. the MTU of edge system (good old ethernet) not scaling upward? > > b. TCP's back-to-back busrtiness behaviour? > > > > Fix either one of those, and an initial window of more than one > > segment looks less compelling. > > I do not follow. See RFC 2414 for (what I believe are) a number of > good reasons to use an initial cwnd of more than 1 segment. (section 3) Those reasons are related to the (legacy, dammit!) TCP implementation. 1. is, I think, basically a problem with delayed-ack implementations, which should ack the first packet immediately before going into delay. (I'd guess that paced TCP should make the effects of delayed acks less desirable; acking the first packet strikes me as a good idea regardless.) 2. is made moot by a larger MTU on edge systems leading to larger path MTU throughout. 3. as for 1., and the effect on slow-start should be ameliorated by byte-counting. Sections 4 and 5 list the disadvantages of larger initial cwnd - it's harder to encounter unnecessary retransmits when it's only 1 segment. L. PGP From owner-tcp-impl@lerc.nasa.gov Fri Mar 30 10:18:47 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20085 for ; Fri, 30 Mar 2001 10:18:46 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id KAA20815; Fri, 30 Mar 2001 10:18:43 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma019269; Fri, 30 Mar 01 10:17:01 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA00079 for tcp-impl-outgoing; Fri, 30 Mar 2001 10:06:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA00019 for ; Fri, 30 Mar 2001 10:06:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA09168; Fri, 30 Mar 2001 10:06:36 -0500 Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009119; Fri, 30 Mar 01 10:05:40 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2UF5cK27535 for tcp-impl@grc.nasa.gov env-from ; Fri, 30 Mar 2001 08:05:38 -0700 (MST) Date: Fri, 30 Mar 2001 08:05:38 -0700 (MST) From: Vernon Schryver Message-Id: <200103301505.f2UF5cK27535@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: initial window size Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Lloyd Wood > ... > Am I right in thinking that we can blame the existence of this on: > a. the MTU of edge system (good old ethernet) not scaling upward? > b. TCP's back-to-back busrtiness behaviour? > > Fix either one of those, and an initial window of more than one > segment looks less compelling. The 1500 byte MTU of Ethernet has worse consequences than anything mentioned in RFC 2414, but has nevertheless resisted fixing. According to a trade rag I saw this week, Ethernet claims 90% of the LAN market, which sounds low to me. The consequences I mean can be seen with your favorite TCP benchmark, a pair of computers, and a LAN medium that is faster than the computers and has an MTU of at least 4500. (By "faster" I mean that the computers cannot saturate it with a single TCP stream.) Vary the MTU used by the computers from 1000 through the medium's maximum while measuring single stream TCP through-put. Notice that the local peaks ans valleys that correspond to various things in your computers, but also notice that throughput increases linearly or faster with MTU. Or equivalently, somehow measure total CPU cycles/byte on a fast pair of computers. Or look at router performance advertisments in the trade rags and notice that the honest ones are in packets/second. In other words, the 1500 byte Ethernet MTU makes bridging among 10, 100, and 100 MHz Ethernet easy, but it does terrible things to performance. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Fri Mar 30 10:21:20 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20195 for ; Fri, 30 Mar 2001 10:21:15 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id KAA22534; Fri, 30 Mar 2001 10:21:13 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma019656; Fri, 30 Mar 01 10:17:37 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA00707 for tcp-impl-outgoing; Fri, 30 Mar 2001 10:08:58 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA00693; Fri, 30 Mar 2001 10:08:57 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA15909; Fri, 30 Mar 2001 10:09:39 -0500 (EST) Message-Id: <200103301509.KAA15909@guns.lerc.nasa.gov> To: L.Wood@eim.surrey.ac.uk From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: arun , tcp-impl@grc.nasa.gov Subject: Re: initial window size Organization: BBN Technologies/NASA GRC Song-of-the-Day: Eight Days a Week Date: Fri, 30 Mar 2001 10:09:39 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk OK. I am getting your points, now... > 1. is, I think, basically a problem with delayed-ack > implementations, which should ack the first packet immediately > before going into delay. (I'd guess that paced TCP should make > the effects of delayed acks less desirable; acking the first > packet strikes me as a good idea regardless.) So, you're trading one hack for another. Fine. > 2. is made moot by a larger MTU on edge systems leading to larger > path MTU throughout. I'll buy that. > 3. as for 1., and the effect on slow-start should be ameliorated > by byte-counting. But, byte counting+larger initial window is better yet. They are orthogonal, I think. One more note that was not true when 2414 was written... With limited transmit, using an initial window of more than one segment makes loss recovery more robust and less reliant on the RTO. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Sat Mar 31 02:41:46 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07326 for ; Sat, 31 Mar 2001 02:41:45 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id CAA06004; Sat, 31 Mar 2001 02:41:44 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma005184; Sat, 31 Mar 01 02:40:49 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA24263 for tcp-impl-outgoing; Sat, 31 Mar 2001 02:15:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA24257 for ; Sat, 31 Mar 2001 02:15:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA25493; Sat, 31 Mar 2001 02:15:03 -0500 Received: from f258.law7.hotmail.com(216.33.236.136) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025487; Sat, 31 Mar 01 02:15:03 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 Mar 2001 23:15:01 -0800 Received: from 172.146.168.199 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 31 Mar 2001 07:15:01 GMT X-Originating-IP: [172.146.168.199] From: "Moncef Boualem" To: tcp-impl@lerc.nasa.gov Subject: LOST CONNECTION Date: Sat, 31 Mar 2001 02:15:01 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Mar 2001 07:15:01.0885 (UTC) FILETIME=[4D5112D0:01C0B9B2] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hi folks, An ftp transfer between an NT client and a Sun Solaris server results in a sudden "LOST CONNECTION" message on the server side. It all happens after the NT machine initiates the FTP connection and starts uploading PDF files into the server. Then after several successful transfers the connection gets cut. The link between the two machines is: ethernet-t1-ethernet. Is there anything to tune up in the TCP stack? thanks. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-tcp-impl@lerc.nasa.gov Sat Mar 31 20:33:28 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08544 for ; Sat, 31 Mar 2001 20:33:27 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id UAA02414; Sat, 31 Mar 2001 20:33:26 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma001574; Sat, 31 Mar 01 20:32:13 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA05296 for tcp-impl-outgoing; Sat, 31 Mar 2001 20:11:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA05284 for ; Sat, 31 Mar 2001 20:11:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA07116; Sat, 31 Mar 2001 20:11:10 -0500 Received: from 50-209.235.22.dellhost.com(209.235.22.50) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007092; Sat, 31 Mar 01 20:10:23 -0500 Received: from hal [24.240.187.186] by atlmail3.sagenetworks.com (SMTPD32-6.05) id A01E8F80144; Sat, 31 Mar 2001 20:10:54 -0500 Message-ID: <001401c0ba48$9e296ae0$babbf018@hal> From: "Hal F. Gottfried" To: "Moncef Boualem" , References: Subject: Re: LOST CONNECTION Date: Sat, 31 Mar 2001 20:11:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Does this only happen with PDF files or with other files as well ? Can you see what is happening on the Sun machine ? What version of Solaris is it running ? Hal F. Gottfried ProTech Training and Technical Services ----- Original Message ----- From: "Moncef Boualem" To: Sent: Saturday, March 31, 2001 2:15 AM Subject: LOST CONNECTION > Hi folks, > An ftp transfer between an NT client and a Sun Solaris server > results in a sudden "LOST CONNECTION" message on the server side. > It all happens after the NT machine initiates the FTP connection and > starts uploading PDF files into the server. Then after several successful > transfers the connection gets cut. The link between the > two machines is: ethernet-t1-ethernet. Is there anything to > tune up in the TCP stack? thanks. > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > >