From owner-tcp-impl@grc.nasa.gov Fri Feb 1 07:25:46 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19997 for ; Fri, 1 Feb 2002 07:25:46 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 28B9BC6957 for ; Fri, 1 Feb 2002 07:25:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA26832 for tcp-impl-outgoing; Fri, 1 Feb 2002 07:11:09 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA24919; Fri, 1 Feb 2002 06:56:13 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA24364; Fri, 1 Feb 2002 06:56:13 -0500 (EST) Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 41A7E640CA; Fri, 1 Feb 2002 06:56:12 -0500 (EST) Received: from dttconsulting.demon.co.uk ([158.152.95.189] helo=roger1) by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1) id 16WbME-000Ik7-0B; Fri, 1 Feb 2002 10:55:51 +0000 Reply-To: From: "Roger Stanyard" To: "Satellite Industry Contacts" Subject: Satcoms Insider Date: Fri, 1 Feb 2002 11:05:42 -0000 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 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleague, You may be aware that we publish the trade newsletter Satcoms Insider. Chris Forrester, editor of Interspace and one of the best satellite journalists in Europe, is now contributing to it. From time to time we offer a free three issue trial subscription, delivered in PDF form by email. The trial offer allows would be subscribers to get to know the product which specialises in provided news, analysis and market research in satellite communications with particular emphasis on IP, digital broadcasting, broadband access and convergence. Satcoms Insider offers a combination of market research and business analysis. Its coverage is global but with a European perspective. If you would like to take advantage of the free trial offer all you need do is email me at interspace@enterprise.net. I would like to make it clear that there as no obligations if you do so. However, at the end of the trial we will offer you a subscription at a 10% discount on the regular rate of US$995. We also offer a very competitive site licence. Best Regards Roger Stanyard From owner-tcp-impl@grc.nasa.gov Sun Feb 3 14:22:54 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29067 for ; Sun, 3 Feb 2002 14:22:54 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 91ADBC6976 for ; Sun, 3 Feb 2002 14:22:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA22703 for tcp-impl-outgoing; Sun, 3 Feb 2002 14:03:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA22693 for ; Sun, 3 Feb 2002 14:03:20 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA09042 for ; Sun, 3 Feb 2002 14:03:19 -0500 (EST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4DC1F64099 for ; Sun, 3 Feb 2002 13:59:35 -0500 (EST) Received: from yasmine.ece.arizona.edu (yasmine [128.196.28.123]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g13IxU3S025527 for ; Sun, 3 Feb 2002 11:59:34 -0700 (MST) Received: (from krunz@localhost) by yasmine.ece.arizona.edu (8.10.2+Sun/8.10.2) id g13J2nW08999 for tcp-impl@lerc.nasa.gov; Sun, 3 Feb 2002 12:02:49 -0700 (MST) Date: Sun, 3 Feb 2002 12:02:49 -0700 (MST) Message-Id: <200202031902.g13J2nW08999@yasmine.ece.arizona.edu> From: krunz@ece.arizona.edu To: tcp-impl@lerc.nasa.gov Subject: Mobicom 2002 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk [Sorry if you receive duplicates of this message] Colleagues, Note that the deadline for Mobicom 2002 is less than one month away. Please find enclosed an updated CFP. M. Krunz ********************************************************************* Call for Papers *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Submission Deadline: March 1, 2002 ********************************************************************* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: - No longer than 12 pages (double column); in font no smaller than 10 points - Fit properly on US Letter-sized paper (8.5 ' 11 inches) with reasonable margins - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier,Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: * Paper submissions due: March 1, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu EXECUTIVE COMMITTEE: -------------------- * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Mercury Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Co-Chairs: - Suresh Singh, Portland State University - Robin Kravets, University of Illinois, Urbana-Champaign * Student Poster Co-Chairs: - Elizabeth M. Belding-Royer, University of California, Santa Barbara - Sung-Ju Lee, HP Laboratories * Student Travel Award Co-Chairs: - Yuguang Fang, University of Florida - Violet R. Syrotiuk, University of Texas at Dallas * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Webmaster: Michael E. Kounavis, Columbia University PROGRAM COMMITTEE: -------------------- Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University Program Committee: - Arup Acharya, IBM Research - Prathima Agrawal, Telcordia - B. R. Badrinath, Rutgers University - Victor Bahl, Microsoft Research - Stefano Basagni, Northeastern University - Roberto Battiti, University of Trento - Pravin Bhagwat, ReefEdge - Scott Corson, Flarion - Sajal Das, University Texas at Arlington - Nigel Davies, Lancaster University - Dan Duchamp, Stevens Institute of Technology - Maria Ebling, IBM Research - Magda El-Zarki, University of California, Irvine - Anthony Ephremides, University of Maryland - Deborah Estrin, University of California, Los Angeles - J.J. Garcia-Luna-Aceves, University of California at Santa Cruz - Kang G. Shin, University of Michigan - Mario Gerla, University of California, Los Angeles - Ramesh Govindan, USC/ISI - Nitin H. Vaidya, University of Illinois at Urbana-Champaign - Ravi Jain, Telcordia - David B. Johnson, Rice University - Anthony Joseph, University of California, Berkeley - Edward Knightly, Rice University - Tom LaPorta, Lucent Technologies - Songwu Lu, University of California, Los Angeles - Robert Morris, MIT - S. Muthukrishnan, AT&T Research - Venkat Padmanabhan, Microsoft Research - Charles Perkins, Nokia - Chiara Petrioli, Universit "La Sapienza" - George Polyzos, Athens University of Economics and Business - Parmesh Ramanathan, University of Wisconsin - Madison - Ram Ramanathan, BBN Technologies - Ramachandran Ramjee, Lucent Technologies - Daniela Rus, Dartmouth College - Srinivasan Seshan, Carnegie Mellon University - Suresh Singh, Portland State University - Leandros Tassiulas, University of Maryland - Mani Srivastava, University of California, Los Angeles - Frank Stajano, AT&T Laboratories Cambridge - Martha Steenstrup, Stow Research - Violet R. Syrotiuk, University of Texas at Dallas - Andras Valko, Ericsson Research - Adam Wolisz, Technical University of Berlin - Michele Zorzi, Universita di Ferrara From owner-tcp-impl@grc.nasa.gov Wed Feb 6 09:29:42 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20870 for ; Wed, 6 Feb 2002 09:29:41 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 47A37640FC for ; Wed, 6 Feb 2002 09:28:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA15414 for tcp-impl-outgoing; Wed, 6 Feb 2002 09:11:41 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA15399 for ; Wed, 6 Feb 2002 09:11:40 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id JAA18092 for ; Wed, 6 Feb 2002 09:11:39 -0500 (EST) Received: from mail.et6.tu-harburg.de (pollux.et6.tu-harburg.de [134.28.85.242]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 02107640D4 for ; Wed, 6 Feb 2002 09:11:26 -0500 (EST) Received: from tu-harburg.de (antares.et6.tu-harburg.de [134.28.85.61]) by mail.et6.tu-harburg.de (Postfix) with ESMTP id 7FEBC7A70 for ; Wed, 6 Feb 2002 15:11:25 +0100 (CET) Message-ID: <3C61398D.90005@tu-harburg.de> Date: Wed, 06 Feb 2002 15:11:25 +0100 From: Sebastian Zimmermann Organization: Technische =?ISO-8859-15?Q?Universit=E4t?= Hamburg-Harburg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020203 X-Accept-Language: de, en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Connection Establishment Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I would like to ask for some help with correct connection establishment: 1st case: the client does the active open, server sends data (payload) - client sends SYN - server sends SYN-ACK - client sends ACK - server sends data I assume, that this is correct. But what happens in the 2nd case: the server does the active open and sends data - server sends SYN - client sends SYN+ACK - server sends ACK And now the question: May the server send the data already with the final ACK of the connection establishment (piggyback), or must it send two packets (ACK and data), or must it wait for the clients ACK of the ACK (and then send data)? Thanks for your help Sebastian From owner-tcp-impl@grc.nasa.gov Wed Feb 6 10:09:41 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22269 for ; Wed, 6 Feb 2002 10:09:41 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id AEE1E64169 for ; Wed, 6 Feb 2002 10:07:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA29832 for tcp-impl-outgoing; Wed, 6 Feb 2002 09:57:34 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA29814 for ; Wed, 6 Feb 2002 09:57:32 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id JAA26757 for ; Wed, 6 Feb 2002 09:57:31 -0500 (EST) Received: from frantic.weston.bsdi.com (frantic-dmz.weston.BSDI.COM [206.196.54.22]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 18A89640A8 for ; Wed, 6 Feb 2002 09:56:10 -0500 (EST) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.10.1/8.10.1) id g16EtSe24586; Wed, 6 Feb 2002 08:55:28 -0600 (CST) Date: Wed, 6 Feb 2002 08:55:28 -0600 (CST) From: David Borman Message-Id: <200202061455.g16EtSe24586@frantic.weston.bsdi.com> To: S.Zimmermann@tu-harburg.de, tcp-impl@grc.nasa.gov Subject: Re: Connection Establishment Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Sebastian, > From: Sebastian Zimmermann > To: tcp-impl@grc.nasa.gov > Subject: Connection Establishment ... > 2nd case: the server does the active open and sends data > > - server sends SYN > - client sends SYN+ACK > - server sends ACK > > And now the question: > > May the server send the data already with the final ACK of the > connection establishment (piggyback), Yes. It can even include the FIN if it all fits in the packet. > or must it send two packets (ACK and data), No. > or must it wait for the clients ACK of the ACK (and then send > data)? ACK packets are never acked. If the ACK gets lost, the other side will retransmit the data (SYN) to elicit another ACK. > > Thanks for your help > > Sebastian -David Borman, dab@bsdi.com From owner-tcp-impl@grc.nasa.gov Wed Feb 6 10:33:41 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23386 for ; Wed, 6 Feb 2002 10:33:41 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8A5BBC6944 for ; Wed, 6 Feb 2002 10:33:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09846 for tcp-impl-outgoing; Wed, 6 Feb 2002 10:23:49 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA09826 for ; Wed, 6 Feb 2002 10:23:47 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA02728 for ; Wed, 6 Feb 2002 10:23:45 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8797BC68E2 for ; Wed, 6 Feb 2002 10:23:21 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04582; Wed, 6 Feb 2002 10:23:18 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23544; Wed, 6 Feb 2002 10:23:19 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Feb 2002 10:23:18 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55762FAC@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Sebastian Zimmermann'" , tcp-impl@grc.nasa.gov Subject: RE: Connection Establishment Date: Wed, 6 Feb 2002 10:23:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Sebastian: -> May the server send the data already with the final ACK of the -> connection establishment (piggyback), or must it send two -> packets (ACK -> and data), or must it wait for the clients ACK of the ACK -> (and then send -> data)? As per TCP standard (not w.r.t. any API implementations, like sockets) Machine A initiates a connection to machine B. A sends a segment with ISN x, chosen according A's clock, and with SYN bit set to 1, this is the connection request message. - the ACK flag is set to 0 - this segment is still a regular TCP segment; it can carry data too (piggyback 1) - however, if it does contain data, machine B cannot deliver the data to application until the connection is successfully established B returns a segment whose Ack=x+1, Seq=y,theISN of B chosen according to B's clock, and SYN=1. - this is the connection acceptance message. - if the first segment from A contains b bytes of data, then Ack=x+b+1. - this segment itself can contain data too. (piggyback 2) After receiving the acceptance, A considers the connection established. A then sends B a segment with Ack=y+1 and SYN=0. - this is the connection confirmation message - This ack is mostly sent by TCP with out user interaction. But TCP can still piggyback data in this segment. (piggyback 3) - all segments from this point on will have SYN=0 After receiving the confirmation, B considers the connection established. But most of the APIs don't have any provision for this. Venkata Naidu This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. From owner-tcp-impl@grc.nasa.gov Wed Feb 6 12:07:22 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25823 for ; Wed, 6 Feb 2002 12:07:21 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7E42AC6A1C for ; Wed, 6 Feb 2002 12:05:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA09374 for tcp-impl-outgoing; Wed, 6 Feb 2002 11:54:52 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA09369 for ; Wed, 6 Feb 2002 11:54:51 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA19373 for ; Wed, 6 Feb 2002 11:54:49 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 79D3F640D7 for ; Wed, 6 Feb 2002 11:51:22 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g16GpIO22011; Wed, 6 Feb 2002 08:51:18 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA20772; Wed, 6 Feb 2002 16:51:18 GMT Date: Wed, 6 Feb 2002 16:51:18 GMT Message-Id: <200202061651.QAA20772@gra.isi.edu> To: tcp-impl@grc.nasa.gov, S.Zimmermann@tu-harburg.de Subject: Re: Connection Establishment X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk *> Hello, *> *> I would like to ask for some help with correct connection establishment: *> *> 1st case: the client does the active open, server sends data (payload) *> *> - client sends SYN *> - server sends SYN-ACK *> - client sends ACK *> - server sends data *> *> I assume, that this is correct. But what happens in the *> *> 2nd case: the server does the active open and sends data *> *> - server sends SYN *> - client sends SYN+ACK *> - server sends ACK *> *> And now the question: *> *> May the server send the data already with the final ACK of the *> connection establishment (piggyback), or must it send two packets (ACK *> and data), or must it wait for the clients ACK of the ACK (and then send *> data)? *> *> Thanks for your help *> *> Sebastian *> Without even reading your question, I can tell you that anything in the TCP state diagram that is not forbidden is allowed, and packetization may be done in any way the implementor desires. (But of course some strategies work better than others.) Bob Braden From owner-tcp-impl@grc.nasa.gov Wed Feb 6 13:35:06 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27896 for ; Wed, 6 Feb 2002 13:35:05 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 35CC664178 for ; Wed, 6 Feb 2002 13:34:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA04389 for tcp-impl-outgoing; Wed, 6 Feb 2002 13:23:53 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA04363 for ; Wed, 6 Feb 2002 13:23:52 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA05566 for ; Wed, 6 Feb 2002 13:23:48 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 33E33C68CF for ; Wed, 6 Feb 2002 13:23:29 -0500 (EST) Received: from sunuk.UK.Sun.COM ([129.156.85.58]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15587 for ; Wed, 6 Feb 2002 11:23:24 -0700 (MST) Received: from scumbag (scumbag.UK.Sun.COM [129.156.199.253]) by sunuk.UK.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id g16INNc03372; Wed, 6 Feb 2002 18:23:23 GMT Message-Id: <200202061823.g16INNc03372@sunuk.UK.Sun.COM> Date: Wed, 6 Feb 2002 18:23:23 +0000 (GMT) From: Jeremy Harris - Network Service Providers Division Reply-To: Jeremy Harris - Network Service Providers Division Subject: RE: Connection Establishment To: tcp-impl@grc.nasa.gov Cc: jgh@uk.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rDSuqNHi4wDEZ/GSrGfi8w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Venkata.Naidu@Marconi.com said: > As per TCP standard (not w.r.t. any API implementations, > like sockets) > > Machine A initiates a connection to machine B. > A sends a segment with ISN x, chosen according > A's clock, and with SYN bit set to 1, this is the > connection request message. > - the ACK flag is set to 0 > - this segment is still a regular TCP segment; it > can carry data too (piggyback 1) I have implemented this; it works nicely. However, the question arises: how much data may be piggybacked on a SYN? What window may the sender assume? > - however, if it does contain data, machine B > cannot deliver the data to application until the > connection is successfully established As a nonstandard extension to TCP, I propose that this restriction can be relaxed in certain situations: IF - The TCP and next layer up ("ULP") are tightly-coupled (e.g. both in the kernel) and have a rich interface - The ULP data consists of a request which - does not require much processing - does not modify any server state (bar stats counters, cache state etc) ( thus making the "at-most-once" property of TCP unneeded ) - The receiver system can adequately defend itself against DOS attack THEN the "piggyback 1" data can be delivered to the ULP. Further, IF - The ULP can respond with public data THEN the "piggyback 2" can carry that response. I believe that an HTTP GET which hits an in-kernel cache satisfies the above constraints; the transaction can then be reduced to a minimum of three packets. Jeremy Harris jeremy.harris@sun.com From owner-tcp-impl@grc.nasa.gov Wed Feb 6 14:14:08 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28922 for ; Wed, 6 Feb 2002 14:14:07 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 468FCC69BE for ; Wed, 6 Feb 2002 14:13:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA17307 for tcp-impl-outgoing; Wed, 6 Feb 2002 14:04:02 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA17286 for ; Wed, 6 Feb 2002 14:04:01 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA13056 for ; Wed, 6 Feb 2002 14:03:58 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 6B2DEC6909 for ; Wed, 6 Feb 2002 14:03:46 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00748; Wed, 6 Feb 2002 14:03:43 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01060; Wed, 6 Feb 2002 14:03:44 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Feb 2002 14:03:43 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55762FAD@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Jeremy Harris - Network Service Providers Division'" , tcp-impl@grc.nasa.gov Subject: RE: Connection Establishment Date: Wed, 6 Feb 2002 14:03:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Jeremy: -> > Machine A initiates a connection to machine B. -> > A sends a segment with ISN x, chosen according -> > A's clock, and with SYN bit set to 1, this is the -> > connection request message. -> > - the ACK flag is set to 0 -> > - this segment is still a regular TCP segment; it -> > can carry data too (piggyback 1) -> -> I have implemented this; it works nicely. However, the question -> arises: how much data may be piggybacked on a SYN? What window may -> the sender assume? Actually there are more interoperability issues here. An intelligent TCP implementation can make an educated guess. In other words, - Include as much data application gives in the first connect request message - If it didn't get through, then in subsequent re-tries either don't include any data or include less data (with exponential back off with limited tries is one solution) This is because, in order to interoperate with different TCP implementations. Other end has either: - no support of piggyback data reception support, or - short of window (you don't know) -> > - however, if it does contain data, machine B -> > cannot deliver the data to application until the -> > connection is successfully established -> -> As a nonstandard extension to TCP, I propose that this restriction -> can be relaxed in certain situations: -> -> IF -> - The TCP and next layer up ("ULP") are tightly-coupled -> (e.g. both in the -> kernel) and have a rich interface -> - The ULP data consists of a request which -> - does not require much processing -> - does not modify any server state (bar stats counters, cache -> state etc) -> ( thus making the "at-most-once" property of TCP unneeded ) -> - The receiver system can adequately defend itself against DOS attack That means, TCP should track type of applications (actually connections). TCP should know before hand that - when it receives data with a connect request, it SHOULD give only if the application has all the above requirements/constraints. -> I believe that an HTTP GET which hits an in-kernel cache -> satisfies the -> above constraints; the transaction can then be reduced to a -> minimum of three packets. Yes! I agree... this is a very good optimization for some applications --Venkata Naidu This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. From owner-tcp-impl@grc.nasa.gov Wed Feb 6 15:15:04 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00268 for ; Wed, 6 Feb 2002 15:15:04 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 86B4B641A5 for ; Wed, 6 Feb 2002 15:13:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA19814 for tcp-impl-outgoing; Wed, 6 Feb 2002 15:03:47 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA19799 for ; Wed, 6 Feb 2002 15:03:46 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA24092 for ; Wed, 6 Feb 2002 15:03:44 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id BCE3AC6991 for ; Wed, 6 Feb 2002 15:01:35 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g16K1IO24461; Wed, 6 Feb 2002 12:01:18 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA20927; Wed, 6 Feb 2002 20:01:18 GMT Date: Wed, 6 Feb 2002 20:01:18 GMT Message-Id: <200202062001.UAA20927@gra.isi.edu> To: tcp-impl@grc.nasa.gov, jgh@uk.sun.com Subject: RE: Connection Establishment X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk *> From owner-tcp-impl@grc.nasa.gov Wed Feb 6 10:35:39 2002 *> Date: Wed, 6 Feb 2002 18:23:23 +0000 (GMT) *> From: Jeremy Harris - Network Service Providers Division *> Subject: RE: Connection Establishment *> To: tcp-impl@grc.nasa.gov *> Cc: jgh@uk.sun.com *> MIME-Version: 1.0 *> Content-MD5: rDSuqNHi4wDEZ/GSrGfi8w== *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> Venkata.Naidu@Marconi.com said: *> > As per TCP standard (not w.r.t. any API implementations, *> > like sockets) *> > *> > Machine A initiates a connection to machine B. *> > A sends a segment with ISN x, chosen according *> > A's clock, and with SYN bit set to 1, this is the *> > connection request message. *> > - the ACK flag is set to 0 *> > - this segment is still a regular TCP segment; it *> > can carry data too (piggyback 1) *> *> I have implemented this; it works nicely. However, the question *> arises: how much data may be piggybacked on a SYN? What window may *> the sender assume? *> Please see RFC 1644 on T/TCP (July 1994)/ Bob Braden From owner-tcp-impl@grc.nasa.gov Thu Feb 7 17:08:56 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11247 for ; Thu, 7 Feb 2002 17:08:56 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 37BFFC696F for ; Thu, 7 Feb 2002 17:05:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA19294 for tcp-impl-outgoing; Thu, 7 Feb 2002 16:50:36 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA19271 for ; Thu, 7 Feb 2002 16:50:35 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA19719 for ; Thu, 7 Feb 2002 16:50:30 -0500 (EST) Received: from nicol6.umkc.edu (nicol6.umkc.edu [134.193.4.67]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1AFC564162 for ; Thu, 7 Feb 2002 16:42:54 -0500 (EST) Received: from localhost ([127.0.0.1] helo=umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.32 #1 (Debian)) id 16YwGe-00008u-00; Thu, 07 Feb 2002 15:39:44 -0600 Message-ID: <3C62F41F.802C2ED6@umkc.edu> Date: Thu, 07 Feb 2002 15:39:43 -0600 From: David Nicol X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en-GB, en, ru MIME-Version: 1.0 To: Jeremy Harris - Network Service Providers Division Cc: tcp-impl@grc.nasa.gov Subject: Re: Connection Establishment References: <200202061823.g16INNc03372@sunuk.UK.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Harris - Network Service Providers Division wrote: > > I believe that an HTTP GET which hits an in-kernel cache satisfies the > above constraints; the transaction can then be reduced to a minimum of > three packets. > > Jeremy Harris jeremy.harris@sun.com fascinating -- you're suggesting HTTP over datagrams. Or at least acting like datagrams when all you really want is a datagram. You can dispense with the connection when all you want is a datagram. -- David L Nicol, humble system administrator (816) 235 1187 "... to regret something you haven't done. So the next time ..." From owner-tcp-impl@grc.nasa.gov Thu Feb 7 19:21:28 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13810 for ; Thu, 7 Feb 2002 19:21:28 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 95153640B6 for ; Thu, 7 Feb 2002 19:21:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA15300 for tcp-impl-outgoing; Thu, 7 Feb 2002 19:10:51 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA15296 for ; Thu, 7 Feb 2002 19:10:49 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id TAA11181 for ; Thu, 7 Feb 2002 19:10:49 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id BA9B0640A1 for ; Thu, 7 Feb 2002 19:10:48 -0500 (EST) Received: from esuncal1 ([129.147.58.119]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10053 for ; Thu, 7 Feb 2002 17:10:48 -0700 (MST) Received: from xpa-fe2 ([129.147.58.119]) by esuncal1.central.sun.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GR60008OTSF4K@esuncal1.central.sun.com> for tcp-impl@grc.nasa.gov; Thu, 07 Feb 2002 17:09:52 -0700 (MST) Received: from Sun.COM ([212.238.123.153]) by mail.sun.net (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPSA id <0GR6006CBTYMF4@mail.sun.net> for tcp-impl@grc.nasa.gov; Thu, 07 Feb 2002 17:13:36 -0700 (MST) Date: Fri, 08 Feb 2002 01:10:44 +0100 From: Henk Langeveld - NL Subject: Re: Connection Establishment To: tcp-impl@grc.nasa.gov Message-id: <3C631784.1030908@Sun.COM> Organization: IT Technology Office EMEA MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 (CK-anonymous) References: <200202061823.g16INNc03372@sunuk.UK.Sun.COM> <3C62F41F.802C2ED6@umkc.edu> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT > Jeremy Harris - Network Service Providers Division wrote: >>I believe that an HTTP GET which hits an in-kernel cache satisfies the >>above constraints; the transaction can then be reduced to a minimum of >>three packets. David Nicol wrote: > fascinating -- you're suggesting HTTP over datagrams. Or at least > acting like datagrams when all you really want is a datagram. You > can dispense with the connection when all you want is a datagram. This is beginning to look like the DNS approach: Just use udp on the first attempt, and revert to tcp when the result would be too large? Frankly, given that one of the conditions given was sufficient resistance/defence against DoS attacks, I doubt this will ever escape the lab. A proper defence against DoS attacks is miserly conduct with your resources, until you've established at least some validity in the request - this will require a round trip from server to client. If you're going to allow initial datagrams carrying data, you'll have to limit the size of that data, possibly using the same constraints as the DNS udp/tcp switch referred to above. You might be thinking of a specific application for this web-service, where you'd control the network stack of both client and server *and* the network in between. Then you've got your value-add network, with your own application protocol - why use http? Henk From owner-tcp-impl@grc.nasa.gov Fri Feb 8 10:19:23 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10575 for ; Fri, 8 Feb 2002 10:19:22 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 49394C6A09 for ; Fri, 8 Feb 2002 10:18:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA19877 for tcp-impl-outgoing; Fri, 8 Feb 2002 10:05:24 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA19863 for ; Fri, 8 Feb 2002 10:05:23 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA10872 for ; Fri, 8 Feb 2002 10:05:22 -0500 (EST) Received: from mail.et6.tu-harburg.de (pollux.et6.tu-harburg.de [134.28.85.242]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id E8B76C68E4 for ; Fri, 8 Feb 2002 10:05:21 -0500 (EST) Received: from tu-harburg.de (antares.et6.tu-harburg.de [134.28.85.61]) by mail.et6.tu-harburg.de (Postfix) with ESMTP id C105A7A73 for ; Fri, 8 Feb 2002 16:05:19 +0100 (CET) Message-ID: <3C63E92F.8040005@tu-harburg.de> Date: Fri, 08 Feb 2002 16:05:19 +0100 From: Sebastian Zimmermann Organization: Technische =?ISO-8859-1?Q?Universit=E4t?= Hamburg-Harburg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020203 X-Accept-Language: de, en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Connection Establishment References: <39469E08BD83D411A3D900204840EC55762FAC@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id KAA19868 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Thank you for all your answers. It looks like I didn't think far enough :-) Sebastian -- +----------------------------------------+ | Technische Universität Hamburg-Harburg | | Kommunikationsnetze (4-06) | | Denickestraße 17 | | 21071 Hamburg | |----------------------------------------| | Fernsprecher: +49 40 42878-3387 | | Fernkopie: +49 40 42878-2941 | | Elektropost: S.Zimmermann@tuhh.de | | http://www.tu-harburg.de/et6 | +----------------------------------------+ From owner-tcp-impl@grc.nasa.gov Mon Feb 11 11:47:18 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09388 for ; Mon, 11 Feb 2002 11:47:18 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id EA3CB6419E for ; Mon, 11 Feb 2002 11:47:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA23343 for tcp-impl-outgoing; Mon, 11 Feb 2002 11:26:00 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA23321 for ; Mon, 11 Feb 2002 11:25:58 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA25768 for ; Mon, 11 Feb 2002 11:25:56 -0500 (EST) Received: from web21006.mail.yahoo.com (web21006.mail.yahoo.com [216.136.227.60]) by seraph2.grc.nasa.gov (Postfix) with SMTP id 4FBF1C6950 for ; Mon, 11 Feb 2002 11:22:57 -0500 (EST) Message-ID: <20020211162256.59253.qmail@web21006.mail.yahoo.com> Received: from [65.88.242.115] by web21006.mail.yahoo.com via HTTP; Mon, 11 Feb 2002 08:22:56 PST Date: Mon, 11 Feb 2002 08:22:56 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: CFP: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues To: YangXiao@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk My apologies if you receive this CFP duplicated. ------------------- Call for Papers- Deadline extented Invited Session Title: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues Invited Session in the 6th World Multi-Conference on Systemics, Cybernetics and Informatics, (SCI 2002) Orlando, Florida, USA, July 14 -18, 2002 Topics of Interest Wireless LANs & Mobile Ad Hoc Networks (not limited to) Simulation, Modeling and performance evaluation of Wireless LANs, such as IEEE 802.11, HIPERLAN, and Ad hoc Networks. Quality-of-service issues in Wireless LANs (IEEE 802.11e, HIPERLAN/2, etc.) and Ad Hoc Networks. Power Consumption issues Higher data rates 3G/4G-WLAN Differentiated Services for Wireless LANs Co-existence of the IEEE 802.11 and 802.15 Resource Management Analytical methods. Deadlines Submission of Extended Abstracts: February 25, 2002 Notification of Acceptance: March 15, 2002 Camera Ready Copies: April 03, 2002 Session Co-Organizers/co-chairs Dr. Yang Xiao, Micro Linear, USA Dr. Bin Wang, Wright State University, USA Instructions For Submission Submission should be in the form of extended abstracts up to 4 pages long. All submitted contributions will be subject to peer review on the basis of technical correctness, quality, relevance, originality, significance, and clarity. Abstracts should be in MS Word, PDF or PS format. Submissions should be sent to the session's co-organizers. Successful submissions will be asked to submit a full paper. Full papers must be formatted according to IEEE-CS guidelines Electronic Submission: Dr. Yang Xiao: YangXiao@IEEE.ORG Dr. Bin Wang: bwang@cs.wright.edu For more details check at http://www.iiis.org/sci2002/ last updated 02/11/02 __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-tcp-impl@grc.nasa.gov Tue Feb 12 22:03:42 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05388 for ; Tue, 12 Feb 2002 22:03:42 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 2836F640EF for ; Tue, 12 Feb 2002 22:03:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA16720 for tcp-impl-outgoing; Tue, 12 Feb 2002 21:47:11 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA16710 for ; Tue, 12 Feb 2002 21:47:10 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id VAA03421 for ; Tue, 12 Feb 2002 21:47:09 -0500 (EST) Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 69B1CC6936 for ; Tue, 12 Feb 2002 21:47:08 -0500 (EST) Received: from ephi ([65.172.158.93]) by philotas.hosting.pacbell.net id VAA03053; Tue, 12 Feb 2002 21:46:46 -0500 (EST) [ConcentricHost SMTP Relay 1.14] From: "Ephi Dror" To: Cc: , , Subject: Please help Date: Tue, 12 Feb 2002 18:46:46 -0800 Message-ID: <001f01c1b438$adbd30f0$2010000a@corp.silverbacksystems.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C1B3F5.9F99F0F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C1B3F5.9F99F0F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Costa and all, I saw yours posting long ago about NFS V2/V3 header splitting technique (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg00075.html ) and I would just like to ask if I may a quick question. In CIFS, you said it may be costly to perform it since it does not have fix size trailer. From my understanding, if I just interested in splitting SMB read respond and write request commands from their payloads, all I need is to parse the header by hunting for those commands and then for each of those commands, the actual payload starts at the offset specified by a field called DataOffset. So to me it does not look like it cost much to do header split for the few commands that are important. Of course, do a pure header split of all SMB commands from their payload could be costly in terms of firmware code space and performance. Am I missing some thing big time here? I really appreciate and respect your view on this subject. Cheers, Ephi ------=_NextPart_000_0020_01C1B3F5.9F99F0F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Costa and all,

 

I saw yours posting long ago about NFS V2/V3 header splitting technique (http:= //www.pdl.cmu.edu/mailinglists/ips/mail/msg00075.html ) and I would just like to ask if I may a quick = question.

 

In CIFS, you said it may be costly to perform it = since it does not have fix size trailer.

 

From my understanding, if I just interested in = splitting  SMB read respond and write = request commands from their payloads, all I need is to parse the header by = hunting for those commands and then for each of those commands, the actual payload = starts at the offset specified by a field called  DataOffset.

 

So to me it does not look like it cost much to do header split = for the few commands that are important.

 

Of course, do a pure header split of all SMB commands from their = payload could be costly in terms of firmware code space and = performance.


Am I missing some thing big time here?

 

I really appreciate and respect your view on this = subject.

 

Cheers,

Ephi

 

 

------=_NextPart_000_0020_01C1B3F5.9F99F0F0-- From owner-tcp-impl@grc.nasa.gov Wed Feb 13 10:30:49 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07605 for ; Wed, 13 Feb 2002 10:30:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id E365DC69D8 for ; Wed, 13 Feb 2002 10:29:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA01897 for tcp-impl-outgoing; Wed, 13 Feb 2002 10:16:57 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA01850 for ; Wed, 13 Feb 2002 10:16:51 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA14391 for ; Wed, 13 Feb 2002 10:16:47 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 41CE9C6972 for ; Wed, 13 Feb 2002 10:15:11 -0500 (EST) Received: from sunuk.UK.Sun.COM ([129.156.85.58]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20419; Wed, 13 Feb 2002 07:15:09 -0800 (PST) Received: from watford-109 (watford-109.UK.Sun.COM [129.156.199.109]) by sunuk.UK.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id g1DFF7c10734; Wed, 13 Feb 2002 15:15:07 GMT Message-Id: <200202131515.g1DFF7c10734@sunuk.UK.Sun.COM> Date: Wed, 13 Feb 2002 15:16:03 +0000 (GMT) From: "Jeremy Harris [RU-UK]" Reply-To: "Jeremy Harris [RU-UK]" Subject: Re: Connection Establishment To: nicold@umkc.edu, Henk.Langeveld@Sun.COM, braden@ISI.EDU Cc: tcp-impl@grc.nasa.gov, jgh@uk.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1/Y3CYI6TTay46+Rh8veCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.9 sun4u sparc Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk [David Nicol] > fascinating -- you're suggesting HTTP over datagrams. Or at least > acting like datagrams when all you really want is a datagram. You > can dispense with the connection when all you want is a datagram. Not quite... I'm suggesting a use of TCP which degenerates to datagram behaviour when it can, gives lower latency, client, net and server resource usage when it can, and uses a full TCP connection when it has to for the general case. [Henk Langeveld] >This is beginning to look like the DNS approach: Just use udp >on the first attempt, and revert to tcp when the result would be >too large? No, it's TCP all the way. >Frankly, given that one of the conditions given was sufficient >resistance/defence against DoS attacks, I doubt this will ever >escape the lab. A proper defence against DoS attacks is miserly >conduct with your resources, until you've established at least >some validity in the request - this will require a round trip from >server to client. I agree about the proper defence. But parsing an http GET and searching a kernel URL cache isn't too expensive, and the eager action on it simple to disable when the system load it high or a SYN attack detected. >If you're going to allow initial datagrams carrying data, you'll >have to limit the size of that data, possibly using the same >constraints as the DNS udp/tcp switch referred to above. Yes. >You might >be thinking of a specific application for this web-service, where >you'd control the network stack of both client and server *and* >the network in between. Then you've got your value-add network, >with your own application protocol - why use http? No, I'd like to see it in general use. [Bob Braden] > *> arises: how much data may be piggybacked on a SYN? What window may > *> the sender assume? > *> > >Please see RFC 1644 on T/TCP (July 1994)/ I did. It suggests using the window specified by a previous connection. Which is fine if you had one. Cheers, Jeremy From owner-tcp-impl@grc.nasa.gov Wed Feb 13 11:03:24 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09019 for ; Wed, 13 Feb 2002 11:03:23 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7C345641C6 for ; Wed, 13 Feb 2002 11:00:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA17241 for tcp-impl-outgoing; Wed, 13 Feb 2002 10:51:20 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA17224 for ; Wed, 13 Feb 2002 10:51:19 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA21931 for ; Wed, 13 Feb 2002 10:51:18 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 5C77B64107 for ; Wed, 13 Feb 2002 10:50:32 -0500 (EST) Received: from romulus.Holland.Sun.COM ([129.159.211.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06763 for ; Wed, 13 Feb 2002 08:50:31 -0700 (MST) Received: from glorantha.holland.sun.com (glorantha [129.159.201.67]) by romulus.Holland.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id QAA27781; Wed, 13 Feb 2002 16:50:30 +0100 (MET) Received: (from henkl@localhost) by glorantha.holland.sun.com (8.9.3+Sun/8.9.3) id QAA16135; Wed, 13 Feb 2002 16:49:58 +0100 (MET) Date: Wed, 13 Feb 2002 16:49:58 +0100 From: Henk Langeveld - NL To: "Jeremy Harris [RU-UK]" , tcp-impl@grc.nasa.gov Subject: Re: Connection Establishment Message-ID: <20020213164957.D15857@Sun.COM> References: <200202131515.g1DFF7c10734@sunuk.UK.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200202131515.g1DFF7c10734@sunuk.UK.Sun.COM>; from jgh@uk.sun.com on Wed, Feb 13, 2002 at 03:16:03PM +0000 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Jeremy Harris [RU-UK]: > I agree about the proper defence. But parsing an http GET and searching > a kernel URL cache isn't too expensive, and the eager action on it > simple to disable when the system load it high or a SYN attack detected. How do you detect a SYN attack? Henk From owner-tcp-impl@grc.nasa.gov Wed Feb 13 12:20:48 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14391 for ; Wed, 13 Feb 2002 12:20:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id CC45CC69AE for ; Wed, 13 Feb 2002 12:18:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13576 for tcp-impl-outgoing; Wed, 13 Feb 2002 12:07:12 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA13553 for ; Wed, 13 Feb 2002 12:07:09 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA06506 for ; Wed, 13 Feb 2002 12:07:07 -0500 (EST) Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 77940C6987 for ; Wed, 13 Feb 2002 12:05:38 -0500 (EST) Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16b33o-0005p7-00; Wed, 13 Feb 2002 17:19:12 +0000 Subject: Re: Connection Establishment To: jgh@uk.sun.com Date: Wed, 13 Feb 2002 17:19:12 +0000 (GMT) Cc: nicold@umkc.edu, Henk.Langeveld@Sun.COM, braden@ISI.EDU, tcp-impl@grc.nasa.gov In-Reply-To: <200202131515.g1DFF7c10734@sunuk.UK.Sun.COM> from "Jeremy Harris [RU-UK]" at Feb 13, 2002 03:16:03 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > >Please see RFC 1644 on T/TCP (July 1994)/ > > I did. It suggests using the window specified by a previous connection. > Which is fine if you had one. And completely unsafe nowdays with proxies stealing some ports, port specific routing and the like. The later TCP rfcs made a convincing case including good studies that the initial congestion window should be two frames. That would I suspect mean that 2*mss was a reasonable way to open fire. Alan From owner-tcp-impl@grc.nasa.gov Thu Feb 14 07:53:55 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16861 for ; Thu, 14 Feb 2002 07:53:55 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A524D64139 for ; Thu, 14 Feb 2002 07:50:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA23933 for tcp-impl-outgoing; Thu, 14 Feb 2002 07:36:22 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA23923 for ; Thu, 14 Feb 2002 07:36:21 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id HAA21525 for ; Thu, 14 Feb 2002 07:36:20 -0500 (EST) Received: from mail.et6.tu-harburg.de (pollux.et6.tu-harburg.de [134.28.85.242]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1895DC693D for ; Thu, 14 Feb 2002 07:34:24 -0500 (EST) Received: from tu-harburg.de (antares.et6.tu-harburg.de [134.28.85.61]) by mail.et6.tu-harburg.de (Postfix) with ESMTP id AE5F37A6F for ; Thu, 14 Feb 2002 13:34:22 +0100 (CET) Message-ID: <3C6BAECE.20402@tu-harburg.de> Date: Thu, 14 Feb 2002 13:34:22 +0100 From: Sebastian Zimmermann Organization: Technische =?ISO-8859-15?Q?Universit=E4t?= Hamburg-Harburg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020203 X-Accept-Language: de, en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: T/TCP (was: Connection Establishment) References: <200202062001.UAA20927@gra.isi.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id HAA23924 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Bob Braden wrote: > Please see RFC 1644 on T/TCP (July 1994)/ FYI: There is also a project at sourceforge: http://sourceforge.net/projects/ttcplinux/ -- +----------------------------------------+ | Technische Universität Hamburg-Harburg | | Kommunikationsnetze (4-06) | | Denickestraße 17 | | 21071 Hamburg | |----------------------------------------| | Fernsprecher: +49 40 42878-3387 | | Fernkopie: +49 40 42878-2941 | | Elektropost: S.Zimmermann@tuhh.de | | http://www.tu-harburg.de/et6 | +----------------------------------------+ From owner-tcp-impl@grc.nasa.gov Thu Feb 14 11:57:40 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27566 for ; Thu, 14 Feb 2002 11:57:39 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 83EE1C69E8 for ; Thu, 14 Feb 2002 11:56:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA06939 for tcp-impl-outgoing; Thu, 14 Feb 2002 11:45:03 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA06931 for ; Thu, 14 Feb 2002 11:45:01 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA03489 for ; Thu, 14 Feb 2002 11:45:01 -0500 (EST) Received: from web21007.mail.yahoo.com (web21007.mail.yahoo.com [216.136.227.61]) by seraph2.grc.nasa.gov (Postfix) with SMTP id 9DBDDC6948 for ; Thu, 14 Feb 2002 11:43:54 -0500 (EST) Message-ID: <20020214164353.75508.qmail@web21007.mail.yahoo.com> Received: from [65.88.242.115] by web21007.mail.yahoo.com via HTTP; Thu, 14 Feb 2002 08:43:53 PST Date: Thu, 14 Feb 2002 08:43:53 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: CFP-Deadline correction To: YangXiao@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk My apologies if you receive this CFP duplicated. ------------------- Call for Papers- Deadline correction Invited Session Title: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues Invited Session in the 6th World Multi-Conference on Systemics, Cybernetics and Informatics, (SCI 2002) Orlando, Florida, USA, July 14 -18, 2002 Topics of Interest Wireless LANs & Mobile Ad Hoc Networks (not limited to) Simulation, Modeling and performance evaluation of Wireless LANs, such as IEEE 802.11, HIPERLAN, and Ad hoc Networks. Quality-of-service issues in Wireless LANs (IEEE 802.11e, HIPERLAN/2, etc.) and Ad Hoc Networks. Power Consumption issues Higher data rates 3G/4G-WLAN Differentiated Services for Wireless LANs Co-existence of the IEEE 802.11 and 802.15 Resource Management Analytical methods. Deadlines Submission of Extended Abstracts: February 17, 2002 Notification of Acceptance: March 10, 2002 Camera Ready Copies: April 03, 2002 Session Co-Organizers/co-chairs Dr. Yang Xiao, Micro Linear, USA Dr. Bin Wang, Wright State University, USA Instructions For Submission Submission should be in the form of extended abstracts up to 4 pages long. All submitted contributions will be subject to peer review on the basis of technical correctness, quality, relevance, originality, significance, and clarity. Abstracts should be in MS Word, PDF or PS format. Submissions should be sent to the session's co-organizers. Successful submissions will be asked to submit a full paper. Full papers must be formatted according to IEEE-CS guidelines Electronic Submission: Dr. Yang Xiao: YangXiao@IEEE.ORG Dr. Bin Wang: bwang@cs.wright.edu For more details check at http://www.iiis.org/sci2002/ last updated 02/11/02 __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-tcp-impl@grc.nasa.gov Thu Feb 14 16:12:34 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09918 for ; Thu, 14 Feb 2002 16:12:34 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 73D62C6A00 for ; Thu, 14 Feb 2002 16:12:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA19441 for tcp-impl-outgoing; Thu, 14 Feb 2002 16:00:20 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA19422 for ; Thu, 14 Feb 2002 16:00:18 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA19448 for ; Thu, 14 Feb 2002 16:00:16 -0500 (EST) Received: from ux13.cso.uiuc.edu (ux13.cso.uiuc.edu [128.174.5.25]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id CC30E640D9 for ; Thu, 14 Feb 2002 15:59:45 -0500 (EST) Received: from localhost (dpereira@localhost [127.0.0.1]) by ux13.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id g1EKxj821126 for ; Thu, 14 Feb 2002 14:59:45 -0600 (CST) Date: Thu, 14 Feb 2002 14:59:44 -0600 (CST) From: "D'laila Pereira" X-X-Sender: Cc: Subject: Client Server In-Reply-To: <3C61398D.90005@tu-harburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hi I am not sure if this is the right newsgroup to ask . But I amlooking for information about client-server design issues, and architecture? especially designing scalable web servers. Can anyone point out the right newsgroup for this? thanks From owner-tcp-impl@grc.nasa.gov Fri Feb 15 19:45:52 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23960 for ; Fri, 15 Feb 2002 19:45:52 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0D2936408E for ; Fri, 15 Feb 2002 19:45:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA04778 for tcp-impl-outgoing; Fri, 15 Feb 2002 19:28:13 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA04763 for ; Fri, 15 Feb 2002 19:28:12 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id TAA13913 for ; Fri, 15 Feb 2002 19:28:09 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 3F966C6968; Fri, 15 Feb 2002 19:27:04 -0500 (EST) Received: from web13801.mail.yahoo.com(216.136.175.11) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAJaaaIE; Fri, 15 Feb 02 19:27:04 -0500 Message-ID: <20020216002703.99581.qmail@web13801.mail.yahoo.com> Received: from [63.104.212.252] by web13801.mail.yahoo.com via HTTP; Fri, 15 Feb 2002 16:27:03 PST Date: Fri, 15 Feb 2002 16:27:03 -0800 (PST) From: Saurabh Shrivastava Subject: BSD implementation of RAW sockets To: tcp-impl@grc.nasa.gov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hi!, this is a RAW socket question. tcp_output before calling ip_output, copies over TTL/TOS from the PCB. but for a RAW socket for which INP_HDRINCL is not set, shouldnt rip_output do the same ? BSD just sets the TOS to 0, TTL to the default. the side effect of this behaviour is that setsockopts for TOS/TTL dont work on a raw socket. please comment ... am i missing something thanks! -saurabh __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-tcp-impl@grc.nasa.gov Sat Feb 16 14:23:44 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15739 for ; Sat, 16 Feb 2002 14:23:44 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B160AC6957; Sat, 16 Feb 2002 14:23:45 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAUVaqXd; Sat, 16 Feb 02 14:23:45 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA08872 for tcp-impl-outgoing; Sat, 16 Feb 2002 14:09:37 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA08868 for ; Sat, 16 Feb 2002 14:09:36 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA10289 for ; Sat, 16 Feb 2002 14:09:35 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 690C2C68CC; Sat, 16 Feb 2002 14:05:02 -0500 (EST) Received: from cmailg7.svr.pol.co.uk(195.92.195.177) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAVDaGNa; Sat, 16 Feb 02 14:05:02 -0500 Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 16cA8q-0001sd-00 for tcp-impl@lerc.nasa.gov; Sat, 16 Feb 2002 19:05:00 +0000 Received: from modem-2985.antelope.dialup.pol.co.uk ([217.134.27.169] helo=yahoo.com) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 16cA8p-00001q-00 for tcp-impl@lerc.nasa.gov; Sat, 16 Feb 2002 19:04:59 +0000 From: "UK Emails 4 Sale" To: Subject: 1 million emails for sale - £5 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 16 Feb 2002 19:08:43 -0000 Reply-To: "UK Emails 4 Sale" Message-Id: Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id OAA08872 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15739 Bulk email list for sale: 1 million emails in total, including 200,000 UK. Emails have been validated, removing the bad ones. List comes on a CD in two files in "comma separated value" format, one file contains 200,000 UK addresses, and the other contains 1 million of the world + uk. The CD is available for just £5 inc p&p! To order the list send a cheque or PO (leaving the name blank) to: Flat 434 405 Kings Rd London SW10 OBB The CD will be sent out by first class post when your money has been received. Note: The list does NOT contain any personal information (eg names of email owners) From owner-tcp-impl@grc.nasa.gov Wed Feb 27 21:09:40 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28387 for ; Wed, 27 Feb 2002 21:09:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id CEF00C6AE8 for ; Wed, 27 Feb 2002 21:08:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA18935 for tcp-impl-outgoing; Wed, 27 Feb 2002 20:54:36 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA18927 for ; Wed, 27 Feb 2002 20:54:35 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id UAA25247 for ; Wed, 27 Feb 2002 20:54:34 -0500 (EST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 84D65C6944 for ; Wed, 27 Feb 2002 20:51:32 -0500 (EST) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g1S1pVgB019636 for ; Wed, 27 Feb 2002 18:51:31 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.10.2+Sun/8.10.2) id g1S1pVv00119 for tcp-impl@lerc.nasa.gov; Wed, 27 Feb 2002 18:51:31 -0700 (MST) Date: Wed, 27 Feb 2002 18:51:31 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200202280151.g1S1pVv00119@ece2.ece.arizona.edu> To: tcp-impl@lerc.nasa.gov Subject: Mobicom 2002 - Final CFP Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk *************************************************************** [Appologies if you receive duplicates of this message] Please note the following changes in this CFP: - Paper submission details have been revised. - A Student Poster Session has been added. - Student travel grants are now available. See below for details. *************************************************************** F I N A L C A L L F O R P A P E R S *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Paper Submission Deadline (EXTENDED): March 8, 2002 ******** No further extensions will be given ********* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: ------- Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: ------------------ Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. **REVISED SUBMISSION INSTRUCTIONS**: ------------------------------------ All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. No other format will be accepted. Papers must meet the following restrictions: - The paper must be original material that has not been previously published nor is currently under review by another conference or journal. - Full papers should be no longer than *15 pages*, in font no smaller than 10 points. (Note that accepted papers, when formatted for the proceedings, may not exceed 12 pages in font no smaller than 9 points). - Challenges papers should be no longer than 8 pages, in font no smaller than 10 points. - All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names *must not* appear in the paper. - The paper should fit properly on US Letter-sized paper (8.5x11 inches) - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file - The paper must be formatted for b/w printers and not color printers. Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ TUTORIALS: ---------- Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: ------- Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: --------------- Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). ** STUDENT POSTER SESSION **: --------------------------- The conference solicits student posters that highlight recent and on-going research by students on mobile computing topics. Proposals should be a maximum of two pages in length. While it does not need to describe completed work, the poster paper should report on research that is beyond the initial stages. The first author of a poster submission must be a student. Poster abstracts will not be published in the proceedings but will instead be published on the web before the conference. Poster submissions will be reviewed. Authors of accepted papers must not submit a poster of the work they present in the conference. For more information about student poster applications contact the Student Poster Co-chairs (ebelding@cs.ucsb.edu or sjlee@hpl.hp.com). **STUDENT TRAVEL AWARDS**: -------------------------- MobiCom will offer a limited number of travel grants to support students. Please contact Student Travel Awards Co-Chairs for application details (fang@ece.ufl.edu or syrotiuk@utdallas.edu). BEST STUDENT PAPER AWARD: ------------------------- Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: ---------------- * Paper submissions due: March 8, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 * Tutorial proposals: May 1, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu EXECUTIVE COMMITTEE: -------------------- * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Mercury Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Co-Chairs: - Suresh Singh, Portland State University - Robin Kravets, University of Illinois, Urbana-Champaign * Student Poster Co-Chairs: - Elizabeth M. Belding-Royer, University of California, Santa Barbara - Sung-Ju Lee, HP Laboratories * Student Travel Award Co-Chairs: - Yuguang Fang, University of Florida - Violet R. Syrotiuk, University of Texas at Dallas * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Webmaster: Michael E. Kounavis, Columbia University PROGRAM COMMITTEE: -------------------- Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University Program Committee: - Arup Acharya, IBM Research - Prathima Agrawal, Telcordia - B. R. Badrinath, Rutgers University - Victor Bahl, Microsoft Research - Stefano Basagni, Northeastern University - Roberto Battiti, University of Trento - Pravin Bhagwat, ReefEdge - Chatschik Bisdikian, IBM Research - Scott Corson, Flarion - Sajal Das, University Texas at Arlington - Nigel Davies, Lancaster University - Dan Duchamp, Stevens Institute of Technology - Maria Ebling, IBM Research - Magda El-Zarki, University of California, Irvine - Anthony Ephremides, University of Maryland - Deborah Estrin, University of California, Los Angeles - J.J. Garcia-Luna-Aceves, University of California at Santa Cruz - Mario Gerla, University of California, Los Angeles - Ramesh Govindan, USC/ISI - Ravi Jain, Telcordia - David B. Johnson, Rice University - Anthony Joseph, University of California, Berkeley - Edward Knightly, Rice University - Tom LaPorta, Lucent Technologies - Songwu Lu, University of California, Los Angeles - Robert Morris, MIT - S. Muthukrishnan, AT&T Research - Brian Noble, University of Michigan - Venkat Padmanabhan, Microsoft Research - Charles Perkins, Nokia - Chiara Petrioli, University "La Sapienza" - George Polyzos, Athens University of Economics and Business - Parmesh Ramanathan, University of Wisconsin - Madison - Ram Ramanathan, BBN Technologies - Ramachandran Ramjee, Lucent Technologies - Daniela Rus, Dartmouth College - Srinivasan Seshan, Carnegie Mellon University - Kang G. Shin, University of Michigan - Suresh Singh, Portland State University - Mani Srivastava, University of California, Los Angeles - Frank Stajano, AT&T Laboratories Cambridge - Martha Steenstrup, Stow Research - Violet R. Syrotiuk, University of Texas at Dallas - Leandros Tassiulas, University of Maryland - Nitin H. Vaidya, University of Illinois at Urbana-Champaign - Andras Valko, Ericsson Research - Adam Wolisz, Technical University of Berlin - Michele Zorzi, Universita di Ferrara From owner-tcp-impl@grc.nasa.gov Thu Feb 28 09:39:22 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25310 for ; Thu, 28 Feb 2002 09:39:22 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 34345C6A05 for ; Thu, 28 Feb 2002 09:37:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA06926 for tcp-impl-outgoing; Thu, 28 Feb 2002 09:27:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA06920 for ; Thu, 28 Feb 2002 09:27:15 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id JAA21986 for ; Thu, 28 Feb 2002 09:27:14 -0500 (EST) Received: from anna.dei.unipd.it (anna.dei.unipd.it [147.162.2.100]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4D811640C3 for ; Thu, 28 Feb 2002 09:27:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by anna.dei.unipd.it (Postfix) with ESMTP id A2337302FE for ; Thu, 28 Feb 2002 15:27:09 +0100 (MET) Received: from bella (bella.dei.unipd.it [147.162.2.250]) by anna.dei.unipd.it (Postfix) with ESMTP id C65D03019F for ; Thu, 28 Feb 2002 15:27:08 +0100 (MET) Date: Thu, 28 Feb 2002 15:27:08 +0100 (MET) From: Ronny Tittoto X-Sender: barret@bella To: tcp-impl@grc.nasa.gov Subject: TCP receiver and Duplicate packets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Dear all, I'm working on TCP performances over GPRS and UMTS networks. I've observed a singular behaviour of TCP receiver in presence of duplicate packets. When a receiver receives a packet with sequence number equal to a packet received before it reply with a duplicate ack. For example: - suppose the reciever has already received packets 1 to 40 - a packet with sequence number 35 arrives - the receiver doesn't need this packet, it has already received it! - the receiver reply with a multiple ack requesting packet 41. My question is: Why does the receiver replay when it receives an old packet already received? Is it an implementation need or a simplification? Thanks a lot! Best regards Ronny ._____________________________________________________________________. |Ronny Tittoto 380560/IL barret@dei.unipd.it | | ronny@chiara.dei.unipd.it | |---------------------------------------------------------------------| | | |_____________________________________________________________________| From owner-tcp-impl@grc.nasa.gov Thu Feb 28 15:49:52 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19020 for ; Thu, 28 Feb 2002 15:49:46 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 181E6C69F0 for ; Thu, 28 Feb 2002 15:47:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA00952 for tcp-impl-outgoing; Thu, 28 Feb 2002 15:34:26 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA00944 for ; Thu, 28 Feb 2002 15:34:25 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA09636 for ; Thu, 28 Feb 2002 15:34:25 -0500 (EST) Received: from mail.mangoosta.net (mail2.mangoosta.net [217.11.161.6]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 76A63C6A92 for ; Thu, 28 Feb 2002 15:08:20 -0500 (EST) Received: from [62.212.115.193] (helo=Dimension-8200.mangoosta.fr) by mail.mangoosta.net id 16gWqg-00066x-00; Thu, 28 Feb 2002 14:08:18 -0600 Message-Id: <4.3.2.7.2.20020228202602.00cb30a8@pop.free.fr> X-Sender: pragon@mail.mangoosta.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Feb 2002 21:07:03 +0100 To: Ronny Tittoto , tcp-impl@grc.nasa.gov From: Philippe Ragon Subject: Re: TCP receiver and Duplicate packets In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Ronny, Sending a duplicate ACK in the case you are describing, is the specified behavior in TCP. Imagine for example that all the ACKs generated by packets 35 to 40 have been lost, without the duplicate ACK, the sender would keep sending ACK 35 until it decides that the connection is lost. In your case (and I know it from experience in the same context) the repetition of packet 35 have probably been triggered not because ACKs have been lost, but because they arrived too late. Without any additional information, such has the one conveyed by D-SACK (refer to RFC 2883), there is no way for the source to infer from this duplicate ACK that it has wrongly repeated packet 35 and undo what it has done (return to slow start, ssthresh lowering, ...) when it has thought that this packet was lost due to network congestion. Quick and reliable detection of spurious re-transmission is an important feature in the GPRS context in order not to degrade performance. Such a subject should be advanced quickly in relevant IETF work group. I hope that people will not infer from my reference to D-SACK that I consider it as the final say in term of spurious retransmission detection, and as a consequence, that I disregard the Eiffel algorithm that is currently under specification study in the 'tswg' work group. Cheers, Philippe Ragon At 15:27 28/02/2002 +0100, Ronny Tittoto wrote: >Dear all, >I'm working on TCP performances over GPRS and UMTS networks. >I've observed a singular behaviour of TCP receiver in presence of >duplicate packets. >When a receiver receives a packet with sequence number equal to a packet >received before it reply with a duplicate ack. >For example: >- suppose the reciever has already received packets 1 to 40 >- a packet with sequence number 35 arrives >- the receiver doesn't need this packet, it has already received it! >- the receiver reply with a multiple ack requesting packet 41. > >My question is: >Why does the receiver replay when it receives an old packet already >received? >Is it an implementation need or a simplification? > >Thanks a lot! >Best regards > >Ronny > >._____________________________________________________________________. >|Ronny Tittoto 380560/IL barret@dei.unipd.it | >| ronny@chiara.dei.unipd.it | >|---------------------------------------------------------------------| >| | >|_____________________________________________________________________| > --------------------------------------------------------------------- Philippe Ragon / Tour Atlas / 10, villa d'Este/ 75013 Paris/ FRANCE Telephone & Fax : (33) 01 45 70 79 53 E-mail : pragon@mangoosta.fr ---------------------------------------------------------------------