From ddc@lcs.mit.edu Tue Feb 16 12:53:57 1988 Posted-Date: Tue, 16 Feb 88 15:51:42 EST Received-Date: Tue, 16 Feb 88 12:53:57 PST Received: from ALLSPICE.LCS.MIT.EDU by venera.isi.edu (5.54/5.51) id AA23429; Tue, 16 Feb 88 12:53:57 PST Received: from ddc.ufda by PTT.LCS.MIT.EDU via PCMAIL with DMSP id AA05428; Tue, 16 Feb 88 15:51:42 EST Date: Tue, 16 Feb 88 15:51:42 EST Message-Id: <8802162051.AA05428@PTT.LCS.MIT.EDU> To: end2end Subject: [atheybey@PTT.LCS.MIT.EDU: Sequence number PS file.] Reply-To: ddc@lcs.mit.edu From: ddc@lcs.mit.edu Sender: ddc@lcs.mit.edu Repository: PTT Originating-Client: ufda Status: R Folks, As you will remember, we have been working for a while now on our network simulator. As a test, we did up three styles of TCP, 4.2 (dump on timeout), 4.3 (try one then dump) and slow start. We are now trying to make all these work and get the tools built to see everything we want to see. But I thought I would pass one a preliminary picture, just for fun. If yuo will cut at the obvious place, and send this to your postscript printer, you will get a picture of a 4.2 TCP in action. (Or inaction...) Picture from Andrew Heybey, TCP from Eman Hashem From ddc@lcs.mit.edu Thu Feb 18 07:19:35 1988 Posted-Date: Thu, 18 Feb 88 10:17:54 EST Received-Date: Thu, 18 Feb 88 07:19:35 PST Received: from ALLSPICE.LCS.MIT.EDU by venera.isi.edu (5.54/5.51) id AA12472; Thu, 18 Feb 88 07:19:35 PST Received: from ddc.ufda by PTT.LCS.MIT.EDU via PCMAIL with DMSP id AA13306; Thu, 18 Feb 88 10:17:54 EST Date: Thu, 18 Feb 88 10:17:54 EST Message-Id: <8802181517.AA13306@PTT.LCS.MIT.EDU> To: van@LBL-CSAM.ARPA Cc: eman@melange.lcs.mit.edu Cc: end2end-interest@venera.isi.edu In-Reply-To: Van Jacobson's message of Tue, 16 Feb 88 18:50:36 PST <8802170250.AA17226@lbl-csam.arpa> Subject: Re: [atheybey@PTT.LCS.MIT.EDU: Sequence number PS file.] Reply-To: ddc@lcs.mit.edu From: ddc@lcs.mit.edu Sender: ddc@lcs.mit.edu Repository: PTT Originating-Client: ufda Status: R Van, Yes, I think we did simulate the bugs, but I am not sure what the "bugs" are. What I mean is that we took the literal timer code from 4.2 and used it. The thing we had to change was how often we update the RTT, but I think that is the same as 4.2 as well. I am going to forward your message to ther person who is doing the simulation code, and let her describe what really happens. If you have suggestions, pass them on to her. Dave From eman@melange.LCS.MIT.EDU Thu Feb 18 09:23:25 1988 Posted-Date: Thu, 18 Feb 88 12:20:58 EST Received-Date: Thu, 18 Feb 88 09:23:25 PST Received: from MELANGE.LCS.MIT.EDU by venera.isi.edu (5.54/5.51) id AA16483; Thu, 18 Feb 88 09:23:25 PST Received: by melange.LCS.MIT.EDU id AA11445; Thu, 18 Feb 88 12:20:58 EST Date: Thu, 18 Feb 88 12:20:58 EST From: eman@melange.LCS.MIT.EDU (Eman Hashem) Message-Id: <8802181720.AA11445@melange.LCS.MIT.EDU> To: van@lbl-csam.arpa Subject: RTT Behavior Cc: end2end-interest@venera.isi.edu Status: R Hello Mr. Jacobson, I am the person who is working on the TCP implementation as part of the simulator group here at the Distributed Systems Group at MIT. Dave Clark has passed to me your inquiries regarding RTT and RTO behavior and calculation. To calculate the RTT, I include in every packet its transmission time. The receiving TCP keeps state info regarding the last packet received (I call it the RTT packet) and its transmission time. When an acknowledgement to a received packet is to be sent, the RTT packet's seq number and transmission time are included in the acknowledgement. Upon receiving the acknowledgement, the sending TCP checks if this is the first ACK for the RTT packet and, if it is not in a retransmission state it updates the RTT as follows: RTT = current time - RTT packet's time. The smoothed RTT (SRTT) and retransmission timeout (RTO) are calculated as specified in RFC 793 using the constants ALPHA = .8 and BETA = 2.0. Another simpler way to calculate the RTT, which I had implemented in the beginning, is simply to have the sending TCP time a single packet every RTT. I think though that my method updates the RTT more often using a broader range of data (packets), and thus I expect it to produce more accurate estimations of RTT. I would appreciate any input regarding the RTT, RTO, and any aspects of my TCP implementation. Thank you. Eman Hashem eman@melange.lcs.mit.edu From eman@melange.LCS.MIT.EDU Fri Feb 19 10:41:37 1988 Posted-Date: Fri, 19 Feb 88 13:40:19 EST Received-Date: Fri, 19 Feb 88 10:41:37 PST Received: from MELANGE.LCS.MIT.EDU by venera.isi.edu (5.54/5.51) id AA13026; Fri, 19 Feb 88 10:41:37 PST Received: by melange.LCS.MIT.EDU id AA12345; Fri, 19 Feb 88 13:40:19 EST Date: Fri, 19 Feb 88 13:40:19 EST From: eman@melange.LCS.MIT.EDU (Eman Hashem) Message-Id: <8802191840.AA12345@melange.LCS.MIT.EDU> To: nowicki@sun.com Cc: van@lbl-csam.arpa, end2end-interest@venera.isi.edu In-Reply-To: Bill Nowicki's message of Thu, 18 Feb 88 10:05:52 PST <8802181805.A A00172@speed.sun.com> Subject: RTT Behavior Status: R The RTT calculation method that I proposed is part of our network simulator. The way you would do this in a standard TCP is have the TCP keep a record of packet transmission times for all packets in the window. I simply found it more convenient to implement the way I described for simulation purposes. It would be slower and more complex to keep track of the transmission times. Again this is only an implementation style. Eman