From owner-tcp-impl@lerc.nasa.gov Sun Jan 3 01:19:30 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA26206 for ; Sun, 3 Jan 1999 01:19:30 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id XAA00394; Sat, 2 Jan 1999 23:53:06 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id XAA00390; Sat, 2 Jan 1999 23:53:04 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA4BC for ; Sat, 2 Jan 1999 20:53:01 -0800 Message-ID: <368EF7AC.D6CD7AE2@ehsco.com> Date: Sat, 02 Jan 1999 20:53:00 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementations Subject: Re: gratuitous ARP conflicts References: <368EF4B6.F9D8C499@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Dang it. > My question is really centered around the other devices on the network > who are listening for the broadcasts and updating their caches with any > new hardware address that they see. RFC 826 says that any device that > already has the IP address of the sender in its ARP cache should update > the information with a new IP address, if one is provided. ^^ hardware > Assuming that some devices are updating their caches with the hardware > address provided by HOST_A during the gratuitous ARP, shouldn't HOST_B > respond with its own gratuitous ARP as well? If it just responds with a > regular (unicast) response, nobody else will see it. Worse, all of the > other devices will have questionable data in their caches, and will > start sending packets to HOST_B, since thats what the cache points to. ^^^^^^ HOST_A I need to lay off the coffee. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Sun Jan 3 01:23:39 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA26207 for ; Sun, 3 Jan 1999 01:19:30 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id XAA29976; Sat, 2 Jan 1999 23:40:33 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id XAA29971; Sat, 2 Jan 1999 23:40:30 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA4B0 for ; Sat, 2 Jan 1999 20:40:24 -0800 Message-ID: <368EF4B6.F9D8C499@ehsco.com> Date: Sat, 02 Jan 1999 20:40:22 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementations Subject: gratuitous ARP conflicts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hi, This isn't a TCP question, but I couldn't think of any better place to ask. If there's a more appropriate list, I'd like to know about it (and will go ask there). Assume that HOST_A comes onto the network and issues a gratuitous ARP. Also assume that the IP addr its announcing is already in use by HOST_B. Normally, Host_B would freak out, issue a console warning message like "HOST_A IS USING MY ADDDRESS!" and maybe send a unicast response back to HOST_A which would inform it of a problem. Whats the correct behavior from here on out? Should HOST_B issue its own gratuitous ARP? My question is really centered around the other devices on the network who are listening for the broadcasts and updating their caches with any new hardware address that they see. RFC 826 says that any device that already has the IP address of the sender in its ARP cache should update the information with a new IP address, if one is provided. Assuming that some devices are updating their caches with the hardware address provided by HOST_A during the gratuitous ARP, shouldn't HOST_B respond with its own gratuitous ARP as well? If it just responds with a regular (unicast) response, nobody else will see it. Worse, all of the other devices will have questionable data in their caches, and will start sending packets to HOST_B, since thats what the cache points to. If HOST_B sent another gratuitous ARP, what happens with HOST_A? Would it insist on sending yet another gratuitous ARP? When does it end? I'm particularly interested in implementation-specific issues. What does vendor X do, versus what does vendor Y do. Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Sun Jan 3 12:11:16 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA02688 for ; Sun, 3 Jan 1999 12:11:15 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id KAA11076; Sun, 3 Jan 1999 10:13:04 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from tuvok.lerc.nasa.gov (ppp19.lerc.nasa.gov [139.88.123.29]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id KAA11072; Sun, 3 Jan 1999 10:12:50 -0500 (EST) Received: from tuvok.lerc.nasa.gov (localhost [127.0.0.1]) by tuvok.lerc.nasa.gov (8.8.5/8.8.5) with ESMTP id KAA01022; Sun, 3 Jan 1999 10:14:26 -0500 (EST) Message-Id: <199901031514.KAA01022@tuvok.lerc.nasa.gov> To: tcp-impl@lerc.nasa.gov Cc: "Vern Paxson" From: Mark Allman Reply-To: mallman@lerc.nasa.gov Subject: tcpimpl meeting minutes Organization: Late Night Hackers, NASA Lewis, Cleveland, Ohio Song-of-the-Day: I'm No Angel Date: Sun, 03 Jan 1999 10:14:24 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Below is a draft version of the tcpimpl meeting minutes from the December meeting. We would appreciate any comments on these minutes (preferably by Wednesday when they are due to the IETF folks). Thanks, allman --- TCPIMPL Meeting Minutes December 9, 1998 Report by: Joe Touch (touch@isi.edu), Mark Allman (mallman@lerc.nasa.gov), Vern Paxson (vern@ee.lbl.gov) The status of WG documents was reviewed, as follows: Known Problems document is now with the AD for submission to the IESG for publication as Informational. NewReno draft is in WG last call period. No major comments on this document to date. The plan is to submit it for Experimental at the same time that 2001.bis goes for Proposed. 2001.bis is under going several minor changes in response to comments during the WG last call period. The re-start document is under heavy revision. Peter Ford led a short discussion on raising the initial window size in 2001.bis (to be a proposed standard, as compared to RFC 2414 which is an experimental RFC that raises the initial congestion window) from 1 segment to "up to 2 segments". The basic argument in favor was that when developing RFC 2414, the only aspects of it that the WG had found merited further experimentation were the larger windows of 3 or 4 segments; support for 2 segments had been strong. In the subsequent discussion at the meeting, several people commented that they thought this was a good idea, nobody disagreed with the change, and the sense of the room was one of enthused support. The issue will also be discussed on the mailing list. Jamshid Mahdavi presented a short report on the usefulness of the WG documents for debugging TCP stacks. In addition, he outlined two new problems: slow start being too aggressive and RTO that were not long enough. He also suggested that the known problems document would benefit from identifying problems as either "sender" or "receiver" bugs. These were judged as probably appropriate for an update of the known problems document, as the current version is now already with the AD. Joe Touch outlined a new algorithm for preventing TCP from sending large bursts into the network. The algorithm needs to be documented in an internet-draft before the group considers it further. Finally, Kevin Lahey led a short discussion on Path MTU Discovery issues. Kevin outlined several issues with path MTU discovery: BUGS using PMTU to determine MSS determining MTU on per-conn basis ACK frequency every 2 packets dynamic determination of segment size multihoming black-hole detection Kevin outlined that an implementation can be within the specification, but still not optimal. First, some implementations reuse PMTU to determine MSS. For example, if you reopen a connection to the same place and reuse the MTU, you won't probe for higher MTU sizes. Second, some implementations rediscover the PMTU for each connection, which can induce high amounts of ICMP traffic and be inefficient, esp. for systems with high numbers of short connections (e.g. HTTP 1.0). Kevin then outlined problems that arise when determining when to send a delayed ACK and how path MTU discovery complicates the situation. Consider two FDDI hosts, where the rings are interconnected by an ethernet. The MSS is 4KB, and the receiver ACKs after 2 MSS's. PMTU squeezes the packets down to 1.5 KB, and therefore, the ACK really ACKs 6 packets, not 2. Some systems solve this by ACKing every other packet, rather than for 2 MSS's. Others determine the ACK frequency using per-connection information. The problems caused by multihomed hosts were then outlined. Consider a host with multiple interfaces with different MTUs. That host should advertise the largest MTU available, so that if the path to that host changes, connections can take advantage of the largest PMTU available. Finally, Kevin outlined problems caused by black holes. RFC 1435 first mentions it - some routers suppress the "FRAGMENTATION NEEDED" ICMP reply, e.g., misconfigured routers or firewalls. The result looks like a black-hole - full-size packets just get lost, but pings and other small packets work fine. In this case, PMTU just freezes. There is no description of how to handle this - there is one implementation of a check timer at the upper layer protocol, but no generalized description of how to solve the problem. We need a spec to do this. A discussion ensued about whether the WG should generate a document on this topic. Also, the floor was opened for other PMTU problems/issues. The chairs indicated that they would like to see a document on some of these subtle problems. However, the document needed to be expedited. Also, it was noted that this topic is slightly out of our charter and therefore, the AD's approval would be needed before officially working on this topic. It was also noted that IPv6 requires PMTU discovery and the ipng WG is having some related discussions, but has not yet solved the problem. The consensus of the room was that a document on "experience with PMTU" would be useful & appropriate, with the chairs specifying that they would require a draft by January since the WG has wound down. The meeting was adjourned noting that we do not plan to hold any further face-to-face meetings, but that the mailing list will remain active. From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 14:24:13 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20469 for ; Mon, 4 Jan 1999 14:24:12 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id MAA26057; Mon, 4 Jan 1999 12:28:21 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from zephyr.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id MAA26053; Mon, 4 Jan 1999 12:28:18 -0500 (EST) From: braden@ISI.EDU Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA23370; Mon, 4 Jan 1999 09:28:11 -0800 (PST) Date: Mon, 4 Jan 1999 09:24:42 -0800 Posted-Date: Mon, 4 Jan 1999 09:24:42 -0800 Message-Id: <199901041724.AA21892@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 4 Jan 1999 09:24:42 -0800 To: tcp-impl@lerc.nasa.gov Subject: Question on initial sequence numbers Cc: braden@ISI.EDU, Richard_Berke@troweprice.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The following question came to me, but since it seems highly relevant to this list, I am forwarding it (with permission). In any replies, please include the CC: to Richard Berke, who is not on this list. Bob Braden ----- Begin Included Message ----- From Richard_Berke@troweprice.com Wed Dec 23 12:49:32 1998 X-Mailer: Novell GroupWise 5.5 Date: Wed, 23 Dec 1998 15:52:48 -0500 From: "Richard Berke" To: Subject: Initial TCP seq numbers - dispute w/ Microsoft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA16448 Content-Length: 2244 X-Lines: 18 Bob Braden- I have been reading RFCs 793, 1072, 1185, and 1323 expecially regarding initial TCP sequence numbers, wrapping of the sequence numbers, and session boundaries. I ran into a dispute with Microsoft over their TCP stack behavior, and am trying to cite the RFCs. I hope you can help, or point me in the right direction. As I glean from the RFCs, the initial TCP sequence number of a session must be selected in a way that eliminates confusion whether subsequent packets belong to a previous session. The old way was to use increasing sequence numbers, driven by clock cycles. As higher transmission rates became possible, the lifetime of the TCP sequence number space decreased until it became under 3 minutes for 100 Mbps. The maximum segment lifetime is the key factor here. A proposed extension to the algorithm incorporates a timestamp field along with the TCP sequence number field. In a packet trace of a recent session with a Microsoft server and a client, I saw a TCP session finish normally with a FIN/ACK. About a minute later, the client requested a new session, during which it pulled a data file from the server. The client and server used the same TCP ports as in the previous session. The server indicated in its SYN ACK a TCP sequence number of 2+million LOWER than the sequence number it had used to send data at the end of the previous session. The rest of the sequence numbers in the session did increase after the initial number. The session proceeded and completed without apparent errors to the data file. Microsoft asserts this behavior is okay. In fact, they tell me that in the near future they will be selecting initial TCP sequence numbers at random as a technique to thwart hijacking of TCP sessions. Microsoft asserts that there is no regard in the client for the prior session TCP once the FINish process completes successfully. I don't find support for this position in the RFC's; I find the reverse. Is Microsoft lucky that it works? Are they non-compliant, but in a benign way? Am I misunderstanding the requirement for increasing TCP sequence numbers for new sessions? Thanks for your patience and sharing your understanding, Richard Berke RPM Consulting rberke@rpm.com ----- End Included Message ----- From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 14:54:30 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20919 for ; Mon, 4 Jan 1999 14:54:29 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA01963; Mon, 4 Jan 1999 13:22:47 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from snowcrash.cymru.net (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA01952; Mon, 4 Jan 1999 13:22:43 -0500 (EST) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id SAA24497; Mon, 4 Jan 1999 18:22:32 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zxFX3-0007U1C; Mon, 4 Jan 99 19:19 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: Question on initial sequence numbers To: braden@ISI.EDU Date: Mon, 4 Jan 1999 19:19:16 +0000 (GMT) Cc: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com In-Reply-To: <199901041724.AA21892@gra.isi.edu> from "braden@ISI.EDU" at Jan 4, 99 09:24:42 am Content-Type: text Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk It seems somewhat dangerous and unneccessary. Random sequence numbering causing overlaps can cause corruption and fights. Its very rare - and there are actual protocol bugs in RST (Ian Heavens draft) which could do this too and are also extremely rare. What most vendors Im aware of do is to compute the sequence space as counter+hash_function(src,dst{, port, port}) Where the hash function is in itself an at least semi secure hash. That means that for any given connection space the sequence numbers follow rfc rules but that seeing one connection space doesn't let you identify another connection space properties unless the hash function is flawed. This covers the same space as "true" random numbers but doesn't break the specifications. Neither scheme is terribly effective if the attacker has snmp access to any router close to either end. Alan From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 14:56:08 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20969 for ; Mon, 4 Jan 1999 14:56:07 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA03183; Mon, 4 Jan 1999 13:34:02 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from zephyr.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA03179; Mon, 4 Jan 1999 13:34:00 -0500 (EST) From: braden@ISI.EDU Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id KAA26954; Mon, 4 Jan 1999 10:33:59 -0800 (PST) Date: Mon, 4 Jan 1999 10:30:09 -0800 Posted-Date: Mon, 4 Jan 1999 10:30:09 -0800 Message-Id: <199901041830.AA21949@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 4 Jan 1999 10:30:09 -0800 To: Richard_Berke@troweprice.com, mpatel@baynetworks.com Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft Cc: Braden@ISI.EDU, tcp-impl@lerc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> > *> I do not think that there is any requirement for initial sequence *> number. *> It could be anywhere between 0 & 4,294,967,295(2^32). *> !!?? See section 4.2.2.9 of RFC-1122, and Appendix B of RFC 1323. *> Apparently, if the connection uses the same ports and IP addresses, it *> should not *> matter if the sequence number is recycled because the previous control *> block is *> already gone and it does not remember to create any conflict. *> Old duplicate segments can cause erroneous data transfers. Bob Braden From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 14:56:15 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20980 for ; Mon, 4 Jan 1999 14:56:14 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA02298; Mon, 4 Jan 1999 13:26:42 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from smtp-gw.BayNetworks.COM (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA02292; Mon, 4 Jan 1999 13:26:38 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/09/30-E) with ESMTP id NAA07016; Mon, 4 Jan 1999 13:23:43 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id NAA08050; Mon, 4 Jan 1999 13:22:31 -0500 (EST) Received: from horizon.engeast (horizon [192.32.174.51]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id NAA05243; Mon, 4 Jan 1999 13:22:29 -0500 for Received: from horizon (localhost) by horizon.engeast (4.1/SMI-4.1) id AA02863; Mon, 4 Jan 99 13:21:24 EST Message-Id: <369106A4.63DECDAD@baynetworks.com> Date: Mon, 04 Jan 1999 13:21:24 -0500 From: "Manish Patel(x67071)" Organization: Bay Networks X-Mailer: Mozilla 3.04 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: Richard Berke Cc: Braden@ISI.EDU, tcp-impl@lerc.nasa.gov Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Richard Berke wrote: > > Bob Braden- > > I have been reading RFCs 793, 1072, 1185, and 1323 expecially regarding initial TCP sequence numbers, wrapping of the sequence numbers, and session boundaries. I ran into a dispute with Microsoft over their TCP stack behavior, and am trying to cite the RFCs. I hope you can help, or point me in the right direction. > > As I glean from the RFCs, the initial TCP sequence number of a session must be selected in a way that eliminates confusion whether subsequent packets belong to a previous session. The old way was to use increasing sequence numbers, driven by clock cycles. As higher transmission rates became possible, the lifetime of the TCP sequence number space decreased until it became under 3 minutes for 100 Mbps. The maximum segment lifetime is the key factor here. A proposed extension to the algorit > > In a packet trace of a recent session with a Microsoft server and a client, I saw a TCP session finish normally with a FIN/ACK. About a minute later, the client requested a new session, during which it pulled a data file from the server. The client and server used the same TCP ports as in the previous session. The server indicated in its SYN ACK a TCP sequence number of 2+million LOWER than the sequence number it had used to send data at the end of the previous session. The rest of the sequ > > Microsoft asserts this behavior is okay. In fact, they tell me that in the near future they will be selecting initial TCP sequence numbers at random as a technique to thwart hijacking of TCP sessions. Microsoft asserts that there is no regard in the client for the prior session TCP once the FINish process completes successfully. I don't find support for this position in the RFC's; I find the reverse. > > Is Microsoft lucky that it works? Are they non-compliant, but in a benign way? > Am I misunderstanding the requirement for increasing TCP sequence numbers for new sessions? > I do not think that there is any requirement for initial sequence number. It could be anywhere between 0 & 4,294,967,295(2^32). Apparently, if the connection uses the same ports and IP addresses, it should not matter if the sequence number is recycled because the previous control block is already gone and it does not remember to create any conflict. > Thanks for your patience and sharing your understanding, > Richard Berke > RPM Consulting > rberke@rpm.com > > ----- End Included Message ----- -- __ __ __Manish Patel__ ____________________________________________________________________ | mailto:mpatel@baynetworks.com (978) 916 7071 _____ ® | |____/|\__/|\_______/|\_______/|\___/|____/|____/| |___/|___/|___| / | \/ | \ / |_\ / | \ / | / | /_|___ _| / |__/ | / /\/ /\/| / | /| / /\ / / / / | /| / | / / / / / / / | / |_/ | / / / / / / _|___/ | / |_/ / | / | / | / | / | / | / | / | / | | / | / | / |/ |/ |/ |/ |/ |/ |/ |/ |_____|/ |/ |/ ____________________________________________________________________ | Bay Networks Inc., 600 Technology Park, Billerica, MA 01821. | |____________________________________________________________________| From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 15:13:02 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21154 for ; Mon, 4 Jan 1999 15:13:02 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA05624; Mon, 4 Jan 1999 13:58:30 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from snowcrash.cymru.net (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA05619; Mon, 4 Jan 1999 13:58:27 -0500 (EST) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id SAA25037; Mon, 4 Jan 1999 18:58:08 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zxG5U-0007U1C; Mon, 4 Jan 99 19:54 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft To: mpatel@BayNetworks.COM (Manish Patel) Date: Mon, 4 Jan 1999 19:54:51 +0000 (GMT) Cc: Richard_Berke@troweprice.com, Braden@ISI.EDU, tcp-impl@lerc.nasa.gov In-Reply-To: <369106A4.63DECDAD@baynetworks.com> from "Manish Patel" at Jan 4, 99 01:21:24 pm Content-Type: text Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Apparently, if the connection uses the same ports and IP addresses, it > should not > matter if the sequence number is recycled because the previous control > block is > already gone and it does not remember to create any conflict. Common misconception. The 2 minute drain time means all segments from the start of the wait time have left the network, it does not mean all control blocks are dead. Alan From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 15:22:36 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21225 for ; Mon, 4 Jan 1999 15:22:36 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id OAA07675; Mon, 4 Jan 1999 14:17:15 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from aland.bbn.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA07671; Mon, 4 Jan 1999 14:17:13 -0500 (EST) Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id LAA08484; Mon, 4 Jan 1999 11:14:17 -0800 (PST) Message-Id: <199901041914.LAA08484@aland.bbn.com> To: "Manish Patel(x67071)" cc: Richard Berke , Braden@ISI.EDU, tcp-impl@lerc.nasa.gov Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft In-reply-to: Your message of "Mon, 04 Jan 1999 13:21:24 EST." <369106A4.63DECDAD@baynetworks.com> Date: Mon, 04 Jan 1999 11:14:16 -0800 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <369106A4.63DECDAD@baynetworks.com>, "Manish Patel(x67071)" writes: > I do not think that there is any requirement for initial sequence >number. >It could be anywhere between 0 & 4,294,967,295(2^32). Yes there is -- read the Tomlinson paper and the Sunshine and Dalal paper on sequence numbers. The basic issue is if a segment with a sequence number from a previous incarnation of the connection is still alive in the network when the sequence space of the new connection overlaps that sequence number, then there's a chance that the old segment will get delivered to the destination and mistaken as new data. Craig From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 15:27:03 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21259 for ; Mon, 4 Jan 1999 15:27:03 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id OAA06776; Mon, 4 Jan 1999 14:09:05 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Twig.Rodents.Montreal.QC.CA (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA06767; Mon, 4 Jan 1999 14:08:59 -0500 (EST) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.5/8.8.5) id OAA05416; Mon, 4 Jan 1999 14:08:21 -0500 (EST) Date: Mon, 4 Jan 1999 14:08:21 -0500 (EST) From: der Mouse Message-Id: <199901041908.OAA05416@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: braden@ISI.EDU, Richard_Berke@troweprice.com Cc: tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Well, I'm hardly a TCP guru, but here's my take on this. I'm sure that if I've botched it, someone who *does* know will correct me. With that caveat...*charrrrge!* :) > In a packet trace [] I saw a TCP session finish normally with a > FIN/ACK. About a minute later, the client requested a new session, > []. The client and server used the same TCP ports as in the previous > session. The server indicated in its SYN ACK a TCP sequence number > of 2+million LOWER than the sequence number it had used to send data > at the end of the previous session. > Microsoft asserts this behavior is okay. In theory, they are wrong; in practice, they're probably right. > In fact, they tell me that in the near future they will be selecting > initial TCP sequence numbers at random as a technique to thwart > hijacking of TCP sessions. The person who told you this is either incompetent or confused. Random ISNs does not thwart session *hijacking*. What it does thwart is session *forging*, where host A pretends to be host B when speaking to host C, and manages to carry out a complete session without seeing any of C's response packets (which go to B, who may be dead or inaccessible or even nonexistent). In order to do this, A has to guess the ISN C chooses for the connection. > Microsoft asserts that there is no regard in the client for the prior > session TCP once the FINish process completes successfully. As I said above, this is a case where practice and theory diverge widely. IP packet TTLs are theoretically times in seconds. In practice, nowadays, they are hop counts (how many routers, even those that can have >1sec queues, actually bother to decrement the TTL for every second a packet spends waiting?). The theoretical reason for the holddown is that a data packet may fall into a routing warp and get stuck in a very high-delay path; a retransmission succeeds and the conneciton completes. Later, the stuck packet can emerge and hit the new session. This is possible whether or not the client has FINned the first connection, and if the sequence numbers are reasonable, it will be accepted as valid data. The requirement is intended to ensure that by the time the second connection's sequence numbers have made it around to where they overlap the first connection, the MSL will have caused any old segments to expire if they're still bouncing around the network somewhere. In practice, this happens rarely enough to be ignored, especially by the likes of "so what's rebooting twice a day?" Microsoft. Perhaps they'll change their tune when some big customer gets hit by a once-in-a-blue-moon event like this; more likely, since it won't be easily reproducible, they'll just write it off. 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 Jan 4 16:09:23 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA21734 for ; Mon, 4 Jan 1999 16:09:22 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA13214; Mon, 4 Jan 1999 15:04:02 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from snowcrash.cymru.net (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA13208; Mon, 4 Jan 1999 15:04:00 -0500 (EST) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id UAA26249 for ; Mon, 4 Jan 1999 20:03:58 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zxH7E-0007U1C; Mon, 4 Jan 99 21:00 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: SACK behaviour To: tcp-impl@lerc.nasa.gov Date: Mon, 4 Jan 1999 21:00:43 +0000 (GMT) Content-Type: text Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I've got a set of traces from a certain vendors hub product that seem to show that they ignore connection requests with SACK. Is anyone keeping a database of broken with SACK tcp products ? From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 16:37:26 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22037 for ; Mon, 4 Jan 1999 16:37:25 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA16158; Mon, 4 Jan 1999 15:30:18 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from smtp-gw.BayNetworks.COM (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA16153; Mon, 4 Jan 1999 15:30:15 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/09/30-E) with ESMTP id PAA14118; Mon, 4 Jan 1999 15:29:33 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id PAA23577; Mon, 4 Jan 1999 15:28:13 -0500 (EST) Received: from horizon.engeast (horizon [192.32.174.51]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA11447; Mon, 4 Jan 1999 15:28:12 -0500 for Received: from horizon (localhost) by horizon.engeast (4.1/SMI-4.1) id AA10170; Mon, 4 Jan 99 15:24:45 EST Message-Id: <3691238C.695678E2@baynetworks.com> Date: Mon, 04 Jan 1999 15:24:44 -0500 From: "Manish Patel(x67071)" Organization: Bay Networks X-Mailer: Mozilla 3.04 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: Alan Cox Cc: Richard_Berke@troweprice.com, Braden@ISI.EDU, tcp-impl@lerc.nasa.gov Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Alan Cox wrote: > > > Apparently, if the connection uses the same ports and IP addresses, it > > should not > > matter if the sequence number is recycled because the previous control > > block is > > already gone and it does not remember to create any conflict. > > Common misconception. > > The 2 minute drain time means all segments from the start of the wait time > have left the network, it does not mean all control blocks are dead. > I agree that if the segments from the previous session arrives after new connection(with same socket pair) starts can cause the problem. But, there should not be any duplicate control block. If the new connection is established using the same port and IP address, the old block must be dead, otherwise the new connection must be using different port or should be rejected if compels to use the same port. Please see my comments below and advise. > Alan > > In a packet trace of a recent session with a Microsoft server and a client, I saw a TCP session finish normally with a FIN/ACK. About a minute later, the client requested a new session, during which it pulled a data file from the server. The client and server used the same TCP ports as in the previous session. The server indicated in its SYN ACK a TCP sequence number of 2+million LOWER than the sequence number it had used to send data at the end of the previous session. The rest of the sequ > > Microsoft asserts this behavior is okay. In fact, they tell me that in the near future they will be selecting initial TCP sequence numbers at random as a technique to thwart hijacking of TCP sessions. Microsoft asserts that there is no regard in the client for the prior session TCP once the FINish process completes successfully. I don't find support for this position in the RFC's; I find the reverse. > > Is Microsoft lucky that it works? Are they non-compliant, but in a benign way? > Am I misunderstanding the requirement for increasing TCP sequence numbers for new sessions? > Seems like it works because receiving FIN and closing gracefully reflects that there is no delayed segment from previous connection. How many possibilities that a segment from the old connection would arrive? 1. The packet is lost in the network or delayed by a great time. (Receiving end will not process FIN an OSS) 2. The ack for that packet got lost. (Sending end will not forward window and/or send FIN) So, in any case the the old connection would not have closed gracefully and the new connection would have different socket. Lower sequence number could only be a problem in case of RST, where there is a possibility of previous session segment arrival. If above is not true, let me know. Thanks, -- __ __ __Manish Patel__ ____________________________________________________________________ | mailto:mpatel@baynetworks.com (978) 916 7071 _____ ® | |____/|\__/|\_______/|\_______/|\___/|____/|____/| |___/|___/|___| / | \/ | \ / |_\ / | \ / | / | /_|___ _| / |__/ | / /\/ /\/| / | /| / /\ / / / / | /| / | / / / / / / / | / |_/ | / / / / / / _|___/ | / |_/ / | / | / | / | / | / | / | / | / | | / | / | / |/ |/ |/ |/ |/ |/ |/ |/ |_____|/ |/ |/ ____________________________________________________________________ | Bay Networks Inc., 600 Technology Park, Billerica, MA 01821. | |____________________________________________________________________| From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 17:23:12 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22516 for ; Mon, 4 Jan 1999 17:23:12 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA20740; Mon, 4 Jan 1999 16:18:13 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from aland.bbn.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA20732; Mon, 4 Jan 1999 16:18:10 -0500 (EST) Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id NAA08811; Mon, 4 Jan 1999 13:17:20 -0800 (PST) Message-Id: <199901042117.NAA08811@aland.bbn.com> To: "Manish Patel(x67071)" cc: tcp-impl@lerc.nasa.gov Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft In-reply-to: Your message of "Mon, 04 Jan 1999 15:24:44 EST." <3691238C.695678E2@baynetworks.com> Date: Mon, 04 Jan 1999 13:17:20 -0800 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <3691238C.695678E2@baynetworks.com>, "Manish Patel(x67071)" writes: > Seems like it works because receiving FIN and closing gracefully >reflects that >there is no delayed segment from previous connection. No -- it simply says that a FIN arrived (packets may arrive in any order). Craig From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 17:52:39 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22891 for ; Mon, 4 Jan 1999 17:52:39 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA23229; Mon, 4 Jan 1999 16:43:30 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA23216; Mon, 4 Jan 1999 16:43:27 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id OAA03479 env-from ; Mon, 4 Jan 1999 14:43:22 -0700 (MST) Date: Mon, 4 Jan 1999 14:43:22 -0700 (MST) From: Vernon Schryver Message-Id: <199901042143.OAA03479@calcite.rhyolite.com> To: tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers Cc: Richard_Berke@troweprice.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: braden@ISI.EDU > To: tcp-impl@lerc.nasa.gov > Cc: braden@ISI.EDU, Richard_Berke@troweprice.com > ... > I have been reading RFCs 793, 1072, 1185, and 1323 expecially ... ] From: alan@lxorguk.ukuu.org.uk (Alan Cox) ]It seems somewhat dangerous and unneccessary. ... ] What most vendors Im aware of do is to compute the sequence space as ] ] counter+hash_function(src,dst{, port, port}) ] ... Yes, RFC 1948 should be added to that list of RFC's. Besides describing the New Offishal IETF method of generating initial sequence numbers, RFC 1948 talks about reasons to space them. There is some distinctly lame Security Checking Software out there that the suckers--oops--network administrators and purchasers are using that purports to detect insecure initial sequence numbers. Its documentation evidently mentions RFC 1948 and so has made RFC 1948 a check-list item around the world. Never mind that according to its vendor, this wonderful software does not detect some dubious initial sequence numbers, nor that it's test apparently consists of sending a burst of back-to-back SYN's on the local LAN, and then looking for constant, non-zero deltas. If the bad guy is on your LAN, then worrying that he might guess initial sequences numbers is as perceptive as worrying about getting fleas by petting a rabid wolf. As far as I can see, there would be no problem (other than cost) with what Microsoft is alledged to be doing if they guarantee that all initial sequence numbers are "sufficently far apart." "Smaller" is as good as "larger", provided the delta is large enough so the probability of collision is small enough. Incrementing with a clock is one way to get "far apart," but there are plenty of other permutations of the natural order of the most significant ~16 bits that would work just as well. Of course, no one with a clue about the problem would bother with a simple permuation such as an LCRN. You must assume the bad guy has access to your source and can get enough samples from any running system to solve any non-crypto random number generator. However, if you were willing to keep enough state and spend enough cycles, you might use a dynamic mapping of the most significant bits. You could be to keep cycling your secure random number generator until it delivers a number sufficiently different from recent choices. It's not what I'd do, but maybe Microsoft is expecting faster computers than those I've written initial sequence number code for. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 18:00:11 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA22932 for ; Mon, 4 Jan 1999 18:00:11 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA24327; Mon, 4 Jan 1999 16:57:14 -0500 (EST) Received: from mintaka.isr.umd.edu (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA24321; Mon, 4 Jan 1999 16:57:12 -0500 (EST) Received: from xena.isr.umd.edu ((IDENT root)@xena.isr.umd.edu [128.8.111.179]) by mintaka.isr.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id QAA08433; Mon, 4 Jan 1999 16:52:29 -0500 (EST) Received: from xena.isr.umd.edu ((IDENT sendmail)@localhost [127.0.0.1]) by xena.isr.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id QAA21280; Mon, 4 Jan 1999 16:53:45 -0500 (EST) Received: from localhost by xena.isr.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id QAA21275; Mon, 4 Jan 1999 16:53:43 -0500 (EST) X-Authentication-Warning: xena.isr.umd.edu: vgb owned process doing -bs Date: Mon, 4 Jan 1999 16:53:43 -0500 (EST) From: "Vijay G. Bharadwaj" Reply-To: "Vijay G. Bharadwaj" To: "Manish Patel(x67071)" cc: Alan Cox , Richard_Berke@troweprice.com, Braden@ISI.EDU, tcp-impl@lerc.nasa.gov Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft In-Reply-To: <3691238C.695678E2@baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Mon, 4 Jan 1999, Manish Patel(x67071) wrote: > Seems like it works because receiving FIN and closing gracefully > reflects that > there is no delayed segment from previous connection. No it doesn't. > How many possibilities that a segment from the old connection would > arrive? > > 1. The packet is lost in the network or delayed by a great time. > (Receiving end will not process FIN an OSS) Let's look at this scenario in some detail. - Packet is delayed greatly in the network. - Sender retransmits packet. - Retransmission (or maybe original) arrives at receiver. - Receiver ACKs. - In due course FIN happens. - New connection starts up. - Now the delayed segment arrives and is accepted as valid. Also consider a more complicated scenario: - ACK packet gets "greatly delayed" - but a later ACK covers this sequence #, so things move on - FIN happens, connection closes - new connection starts, reusing sequence space - happens to lose a segment with seq # just below our stale ACK - stale ACK arrives - sender moves on, receiver is still waiting for segment - this connection is doomed In short, doing this is wrong and dangerous. If it works, it's because you get lucky and the typical user doesn't know when he/she gets unlucky. ("Darn, this webpage is fouled up, let me just hit reload.") -Vijay From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 18:59:52 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA23266 for ; Mon, 4 Jan 1999 18:59:52 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA28336; Mon, 4 Jan 1999 17:50:48 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from frantic.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA28329; Mon, 4 Jan 1999 17:50:45 -0500 (EST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id QAA27181; Mon, 4 Jan 1999 16:50:39 -0600 (CST) Date: Mon, 4 Jan 1999 16:50:39 -0600 (CST) From: David Borman Message-Id: <199901042250.QAA27181@frantic.bsdi.com> To: tcp-impl@lerc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: Question on initial sequence numbers Cc: Richard_Berke@troweprice.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon, > From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 16:07:45 1999 > X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f > Date: Mon, 4 Jan 1999 14:43:22 -0700 (MST) > From: Vernon Schryver > To: tcp-impl@lerc.nasa.gov > Subject: Re: Question on initial sequence numbers > Cc: Richard_Berke@troweprice.com > ... > As far as I can see, there would be no problem (other than cost) with what > Microsoft is alledged to be doing if they guarantee that all initial > sequence numbers are "sufficently far apart." "Smaller" is as good as > "larger", provided the delta is large enough so the probability of > collision is small enough. Incrementing with a clock is one way to get > "far apart," but there are plenty of other permutations of the natural > order of the most significant ~16 bits that would work just as well. Well, I wouldn't say "no problem". What I see at issue is that many TCP implementations (such as BSD) will allow a connection in TIME-WAIT to be reused before the TIME-WAIT has expired, if the incoming SYN has an ISS that is greater than the FIN from the previous instance of the connection. Otherwise, since there is no ACK bit, the SYN and any retranmissions of the SYN will be silently dropped until the TIME-WAIT state expires. So, for a TCP that generates random ISS values, when quickly re-using a TCP connection, they are going to have a 50/50 chance of the connection either being quickly established, or hung up doing SYN retransmissions until the TIME-WAIT connection on the server goes away or the client gives up on its SYN retransmissions. Of course, one problem is that since most TCPs destroy the PCB after getting the FIN in LAST-ACK state, if they immediatly reuse the connection they have no idea what the last sequence number used was. So the new ISS is just the standard ISS increment, and if the previous connection transfered more data than the delta between the ISSs, the ISS on the new SYN won't pass the TIME-WAIT check... -David Borman, dab@bsdi.com PS: by "standard ISS increment", I don't mean just a fixed value. From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 19:00:23 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23285 for ; Mon, 4 Jan 1999 19:00:22 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA27346; Mon, 4 Jan 1999 17:38:59 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from palrel1.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA27342; Mon, 4 Jan 1999 17:38:57 -0500 (EST) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.8.80.103]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id OAA06575 for ; Mon, 4 Jan 1999 14:38:48 -0800 (PST) Received: from cup.hp.com (raj@loiter [15.8.80.103]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id OAA25064 for ; Mon, 4 Jan 1999 14:38:34 -0800 (PST) Message-ID: <369142EA.9276C0DF@cup.hp.com> Date: Mon, 04 Jan 1999 14:38:34 -0800 From: Rick Jones Organization: SNSL X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: tcp-impl@lerc.nasa.gov Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk There is also a stack out there that does not always wait TIME_WAIT state length. It has a fixed number of TCB's (configurable through a registry parm) and if all the TCB's are busy when a SYN arrives, it will take one still in TIME_WAIT. The higher the connection rate, the shorter TIME_WAIT gets. I think the default maximum is something like 2000 TCB's. rick jones -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 19:00:59 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23303 for ; Mon, 4 Jan 1999 19:00:58 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA28481; Mon, 4 Jan 1999 17:54:55 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from snowcrash.cymru.net (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA28477; Mon, 4 Jan 1999 17:54:52 -0500 (EST) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id WAA29199; Mon, 4 Jan 1999 22:54:47 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zxJmU-0007U2C; Mon, 4 Jan 99 23:51 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: Question on initial sequence numbers To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Mon, 4 Jan 1999 23:51:29 +0000 (GMT) Cc: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com In-Reply-To: <199901042143.OAA03479@calcite.rhyolite.com> from "Vernon Schryver" at Jan 4, 99 02:43:22 pm Content-Type: text Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > collision is small enough. Incrementing with a clock is one way to get > "far apart," but there are plenty of other permutations of the natural > order of the most significant ~16 bits that would work just as well. > Of course, no one with a clue about the problem would bother with a simple > permuation such as an LCRN. You must assume the bad guy has access to Its not as simple as it first looks because BSD also allowed the shortcut from timewait for sequence spaces subject to certain range rules. That means you either have to ignore the shortcuts or for a given src,dst,ports pair keep incrementing sanely From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 19:20:21 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23434 for ; Mon, 4 Jan 1999 19:20:20 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id SAA29675; Mon, 4 Jan 1999 18:17:05 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id SAA29669; Mon, 4 Jan 1999 18:17:02 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id QAA03757 env-from ; Mon, 4 Jan 1999 16:16:57 -0700 (MST) Date: Mon, 4 Jan 1999 16:16:57 -0700 (MST) From: Vernon Schryver Message-Id: <199901042316.QAA03757@calcite.rhyolite.com> To: tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers Cc: Richard_Berke@troweprice.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: David Borman > To: tcp-impl@lerc.nasa.gov, vjs@calcite.rhyolite.com > Cc: Richard_Berke@troweprice.com > > ... > > As far as I can see, there would be no problem (other than cost) with what > > Microsoft is alledged to be doing if they guarantee that all initial > > sequence numbers are "sufficently far apart." "Smaller" is as good as > > "larger", provided the delta is large enough so the probability of > ... > Well, I wouldn't say "no problem". What I see at issue is that many > TCP implementations (such as BSD) will allow a connection in TIME-WAIT to > be reused before the TIME-WAIT has expired, if the incoming SYN has an ISS > that is greater than the FIN from the previous instance of the connection. > Otherwise, since there is no ACK bit, the SYN and any retranmissions of the > SYN will be silently dropped until the TIME-WAIT state expires. > > So, for a TCP that generates random ISS values, when quickly re-using a > TCP connection, they are going to have a 50/50 chance of the connection > either being quickly established, or hung up doing SYN retransmissions until > the TIME-WAIT connection on the server goes away or the client gives up on > its SYN retransmissions. That's a good point. What is the political odor of that BSD feature in the IETF today? > Of course, one problem is that since most TCPs destroy the PCB after > getting the FIN in LAST-ACK state, if they immediatly reuse the > connection they have no idea what the last sequence number used was. > So the new ISS is just the standard ISS increment, and if the previous > connection transfered more data than the delta between the ISSs, the > ISS on the new SYN won't pass the TIME-WAIT check... Both this problem and your other point apply only if the same (addr,port,addr,port) 4-tuple is used, right? In both problems, isn't the worst case a TIME-WAIT delay, and not the data corruption of the likely implementation of the alledged random Microsoft ISS's? Of course, over the years we've each heard vastly more complaints about TIME-WAIT delays than about data corruption, and never mind validity. How likely is the re-use of a 4-tuple today? In ancient days, wasn't it fairly unlikely because hosts had enough state to keep the client end of a connection in TIME-WAIT? Reboot-every-few-minutes DOS hurt that protection, but current Microsoft systems don't like unscheduled rebooting and simply don't reboot quickly. (A 300 MHz PII WIN95 w/fast disks of my acquantance wants about 100 seconds if it doesn't insist on running chkdisk, and lots more if it does. Don't ask about the agility of the 33 MHz 486 NT system I use. Redhat 5.2 Linux is worse.) On the fifth hand, dynamic PPP IP addresses could mean that some 4-tuples are rather popular. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 19:26:25 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23500 for ; Mon, 4 Jan 1999 19:26:24 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id SAA29646; Mon, 4 Jan 1999 18:16:20 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from dm.cobaltmicro.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id SAA29642; Mon, 4 Jan 1999 18:16:18 -0500 (EST) Received: (from davem@localhost) by dm.cobaltmicro.com (8.8.7/8.8.7) id PAA27816; Mon, 4 Jan 1999 15:17:05 -0800 Date: Mon, 4 Jan 1999 15:17:05 -0800 Message-Id: <199901042317.PAA27816@dm.cobaltmicro.com> From: "David S. Miller" To: dab@BSDI.COM CC: tcp-impl@lerc.nasa.gov, vjs@calcite.rhyolite.com, Richard_Berke@troweprice.com In-reply-to: <199901042250.QAA27181@frantic.bsdi.com> (message from David Borman on Mon, 4 Jan 1999 16:50:39 -0600 (CST)) Subject: Re: Question on initial sequence numbers References: <199901042250.QAA27181@frantic.bsdi.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Date: Mon, 4 Jan 1999 16:50:39 -0600 (CST) From: David Borman Of course, one problem is that since most TCPs destroy the PCB after getting the FIN in LAST-ACK state, if they immediatly reuse the connection they have no idea what the last sequence number used was. And there are some implementations which destroy the PCB yet still keep around enough state to compute the ISS properly if the TIME_WAIT is awoken back into a new connection. Later, David S. Miller davem@dm.cobaltmicro.com From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 19:39:44 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23674 for ; Mon, 4 Jan 1999 19:39:44 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id SAA00675; Mon, 4 Jan 1999 18:33:17 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id SAA00671; Mon, 4 Jan 1999 18:33:15 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id QAA03867 env-from ; Mon, 4 Jan 1999 16:33:12 -0700 (MST) Date: Mon, 4 Jan 1999 16:33:12 -0700 (MST) From: Vernon Schryver Message-Id: <199901042333.QAA03867@calcite.rhyolite.com> To: Richard_Berke@troweprice.com, tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: alan@lxorguk.ukuu.org.uk (Alan Cox) > > collision is small enough. Incrementing with a clock is one way to get > > "far apart," but there are plenty of other permutations of the natural > Its not as simple as it first looks because BSD also allowed the shortcut > from timewait for sequence spaces subject to certain range rules. That means > you either have to ignore the shortcuts or for a given src,dst,ports pair > keep incrementing sanely Or keep asking your crypto random number generator until it gives you a number far enough away on the down side that it looks "larger." That's at most only another factor of two in the hammering on your random number generator. One MD5 is tolerable for RFC 1948 least significant bits on modern hardware, but the worst case number of MD5 (or other) cyclings to guarantee far apart fully random ISS's sounds large enough that a mere factor of two wouldn't matter. Again, I personally wouldn't bother, and doubt anyone with a clue about ISS's would. It's too easy to fiddle the less significant bits as suggested by RFC 1948 or other mechanisms (e.g. usec resolution clocks). I also suspect that any real random ISS implementation would not worry about getting far apart ISS, but would be be something "kick ass" and bogus like ISS=rand(3). Vernon Schryver vjs@rhyolite.com P.S. I apologize for not combining this point with my previous message. P.P.S. I've been told that the official doctrine of a certain large software outfit is that all of their programmers are "kick ass." From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 19:46:27 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23707 for ; Mon, 4 Jan 1999 19:46:26 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id SAA01193; Mon, 4 Jan 1999 18:42:40 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-main) id SAA01189; Mon, 4 Jan 1999 18:42:37 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA01302; Mon, 4 Jan 1999 15:41:59 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id PAA20631; Mon, 4 Jan 1999 15:41:58 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA10867; Mon, 4 Jan 1999 15:41:54 -0800 (PST) Date: Mon, 4 Jan 1999 15:41:53 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Question on initial sequence numbers To: Vernon Schryver Cc: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com In-Reply-To: "Your message with ID" <199901042316.QAA03757@calcite.rhyolite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > In both problems, isn't the worst case a TIME-WAIT delay, and not the data > corruption of the likely implementation of the alledged random Microsoft > ISS's? Of course, over the years we've each heard vastly more complaints > about TIME-WAIT delays than about data corruption, and never mind validity. I guess the reason is that most implementations' ISN go forward instead of backward a little bit as described in the original mail about MS stack. Going forward a little bit in sequence number space is better in protecting against sequence number collision than going backward a little bit, which is equivalent to going forward too much. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Mon Jan 4 20:53:00 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA24036 for ; Mon, 4 Jan 1999 20:53:00 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id TAA04722; Mon, 4 Jan 1999 19:47:05 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from sales-finance.vpnet.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id TAA04718; Mon, 4 Jan 1999 19:47:03 -0500 (EST) Received: by vpnet.com with Internet Mail Service (5.0.1460.8) id ; Mon, 4 Jan 1999 16:46:38 -0800 Message-ID: <70C20C1647EBD11183F800805FA67B43011378@vpnet.com> From: Sankar Ramamoorthi To: "'Kacheong Poon'" , Vernon Schryver Cc: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com Subject: RE: Question on initial sequence numbers Date: Mon, 4 Jan 1999 16:46:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The problem becomes more significant with devices like network appliances, becoming more common. These have characterstics like High Availability, fast reboot times etc. It is likely all TIME-WAIT is lost across reboots/failover. -- sankar -- -----Original Message----- From: Kacheong Poon [mailto:Kacheong.Poon@Eng.Sun.COM] Sent: Monday, January 04, 1999 3:42 PM To: Vernon Schryver Cc: tcp-impl@lerc.nasa.gov; Richard_Berke@troweprice.com Subject: Re: Question on initial sequence numbers > In both problems, isn't the worst case a TIME-WAIT delay, and not the data > corruption of the likely implementation of the alledged random Microsoft > ISS's? Of course, over the years we've each heard vastly more complaints > about TIME-WAIT delays than about data corruption, and never mind validity. I guess the reason is that most implementations' ISN go forward instead of backward a little bit as described in the original mail about MS stack. Going forward a little bit in sequence number space is better in protecting against sequence number collision than going backward a little bit, which is equivalent to going forward too much. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 13:34:07 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA09254 for ; Tue, 5 Jan 1999 13:34:06 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id LAA12242; Tue, 5 Jan 1999 11:34:16 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from boreas.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id LAA12224; Tue, 5 Jan 1999 11:34:13 -0500 (EST) Received: from isi.edu (ras02.isi.edu [128.9.176.102]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05634; Tue, 5 Jan 1999 08:34:00 -0800 (PST) Message-ID: <3692AF65.E00D5C36@isi.edu> Date: Tue, 05 Jan 1999 16:33:41 -0800 From: Joe Touch Organization: USC/ISI X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'Kacheong Poon'" , Vernon Schryver , tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com Subject: Re: Question on initial sequence numbers References: <70C20C1647EBD11183F800805FA67B43011378@vpnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Sankar Ramamoorthi wrote: > > The problem becomes more significant with devices like network appliances, > becoming more common. These have characterstics like High Availability, fast > reboot > times etc. It is likely all TIME-WAIT is lost across reboots/failover. The 2*MSL is supposed to be ensured; this is accomplished by either: - a reboot that takes 2*MSL anyway - prohibiting new connections for 2*MSL after a reboot Accepting new connections immediately after a quick reboot would be 'breaking' that rule. Joe From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 14:17:02 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09766 for ; Tue, 5 Jan 1999 14:17:02 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id MAA19863; Tue, 5 Jan 1999 12:44:56 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from sales-finance.vpnet.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id MAA19856; Tue, 5 Jan 1999 12:44:51 -0500 (EST) Received: by vpnet.com with Internet Mail Service (5.0.1460.8) id ; Tue, 5 Jan 1999 09:44:29 -0800 Message-ID: <70C20C1647EBD11183F800805FA67B43011381@vpnet.com> From: Sankar Ramamoorthi To: "'Joe Touch'" , Sankar Ramamoorthi Cc: "'Kacheong Poon'" , Vernon Schryver , tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com Subject: RE: Question on initial sequence numbers Date: Tue, 5 Jan 1999 09:44:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I agree with you what you say ie: the 2*MSL should not be broken. My concern was whether all devices with fast reboot times or failover capabilites observe this rule or even know about it. Some examples of such devices are proxy servers, packet shapers, transparent proxy servers... -- sankar -- -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Tuesday, January 05, 1999 4:34 PM To: Sankar Ramamoorthi Cc: 'Kacheong Poon'; Vernon Schryver; tcp-impl@lerc.nasa.gov; Richard_Berke@troweprice.com Subject: Re: Question on initial sequence numbers Sankar Ramamoorthi wrote: > > The problem becomes more significant with devices like network appliances, > becoming more common. These have characterstics like High Availability, fast > reboot > times etc. It is likely all TIME-WAIT is lost across reboots/failover. The 2*MSL is supposed to be ensured; this is accomplished by either: - a reboot that takes 2*MSL anyway - prohibiting new connections for 2*MSL after a reboot Accepting new connections immediately after a quick reboot would be 'breaking' that rule. Joe From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 14:59:26 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA10173 for ; Tue, 5 Jan 1999 14:59:25 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA26530; Tue, 5 Jan 1999 13:44:30 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA26518; Tue, 5 Jan 1999 13:44:28 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA6B2; Tue, 5 Jan 1999 10:44:24 -0800 Message-ID: <36925D80.E697B218@ehsco.com> Date: Tue, 05 Jan 1999 10:44:16 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com Subject: Re: Question on initial sequence numbers References: <70C20C1647EBD11183F800805FA67B43011378@vpnet.com> <3692AF65.E00D5C36@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Accepting new connections immediately after a quick reboot > would be 'breaking' that rule. Almost every OS that I've ever tested breaks this rule, unfortunately. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 16:06:35 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11249 for ; Tue, 5 Jan 1999 16:06:35 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id OAA03197; Tue, 5 Jan 1999 14:45:06 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA03178; Tue, 5 Jan 1999 14:45:02 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id MAA06903 env-from ; Tue, 5 Jan 1999 12:44:59 -0700 (MST) Date: Tue, 5 Jan 1999 12:44:59 -0700 (MST) From: Vernon Schryver Message-Id: <199901051944.MAA06903@calcite.rhyolite.com> To: Richard_Berke@troweprice.com, tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "Eric A. Hall" > > Accepting new connections immediately after a quick reboot > > would be 'breaking' that rule. > > Almost every OS that I've ever tested breaks this rule, unfortunately. That rule is not broken if the system cannot be started in less than 2*MSL. Only systems that can do a genuine quick reboot are able to break that rule. If the system is quiet for 120 seconds after being told to reboot and until the first user process runs, then the system cannot and does not break that rule. Which systems have you tested that break that rule? I can't think of a operating system that I've seen in recent years that could break that rule if it wanted to, because they boot soooo sloooowly. Windows 95, Windows 98, Windows NT Workstation 4.0, IRIX of all versions since it was renamed from "UNIX" in about 1987, all versions of SunOS and Solaris I've seen (albeit none newer ~1994), Linux in Redhat 5.1 and 5.2, NetBSD as of a few years ago, and FreeBSD through 2.2.7 are unable to break that rule unless you insist on the official, full MSL instead of the common BSD short value. Some of those systems could break that rule even with the full 120 second MSL of RFC 793. SHEESH!--Some could not break that rule even if the MSL were significantly longer than 120 seconds. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 16:31:56 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11554 for ; Tue, 5 Jan 1999 16:31:56 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA07658; Tue, 5 Jan 1999 15:22:43 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from palrel3.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA07647; Tue, 5 Jan 1999 15:22:40 -0500 (EST) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.8.80.103]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id MAA22900 for ; Tue, 5 Jan 1999 12:22:44 -0800 (PST) Received: from cup.hp.com (raj@loiter [15.8.80.103]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id MAA26464 for ; Tue, 5 Jan 1999 12:22:38 -0800 (PST) Message-ID: <3692748D.6F89ED22@cup.hp.com> Date: Tue, 05 Jan 1999 12:22:37 -0800 From: Rick Jones Organization: SNSL X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers References: <199901051944.MAA06903@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk All it really takes is switching an IP address from one system to another in the event of failure. Then instead of being a question of how long it takes for a system to reboot, it becomes a question of how long it takes for the system failure to be detected and the IP address (identity) be assumed by the back-up system (and of course, whether or not the backup system was being kept up-to-date wrt TIME_WAIT. Given the pressures on HA in certain markets, I think there is pressure to have this detection and failover happen in << TIME_WAIT. I am reasonably confident that modulo icky things like DB recovery the switchovers are happening < 60 seconds today on a number of platforms. Probably much less. rick jones -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 18:51:42 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12636 for ; Tue, 5 Jan 1999 18:51:41 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA18999; Tue, 5 Jan 1999 17:12:19 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA18995; Tue, 5 Jan 1999 17:12:16 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id PAA07375 env-from ; Tue, 5 Jan 1999 15:12:11 -0700 (MST) Date: Tue, 5 Jan 1999 15:12:11 -0700 (MST) From: Vernon Schryver Message-Id: <199901052212.PAA07375@calcite.rhyolite.com> To: tcp-impl@lerc.nasa.gov Subject: fast booting & 2*MSL Cc: Richard_Berke@troweprice.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Rick Jones > All it really takes is switching an IP address from one system to > another in the event of failure. ... > Given the pressures on HA in certain markets, I think there is pressure > to have this detection and failover happen in << TIME_WAIT. I am > reasonably confident that modulo icky things like DB recovery the > switchovers are happening < 60 seconds today on a number of platforms. > Probably much less. That's a good point. I but both SGI's and HP's HA offerings switch in less than 60 seconds at least some times. ] From: rames ] To: Vernon Schryver ] CC: Richard_Berke@troweprice.com, tcp-impl@lerc.nasa.gov ] > Which systems have you tested that break that rule? ] ] Embedded systems with TCP/IP stacks in ROM are up in a matter of ] seconds. See, for example, the AMD Net186 Network Appliance demo board ] at ] ... That's another good point. One saving grace is that such systems are not likely to have WWW servers hit by zillions of clients. They are also less likely to originate TCP connections, and so can hope their peers will honor TIME-WAIT and pick new port numbers. They are also simpler and could be fixed more easily. On the other hand, their designers are even more likely to take short cuts for speed over reliability and to feel pressures to start working sooner after a reboot. ] From: "Eric A. Hall" ] > > Almost every OS that I've ever tested breaks this rule, unfortunately. ] ] > Which systems have you tested that break that rule? ] ] I can get Linux and NT to boot in less than 120 seconds by thinning down ] the number of services in use and using fast gear. I could probably boot ] a Sun box in that same time frame if I tried hard enough. I'd have to see Redhat 5.1, 5.2, or NT 4.0 boot in less than 120 seconds to believe it. Even so, note that I wrote about the de facto standard 2*MSL, which is less than 2 minutes. ] Big systems ] (VMS, MPE) take longer, but that's mostly due to hardware. That must involve a definition of "hardware" other than the one I use. ] Even Compaq ] systems (with their overzealous POST tests) running DOS can take longer ] than two minutes, but the OS doesn't care. Yes, cold-start tests take far too long on many systems, and have for decades. I figure that syndrome is another case of work expanding to fill the time available. If power-on diagnostics don't take much time, then the organization responsible for them loses clout and can suffer. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 19:08:12 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12745 for ; Tue, 5 Jan 1999 19:08:11 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA23788; Tue, 5 Jan 1999 17:52:34 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from snowcrash.cymru.net (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA23784; Tue, 5 Jan 1999 17:52:32 -0500 (EST) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id WAA22887; Tue, 5 Jan 1999 22:52:26 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zxgDm-0007U2C; Tue, 5 Jan 99 23:49 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: fast booting & 2*MSL To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Tue, 5 Jan 1999 23:49:09 +0000 (GMT) Cc: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com In-Reply-To: <199901052212.PAA07375@calcite.rhyolite.com> from "Vernon Schryver" at Jan 5, 99 03:12:11 pm Content-Type: text Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > ] I can get Linux and NT to boot in less than 120 seconds by thinning down > ] the number of services in use and using fast gear. I could probably boot > ] a Sun box in that same time frame if I tried hard enough. > > I'd have to see Redhat 5.1, 5.2, or NT 4.0 boot in less than 120 seconds > to believe it. Even so, note that I wrote about the de facto standard > 2*MSL, which is less than 2 minutes. Been there, done that. The PC POST test tends to save you but from a warm restart you can easily have a PC OS rebooting in under 60 seconds. A read only box like a dedicated web server with the root fs burned on CDROM for security reasons (hey its cheap and effective) can easily come up in 30 seconds including BIOS time. There are other cases of fast address change. An ISDN dialup port can be reused in 3 or 4 seconds. > the time available. If power-on diagnostics don't take much time, then > the organization responsible for them loses clout and can suffer. PS/2 8) From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 19:13:38 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12824 for ; Tue, 5 Jan 1999 19:13:38 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA23932; Tue, 5 Jan 1999 17:56:56 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from palrel3.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA23928; Tue, 5 Jan 1999 17:56:54 -0500 (EST) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.8.80.103]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id OAA05181 for ; Tue, 5 Jan 1999 14:56:56 -0800 (PST) Received: from cup.hp.com (raj@loiter [15.8.80.103]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id OAA26652 for ; Tue, 5 Jan 1999 14:56:50 -0800 (PST) Message-ID: <369298B2.45CD1773@cup.hp.com> Date: Tue, 05 Jan 1999 14:56:50 -0800 From: Rick Jones Organization: SNSL X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: tcp-impl@lerc.nasa.gov Subject: Re: fast booting & 2*MSL References: <199901052212.PAA07375@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > ] Embedded systems with TCP/IP stacks in ROM are up in a matter of > ] seconds. See, for example, the AMD Net186 Network Appliance demo board > ] at > ] ... > > That's another good point. One saving grace is that such systems are not > likely to have WWW servers hit by zillions of clients. They are also less > likely to originate TCP connections, and so can hope their peers will > honor TIME-WAIT and pick new port numbers. They are also simpler and > could be fixed more easily. On the other hand, their designers are even > more likely to take short cuts for speed over reliability and to feel > pressures to start working sooner after a reboot. There is no guarantee that an embedded web server will have the clients do the initial FIN is there? I suspect (not that I have any real data...) that concern for "connection resources" would be such that the embedded designer would be inclined to be aggressive in closing connections - ie not make much use of persistent connections where the chances are better that the client will initiate the close. Those devices will have a fixed quantity of RAM etc right? I wonder if they will be written to stop accepting connections when there are no free control blocks (goodness), or if they will just decided to prematurely reuse a control blcok in TIME_WAIT (badness). > ] Big systems > ] (VMS, MPE) take longer, but that's mostly due to hardware. > > That must involve a definition of "hardware" other than the one I use. Some platforms have hardware (ok, really firmware) that is more aggressice (conservative?) in start-up self tests than others. MPE (well, MPE/XL or now MPE/iX) is an OS that runs on PA-RISC which can have some rather lengthy self-tests for cache and CPU's and such. Newer systems of such flavor can disable many of these tests (implemented under pressure from customers looking for faster boot times....) though it probably still takes at least a couple minutes for such systems to boot all the way to the point that they are exchanging TCP segments. Perhaps not a full four minute 2*MSL, but probably more than two minutes. There is continuing pressure to reduce that boot time further. rick jones -- today, an ACK takes just as many CPU cycles as a data segment... these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 19:28:09 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12892 for ; Tue, 5 Jan 1999 19:28:09 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id SAA25446; Tue, 5 Jan 1999 18:18:48 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from worf.qntm.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id SAA25442; Tue, 5 Jan 1999 18:18:45 -0500 (EST) Received: from mail.qntm.com by worf.qntm.com with ESMTP (1.40.112.12/16.2) id AA154488314; Tue, 5 Jan 1999 15:18:35 -0800 Received: from milcmima.qntm.com by mail.qntm.com with ESMTP (1.37.109.24/16.2) id AA161177404; Tue, 5 Jan 1999 15:03:26 -0800 Received: by milcmima.qntm.com with Internet Mail Service (5.5.2232.9) id ; Tue, 5 Jan 1999 14:58:23 -0800 Message-Id: From: Rodney Van Meter To: "'Rick Jones'" , tcp-impl@lerc.nasa.gov Subject: RE: Question on initial sequence numbers Date: Tue, 5 Jan 1999 14:58:57 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Okay, time for me to show my ignorance :-). I'm on the side of the conservatives here (stick to the rules as spec'ed in order to be right), but I have a few questions: 1) How does DHCP deal with the possibility of giving out the same IP address resulting in corruption? Does it simply refuse to give out a specific address until TIME_WAIT after the prior lease expires? 2) How does IPv6 automatic address configuration (or any other distributed address selection mechanism) avoid this? What if host A picks address 1.2.3.4(.x.y.z...), then it dies mid-stream, host B comes up and, using the same algorithm, picks 1.2.3.4, since as far as it can tell, it's not in use? Or will, with IPv6, no two hosts ever pick the same address? 3) If we're using non-routable addresses, traffic guaranteed to be on this LAN only, is it possible to relax the TIME_WAIT constraint? 4) Getting off the list topic a bit, but, are XTP and other transport protocols vulnerable to the same problem? --Rod P.S. I'll go with whatever Bob Braden says ;-). > -----Original Message----- > From: Rick Jones [SMTP:raj@cup.hp.com] > Sent: Tuesday, January 05, 1999 12:23 PM > To: tcp-impl@lerc.nasa.gov > Subject: Re: Question on initial sequence numbers > > All it really takes is switching an IP address from one system to > another in the event of failure. Then instead of being a question of how > long it takes for a system to reboot, it becomes a question of how long > it takes for the system failure to be detected and the IP address > (identity) be assumed by the back-up system (and of course, whether or > not the backup system was being kept up-to-date wrt TIME_WAIT. > > Given the pressures on HA in certain markets, I think there is pressure > to have this detection and failover happen in << TIME_WAIT. I am > reasonably confident that modulo icky things like DB recovery the > switchovers are happening < 60 seconds today on a number of platforms. > Probably much less. > > rick jones > -- > these opinions are mine, all mine; HP might not want them anyway... :) > feel free to email, or post, but please do not do both... > my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 19:33:31 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12979 for ; Tue, 5 Jan 1999 19:33:31 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA12649; Tue, 5 Jan 1999 16:09:23 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from panama.ussw.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA12645; Tue, 5 Jan 1999 16:09:21 -0500 (EST) Received: from ussw.com (traveler2.ussw.com [206.251.94.206]) by panama.ussw.com (8.8.7/8.8.7) with ESMTP id NAA03590; Tue, 5 Jan 1999 13:08:57 -0800 Message-ID: <369280D5.C7C17E83@ussw.com> Date: Tue, 05 Jan 1999 13:15:01 -0800 From: rames X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver CC: Richard_Berke@troweprice.com, tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers References: <199901051944.MAA06903@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon Schryver wrote: > Which systems have you tested that break that rule? Embedded systems with TCP/IP stacks in ROM are up in a matter of seconds. See, for example, the AMD Net186 Network Appliance demo board at http://www.amd.com/products/lpd/186es/21780a.html When running a TCP/IP stack, this board is up in seconds. Richard Ames U S Software richard@ussw.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 20:02:42 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA13139 for ; Tue, 5 Jan 1999 20:02:42 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA14232; Tue, 5 Jan 1999 16:22:57 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA14223; Tue, 5 Jan 1999 16:22:54 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA788; Tue, 5 Jan 1999 13:22:49 -0800 Message-ID: <369282A0.DF19A004@ehsco.com> Date: Tue, 05 Jan 1999 13:22:40 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver CC: Richard_Berke@troweprice.com, tcp-impl@lerc.nasa.gov Subject: Re: Question on initial sequence numbers References: <199901051944.MAA06903@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > Almost every OS that I've ever tested breaks this rule, unfortunately. > Which systems have you tested that break that rule? I can get Linux and NT to boot in less than 120 seconds by thinning down the number of services in use and using fast gear. I could probably boot a Sun box in that same time frame if I tried hard enough. Big systems (VMS, MPE) take longer, but that's mostly due to hardware. Even Compaq systems (with their overzealous POST tests) running DOS can take longer than two minutes, but the OS doesn't care. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 20:09:51 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA13162 for ; Tue, 5 Jan 1999 20:09:51 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id TAA28138; Tue, 5 Jan 1999 19:03:15 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id TAA28134; Tue, 5 Jan 1999 19:03:13 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA86B; Tue, 5 Jan 1999 16:03:10 -0800 Message-ID: <3692A839.83958096@ehsco.com> Date: Tue, 05 Jan 1999 16:03:05 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@lerc.nasa.gov, Richard_Berke@troweprice.com Subject: Re: fast booting & 2*MSL References: <199901052212.PAA07375@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I'd have to see Redhat 5.1, 5.2, or NT 4.0 boot in less than 120 seconds > to believe it. Even so, note that I wrote about the de facto standard > 2*MSL, which is less than 2 minutes. My Toshiba Tecra 8000 running NT4 wks reboots in 110 seconds without doing anything fancy. This is measured from hitting "shutdown" at the login prompt until the login prompt is fully restored (after all services have started and the disk stops working). The state times ar 20 seconds for shutdown, 25 seconds for system restart (boot menus, etc.), and 65 seconds for NT to finish loading (and I mean fully finished). Typically the slow part of the process is the hardware. Scanning the SCSI bus takes time, for example. Using IDE drives is a lot faster. There are other areas that can be streamlined. It's not that difficult to reboot a minimal system in ~90 seconds. > ] Even Compaq systems (with their overzealous POST tests) running DOS > ] can take longer than two minutes, but the OS doesn't care. > Yes, cold-start tests take far too long on many systems, and have for Compaq boxes are slow on warm start, too. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 5 20:49:33 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA13343 for ; Tue, 5 Jan 1999 20:49:32 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id TAA29878; Tue, 5 Jan 1999 19:37:26 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id TAA29874; Tue, 5 Jan 1999 19:37:24 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA890 for ; Tue, 5 Jan 1999 16:37:21 -0800 Message-ID: <3692B03C.8866D5A5@ehsco.com> Date: Tue, 05 Jan 1999 16:37:16 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@lerc.nasa.gov Subject: Re: fast booting & 2*MSL References: <199901052212.PAA07375@calcite.rhyolite.com> <369298B2.45CD1773@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > embedded web server ... Embedded web servers open a whole 'nother can of worms. HTTP 1.1's use of persistent connections -- in conjunction with long connections that are used to transfer many many files (as found on internal web sites in particular) -- increases the chance that at least one connection willl eventually reuse sequence numbers. Combined with fast boot times, this could represent a real problem. This would be true of any OS that is capable of fast booting, supports HTTP 1.1 and is used to transfer lots and lots of data. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Wed Jan 6 12:28:55 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05400 for ; Wed, 6 Jan 1999 12:28:54 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id KAA16777; Wed, 6 Jan 1999 10:23:04 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from ietf.org (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id JAA04156; Wed, 6 Jan 1999 09:38:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26217; Wed, 6 Jan 1999 09:38:51 -0500 (EST) Message-Id: <199901061438.JAA26217@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;@ns.cnri.reston.va.us Cc: tcp-impl@lerc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tcpimpl-cong-control-03.txt Date: Wed, 06 Jan 1999 09:38:51 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Implementation Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman, V. Paxson, W. Stevens Filename : draft-ietf-tcpimpl-cong-control-03.txt Pages : 11 Date : 05-Jan-99 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-cong-control-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpimpl-cong-control-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpimpl-cong-control-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990105154625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpimpl-cong-control-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpimpl-cong-control-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990105154625.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-tcp-impl@cthulhu.engr.sgi.com Thu Jan 7 09:34:37 1999 Received: from sgi.sgi.com (sgi-too.SGI.COM [204.94.211.39]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26963 for ; Thu, 7 Jan 1999 09:34:37 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA08256; Thu, 7 Jan 1999 06:26:59 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA31679 for tcp-impl-list; Thu, 7 Jan 1999 06:21:56 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA91755 for ; Thu, 7 Jan 1999 06:21:54 -0800 (PST) mail_from (scoya@ns.cnri.reston.va.us) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA04925 for ; Thu, 7 Jan 1999 06:21:53 -0800 (PST) mail_from (scoya@ns.cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26650; Thu, 7 Jan 1999 09:21:50 -0500 (EST) Message-Id: <199901071421.JAA26650@ietf.org> To: IETF-Announce:;;@ns.cnri.reston.va.us Cc: tcp-impl@cthulhu.engr.sgi.com From: The IESG SUBJECT: Last Call: TCP Congestion Control to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 07 Jan 1999 09:21:50 -0500 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk The IESG has received a request from the TCP Implementation Working Group to consider TCP Congestion Control as a Proposed Standard. The IESG will also consider publication of The NewReno Modification to TCP's Fast Recovery Algorithm as an Experimental RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 21, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-cong-control-03.txt http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-newreno-01.txt From owner-tcp-impl@lerc.nasa.gov Thu Jan 7 12:14:30 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04062 for ; Thu, 7 Jan 1999 12:14:29 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id KAA02369; Thu, 7 Jan 1999 10:23:36 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from ietf.org (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id KAA25019; Thu, 7 Jan 1999 10:11:05 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27844; Thu, 7 Jan 1999 10:11:01 -0500 (EST) Message-Id: <199901071511.KAA27844@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;@ns.cnri.reston.va.us Cc: tcp-impl@lerc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tcpimpl-pmtud-00.txt Date: Thu, 07 Jan 1999 10:11:00 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Implementation Working Group of the IETF. Title : TCP Problems with Path MTU Discovery Author(s) : K. Lahey Filename : draft-ietf-tcpimpl-pmtud-00.txt Pages : 15 Date : 06-Jan-99 This memo catalogs several known TCP implementation problems dealing with Path MTU Discovery [RFC1191], including the long-standing black hole problem, stretch ACKs due to confusion between MSS and segment size, and MSS advertisement based on PMTU. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpimpl-pmtud-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990106095321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpimpl-pmtud-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990106095321.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-tcp-impl@lerc.nasa.gov Fri Jan 8 10:09:04 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13529 for ; Fri, 8 Jan 1999 10:09:04 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id IAA07397; Fri, 8 Jan 1999 08:06:12 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from nagpcy.nagra-kudelski.ch (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-main) id IAA02718; Fri, 8 Jan 1999 08:02:41 -0500 (EST) Received: from [10.0.3.111] by nagpcy.nagra-kudelski.ch (NTMail 3.02.13) with ESMTP id la099175 for ; Fri, 8 Jan 1999 14:02:24 +0100 From: "Nicolas Pauli" To: Subject: RE: socket termination problem Date: Fri, 8 Jan 1999 14:02:37 +0100 Message-ID: <005101be3b07$2af40e80$6f03000a@saspc11.nagra-kudelski.ch> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Dear all, Let me explain my situation: I have 3 tasks running. First on the server's side: the first one accepts connections, the second one only reads data on the socket and then close the connection. On the client's side: I open connections, send data, the close the socket. My problem is that sockets do not close themselves correctly: the close on the client's side is properly done, i.e. client socket goes to FIN_WAIT2 state and server socket goes to CLOSED_WAIT state. But when I close the socket on the server's side, nothing seems to change. Sockets stay in the previous states. I have checked that the close on the server is done everytime. Does anybody have an idea? Thanks in advance. Nico PS: this happens on a DEC Unix 4.2, with DEC C++ compiler. From owner-tcp-impl@lerc.nasa.gov Wed Jan 13 23:58:13 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA26633 for ; Wed, 13 Jan 1999 23:58:12 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id WAA24954; Wed, 13 Jan 1999 22:25:11 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from mail-relay2.yahoo.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id WAA24220; Wed, 13 Jan 1999 22:21:26 -0500 (EST) Received: from borogove.yahoo.com (borogove.yahoo.com [205.216.162.65]) by mail-relay2.yahoo.com (8.9.1a/8.8.8) with ESMTP id TAA20337; Wed, 13 Jan 1999 19:21:24 -0800 (PST) Received: from localhost.yahoo.com (localhost.yahoo.com [127.0.0.1]) by borogove.yahoo.com (8.8.7/8.8.8) with SMTP id TAA03404; Wed, 13 Jan 1999 19:21:24 -0800 (PST) Message-Id: <199901140321.TAA03404@borogove.yahoo.com> To: kml@nas.nasa.gov cc: tcp-impl@lerc.nasa.gov Subject: common blackholes, Re: I-D ACTION:draft-ietf-tcpimpl-pmtud-00.txt In-reply-to: Your message of "Thu, 07 Jan 1999 10:11:00 EST." <199901071511.KAA27844@ietf.org> Date: Wed, 13 Jan 1999 19:21:24 -0800 From: John Hanley Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Thanks for writing up these MTU issues. FYI, there is a common form of blackhole which may be located very close to a TCP server (such as a web server). It might be worth mentioning. Various vendors have layer-4 "load balancers" which accept port 80 requests sent to a "virtual IP" and divvy up the work among multiple backend web servers. Such a device will use a table or a socket identifier hash to map particular request packets to a particular server. When such a device recieves an ICMP packet saying "fragmentation required", it is essential that is use that *same* mapping to send the ICMP to the proper backend server. (Flooding to all servers Would Be Bad :-( Detection: Suppose the backend server implementing PMTUD has at least two IP addresses besides the loopback address: one address is subject to the layer-4 munging and one address gets plain old boring layer-3 service. Arrange for TCP traffic to be exchanged between a single client IP and both server IPs, and notice that only conversations which use the "virtual IP" suffer from blackholing. The second IP (to avoid munging) is not needed with some configurations; just use a TCP port other than 80, or use a protocol other than TCP. There is one more configuration issue which may be worth mentioning. Some people believe it is reasonable to use rfc1918 addresses (net 10) on point-to-point circuits within their cloud. This causes traceroute misery if you get "TTL exceeded" ICMPs with source address of 10.0.0.1. Worse, if you get "frag required" ICMPs with source address of 10.0.0.1, and a topology-enforcing ACL on some router filters bogus/spoofed source addresses, then PMTUD sees a blackhole. Cheers, JH From owner-tcp-impl@lerc.nasa.gov Thu Jan 14 16:09:22 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA17173 for ; Thu, 14 Jan 1999 16:09:22 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id OAA25731; Thu, 14 Jan 1999 14:25:13 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA24215; Thu, 14 Jan 1999 14:21:08 -0500 (EST) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20220; Thu, 14 Jan 1999 11:21:06 -0800 (PST) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id LAA24205; Thu, 14 Jan 1999 11:21:06 -0800 (PST) Date: Thu, 14 Jan 1999 11:21:06 -0800 (PST) Message-Id: <199901141921.LAA24205@rum.isi.edu> To: kml@nas.nasa.gov, jh@yahoo-inc.com Subject: Re: common blackholes, Re: I-D ACTION:draft-ietf-tcpimpl-pmtud-00.txt Cc: tcp-impl@lerc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: John Hanley > > Thanks for writing up these MTU issues. > > FYI, there is a common form of blackhole which may be located very close > to a TCP server (such as a web server). It might be worth mentioning. > > Various vendors have layer-4 "load balancers" which accept port 80 requests > sent to a "virtual IP" and divvy up the work among multiple backend web > servers. Such a device will use a table or a socket identifier hash > to map particular request packets to a particular server. When such a > device recieves an ICMP packet saying "fragmentation required", it is > essential that is use that *same* mapping to send the ICMP to the > proper backend server. (Flooding to all servers Would Be Bad :-( There are a whole slew of proiblems that are the result of this kind of transparent caching, which break the MUSTs in the host- (1122, standard) and gateway-requirements (1812, proposed standard) RFCs, and the recommendations in the NAT (1631, informational) and load-sharing (2391, informational) RFCs. I'm collecting a list of such problems for an I-D for the (pending) WREC (web replication and caching) WG. The problems I know of are related to IPSEC, spoofing detectors, traceroute and ping, and TCP control block sharing. This generalizes the ICMP problems I know of for traceroute. If there are other known problems, please post or send me direct e-mail, and I'll post the results here in a few weeks when they're colleted. Thanks, Joe From owner-tcp-impl@lerc.nasa.gov Thu Jan 14 16:34:14 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA17881 for ; Thu, 14 Jan 1999 16:34:13 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA12261; Thu, 14 Jan 1999 15:06:31 -0500 (EST) Received: from mintaka.isr.umd.edu (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA08831; Thu, 14 Jan 1999 14:58:36 -0500 (EST) Received: from segfault.isr.umd.edu ((IDENT root)@segfault.isr.umd.edu [128.8.111.130]) by mintaka.isr.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id OAA05747; Thu, 14 Jan 1999 14:57:09 -0500 (EST) Received: from segfault.isr.umd.edu ((IDENT sendmail)@localhost [127.0.0.1]) by segfault.isr.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id OAA27666; Thu, 14 Jan 1999 14:58:31 -0500 (EST) Received: from localhost by segfault.isr.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id OAA27661; Thu, 14 Jan 1999 14:58:29 -0500 (EST) X-Authentication-Warning: segfault.isr.umd.edu: corson owned process doing -bs Date: Thu, 14 Jan 1999 14:58:29 -0500 (EST) From: "M. Scott Corson" X-Sender: corson@segfault.isr.umd.edu Reply-To: "M. Scott Corson" Subject: IJSC IPoverSat CFP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * CALL FOR PAPERS * * * * Special Issue of the * * International Journal of Satellite Communications * * on * * Internet Protocols over Satellite * * * * http://www.interscience.wiley.com/jpages/0737-2884/ * * * * * * Papers due: February 28, 1999 * * Notification of acceptance: April 30, 1999 * * Publication: Late 1999 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The International Journal of Satellite Communications is a quarterly journal which provides a focus for professionals in all aspects of satellite communications. The Journal is unique in that it provides for a rapid dissemination of new results and trends in this constantly changing industry. In addition to areas of specific interest, the journal regularly includes items of general interest and tutorials. The Journal covers all aspects of the theory and practice of satellite systems and networks. This special issue focuses on the usage of *Internet Protocols* in Satellite-based Information Systems. Papers on topics such as: TCP over Satellite Reliable Multicast Transport IP-based Satellite Constellations Unidirectional and Asymmetric Routing IP-based Quality of Service Support over Satellite Internetworking of Space-Based and Terrestrial Infrastructures and other topics of current interest are encouraged. Please send submissions to the guest editor listed below. Electronic submissions preferred, but hardcopy is accepted. If hardcopy, please send 4 copies. In order to enable the publisher to do everything to ensure prompt publication, the full postal address should be given for the author who will check proofs, along with telephone, telex and telefax numbers where possible. Guest Editor: M. Scott Corson (corson@isr.umd.edu) Center for Satellite and Hybrid Communication Networks Institute for Systems Research A.V. Williams Building (115) University of Maryland College Park, MD 20895 From owner-tcp-impl@cthulhu.engr.sgi.com Sat Jan 16 11:53:42 1999 Received: from sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15886 for ; Sat, 16 Jan 1999 11:53:41 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA01335; Sat, 16 Jan 1999 11:49:19 -0500 (EST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA30884 for tcp-impl-list; Sat, 16 Jan 1999 07:53:53 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA19018 for ; Sat, 16 Jan 1999 07:53:52 -0800 (PST) mail_from (i2n0@yahoo.com) Received: from mexnet01.mcsa.net.mx (mexnet01.mcsa.net.mx [200.33.47.216]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA04930 for ; Sat, 16 Jan 1999 10:53:50 -0500 (EST) mail_from (i2n0@yahoo.com) From: i2n0@yahoo.com Received: from mexpru.mcsa.net.mx ([200.33.47.221]) by mexnet01.mcsa.net.mx (8.8.5/SCO5) with ESMTP id JAA26363; Sat, 16 Jan 1999 09:51:45 -0600 (CST) Received: from jamie ([204.244.195.142]) by mexpru.mcsa.net.mx (8.8.5/SCO5) with SMTP id GAA27121; Sat, 16 Jan 1999 06:29:16 -0600 (CST) Date: Sat, 16 Jan 1999 06:29:16 -0600 (CST) Message-Id: <199901161229.GAA27121@mexpru.mcsa.net.mx> To: friend@exite.com Subject: Tyson vs Botha Wannna Bet! Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Feeling Lucky?? CASH IN ON thE FIGHT!!!! - http://209.67.19.99/want_to_bet/ TYSON V.s. BOTHA SATURDAY NIGHT JAN 16 9pm! REAL LIVE LAS VEGAS GAMBLING Place your bet online with up to the minute odds! Mike Tyson -750 Frans Botha +500 http://209.67.19.99/want_to_bet/ CLICK HERE to enter From owner-tcp-impl@lerc.nasa.gov Sat Jan 16 13:36:02 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA16390 for ; Sat, 16 Jan 1999 13:36:01 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id MAA02059; Sat, 16 Jan 1999 12:05:14 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id LAA29762; Sat, 16 Jan 1999 11:59:53 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id JAA03933 env-from ; Sat, 16 Jan 1999 09:59:48 -0700 (MST) Date: Sat, 16 Jan 1999 09:59:48 -0700 (MST) From: Vernon Schryver Message-Id: <199901161659.JAA03933@calcite.rhyolite.com> To: postmaster@relay.engr.sgi.com, postmaster@sgi.com, tcp-impl@lerc.nasa.gov Subject: spam through this list Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Assuming that the enclosed announcment was valid (I think it was), could someone please turn off the old instance of the IETF tcp-impl list on relay.engr.sgi.com? I suspect the spam filtering on sgi.sgi.com is no longer being maintained, so that the old list is only a source of garbage such as the spam today. All that would be necessary is to remove the alias on cthulhu. If I were still an SGI employee with access to the filters on sgi.sgi.com, I would add owner-tcp-impl@cthulhu.engr.sgi.com to the bait-with-bounce list on sgi.sgi.com, so that all messages sent to that address would be treated as spam, and subsequent copies would be discarded. For my personal defense, I'm adding owner-tcp-impl@cthulhu.engr.sgi.com to my blacklist. Vernon Schryver vjs@rhyolite.com > To: tcp-impl@lerc.nasa.gov > Cc: "Vern Paxson" > From: Mark Allman > Date: Thu, 29 Oct 1998 13:33:54 -0500 > TCP-impl Folks: > > The tcp-impl mailing list is moving to NASA LeRC as of right now. > As of several minutes ago, the list of people on the mailing list > was identical at LeRC and SGI. So, please use > "tcp-impl@lerc.nasa.gov" from now on. The list archive is available > both as a flat file and a hypermail web index from the following > URL: > > http://tcp-impl.lerc.nasa.gov/tcp-impl > > I'd like to thank SGI for hosting the mailing list and archive at > their site for a long time. We very much appreciate their efforts! > The move is simply an attempt to make things a little easier for > Vern and I to manage. > > allman > > > --- > http://gigahertz.lerc.nasa.gov/~mallman/ > From owner-tcp-impl@lerc.nasa.gov Sat Jan 16 14:48:00 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA16702 for ; Sat, 16 Jan 1999 14:47:59 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA02300; Sat, 16 Jan 1999 13:45:18 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA29531; Sat, 16 Jan 1999 13:37:06 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA09904; Sat, 16 Jan 1999 13:37:04 -0500 (EST) mail_from (sivo@klaatu.engr.sgi.com) Received: from klaatu.engr.sgi.com (klaatu.engr.sgi.com [150.166.42.101]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA64264; Sat, 16 Jan 1999 10:37:04 -0800 (PST) mail_from (sivo@klaatu.engr.sgi.com) Received: (from sivo@localhost) by klaatu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA93387; Sat, 16 Jan 1999 10:36:55 -0800 (PST) Date: Sat, 16 Jan 1999 10:36:55 -0800 (PST) From: sivo@klaatu.engr.sgi.com (Peter Sivo) Message-Id: <199901161836.KAA93387@klaatu.engr.sgi.com> To: Vernon Schryver Subject: Re: spam through this list Cc: tcp-impl@lerc.nasa.gov, postmaster@sgi.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk THanks for pointing that out Vernon. Since I _just_ started watching the postmaster email on relay (since my group is taking it over from the dsd folks), I appreciate the input. The alias has been removed. \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ \_ Peter J. Sivo | email: sivo@engr.sgi.com | Men go and come, \_ \_ IS/Manager SNS | voice: (650)933-6015 | but earth abides. \_ \_ Silicon Graphics | cpager: sivo_p@pager.sgi.com | \_ \_ \_ \_ **All opinions are my own and not necessarily those of my employer** \_ \_ PGP 2.6 Public Key available on all PGP Internet Key Servers \_ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ From owner-tcp-impl@lerc.nasa.gov Mon Jan 18 18:14:30 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27146 for ; Mon, 18 Jan 1999 18:14:25 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA08694; Mon, 18 Jan 1999 16:26:45 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from fred.muc.de (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA05021; Mon, 18 Jan 1999 16:17:46 -0500 (EST) Received: (qmail 684 invoked by uid 500); 18 Jan 1999 21:17:17 -0000 Message-ID: <19990118221717.A664@kali.munich.netsurf.de> Date: Mon, 18 Jan 1999 22:17:17 +0100 From: Andi Kleen To: "David S. Miller" , ak@muc.de Cc: sparclinux-cvs@vger.rutgers.edu, tcp-impl@lerc.nasa.gov Subject: Re: CVS Update@vger.rutgers.edu: linux References: <19990116083113Z154298-8093+5841@vger.rutgers.edu> <19990116113856.B587@kali.munich.netsurf.de> <199901170010.QAA23440@dm.cobaltmicro.com> <19990117130720.A619@kali.munich.netsurf.de> <199901180639.WAA04907@dm.cobaltmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <199901180639.WAA04907@dm.cobaltmicro.com>; from David S. Miller on Sun, Jan 17, 1999 at 10:39:18PM -0800 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sun, Jan 17, 1999 at 10:39:18PM -0800, David S. Miller wrote: > Date: Sun, 17 Jan 1999 13:07:20 +0100 > From: Andi Kleen > > If I understand RFC2018.8 (Data Receiver Reneging) correctly they > require reporting the last received sack block (even if it was > discarded) so that the sender has the best possible idea about > 'forward process' on the connection. Linux violates that currently. > > I still don't understand. If we discard it, why should we report a > SACK about it? It sounds to me like the RFC is asking us to > acknowledge data not in our queue, that simply does not make any > sense. A SACK is not a real ack, the 2018 requires that all data is kept in the retransmit queue until it is acked by the "classic" ack field. > > I might be missing something critical, if so please help me > understand. > > But how I see it right now the RFC simply makes no sense. I am not sure if I understand the intentions of the RFC correctly, but for me it looks the authors valued the information about forward progress (to update the neighbour entry?) as more important as the delay the additional SACK may cause (the sender will eat an timeout to clear the SACK flags in the retransmit queue). I assume they had some good reasons to specify that, but maybe that is a good question for the tcpimpl group cc'ed there, maybe someone there can shed light on this. -Andi From owner-tcp-impl@lerc.nasa.gov Tue Jan 19 14:50:33 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA26027 for ; Tue, 19 Jan 1999 14:50:32 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA05476; Tue, 19 Jan 1999 13:15:33 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA02680; Tue, 19 Jan 1999 13:08:27 -0500 (EST) Received: from odin.corp.sgi.com ([198.29.75.194]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id KAA00646; Tue, 19 Jan 1999 10:08:15 -0800 (PST) mail_from (wli@wli.engr.sgi.com) Received: from wli.engr.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA16162; Tue, 19 Jan 1999 10:08:14 -0800 Received: by wli.engr.sgi.com (980205.SGI.8.8.8/940406.SGI.AUTO) id KAA00849; Tue, 19 Jan 1999 10:08:12 -0800 (PST) From: "William Li" Message-Id: <9901191008.ZM848@wli.engr.sgi.com> Date: Tue, 19 Jan 1999 10:08:12 -0800 In-Reply-To: Andi Kleen "Re: CVS Update@vger.rutgers.edu: linux" (Jan 18, 10:17pm) References: <19990116083113Z154298-8093+5841@vger.rutgers.edu> <19990116113856.B587@kali.munich.netsurf.de> <199901170010.QAA23440@dm.cobaltmicro.com> <19990117130720.A619@kali.munich.netsurf.de> <199901180639.WAA04907@dm.cobaltmicro.com> <19990118221717.A664@kali.munich.netsurf.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Andi Kleen , "David S. Miller" Subject: Re: CVS Update@vger.rutgers.edu: linux Cc: sparclinux-cvs@vger.rutgers.edu, tcp-impl@lerc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Jan 18, 10:17pm, Andi Kleen wrote: > Subject: Re: CVS Update@vger.rutgers.edu: linux > > I still don't understand. If we discard it, why should we report a > > SACK about it? It sounds to me like the RFC is asking us to > > acknowledge data not in our queue, that simply does not make any > > sense. > What I understand is that a receiver discard the data but must SACK it. The discard part is because the receiver runs out resource (receiver buf), the SACK part is to notify the sender that it should not retransmit this data right away. plus: > A SACK is not a real ack, the 2018 requires that all data is kept > in the retransmit queue until it is acked by the "classic" ack field. > > -Andi >-- End of excerpt from Andi Kleen -- William Li wli@sgi.com/650-933-3751 From owner-tcp-impl@lerc.nasa.gov Tue Jan 19 21:12:58 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA03881 for ; Tue, 19 Jan 1999 21:12:57 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id TAA07381; Tue, 19 Jan 1999 19:47:31 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-main) id TAA07231; Tue, 19 Jan 1999 19:46:46 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA23891; Tue, 19 Jan 1999 16:46:16 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id QAA02458; Tue, 19 Jan 1999 16:46:10 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id QAA00437; Tue, 19 Jan 1999 16:46:06 -0800 (PST) Date: Tue, 19 Jan 1999 16:46:06 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: CVS Update@vger.rutgers.edu: linux To: Andi Kleen Cc: tcp-impl@lerc.nasa.gov In-Reply-To: "Your message with ID" <19990118221717.A664@kali.munich.netsurf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I am not sure if I understand the intentions of the RFC correctly, > but for me it looks the authors valued the information about forward progress > (to update the neighbour entry?) as more important as the delay the > additional SACK may cause (the sender will eat an timeout to clear the SACK > flags in the retransmit queue). I assume they had some good reasons to > specify that, but maybe that is a good question for the tcpimpl group cc'ed > there, maybe someone there can shed light on this. One reason may be consistency. Suppose a TCP stack decides to free up segments in the receive queue. But it has already sent ACKs with SACK info for those segments. For the newly received segments, which are going to be dicarded, it is more consistent to SACK them also. Also, for those implementations which make use of the SACK info to determine the number of segments in the pipe, not SACK'ing the received but discarded segments may disrupt their calculations. Granted, ACKs can be lost. But if they are not lost, SACK info can help the sender to make more intelligent choice. An intelligent sender may keep a count on the SACK'ed segments. Since the RFC requires that those received but discarded segment will only elicit one SACK block, it may make an intelligent choice to retransmit a SACK'ed segment by looking at the SACK count pattern. So a timeout may not be needed. To me, SACK info is an aid for a sender to make intelligent choices in sending. Receiving a segment but failing to SACK it takes away some of the benefits of SACK. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Tue Jan 19 21:12:59 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA03883 for ; Tue, 19 Jan 1999 21:12:58 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id TAA10384; Tue, 19 Jan 1999 19:57:36 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-main) id TAA07231; Tue, 19 Jan 1999 19:46:46 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA23891; Tue, 19 Jan 1999 16:46:16 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id QAA02458; Tue, 19 Jan 1999 16:46:10 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id QAA00437; Tue, 19 Jan 1999 16:46:06 -0800 (PST) Date: Tue, 19 Jan 1999 16:46:06 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: CVS Update@vger.rutgers.edu: linux To: Andi Kleen Cc: tcp-impl@lerc.nasa.gov In-Reply-To: "Your message with ID" <19990118221717.A664@kali.munich.netsurf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I am not sure if I understand the intentions of the RFC correctly, > but for me it looks the authors valued the information about forward progress > (to update the neighbour entry?) as more important as the delay the > additional SACK may cause (the sender will eat an timeout to clear the SACK > flags in the retransmit queue). I assume they had some good reasons to > specify that, but maybe that is a good question for the tcpimpl group cc'ed > there, maybe someone there can shed light on this. One reason may be consistency. Suppose a TCP stack decides to free up segments in the receive queue. But it has already sent ACKs with SACK info for those segments. For the newly received segments, which are going to be dicarded, it is more consistent to SACK them also. Also, for those implementations which make use of the SACK info to determine the number of segments in the pipe, not SACK'ing the received but discarded segments may disrupt their calculations. Granted, ACKs can be lost. But if they are not lost, SACK info can help the sender to make more intelligent choice. An intelligent sender may keep a count on the SACK'ed segments. Since the RFC requires that those received but discarded segment will only elicit one SACK block, it may make an intelligent choice to retransmit a SACK'ed segment by looking at the SACK count pattern. So a timeout may not be needed. To me, SACK info is an aid for a sender to make intelligent choices in sending. Receiving a segment but failing to SACK it takes away some of the benefits of SACK. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Fri Jan 22 17:24:45 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06895 for ; Fri, 22 Jan 1999 17:24:44 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA15541; Fri, 22 Jan 1999 15:47:49 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from ietf.org (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA14025; Fri, 22 Jan 1999 15:41:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA01850; Fri, 22 Jan 1999 15:41:07 -0500 (EST) Message-Id: <199901222041.PAA01850@ietf.org> To: IETF-Announce:;;@ns.cnri.reston.va.us Cc: RFC Editor Cc: Internet Architecture Board Cc: tcp-impl@lerc.nasa.gov From: The IESG Subject: Document Action: Known TCP Implementation Problems to Informational Date: Fri, 22 Jan 1999 15:41:07 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The IESG has approved the Internet-Draft 'Known TCP Implementation Problems' as a Informational RFC. This document is the product of the TCP Implementation Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. From owner-tcp-impl@lerc.nasa.gov Tue Jan 26 07:56:13 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA15774 for ; Tue, 26 Jan 1999 07:56:13 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id GAA25558; Tue, 26 Jan 1999 06:07:47 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from lestat.nas.nasa.gov (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id GAA25440; Tue, 26 Jan 1999 06:06:13 -0500 (EST) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id DAA03302; Tue, 26 Jan 1999 03:06:05 -0800 (PST) Message-Id: <199901261106.DAA03302@lestat.nas.nasa.gov> To: tcp-impl@lerc.nasa.gov Subject: out-of-window SYNs ... what to do? Cc: frank@wins.uva.nl, mycroft@mit.edu Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 26 Jan 1999 03:06:04 -0800 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hi folks... While debugging a completely unrelated issue in the NetBSD kernel today, I noticed some behavior which I felt warranted some discussion here (and please forgive me if this horse has been beaten into mush already...) The problem was observed between a diskless Network Computer (`client') and home directory server for its workgroup (`server'). The two systems are using NFSv3 (over TCP) to communicate. So, consider the following scenario: (1) client.1023 mounts server.2049. This causes a TCP connection to be established. (2) Power cord on client is pulled, and reinserted. Client reboots. Now, at this point, you have the server in ESTABLISHED state for this connection. The client thinks here is no connection. (3) client.1023 mounts server.2049. This causes a TCP connection to be established. ...except, the connection never completes. Indeed, server never sends SYN,ACK because out-of-window SYNs are simply dropped on the floor. At this point, client is hosed. The only way we can be unwedged is for the server to send what it thinks is an in-window packet. This can be either a keepalive (very infrequent) or, if we're lucky, a retransmission of data left un-ACK'd when the client went down (much more frequent). This packet will cause the client to generate an RST, which will cause the socket on the server to close, which will cause the client's attempts to connect to complete (since it will be a "fresh" connection at this point). This behavior is probably technically correct (tho, at nearly 3am, I'm too tired to go look it up right now). However, the effect it produces is annoying at best. While brainstorming, some colleagues and I came up with the idea that resending the last ACK for the current window would be a reasonable course of action for the server to take in this situation (i.e. when it discovers an out-of-window SYN for an established connection). This would simply expedite the discovery of the no-longer-established connection (by forcing the client to send the RST sooner). Anyhow, I'd appreciate some input on this... Thanks! -- Jason R. Thorpe From owner-tcp-impl@lerc.nasa.gov Tue Jan 26 07:56:26 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA15785 for ; Tue, 26 Jan 1999 07:56:25 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id GAA26841; Tue, 26 Jan 1999 06:17:52 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from lestat.nas.nasa.gov (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id GAA25440; Tue, 26 Jan 1999 06:06:13 -0500 (EST) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id DAA03302; Tue, 26 Jan 1999 03:06:05 -0800 (PST) Message-Id: <199901261106.DAA03302@lestat.nas.nasa.gov> To: tcp-impl@lerc.nasa.gov Subject: out-of-window SYNs ... what to do? Cc: frank@wins.uva.nl, mycroft@mit.edu Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 26 Jan 1999 03:06:04 -0800 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hi folks... While debugging a completely unrelated issue in the NetBSD kernel today, I noticed some behavior which I felt warranted some discussion here (and please forgive me if this horse has been beaten into mush already...) The problem was observed between a diskless Network Computer (`client') and home directory server for its workgroup (`server'). The two systems are using NFSv3 (over TCP) to communicate. So, consider the following scenario: (1) client.1023 mounts server.2049. This causes a TCP connection to be established. (2) Power cord on client is pulled, and reinserted. Client reboots. Now, at this point, you have the server in ESTABLISHED state for this connection. The client thinks here is no connection. (3) client.1023 mounts server.2049. This causes a TCP connection to be established. ...except, the connection never completes. Indeed, server never sends SYN,ACK because out-of-window SYNs are simply dropped on the floor. At this point, client is hosed. The only way we can be unwedged is for the server to send what it thinks is an in-window packet. This can be either a keepalive (very infrequent) or, if we're lucky, a retransmission of data left un-ACK'd when the client went down (much more frequent). This packet will cause the client to generate an RST, which will cause the socket on the server to close, which will cause the client's attempts to connect to complete (since it will be a "fresh" connection at this point). This behavior is probably technically correct (tho, at nearly 3am, I'm too tired to go look it up right now). However, the effect it produces is annoying at best. While brainstorming, some colleagues and I came up with the idea that resending the last ACK for the current window would be a reasonable course of action for the server to take in this situation (i.e. when it discovers an out-of-window SYN for an established connection). This would simply expedite the discovery of the no-longer-established connection (by forcing the client to send the RST sooner). Anyhow, I'd appreciate some input on this... Thanks! -- Jason R. Thorpe From owner-tcp-impl@lerc.nasa.gov Tue Jan 26 11:16:40 1999 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA18023 for ; Tue, 26 Jan 1999 11:16:40 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id JAA03823; Tue, 26 Jan 1999 09:38:00 -0500 (EST) X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from frantic.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id JAA02235; Tue, 26 Jan 1999 09:30:49 -0500 (EST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id IAA10865; Tue, 26 Jan 1999 08:30:02 -0600 (CST) Date: Tue, 26 Jan 1999 08:30:02 -0600 (CST) From: David Borman Message-Id: <199901261430.IAA10865@frantic.bsdi.com> To: tcp-impl@lerc.nasa.gov, thorpej@nas.nasa.gov Subject: Re: out-of-window SYNs ... what to do? Cc: frank@wins.uva.nl, mycroft@mit.edu Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Jason, > Subject: out-of-window SYNs ... what to do? > From: Jason Thorpe > Date: Tue, 26 Jan 1999 03:06:04 -0800 > ... > So, consider the following scenario: > > (1) client.1023 mounts server.2049. This causes a TCP connection > to be established. > > (2) Power cord on client is pulled, and reinserted. Client reboots. > > Now, at this point, you have the server in ESTABLISHED state for this > connection. The client thinks here is no connection. > > (3) client.1023 mounts server.2049. This causes a TCP connection > to be established. > > ...except, the connection never completes. Indeed, server never sends SYN,ACK > because out-of-window SYNs are simply dropped on the floor. This is a bug. The out-of-window SYN should have been acked before it was dropped. In Established state, the first check is to see if the packet is in the window. If it isn't, then an ACK is to be generated and the packet dropped. See page 69 of RFC 793. To make this even clearer, look down at page 71, where it says: fourth, check the SYN bit, ... If the SYN is not in the window this step would not be reached and an ack would have been sent in the first step (sequence number check). -David Borman, dab@bsdi.com