From owner-tcp-impl@lerc.nasa.gov Wed Jul 7 10:57:24 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10704 for ; Wed, 7 Jul 1999 10:57:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA04253 for tcp-impl-outgoing; Wed, 7 Jul 1999 07:54:43 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA04243 for ; Wed, 7 Jul 1999 07:54:40 -0400 (EDT) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id NAA03960 for ; Wed, 7 Jul 1999 13:54:34 +0200 (MET DST) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id NAA28905; Wed, 7 Jul 1999 13:54:33 +0200 (MET DST) Message-ID: <37833FF8.C7E36679@eth.ericsson.se> Date: Wed, 07 Jul 1999 13:54:32 +0200 From: =?iso-8859-1?Q?P=E9ter=20Kr=E9mer?= Organization: ETH/RL/S X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Automated TCP test Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi! We have been working on platform independent solution for automated TCP tests. Although, we do not feel 100% ready, we decided to share our experience with this forum and also looking forward to get valuable feedback from you. Briefly, we test TCP features without performing any modification to the tested implementation (using the black-box method). The basic idea behind the applied methodology is to drive the TCP under test into a specific state then apply a stimuli and check if we got the right answer. We believe that this approach is advantageous to the whole community, since it gives a measure of correctness of implementations according to the RFC. We have been working parallel to the discussions in this list and managed to develop formal description of tests, based on previous versions of "Known TCP Implementation Problems (RFC 2525)". All test cases are written in TTCN, an abstract notation, which has common use in telecom protocol tests. The use of such an abstraction allows TCP testers to write test scripts based on this notation or use available tools for automatic compilation and execution. We also performed these tests on 4 different implementations (Linux, Solaris, FreeBSD and NT) and managed to detect errors, which are not addressed by the RFC mentioned before. A postscript version of the paper (submitted to INFOCOM2000)describing method and experiences can be found online on http://www.cs.columbia.edu/~hgs/papers/infocom2000/591-2818661292.ps We are awaiting your comments, Roland Gecse, Peter Kremer. From owner-tcp-impl@lerc.nasa.gov Wed Jul 7 14:49:48 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20398 for ; Wed, 7 Jul 1999 14:49:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA05657 for tcp-impl-outgoing; Wed, 7 Jul 1999 12:09:22 -0400 (EDT) Received: from gateway.sequent.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA05653 for ; Wed, 7 Jul 1999 12:09:20 -0400 (EDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id JAA13781; Wed, 7 Jul 1999 09:09:18 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5/token.aware-1.2) id JAA10376; Wed, 7 Jul 1999 09:09:16 -0700 (PDT) From: Vivek Kashyap Message-Id: <199907071609.JAA10376@eng4.sequent.com> Subject: Re: Automated TCP test To: Peter.Kremer@eth.ericsson.se (=?iso-8859-1?Q?P=E9ter=20Kr=E9mer?=) Date: Wed, 7 Jul 1999 09:09:16 -0700 (PDT) Cc: viv@sequent.com (Vivek Kashyap), tcp-impl@grc.nasa.gov In-Reply-To: <37833FF8.C7E36679@eth.ericsson.se> from "=?iso-8859-1?Q?P=E9ter=20Kr=E9mer?=" at Jul 7, 99 01:54:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I had some time back found a problem not listed in rfc2525. you might find it of interest: --------------------------------------------------------------------- in certain situations the server fails to enter persist state. ========================================================================= 1) Scenario ... not entering persist state Server: Client: listen,accept,read... connect,write, In a loop write read()..not reading all so that the window fills up shutdown (..,SHUT_WR) (app blocked on write) send FIN (ack all data and window of 0) rcv FIN send ACK rcv ACK wait in CLOSE_WAIT wait in FIN_WAIT2 The server stays in CLOSE_WAIT state blocking the application. The client is in FIN_WAIT2 awaiting a FIN from the server. Analysis: The server fails to enter the persist state because: When a FIN is received tcp immediately arranges to ACK it but in BSDLite/FreeBSD 2.2.6 implementations it does not check for entry into persist mode if TF_ACKNOW/t_force flags are set. Thus the ACK is sent but TCP does not enter persist mode. So the server will not send any probes and there is no retransmit timer running. The client is in FIN_WAIT2 and might terminate directly based on the FIN_WAIT2 timer. In the case that I looked at the client machine had crashed. Thus the server will forever stay in CLOSE_WAIT since it is never going to probe, so will never get a RST and hence the app will never get an indication of the peer having gone away. Of course, if there is no FIN_WAIT2 timer implemented then both ends will always stay in their respective states. Note: (based on BSD sockets API) This will occur only when a shutdown() is called since the client side TCP is still willing to read data until a close or shutdown(..,RD) is done. Therefore it is perfectly ok in sending a FIN and a window of 0. > > Hi! > > We have been working on platform independent solution for automated TCP > tests. Although, we do not feel 100% ready, we decided to share our > experience with this forum and also looking forward to get valuable > feedback from you. > > Briefly, we test TCP features without performing any modification to > the tested implementation (using the black-box method). > The basic idea behind the applied methodology is to drive the TCP under > test into a specific state then apply a stimuli and check if we got the > right answer. > > We believe that this approach is advantageous to the whole community, > since it gives a measure of correctness of implementations according to > the RFC. > > We have been working parallel to the discussions in this list and > managed to develop formal description of tests, based on previous > versions of "Known TCP Implementation Problems (RFC 2525)". All test > cases are written in TTCN, an abstract notation, which has common use > in telecom protocol tests. > > The use of such an abstraction allows TCP testers to write test scripts > based on this notation or use available tools for automatic compilation > and execution. We also performed these tests on 4 different > implementations (Linux, Solaris, FreeBSD and NT) and managed to detect > errors, which are not addressed by the RFC mentioned before. A > postscript version of the paper (submitted to INFOCOM2000)describing > method and experiences can be found online on > > http://www.cs.columbia.edu/~hgs/papers/infocom2000/591-2818661292.ps > > We are awaiting your comments, > > Roland Gecse, Peter Kremer. > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) From owner-tcp-impl@lerc.nasa.gov Sat Jul 10 19:57:25 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12070 for ; Sat, 10 Jul 1999 19:57:24 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA05287 for tcp-impl-outgoing; Sat, 10 Jul 1999 17:02:21 -0400 (EDT) Received: from star.cirrus.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA05283 for ; Sat, 10 Jul 1999 17:02:20 -0400 (EDT) Received: from ss563.corp.cirrus.com (ss563.corp.cirrus.com [141.131.8.55]) by star.cirrus.com (8.9.3/8.8.8) with ESMTP id OAA24060 for ; Sat, 10 Jul 1999 14:02:18 -0700 (PDT) Received: from ssu011.corp (ssu011.basiscomm.com [141.131.34.154]) by ss563.corp.cirrus.com with SMTP id OAA22082 (8.7.5/IDA-1.6 for ); Sat, 10 Jul 1999 14:02:17 -0700 (PDT) Received: by ssu011.corp (SMI-8.6/SMI-SVR4) id OAA12206; Sat, 10 Jul 1999 14:02:03 -0700 From: bhaveshp@corp.cirrus.com (Bhavesh Pathak - BasisComm) Message-Id: <199907102102.OAA12206@ssu011.corp> Subject: doubts in rfc793 To: tcp-impl@grc.nasa.gov Date: Sat, 10 Jul 1999 14:02:03 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24alpha3] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dear everybody, while going through the rfc793, I got following doubts. I absence of any active mailing list where such a basic rfc can be help to resolve this kind of doubts, I am sending this queries to this list. with regards, bhavesh Doubt-1 ------- TCP A TCP B 1. CLOSED CLOSED 2. SYN-SENT --> ... 3. SYN-RECEIVED <-- <-- SYN-SENT 4. ... --> SYN-RECEIVED 5. SYN-RECEIVED --> ... 6. ESTABLISHED <-- <-- SYN-RECEIVED 7. ... --> ESTABLISHED Simultaneous Connection Synchronization (Figure 8.) Here(at line 6), I am not able to understand why TCP-B needs to re-transmit another SYN. Doubt-2 ------- The RFC says that (this is just after connection diag. in the section 3.4) "1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means. " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RFC seems to be saying that SYN addressed to non-existent connection is illegal. But, I think that when we are opening a connection, the SYN can be addressed to ONLY non-existent connection because SYN only starts up the connection. Doubt-3 ------- RFC refers to "security level, compartment and precedence", have this been in implemented in the TCP/IP stacks. Doubt-4 ------- RFC says that, "The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero. The sending TCP must regularly retransmit to the receiving TCP even when the window is zero." 1. when send window is 0, how tcp will be able send data? 2. does it mean that retransmission are not affected by the present window size (0 in the above case)? From owner-tcp-impl@lerc.nasa.gov Sun Jul 11 06:01:53 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01054 for ; Sun, 11 Jul 1999 06:01:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA13584 for tcp-impl-outgoing; Sun, 11 Jul 1999 03:14:15 -0400 (EDT) Received: from Twig.Rodents.Montreal.QC.CA (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA13577 for ; Sun, 11 Jul 1999 03:14:10 -0400 (EDT) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA16952; Sun, 11 Jul 1999 03:13:45 -0400 (EDT) Date: Sun, 11 Jul 1999 03:13:45 -0400 (EDT) From: der Mouse Message-Id: <199907110713.DAA16952@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: bhaveshp@corp.cirrus.com (Bhavesh Pathak - BasisComm) Cc: tcp-impl@grc.nasa.gov Subject: Re: doubts in rfc793 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Doubt-2 > ------- > The RFC says that (this is just after connection diag. in the section 3.4) > "1. If the connection does not exist (CLOSED) then a reset is sent > in response to any incoming segment except another reset. In particular, > SYNs addressed to a non-existent connection are rejected by this means. " > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > RFC seems to be saying that SYN addressed to non-existent connection > is illegal. Basically, yes, though I would prefer a different word, since it's valid to attempt to connect when there's nobody listening. The receiving TCP stack just has to reject the attempt. > But, I think that when we are opening a connection, the SYN can > be addressed to ONLY non-existent connection because SYN only > starts up the connection. This is a flaw in the language. When there is "someone there", the receiving stack has a TCB in SYN-SENT or LISTEN (the former only in the case of a simultaneous open, something that I suspect essentially never happens in practice). In the sentence you emphasized, I believe "connection" really means "address/port pair" (loosely, "socket"). > RFC says that, > "The sending TCP must be prepared to accept from the user and send at > least one octet of new data even if the send window is zero. The sending > TCP must regularly retransmit to the receiving TCP even when the window > is zero." > > 1. when send window is 0, how tcp will be able send data? It can't. The point of this low-rate constant retransmission is to probe the window, so that in case it opens but the packet carrying that fact manages to get lost in transit, data transfer doesn't stall indefinitely. > 2. does it mean that retransmission are not affected by the present > window size (0 in the above case)? Retransmission of what? Zero-window probes are very different from retransmitting already-sent data. I don't recall offhand what you're supposed to do if you send some data that's in-window, the peer shrinks its advertised window so that what you sent is partially (or entirely) past the window before acking what you sent, and then your retransmission timer goes off. It seems to me there's little point in sending data outside what you think the window is, except for two cases: (1) zero-window probes and (2) when the bandwidth*delay product is high enough that the window is likely to have opened by the time the segment arrives. The latter case is hard enough to predict that it's probably better addressed by window-enlargement schemes, it seems to me. (If the bandwidth*delay product is larger than the peer's available buffer space, but the peer is fast enough to swallow bits at full path bandwidth, this strategy will lose. I suspect this is relatively rare.) der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Mon Jul 12 19:53:35 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22780 for ; Mon, 12 Jul 1999 19:53:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA13635 for tcp-impl-outgoing; Mon, 12 Jul 1999 16:39:19 -0400 (EDT) Received: from dangle.wins.hrl.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA13620; Mon, 12 Jul 1999 16:39:08 -0400 (EDT) Received: from ambrose.wins.hrl.com by dangle.wins.hrl.com (5.65v3.2/1.1.10.5/24Apr98-0905PM) id AA24955; Mon, 12 Jul 1999 13:38:08 -0700 Message-Id: <378A51BE.12AB498A@hrl.com> Date: Mon, 12 Jul 1999 13:36:14 -0700 From: Dennis Connors Organization: Networking and Media Computing Group at HRL Laboratories X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov, tcp-sat@grc.nasa.gov Subject: Call for Papers, WOSBIS 99 Content-Type: multipart/alternative; boundary="------------F14F55582044FD6A78AFBD34" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --------------F14F55582044FD6A78AFBD34 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * CALL FOR PAPERS * * * * WOSBIS 99 * * * * Fourth IEEE International Workshop on * * Satellite-Based Information Systems * * Wednesday, December 8th, 1999 * * Rio de Janeiro, Brazil * * * * In conjunction with IEEE Globecom 99 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * SCOPE Satellite communications will play an increasingly important role in our future information-based society. This is evidenced by the systems currently in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium) as well as those to offer broadband, interactive, and multimedia Internet services around the next millenium (SpaceWay, Teledesic, Astrolink, etc.). WOSBIS, held three times in 96, 97, 98 in conjunction with MobiCOM, is a premier workshop on satellite networks and services and provides a forum for exploratory research contributions on lifting the technological barriers to achieve innovative satellite applications and services. This year, WOSBIS will be held in conjunction with GLOBECOM'99 and focuses on the communication aspect of satellite-based information services, more specifically in the network layer, data link layer, and medium access sub-layer. We are interested in work that is relevant to both ongoing systems (i.e. current LEO deployment, high bandwidth GEO systems, etc.) and future satellite networks. TOPICS Papers are solicited in all research and applied areas related to satellite-based information systems (including, but not limited to): * Datalink technology for satellites, ATM over satellites * Resource management and network management * Inter-satellite link communications * Constellation planning and LEO routing * Bandwidth and latency management * Quality of Service support in satellite networks * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks * IP protocols for satellite * High-data rate terminals * Architectures of high speed satellite networks * Satellite on-broad processing architectures * Algorithms for packet scheduling in satellite networks * Routing protocols in satellite networks * Satellite network control and management * Mobile satellite services SUBMISSION GUIDELINES All submissions will be handled electronically. Authors should e-mail a PostScript version of their paper to connors@hrl.com In order to ensure that the PostScript versions of the papers can be printed, authors should be careful that their papers meet the following restrictions: - PostScript version 2 or later. - Within 5 to 10 pages. - Fits properly on "US Letter" size paper (8.5X11 inches) - Reference 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 file. It is expected that all accepted papers will be presented at the workshop. IMPORTANT DATES Submissions due: August 31, 1999 Notification of acceptance: October 1, 1999 Final papers due: November 1, 1999 Workshop: December 8, 1999 ORGANIZATION TECHNICAL PROGRAM CO-CHAIRS Srikanth Krishnamurthy, HRL Labs, USA Dennis Connors, HRL Labs, USA GENERAL CO-CHAIRS Son K. Dao, HRL Labs, USA Randy Katz, UC Berkeley, USA -- Dennis P. Connors email: connors@hrl.com Research Staff Member Information Sciences Laboratory fax: (310) 317-5695 HRL Laboratories, L.L.C. (formerly Hughes Research Labs) BLDG 254, M/S RL96 3011 Malibu Canyon Road Malibu, CA 90265 URL: http://www.wins.hrl.com/3.0/people/connors --------------F14F55582044FD6A78AFBD34 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*                                                                           *
*                             CALL FOR PAPERS                               *
*                                                                           *
*                                WOSBIS 99                                  *
*                                                                           *
*                       Fourth IEEE International Workshop on               *
*                 Satellite-Based Information Systems                 *
*                         Wednesday, December 8th, 1999                     *
*       Rio de Janeiro, Brazil                          *
*                                                                           *
*                   In conjunction with IEEE Globecom 99                    *
*                                                                           *
*                                                                           *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 

                                    SCOPE

Satellite communications will play an increasingly important role in our
future information-based society.  This is evidenced by the systems
currently  in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium) as
well as those to offer broadband, interactive, and multimedia Internet
services around the next millenium (SpaceWay, Teledesic, Astrolink, etc.).

WOSBIS, held three times in 96, 97, 98 in conjunction with MobiCOM,
is a premier workshop on satellite networks and services and provides
a forum for exploratory research contributions on lifting the
technological barriers to achieve innovative satellite applications
and services.  This year, WOSBIS will be held in conjunction with
GLOBECOM'99 and focuses on the communication aspect of satellite-based
information services, more specifically in the network layer, data link
layer, and medium access sub-layer.  We are interested in work that is
relevant to both ongoing systems (i.e. current LEO deployment, high
bandwidth GEO systems, etc.) and future satellite networks.
 
 

                                    TOPICS

Papers are solicited in all research and applied areas related to satellite-based
information systems (including, but not limited to):
 

     * Datalink technology for satellites, ATM over satellites
     * Resource management and network management
     * Inter-satellite link communications
     * Constellation planning and LEO routing
     * Bandwidth and latency management
     * Quality of Service support in satellite networks
     * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks
     * IP protocols for satellite
     * High-data rate terminals
     * Architectures of high speed satellite networks
     * Satellite on-broad processing architectures
     * Algorithms for packet scheduling in satellite networks
     * Routing protocols in satellite networks
     * Satellite network control and management
     * Mobile satellite services
 

                             SUBMISSION GUIDELINES

All submissions will be handled electronically. Authors should e-mail
a PostScript version of their paper to connors@hrl.com In order to
ensure that the PostScript versions of the papers can be printed,
authors should be careful that their papers meet the following restrictions:

   - PostScript version 2 or later.
   - Within 5 to 10 pages.
   - Fits properly on "US Letter" size paper (8.5X11 inches)
   - Reference 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 file.

It is expected that all accepted papers will be presented at the workshop.
 
 

                                 IMPORTANT DATES

   Submissions due: August 31, 1999
   Notification of acceptance: October 1, 1999
   Final papers due: November 1, 1999
   Workshop: December 8, 1999
 
 

                                   ORGANIZATION

TECHNICAL PROGRAM CO-CHAIRS

   Srikanth Krishnamurthy, HRL Labs, USA
   Dennis Connors, HRL Labs, USA

GENERAL CO-CHAIRS

   Son K. Dao, HRL Labs, USA
   Randy Katz, UC Berkeley, USA
  

-- 
Dennis P. Connors                               email: connors@hrl.com
Research Staff Member                           
Information Sciences Laboratory                 fax: (310) 317-5695
HRL Laboratories, L.L.C. 
(formerly Hughes Research Labs)
BLDG 254, M/S RL96
3011 Malibu Canyon Road
Malibu, CA  90265
URL: http://www.wins.hrl.com/3.0/people/connors
  --------------F14F55582044FD6A78AFBD34-- From owner-tcp-impl@lerc.nasa.gov Wed Jul 21 14:30:08 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14671 for ; Wed, 21 Jul 1999 14:30:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA11603 for tcp-impl-outgoing; Wed, 21 Jul 1999 11:59:32 -0400 (EDT) Received: from frantic.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA11597 for ; Wed, 21 Jul 1999 11:59:30 -0400 (EDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id KAA13507; Wed, 21 Jul 1999 10:58:55 -0500 (CDT) Date: Wed, 21 Jul 1999 10:58:55 -0500 (CDT) From: David Borman Message-Id: <199907211558.KAA13507@frantic.bsdi.com> To: joe@midnight.com, tcp-impl@grc.nasa.gov Subject: Re: Need a clarification on use of ACK Flag..... Cc: joe@morning.midnight.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Joseph, All normal TCP packets will have the ACK bit set, except for the initial SYN packet. > Date: Wed, 21 Jul 1999 10:27:57 -0400 > From: "A. Joseph Dupre III" > Subject: Need a clarification on use of ACK Flag..... > ... > >From RFC 793: (page 16) > ======================= > Acknowledgment Number: 32 bits > > If the ACK control bit is set this field contains the value of the > next sequence number the sender of the segment is expecting to > receive. Once a connection is established this is always sent. > > > One vendor who we are trying to interoperate with has interpreted the > above lines to mean that an ACK control bit MUST always be SET on > every packet that is sent by our TCP after reaching ESTABLISHED state. > This means setting the ACK flag on data segments, FIN, and RST. Yes, that is correct. > However, when looking at the state machine below from RFC 793, it does not > show the ACK Flag being set on FIN packets for example. When looking > at Steven's TCP/IP Illustrated #1, one transition from FIN_WAIT_1 to > TIME_WAIT has an explicit FIN,ACK as the receive event that causes > that transition. The state machine is not the protocol definition, you have to read the text. > Any help people can provide me in understanding the appropriate use of > the ACK control flag would be greatly appreciated. Particularly if > there is a section of the RFC 793 that clears this up or some other > RFC such as 1122, pointing me at that would be great. The above text that you quoted is quite clear, isn't it? Once you get into established state, the ACK bit/field is always set. -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Wed Jul 21 14:44:29 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14672 for ; Wed, 21 Jul 1999 14:30:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA00016 for tcp-impl-outgoing; Wed, 21 Jul 1999 10:27:58 -0400 (EDT) Received: from midnight.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA00012 for ; Wed, 21 Jul 1999 10:27:57 -0400 (EDT) Received: from morning.midnight.com (IDENT:joe@morning [137.103.210.44]) by midnight.com (8.9.3/8.9.3) with ESMTP id KAA11606; Wed, 21 Jul 1999 10:26:27 -0400 Received: (from joe@localhost) by morning.midnight.com (8.9.3/8.9.3) id KAA09643; Wed, 21 Jul 1999 10:27:57 -0400 Date: Wed, 21 Jul 1999 10:27:57 -0400 Message-Id: <199907211427.KAA09643@morning.midnight.com> From: "A. Joseph Dupre III" To: tcp-impl@grc.nasa.gov Cc: joe@morning.midnight.com Subject: Need a clarification on use of ACK Flag..... Reply-to: joe@midnight.com (A. Joseph Dupre III 617/890-1001) Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello, I could use some help interpretting the below section of RFC 793: From RFC 793: (page 16) ======================= Acknowledgment Number: 32 bits If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. One vendor who we are trying to interoperate with has interpreted the above lines to mean that an ACK control bit MUST always be SET on every packet that is sent by our TCP after reaching ESTABLISHED state. This means setting the ACK flag on data segments, FIN, and RST. However, when looking at the state machine below from RFC 793, it does not show the ACK Flag being set on FIN packets for example. When looking at Steven's TCP/IP Illustrated #1, one transition from FIN_WAIT_1 to TIME_WAIT has an explicit FIN,ACK as the receive event that causes that transition. Any help people can provide me in understanding the appropriate use of the ACK control flag would be greatly appreciated. Particularly if there is a section of the RFC 793 that clears this up or some other RFC such as 1122, pointing me at that would be great. ------------------------------------------------------------------------------- September 1981 Transmission Control Protocol Functional Specification +---------+ ---------\ active OPEN | CLOSED | \ ----------- +---------+<---------\ \ create TCB | ^ \ \ snd SYN passive OPEN | | CLOSE \ \ ------------ | | ---------- \ \ create TCB | | delete TCB \ \ V | \ \ +---------+ CLOSE | \ | LISTEN | ---------- | | +---------+ delete TCB | | rcv SYN | | SEND | | ----------- | | ------- | V +---------+ snd SYN,ACK / \ snd SYN +---------+ | |<----------------- ------------------>| | | SYN | rcv SYN | SYN | | RCVD |<-----------------------------------------------| SENT | | | snd ACK | | | |------------------ -------------------| | +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+ | -------------- | | ----------- | x | | snd ACK | V V | CLOSE +---------+ | ------- | ESTAB | | snd FIN +---------+ | CLOSE | | rcv FIN V ------- | | ------- +---------+ snd FIN / \ snd ACK +---------+ | FIN |<----------------- ------------------>| CLOSE | | WAIT-1 |------------------ | WAIT | +---------+ rcv FIN \ +---------+ | rcv ACK of FIN ------- | CLOSE | | -------------- snd ACK | ------- | V x V snd FIN V +---------+ +---------+ +---------+ |FINWAIT-2| | CLOSING | | LAST-ACK| +---------+ +---------+ +---------+ | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN -------------- | Timeout=2MSL -------------- | | ------- x V ------------ x V \ snd ACK +---------+delete TCB +---------+ ------------------------>|TIME WAIT|------------------>| CLOSED | +---------+ +---------+ TCP Connection State Diagram Figure 6. [Page 23] ............................................................................... A. Joseph Dupre III : Midnight Networks 205B Lowell St. Wilmington, MA 01887 Software Engineer : Vox 781/890-1001 joe@midnight.com : Fax 781/890-0028 *** Midnight Networks is hiring! *** *** Come check out our job opportunities- www.midnight.com/jobs.html *** From owner-tcp-impl@lerc.nasa.gov Fri Jul 30 11:04:15 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04444 for ; Fri, 30 Jul 1999 11:04:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA05884 for tcp-impl-outgoing; Fri, 30 Jul 1999 08:03:46 -0400 (EDT) Received: from sophia.inria.fr (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA05878 for ; Fri, 30 Jul 1999 08:03:43 -0400 (EDT) Received: from sophia.inria.fr by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id OAA02289; Fri, 30 Jul 1999 14:03:41 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host clope.inria.fr [138.96.48.13] claimed to be sophia.inria.fr Message-ID: <37A1949D.3DDA9DB4@sophia.inria.fr> Date: Fri, 30 Jul 1999 14:03:41 +0200 From: "Chadi M. BARAKAT" Organization: MISTRAL - INRIA Sophia Antipolis X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@lerc.nasa.gov, pilc@grc.nasa.gov Subject: Impact of Receiver Window Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello, While simulating TCP, I found that the receiver window (rwnd) prevents sometimes the source from sending new packets during the recovery phase. This happens when the inflated congestion window (cwnd) exceeds rwnd. First, this causes bursts at the end of the recovery phase which overwhelms network buffers. Second, this causes low throughput during Fast Recovery. Third, in case of Reno, this may prohibit the source from correcting the second loss in a window (Reno cannot correct more than two losses). It is true that when cwnd = rwnd (suppose that the source has enough data to fully utilize its window), the receiver buffer is full. But, we know that when the retransmission is received, some places will be emptied in this receiver. So we can follow the retransmission with some new packets (a kind of anticipation). If these packets find places in the buffer, our anticipation succeeds. Otherwise some packets will be rejected and we can simply suppose at the source that these packets are not transmitted. Such anticipation requires to change the condition : take the minimum of cwnd and rwnd and try to transmit new data. Why to not inflate the rwnd along with cwnd during Fast Recovery? When a dupack is received, we increase rwnd by one segment as we do with cwnd. When a partial ACK is received, we deflate rwnd and set it again to the real window advertised by the receiver. Concerning the maximum sequence number transmitted, we set to it " snd_unack + rwnd - 1 " (of course if the actual maximum sequence number is larger than this quantity). snd_unack : the highest sequence number acked. I think that transmitting more packets that the receiver window (during a short period) doesn't violate TCP congestion control. No more load is injected in the network than in the case of large rwnd. Your feedback is very welcome Chadi -- http://www.inria.fr/mistral/personnel/Chadi.Barakat From owner-tcp-impl@lerc.nasa.gov Fri Jul 30 12:10:07 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05929 for ; Fri, 30 Jul 1999 12:10:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA25891 for tcp-impl-outgoing; Fri, 30 Jul 1999 09:30:58 -0400 (EDT) Received: from orchard.arlington.ma.us (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA25872 for ; Fri, 30 Jul 1999 09:30:56 -0400 (EDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id NAA21166; Fri, 30 Jul 1999 13:30:47 GMT Message-Id: <199907301330.NAA21166@orchard.arlington.ma.us> To: "Chadi M. BARAKAT" cc: tcp-impl@lerc.nasa.gov, pilc@grc.nasa.gov Subject: Re: Impact of Receiver Window In-Reply-To: Message from "Chadi M. BARAKAT" of "Fri, 30 Jul 1999 14:03:41 +0200." <37A1949D.3DDA9DB4@sophia.inria.fr> Date: Fri, 30 Jul 1999 09:30:47 -0400 From: Bill Sommerfeld Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk the receiver window is used for application flow control, and not all applications immediately consume in-sequence data.. But, we know that when the retransmission is received, some places will be emptied in this receiver. not necessarily. if the receiving application is busy dealing with other things and is ignoring the TCP connection for a while, the window will just close, and no space will be freed. Even if the app *is* almost ready to consume the in-sequence data, it could conceivably be paged/swapped out and not actually be able to consume it until after the beyond-the-window packet arrives and is discarded. No more load is injected in the network than in the case of large rwnd. Except that the receiver has only admitted having rwnd worth of buffering; should it not be actively consuming data from the connection, you'll just be sending packets which will be discarded by the receiver. - Bill From owner-tcp-impl@lerc.nasa.gov Fri Jul 30 13:21:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07020 for ; Fri, 30 Jul 1999 13:21:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA06861 for tcp-impl-outgoing; Fri, 30 Jul 1999 10:34:14 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA06585; Fri, 30 Jul 1999 10:31:49 -0400 (EDT) Received: from guns.lerc.nasa.gov by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA25007; Fri, 30 Jul 1999 10:31:49 -0400 (EDT) Message-Id: <199907301431.KAA25007@guns.lerc.nasa.gov> To: "Chadi M. BARAKAT" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcp-impl@lerc.nasa.gov, pilc@grc.nasa.gov Subject: Re: Impact of Receiver Window Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Mrs. Robinson Date: Fri, 30 Jul 1999 10:31:48 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A couple notes in addition to Bill's comments about application layer control. > While simulating TCP, I found that the receiver window (rwnd) > prevents sometimes the source from sending new packets during the > recovery phase. This happens when the inflated congestion window > (cwnd) exceeds rwnd. First, this causes bursts at the end of the > recovery phase which overwhelms network buffers. Second, this > causes low throughput during Fast Recovery. Third, in case of > Reno, this may prohibit the source from correcting the second loss > in a window (Reno cannot correct more than two losses). As a note, this effect is explored for various versions of TCP in the following: Chris Hayes. Analyzing the Performance of New TCP Implementations over Satellite Links. Master's Thesis, Ohio University, August 1997. http://jarok.cs.ohiou.edu/papers/hayes-thesis.ps > I think that transmitting more packets that the receiver window > (during a short period) doesn't violate TCP congestion control. No > more load is injected in the network than in the case of large > rwnd. I agree you could get the same impact on the network by opening rwnd. However, there is one key difference, I think. If the segment you send is rejected once it gets to the receiver because of no buffer space then we wasted capacity in any congested routers in the network path (and, we know there is at least one). I believe such cases are discussed in the following paper (probably in the context of constant rate UDP traffic): Floyd, S., and Fall, K., Promoting the Use of End-to-End Congestion Control in the Internet, May 1999. (To appear in IEEE/ACM Transactions on Networking, August 1999. http://www.aciri.org/floyd/papers/collapse.may99.ps While I don't think the case you are suggesting is nearly as bad as the case of streaming UDP apps, I think there is a potential for it to have a negative impact on the network. allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Fri Jul 30 15:17:27 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08400 for ; Fri, 30 Jul 1999 15:17:24 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA19625 for tcp-impl-outgoing; Fri, 30 Jul 1999 12:20:34 -0400 (EDT) Received: from sabre.sjf.novell.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA19618 for ; Fri, 30 Jul 1999 12:20:32 -0400 (EDT) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.1/8.9.1) id JAA00809; Fri, 30 Jul 1999 09:20:25 -0700 Reply-To: mahdavi@novell.com To: "Chadi M. BARAKAT" Cc: tcp-impl@lerc.nasa.gov, pilc@grc.nasa.gov Subject: Re: Impact of Receiver Window References: <37A1949D.3DDA9DB4@sophia.inria.fr> From: Jamshid Mahdavi Date: 30 Jul 1999 09:20:24 -0700 In-Reply-To: "Chadi M. BARAKAT"'s message of "Fri, 30 Jul 1999 14:03:41 +0200" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The real problem is that applications tend to unnecessarily limit rwnd (usually by simply using the OS default values). For a different solution to this problem, see our autotuning research at: http://www.psc.edu/networking/auto.html As others have pointed out, if the application actually meant to limit the window, sending beyond the window is a bad idea. --J From owner-tcp-impl@lerc.nasa.gov Sat Jul 31 13:54:17 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02753 for ; Sat, 31 Jul 1999 13:54:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA15232 for tcp-impl-outgoing; Sat, 31 Jul 1999 10:54:33 -0400 (EDT) Received: from fsnt.future.futsoft.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA15226 for ; Sat, 31 Jul 1999 10:54:29 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Sat, 31 Jul 1999 20:22:02 +0530 Received: from shankarv.future.futsoft.com ([10.0.14.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id UAA30586 for ; Sat, 31 Jul 1999 20:33:01 +0530 Received: by shankarv.future.futsoft.com with Microsoft Mail id <01BEDB92.D970A960@shankarv.future.futsoft.com>; Sat, 31 Jul 1999 20:25:37 +0530 Message-Id: <01BEDB92.D970A960@shankarv.future.futsoft.com> From: Shankar Vasudevan To: "'tcp-impl@lerc.nasa.gov'" Subject: ICMP Domain Name Messages Date: Sat, 31 Jul 1999 20:25:35 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit hi, page 4 of the RFC 1788 says "On receipt of an ICMP error message, the implementations MAY attempt to resolve the Domain Name using the IN-ADDR method." i want to know what the term "ICMP error message" refers to is it the Domain Name Request message received by the destination machine? if so would n't the machine have its own Domain Name? should it find its Domain Name by IN-ADDR method. else is it a ICMP error message received by the source which had sent a Domain Name Request? if so isnt this violating the general rule that no ICMP error for an ICMP? please help me out. my mail id is shankarv@future.futsoft.com thanx a lot with regards shankar vasudevan