From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 11:49:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15005 for ; Tue, 1 Aug 2000 11:49:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA16808 for tcp-impl-outgoing; Tue, 1 Aug 2000 09:52:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA16786 for ; Tue, 1 Aug 2000 09:52:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA10968; Tue, 1 Aug 2000 09:52:19 -0400 Received: from printfile.ietf.marconi.com(147.73.128.4) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010915; Tue, 1 Aug 00 09:51:42 -0400 Received: from oyster (wireless-134-109.ietf.marconi.com [147.73.134.109]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with SMTP id JAA02837; Tue, 1 Aug 2000 09:55:43 -0400 (EDT) From: "Scott Lawrence" To: "Ian Heavens" , Subject: RE: The TCP RST Date: Tue, 1 Aug 2000 09:51:59 -0400 Message-ID: <000c01bffbbf$a9c74f40$6d864993@oyster.ietf.marconi.com> 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 In-Reply-To: <20000731205427.B28460@malatesta.spider.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I think that it would be helpful if you would be more specific about what sort of issues you'd like to discuss. I am in Pittsburg, and interested in what the issues might be, but that invitation was a bit nebulous - and in any event it would be good to get the issues on the list so that they get wider visibility. From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 11:58:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16848 for ; Tue, 1 Aug 2000 11:58:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA20756 for tcp-impl-outgoing; Tue, 1 Aug 2000 10:14:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA20714 for ; Tue, 1 Aug 2000 10:14:14 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA13771; Tue, 1 Aug 2000 10:14:14 -0400 Received: from unknown(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013515; Tue, 1 Aug 00 10:11:44 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id PAA04840; Tue, 1 Aug 2000 15:11:36 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA10586; Tue, 1 Aug 2000 15:11:36 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id PAA29045; Tue, 1 Aug 2000 15:11:35 +0100 (BST) Date: Tue, 1 Aug 2000 15:11:35 +0100 From: Ian Heavens To: Scott Lawrence Cc: Ian Heavens , tcp-impl@grc.nasa.gov Subject: Re: The TCP RST Message-ID: <20000801151135.C29020@malatesta.spider.com> References: <20000731205427.B28460@malatesta.spider.com> <000c01bffbbf$a9c74f40$6d864993@oyster.ietf.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <000c01bffbbf$a9c74f40$6d864993@oyster.ietf.marconi.com>; from lawrence@agranat.com on Tue, Aug 01, 2000 at 09:51:59AM -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Sure, excuse me for not being more specific. There's two specific areas of interest to me - There's no TIME-WAIT protection after RST. This just needs documentation as I don't think anyone wants to change the TCP state machine to fix this. I've been meaning to write this up for submission as an Informational RFC. I guess once that's done, if there was any interest in fixing the issue, it could be discussed then - There is the potential to include an error code with a RST (RFC 1122 permits data in the RST segment), and the Mentat TCP implementation has been using this for many years (so we can be confident that TCP implementations do not do anything nasty when they receive a RST with data). There's no standard for such error codes and I wonder if implementors would be interested in proposing a taxonomy. I know that such an error code would be very useful in diagnosis. With an API the application layer could exchange error codes, though probably someone will point out that there is a better way of doing that.. Additionally issues with RSTs came up in RFC 2525 and every now and then they crop up (see the two RST-related issues in the RFC). An awful lot of HTTP connections terminate with a RST (P-HTTP fixes this but I wonder if other applications will depart from the norm of graceful termination in both directions). RSTs used to be considered as rare error conditions but maybe this is no longer true. Worth a discussion if anyone out there is interested? ian PS as an aside, what mechanism does SCTP have to avoid TIME-WAIT (a question for Vern)? On Tue, Aug 01, 2000 at 09:51:59AM -0400, Scott Lawrence wrote: > I think that it would be helpful if you would be more specific about > what sort of issues you'd like to discuss. > > I am in Pittsburg, and interested in what the issues might be, but > that invitation was a bit nebulous - and in any event it would be good > to get the issues on the list so that they get wider visibility. > -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 12:47:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29339 for ; Tue, 1 Aug 2000 12:47:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA24937 for tcp-impl-outgoing; Tue, 1 Aug 2000 10:38:05 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA24906 for ; Tue, 1 Aug 2000 10:38:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA16851; Tue, 1 Aug 2000 10:38:01 -0400 Received: from unknown(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016666; Tue, 1 Aug 00 10:37:05 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id PAA05023 for ; Tue, 1 Aug 2000 15:36:44 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA11338; Tue, 1 Aug 2000 15:36:43 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id PAA29096; Tue, 1 Aug 2000 15:36:43 +0100 (BST) Date: Tue, 1 Aug 2000 15:36:43 +0100 From: Ian Heavens To: tcp-impl@grc.nasa.gov Subject: TCP RSTs issues discussion Message-ID: <20000801153643.B29080@malatesta.spider.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This will be at 11.15 Wednesday in the hotel bar of the Doubletree hotel. Off the topic of this list, but I wonder if SCTP could benefit from analysis of the experiences of TCP with RSTs, since it is not widely deployed (e.g. an error code with the SCTP ABORT) cheers ian -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 13:46:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12391 for ; Tue, 1 Aug 2000 13:46:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA08162 for tcp-impl-outgoing; Tue, 1 Aug 2000 11:50:50 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA08118 for ; Tue, 1 Aug 2000 11:50:47 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA26738; Tue, 1 Aug 2000 11:50:43 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026675; Tue, 1 Aug 00 11:50:39 -0400 Received: from isi.edu (ras01.isi.edu [128.9.176.101]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA29005; Tue, 1 Aug 2000 08:50:30 -0700 (PDT) Message-ID: <3986F1BD.105082F4@isi.edu> Date: Tue, 01 Aug 2000 08:50:21 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ian Heavens CC: tcp-impl@grc.nasa.gov Subject: Re: The TCP RST References: <20000731205427.B28460@malatesta.spider.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Ian Heavens wrote: > > hi TCP implementors, > > Anyone at the IETF want to talk about TCP RSTs? I'm here in > Pittsburgh. Issues have come up with application behaviour > and RFC 1122 half duplex close, and various others. I guess if there > is any interest we could list the issues for now, with a view to > pursuing them on this mailing list. I figure I would (given our past work on addressing this specific issue for high-perf web servers, i.e., Infocom 99: "The TIME-WAIT state in TCP and Its Effect on Busy Servers," Theodore Faber, Joe Touch, and Wei Yue, Proc. Infocom '99, pp. 1573-1583. http://www.isi.edu/touch/pubs/infocomm99/ I'm at IETF too... Joe From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 19:28:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04726 for ; Tue, 1 Aug 2000 19:28:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA03075 for tcp-impl-outgoing; Tue, 1 Aug 2000 17:10:01 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA03039 for ; Tue, 1 Aug 2000 17:09:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA13681; Tue, 1 Aug 2000 17:09:57 -0400 Received: from hilbert.umkc.edu(134.193.4.60) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013616; Tue, 1 Aug 00 17:09:05 -0400 Received: (qmail 459426 invoked from network); 1 Aug 2000 21:06:07 -0000 Received: from nicol1.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.62) by hilbert.umkc.edu with SMTP; 1 Aug 2000 21:06:07 -0000 Message-ID: <39873C3A.B8B6C0AC@kasey.umkc.edu> Date: Tue, 01 Aug 2000 16:08:10 -0500 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12-mosix i586) X-Accept-Language: en MIME-Version: 1.0 To: Ian Heavens CC: tcp-impl@grc.nasa.gov Subject: keep RST data nonstandardized for the future! References: <20000801153643.B29080@malatesta.spider.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit That would be the doubletree in Edinburgh? Here's my contribution to the discussion: I think that the fact that a RST can carry data is a built-in mechanism for extending TCP. In my proposal for tcp connections with transparently migrating ends, the data portion of the RST is where I found to stick the additional information, since the "reserved bits" are apparently untouchable, although they would be good too. (they are reserved for the army or something, right, in case they need to nationalize sprintlink all of a sudden for some reason, no?) So I would be against declaring a STANDARD on what that data can be (Apple apparently includes the reset reason in ascii english) unless the standard still leaves some room for extension. Ian Heavens wrote: > > This will be at 11.15 Wednesday in the hotel bar of the Doubletree > hotel. > > Off the topic of this list, but I wonder if SCTP could benefit > from analysis of the experiences of TCP with RSTs, since it > is not widely deployed (e.g. an error code with the SCTP ABORT) > > cheers > > ian > > -- > Ian Heavens, Spider Software Ltd., http://www.spider.com/ > 8 John's Place, Leith, Edinburgh EH6 7EL. > Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com -- David Nicol 816.235.1187 nicold@umkc.edu exec /bin/true From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 19:49:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09218 for ; Tue, 1 Aug 2000 19:49:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA07211 for tcp-impl-outgoing; Tue, 1 Aug 2000 17:56:08 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA07192 for ; Tue, 1 Aug 2000 17:56:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA18967; Tue, 1 Aug 2000 17:56:05 -0400 Received: from unknown(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018904; Tue, 1 Aug 00 17:55:17 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id WAA07085; Tue, 1 Aug 2000 22:55:09 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id WAA19514; Tue, 1 Aug 2000 22:55:08 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id WAA29407; Tue, 1 Aug 2000 22:55:08 +0100 (BST) Date: Tue, 1 Aug 2000 22:55:08 +0100 From: Ian Heavens To: "David L. Nicol" Cc: Ian Heavens , tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! Message-ID: <20000801225508.A29400@malatesta.spider.com> References: <20000801153643.B29080@malatesta.spider.com> <39873C3A.B8B6C0AC@kasey.umkc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <39873C3A.B8B6C0AC@kasey.umkc.edu>; from david@kasey.umkc.edu on Tue, Aug 01, 2000 at 04:08:10PM -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Tue, Aug 01, 2000 at 04:08:10PM -0500, David L. Nicol wrote: > > > That would be the doubletree in Edinburgh? Pittsburgh:-). I inadvertently scheduled it for 11.15 tomorrow when the morning IETF sessions continue to 11.30. So 11.30 is fine to meet. > > Here's my contribution to the discussion: > > > I think that the fact that a RST can carry data is a built-in > mechanism for extending TCP. In my proposal for tcp connections with > transparently migrating ends, the data portion of the RST is where I > found to stick the additional information, since the "reserved bits" > are apparently untouchable, although they would be good too. (they > are reserved for the army or something, right, in case they need to > nationalize sprintlink all of a sudden for some reason, no?) Excuse me for not having read your proposal - could you post a reference? > > So I would be against declaring a STANDARD on what that data can > be (Apple apparently includes the reset reason in ascii english) unless > the standard still leaves some room for extension. > > I think there must be room for "Vendor Extensions", whatever standardisation is agreed, so that your application will continue to work. It's interesting to see this RST data field being used in this way... Apple, Solaris and any Mentat TCP based stack do already include the reason for RST as an ASCII string. This is valuable in that interoperability issues have been ironed out already. cheers ian From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 20:06:51 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12993 for ; Tue, 1 Aug 2000 20:06:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA08937 for tcp-impl-outgoing; Tue, 1 Aug 2000 18:20:36 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA08915 for ; Tue, 1 Aug 2000 18:20:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA21318; Tue, 1 Aug 2000 18:20:32 -0400 Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021223; Tue, 1 Aug 00 18:19:41 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e71MJY610872; Tue, 1 Aug 2000 15:19:34 -0700 (PDT) Message-Id: <200008012219.e71MJY610872@daffy.ee.lbl.gov> To: Ian Heavens Cc: Scott Lawrence , tcp-impl@grc.nasa.gov Subject: Re: The TCP RST In-reply-to: Your message of Tue, 01 Aug 2000 15:11:35 BST. Date: Tue, 01 Aug 2000 15:19:34 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > PS as an aside, what mechanism does SCTP have to avoid TIME-WAIT > (a question for Vern)? My memory's rusty, but I believe SCTP doesn't have a TIME-WAIT state. There's little risk of a subsequent connection being confused with a previous connection, because each connection includes a 32-bit random verification tag (one for each direction) that, if incorrect, leads to packets being dropped. > Off the topic of this list, but I wonder if SCTP could benefit > from analysis of the experiences of TCP with RSTs, since it > is not widely deployed (e.g. an error code with the SCTP ABORT) One thing that would be helpful would be an analysis of SCTP's open/close mechanisms to determine whether they have reliability holes. Vern From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 20:58:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25468 for ; Tue, 1 Aug 2000 20:57:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11416 for tcp-impl-outgoing; Tue, 1 Aug 2000 18:54:16 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA11404 for ; Tue, 1 Aug 2000 18:54:15 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA24906; Tue, 1 Aug 2000 18:54:14 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024883; Tue, 1 Aug 00 18:54:12 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 18:54:09 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFBD@lespaul.process.com> From: Bernie Volz To: "'Ian Heavens'" , "David L. Nicol" Cc: tcp-impl@grc.nasa.gov Subject: RE: keep RST data nonstandardized for the future! Date: Tue, 1 Aug 2000 18:54:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Perhaps an FTP/SMTP/... like response format would be useful - digit code followed by a delimiter (space) followed by human readable text. That way, TCP itself and/or application can decode the numeric code and understand it and the application could also display the returned message for the human to read. It would be interesting for Apple, Sun (Solaris), and/or Mentat to perhaps provide a list of the messages that they currently return so we get an understanding of what the possible reasons they've captured are? Some that I could think of are: - No listener (for a SYN segment) - Unknown connection - Receiver discard connection (data received on a connection with no higher level receiver available) - Application abort (application requested RST on connection instead of closing it) - Bernie Volz -----Original Message----- From: Ian Heavens [mailto:ian@spider.com] Sent: Tuesday, August 01, 2000 5:55 PM To: David L. Nicol Cc: Ian Heavens; tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! On Tue, Aug 01, 2000 at 04:08:10PM -0500, David L. Nicol wrote: > > > That would be the doubletree in Edinburgh? Pittsburgh:-). I inadvertently scheduled it for 11.15 tomorrow when the morning IETF sessions continue to 11.30. So 11.30 is fine to meet. > > Here's my contribution to the discussion: > > > I think that the fact that a RST can carry data is a built-in > mechanism for extending TCP. In my proposal for tcp connections with > transparently migrating ends, the data portion of the RST is where I > found to stick the additional information, since the "reserved bits" > are apparently untouchable, although they would be good too. (they > are reserved for the army or something, right, in case they need to > nationalize sprintlink all of a sudden for some reason, no?) Excuse me for not having read your proposal - could you post a reference? > > So I would be against declaring a STANDARD on what that data can > be (Apple apparently includes the reset reason in ascii english) unless > the standard still leaves some room for extension. > > I think there must be room for "Vendor Extensions", whatever standardisation is agreed, so that your application will continue to work. It's interesting to see this RST data field being used in this way... Apple, Solaris and any Mentat TCP based stack do already include the reason for RST as an ASCII string. This is valuable in that interoperability issues have been ironed out already. cheers ian From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 20:58:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25575 for ; Tue, 1 Aug 2000 20:58:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA12661 for tcp-impl-outgoing; Tue, 1 Aug 2000 19:12:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA12634 for ; Tue, 1 Aug 2000 19:12:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA26812; Tue, 1 Aug 2000 19:12:34 -0400 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026740; Tue, 1 Aug 00 19:11:53 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id B92E04A8 for ; Tue, 1 Aug 2000 16:11:48 -0700 (PDT) Received: from cup.hp.com (raj@localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA06806 for ; Tue, 1 Aug 2000 16:11:38 -0700 (PDT) Message-ID: <39875929.D5A69109@cup.hp.com> Date: Tue, 01 Aug 2000 16:11:37 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <20000801153643.B29080@malatesta.spider.com> <39873C3A.B8B6C0AC@kasey.umkc.edu> <20000801225508.A29400@malatesta.spider.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Apple, Solaris and any Mentat TCP based stack do already include the > reason for RST as an ASCII string. This is valuable in that interoperability > issues have been ironed out already. You can include HP-UX 11.0 and 11i to that list of OSes whose stacks can send ASCII reason info in RST segments. 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 Aug 1 23:39:50 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23729 for ; Tue, 1 Aug 2000 23:39:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA23105 for tcp-impl-outgoing; Tue, 1 Aug 2000 21:43:29 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA23080 for ; Tue, 1 Aug 2000 21:43:26 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA12257; Tue, 1 Aug 2000 21:43:25 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012227; Tue, 1 Aug 00 21:43:14 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 631 for ; Tue, 1 Aug 2000 18:43:13 -0700 Message-ID: <39877CAC.6AFF6211@ehsco.com> Date: Tue, 01 Aug 2000 18:43:09 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <63D30D6E10CFD11190A90000F805FE8602BEBFBD@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Perhaps an FTP/SMTP/... like response format would be useful - > digit code followed by a delimiter (space) followed by human readable > text. That way, TCP itself and/or application can decode the numeric > code and understand it and the application could also display the > returned message for the human to read. I think it's pretty unlikely that applications will get the text if TCP is burning down the connection. Another problem with reverse standardization around data in the stream is that not everbody who does it already will be compliant with whatever approach is finished. Getting explicit errors out of the data stream seems like the best way to go if there's real interest in this. Maybe a TCP option would be a better way to handle a standardized format (as opposed to the legacy ad hoc approach), since that would allow for explicit codes, types and text, the latter of which could be explicitly passed to the application. Another benefit of using an option is that it would be ignored by legacy implementations as a matter of course. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Tue Aug 1 23:54:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26292 for ; Tue, 1 Aug 2000 23:54:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA24083 for tcp-impl-outgoing; Tue, 1 Aug 2000 22:02:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA24073 for ; Tue, 1 Aug 2000 22:01:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA14021; Tue, 1 Aug 2000 22:01:58 -0400 Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013983; Tue, 1 Aug 00 22:01:03 -0400 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id SAA27161; Tue, 1 Aug 2000 18:53:36 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 2 Aug 2000 02:01:02 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id TAA16114; Tue, 1 Aug 2000 19:01:01 -0700 (PDT) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [135.140.53.42]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id TAA03290; Tue, 1 Aug 2000 19:01:01 -0700 (PDT) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id TAA19946; Tue, 1 Aug 2000 19:01:00 -0700 (PDT) Message-Id: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 01 Aug 2000 19:01:55 -0700 To: Bernie Volz From: Ignacio Goyret Subject: RE: keep RST data nonstandardized for the future! Cc: "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBFBD@lespaul.process.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk At 06:54 PM 8/1/00 -0400, Bernie Volz wrote: >Some that I could think of are: >- No listener (for a SYN segment) >- Unknown connection >- Receiver discard connection (data received on a connection with no higher >level receiver available) >- Application abort (application requested RST on connection instead of >closing it) I'm sure that your reasons are well-meant and quite honest, but I have to wonder out loud if these codes won't be of great help to a hacker. For example, if I just get an RST and no code, it is harder for me to guess the reason than if I get an RST with "application abort". In the latter case, it might be easier to mount a DoS based on the knowledge obtained through those messages. For example, in the previous example, I can guess that an application was run and that it probably consumed some resources, so if I can trigger this type of RST, I might be able to consume all the resources on that server and either make it crash or make it run very slowly. Exactly what problem are you trying to solve by adding these codes? I also hope that all those vendors mentioned have knobs to enable these codes only when desired (they should default to disabled). From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 01:54:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14398 for ; Wed, 2 Aug 2000 01:54:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA29881 for tcp-impl-outgoing; Tue, 1 Aug 2000 23:52:33 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA29812 for ; Tue, 1 Aug 2000 23:52:31 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id XAA23950; Tue, 1 Aug 2000 23:52:31 -0400 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023906; Tue, 1 Aug 00 23:51:46 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 320C82AE for ; Tue, 1 Aug 2000 20:51:45 -0700 (PDT) Received: from cup.hp.com (raj@localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id UAA09507 for ; Tue, 1 Aug 2000 20:51:44 -0700 (PDT) Message-ID: <39879AD0.37642554@cup.hp.com> Date: Tue, 01 Aug 2000 20:51:44 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Ignacio Goyret wrote: > > At 06:54 PM 8/1/00 -0400, Bernie Volz wrote: > >Some that I could think of are: > >- No listener (for a SYN segment) > >- Unknown connection > >- Receiver discard connection (data received on a connection with no higher > >level receiver available) > >- Application abort (application requested RST on connection instead of > >closing it) > > I'm sure that your reasons are well-meant and quite honest, but I have to > wonder out loud if these codes won't be of great help to a hacker. Well heck, the very existence of the Internet is the greatest help a cracker has ever received. :) > For example, if I just get an RST and no code, it is harder for me to guess > the reason than if I get an RST with "application abort". In the latter case, > it might be easier to mount a DoS based on the knowledge obtained through > those messages. For example, in the previous example, I can guess that an > application was run and that it probably consumed some resources, so if > I can trigger this type of RST, I might be able to consume all the resources > on that server and either make it crash or make it run very slowly. I would think that in this example, you can already guess that an application was run and/or resources were consumed when your connection was accepted in the first place. Perhaps there are other texts from other situations that _might_ yield script-kiddie-useful info beyond the sending of the RST itself, but I cannot think of one myself at the moment. > I also hope that all those vendors mentioned have knobs to enable these codes > only when desired (they should default to disabled). ndd -set /dev/tcp tcp_text_in_resets 0 for HP-UX 11. The default however, is 1. 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 Wed Aug 2 05:41:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25556 for ; Wed, 2 Aug 2000 05:41:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA13309 for tcp-impl-outgoing; Wed, 2 Aug 2000 03:33:18 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA13250 for ; Wed, 2 Aug 2000 03:33:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA12670; Wed, 2 Aug 2000 03:33:15 -0400 Received: from mentat.com(192.88.122.129) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012631; Wed, 2 Aug 00 03:32:56 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id AAA09882; Wed, 2 Aug 2000 00:32:22 -0700 (PDT) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id AAA29848; Wed, 2 Aug 2000 00:32:21 -0700 (PDT) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id AAA05953; Wed, 2 Aug 2000 00:31:59 -0700 Date: Wed, 2 Aug 2000 00:31:59 -0700 From: jt@mentat.com (Jerry Toporek) Message-Id: <200008020731.AAA05953@rock.mentat.com> To: ian@spider.com, david@kasey.umkc.edu, Volz@ipworks.com Subject: RE: keep RST data nonstandardized for the future! Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > It would be interesting for Apple, Sun (Solaris), and/or Mentat to perhaps > provide a list of the messages that they currently return so we get an > understanding of what the possible reasons they've captured are? > Here's where the discussion left off exactly three years ago... > From jt Wed Jul 30 02:15:28 1997 > To: ian@spider.com > Subject: Re: RST data - meanings > X-Sun-Charset: US-ASCII > Content-Length: 1507 > X-Lines: 37 > Status: O > > > Sorry to hurry you on the RST types, but I'm hoping to put the > > draft in for the IETF deadline - in around 2 days I think... > > > > I'll certainly make sure that the proposed standards deviate > > as little as possible from your usage anyway > > Ok... Here's what we have... It's a pretty shabby collection so I have > added some commentary in parens to help interpret... > > tcp_accept, state changed (something weird happened to accepting stream) > tcp_close, couldn't detach (resource allocation failure) > tcp_close, abort rqstd (SO_LINGER with time -1) > tcp_close, unread data > tcp_close, during connect > tcp_disconnect (T_DISCON_REQ) > tcp_eager_blowoff, can't wait (T_DISCON_REQ before accept) > tcp_kill_conn (administrative request to abort connection) > tcp_kill_conn_by_addr (same thing, different flavor) > tcp_lift_anchor, can't wait (listener closed before accept) > TCPS_LISTEN-TH_ACK (unexpected ACK bit while in LISTEN state) > TCPS_LISTEN-TH_BAD_SECURITY (bad security specification) > TCPS_LISTEN-TH_BAD_PRECEDENCE (bad precedence) > TCPS_SYN_SENT-Bad_seq > TCPS_SYN_SENT-Bad_sec_or_prec-TH_ACK > TCPS_SYN_SENT-Bad_sec_or_prec > Bad_seq_or_prec-TCPS_SYN_RCVD > Bad_seq_or_prec > TH_SYN (SYN bit with unexpected sequence number) > TCPS_SYN_RCVD-bad_ack (SYN-ACK that doesn't ACK SYN) > new data when detached (new data received after close) > TCPS_TIME_WAIT-TH_ACK (inexplicable segment with ACK while TIME_WAIT) > TCPS_TIME_WAIT-??? (similar, but no ACK bit) > > Pretty ugly, actually, but helpful for customer support. > > jt > > From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 12:46:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19840 for ; Wed, 2 Aug 2000 12:46:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA13747 for tcp-impl-outgoing; Wed, 2 Aug 2000 09:34:27 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA13695 for ; Wed, 2 Aug 2000 09:34:23 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA15796; Wed, 2 Aug 2000 09:34:22 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015723; Wed, 2 Aug 00 09:33:39 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 09:33:37 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFC3@lespaul.process.com> From: Bernie Volz To: "'Eric A. Hall'" , tcp-impl@grc.nasa.gov Subject: RE: keep RST data nonstandardized for the future! Date: Wed, 2 Aug 2000 09:33:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Well, it isn't difficult to deal with the backwards compatibility issue PROVIDED none of these messages start with a numeric value. If the n-digit code followed by the delimiter is not present, assume the entire message is text. Using a TCP option is certainly an alternative. Note that this data is intended for the RECEIVER of the RST. That end of the connection will typically still be attached to an application. It would require a new API call or other means to obtain the message and also changing the applications to call this new API. So, most applications already written would not get this information unless modified. Perhaps a 'getsockopt' call of SO_RSTMSGTXT and SO_RSTMSGNUM or some such codes could be used. - Bernie Volz -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Tuesday, August 01, 2000 9:43 PM To: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! > Perhaps an FTP/SMTP/... like response format would be useful - > digit code followed by a delimiter (space) followed by human readable > text. That way, TCP itself and/or application can decode the numeric > code and understand it and the application could also display the > returned message for the human to read. I think it's pretty unlikely that applications will get the text if TCP is burning down the connection. Another problem with reverse standardization around data in the stream is that not everbody who does it already will be compliant with whatever approach is finished. Getting explicit errors out of the data stream seems like the best way to go if there's real interest in this. Maybe a TCP option would be a better way to handle a standardized format (as opposed to the legacy ad hoc approach), since that would allow for explicit codes, types and text, the latter of which could be explicitly passed to the application. Another benefit of using an option is that it would be ignored by legacy implementations as a matter of course. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 13:40:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07977 for ; Wed, 2 Aug 2000 13:40:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA29646 for tcp-impl-outgoing; Wed, 2 Aug 2000 10:54:25 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA29576 for ; Wed, 2 Aug 2000 10:54:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA28700; Wed, 2 Aug 2000 10:54:17 -0400 Received: from unknown(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028615; Wed, 2 Aug 00 10:53:38 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id PAA10843; Wed, 2 Aug 2000 15:53:03 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA20779; Wed, 2 Aug 2000 15:53:00 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id PAA29846; Wed, 2 Aug 2000 15:53:00 +0100 (BST) Date: Wed, 2 Aug 2000 15:52:59 +0100 From: Ian Heavens To: Jerry Toporek Cc: ian@spider.com, david@kasey.umkc.edu, Volz@ipworks.com, tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! Message-ID: <20000802155259.A29837@malatesta.spider.com> References: <200008020731.AAA05953@rock.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <200008020731.AAA05953@rock.mentat.com>; from jt@mentat.com on Wed, Aug 02, 2000 at 12:31:59AM -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I've actually written 75% of this draft and included Jerry's codes that he helpfully sent me three years ago! Also as far as I am aware Mentat is the ONLY TCP stack in wide circulation to use these codes. So if the providers of Mentat-based stacks (HP, Solaris, Apple) are willing to participate in and implement these codes (the internet draft will include example code), we have "de facto" standardisation or at least an example. I've spoken to William from HP on this. I suggest he, I and the Sun TCP people coauthor the draft. William pointed out that the biggest win would be to get the Microsoft stacks to include the error codes so we should approach them too. I've also discussed this with Alison Mankin and we can take this (and other RST issues ) to the Transport Area WG for discussion as needed. She supported the idea (let's face it, if you've ever had to work out why the heck a TCP connection has aborted for no obvious reason, any clue is useful). My thought was to present it as an Informational RFC . This could go on the standards track if there was enough interest - which would then get it into more TCP stacks. I followed the FTP/SMTP code / string idea in the draft as Rick suggested cheers ian On Wed, Aug 02, 2000 at 12:31:59AM -0700, Jerry Toporek wrote: > > > > It would be interesting for Apple, Sun (Solaris), and/or Mentat to perhaps > > provide a list of the messages that they currently return so we get an > > understanding of what the possible reasons they've captured are? > > > > Here's where the discussion left off exactly three years ago... > > > From jt Wed Jul 30 02:15:28 1997 > > To: ian@spider.com > > Subject: Re: RST data - meanings > > X-Sun-Charset: US-ASCII > > Content-Length: 1507 > > X-Lines: 37 > > Status: O > > > > > Sorry to hurry you on the RST types, but I'm hoping to put the > > > draft in for the IETF deadline - in around 2 days I think... > > > > > > I'll certainly make sure that the proposed standards deviate > > > as little as possible from your usage anyway > > > > Ok... Here's what we have... It's a pretty shabby collection so I have > > added some commentary in parens to help interpret... > > > > tcp_accept, state changed (something weird happened to accepting stream) > > tcp_close, couldn't detach (resource allocation failure) > > tcp_close, abort rqstd (SO_LINGER with time -1) > > tcp_close, unread data > > tcp_close, during connect > > tcp_disconnect (T_DISCON_REQ) > > tcp_eager_blowoff, can't wait (T_DISCON_REQ before accept) > > tcp_kill_conn (administrative request to abort connection) > > tcp_kill_conn_by_addr (same thing, different flavor) > > tcp_lift_anchor, can't wait (listener closed before accept) > > TCPS_LISTEN-TH_ACK (unexpected ACK bit while in LISTEN state) > > TCPS_LISTEN-TH_BAD_SECURITY (bad security specification) > > TCPS_LISTEN-TH_BAD_PRECEDENCE (bad precedence) > > TCPS_SYN_SENT-Bad_seq > > TCPS_SYN_SENT-Bad_sec_or_prec-TH_ACK > > TCPS_SYN_SENT-Bad_sec_or_prec > > Bad_seq_or_prec-TCPS_SYN_RCVD > > Bad_seq_or_prec > > TH_SYN (SYN bit with unexpected sequence number) > > TCPS_SYN_RCVD-bad_ack (SYN-ACK that doesn't ACK SYN) > > new data when detached (new data received after close) > > TCPS_TIME_WAIT-TH_ACK (inexplicable segment with ACK while TIME_WAIT) > > TCPS_TIME_WAIT-??? (similar, but no ACK bit) > > > > Pretty ugly, actually, but helpful for customer support. > > > > jt > > > > -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 13:55:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12981 for ; Wed, 2 Aug 2000 13:55:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA04397 for tcp-impl-outgoing; Wed, 2 Aug 2000 11:18:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA04381 for ; Wed, 2 Aug 2000 11:18:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA02637; Wed, 2 Aug 2000 11:18:13 -0400 Received: from unknown(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002577; Wed, 2 Aug 00 11:17:22 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id QAA11014; Wed, 2 Aug 2000 16:17:13 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA21318; Wed, 2 Aug 2000 16:17:13 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id QAA29905; Wed, 2 Aug 2000 16:17:12 +0100 (BST) Date: Wed, 2 Aug 2000 16:17:12 +0100 From: Ian Heavens To: "Eric A. Hall" Cc: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! Message-ID: <20000802161712.B29891@malatesta.spider.com> References: <63D30D6E10CFD11190A90000F805FE8602BEBFBD@lespaul.process.com> <39877CAC.6AFF6211@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <39877CAC.6AFF6211@ehsco.com>; from ehall@ehsco.com on Tue, Aug 01, 2000 at 06:43:09PM -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I don't think it's so important that applications get the text ..though useful, it will involve us with socket and other API issues. tcpdump or on the wire analysis, or syslog, is enough reason to do it. On Tue, Aug 01, 2000 at 06:43:09PM -0700, Eric A. Hall wrote: > > > Perhaps an FTP/SMTP/... like response format would be useful - > > digit code followed by a delimiter (space) followed by human readable > > text. That way, TCP itself and/or application can decode the numeric > > code and understand it and the application could also display the > > returned message for the human to read. > > I think it's pretty unlikely that applications will get the text if TCP > is burning down the connection. Another problem with reverse > standardization around data in the stream is that not everbody who does > it already will be compliant with whatever approach is finished. > I think Mentat-derived TCP stacks are the only ones > Getting explicit errors out of the data stream seems like the best way > to go if there's real interest in this. Maybe a TCP option would be a > better way to handle a standardized format (as opposed to the legacy ad > hoc approach), since that would allow for explicit codes, types and > text, the latter of which could be explicitly passed to the application. > Another benefit of using an option is that it would be ignored by legacy > implementations as a matter of course. > Either approach would work (similar API issues I guess). RST+data has advantage that there's running code (and we know receivers can handle it, as opposed to a new option - presumably with the RST, so the only difference is the TCP header length and a TCP option code. I think I may have mentioned this in the draft, (better go and read it :-). Oh, we'd have to apply for a TCP option whereas RFC 1122 alread pwermits data in the TCP ian ian > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 13:59:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14029 for ; Wed, 2 Aug 2000 13:59:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA03721 for tcp-impl-outgoing; Wed, 2 Aug 2000 11:14:10 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA03682 for ; Wed, 2 Aug 2000 11:14:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA02015; Wed, 2 Aug 2000 11:14:05 -0400 Received: from mentat.com(192.88.122.129) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001926; Wed, 2 Aug 00 11:13:47 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA11105; Wed, 2 Aug 2000 08:13:49 -0700 (PDT) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id IAA07422; Wed, 2 Aug 2000 08:13:49 -0700 (PDT) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id IAA06203; Wed, 2 Aug 2000 08:13:26 -0700 Date: Wed, 2 Aug 2000 08:13:26 -0700 From: jt@mentat.com (Jerry Toporek) Message-Id: <200008021513.IAA06203@rock.mentat.com> To: ian@spider.com Subject: Re: keep RST data nonstandardized for the future! Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A few observations: - We've had this feature in the field for most of a decade. It has been occasionally helpful and I'm not aware of it ever causing a problem. (There was one printer which somehow accepted the strings as data and added them to the last page, but complaints, if any, never got back to us ;-). - We have always provided a switch to turn off the feature, but I am not aware of it ever being used. The default has always been "on". - We would be happy to clean up using a code/text format. As I noted, our current strings are not uniformly attractive nor comprehensible. - The suggested set of messages would, of course, have to be extendable. Some of ours are very implementation specific and would be meaningless in a general specification. - I can't imagine how the information would give a hacker anything that they don't already have. jt From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 16:20:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02404 for ; Wed, 2 Aug 2000 16:20:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA04872 for tcp-impl-outgoing; Wed, 2 Aug 2000 14:13:39 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA04850 for ; Wed, 2 Aug 2000 14:13:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA28874; Wed, 2 Aug 2000 14:13:35 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028791; Wed, 2 Aug 00 14:13:25 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 556; Wed, 2 Aug 2000 11:13:21 -0700 Message-ID: <398864C0.9D7D3A3E@ehsco.com> Date: Wed, 02 Aug 2000 11:13:20 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ian Heavens CC: Jerry Toporek , david@kasey.umkc.edu, Volz@ipworks.com, tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <200008020731.AAA05953@rock.mentat.com> <20000802155259.A29837@malatesta.spider.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > I've actually written 75% of this draft and included Jerry's codes > that he helpfully sent me three years ago! Also as far as I am aware > Mentat is the ONLY TCP stack in wide circulation to use these codes. ONLY has no relevance to WIDE; it's the ONLY or it's not. The problem with data in the stream is multi-dimensional. First of all, the specs let anybody do anything, and I guarantee that somebody is doing something that won't be appreciated. It is highly likely that there are at least a few implementations which (1) use some format you do not, (2) leave binary data as leftovers in the RST, or (3) will do something else in the future since the spec allows it. If we are going to standardize on the interpretation of errors, then the representation should be standardized in such a way that interpretation is not likely. Reverse-standardizing on legacy representations does not satisfy that objective. In other words, if we find out that in some particular scenario there are many stacks which leave binary junk in the data stream for RST then your spec will be instantly broken. To wit: > I followed the FTP/SMTP code / string idea in the draft as Rick > suggested That will make legacy Mentat implementations non-compliant, and will require coding around. The primary benefit of an RST option is that the representation of the failure is removed from the datastream, guaranteeing that the only implementations who do anything with it are the implementations who know WHAT to do with it explicitly. A secondary benefit is that TEXT data is not required, but instead there is room for explicit codes/types in 2 bytes of option data (four bytes if you include all the option overhead which isn't necessary with options that are not variable-length). Trying to do this in the free-form datastream is a bad idea all around, I believe. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 17:18:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23775 for ; Wed, 2 Aug 2000 17:18:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA14350 for tcp-impl-outgoing; Wed, 2 Aug 2000 15:07:47 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA14247 for ; Wed, 2 Aug 2000 15:07:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA07040; Wed, 2 Aug 2000 15:07:39 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006944; Wed, 2 Aug 00 15:07:11 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 15:07:10 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFC7@lespaul.process.com> From: Bernie Volz To: "'Eric A. Hall'" , Ian Heavens Cc: Jerry Toporek , david@kasey.umkc.edu, Bernie Volz , tcp-impl@grc.nasa.gov Subject: RE: keep RST data nonstandardized for the future! Date: Wed, 2 Aug 2000 15:07:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk When we discussed this today, it was decided to consider an instrumentation option for TCP. One of the instrumentation values would be a code (or codes) for the cause of a RST. Implementations are thus still free to do what they do today (such as placing a text message in the data portion); however, that is only useful for packet tracing and is not available or useable by an application. Note that an API interface (for BSD sockets for example) was not really discussed for the instrumentation option and might be an issue to consider. Likely, an option would be sent in a SYN to advertise the ability to support the instrumentation option. Lack of a reply with a similar option in the SYN/ACK would mean that the peer does not support the option and hence it would not be used. (This is similar to how other options, such as SACK, work.) Don't flame this approach yet as it is still in the process of being developed. Also, my brief description above likely has not done it justice. - Bernie Volz -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Wednesday, August 02, 2000 2:13 PM To: Ian Heavens Cc: Jerry Toporek; david@kasey.umkc.edu; Volz@ipworks.com; tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! > I've actually written 75% of this draft and included Jerry's codes > that he helpfully sent me three years ago! Also as far as I am aware > Mentat is the ONLY TCP stack in wide circulation to use these codes. ONLY has no relevance to WIDE; it's the ONLY or it's not. The problem with data in the stream is multi-dimensional. First of all, the specs let anybody do anything, and I guarantee that somebody is doing something that won't be appreciated. It is highly likely that there are at least a few implementations which (1) use some format you do not, (2) leave binary data as leftovers in the RST, or (3) will do something else in the future since the spec allows it. If we are going to standardize on the interpretation of errors, then the representation should be standardized in such a way that interpretation is not likely. Reverse-standardizing on legacy representations does not satisfy that objective. In other words, if we find out that in some particular scenario there are many stacks which leave binary junk in the data stream for RST then your spec will be instantly broken. To wit: > I followed the FTP/SMTP code / string idea in the draft as Rick > suggested That will make legacy Mentat implementations non-compliant, and will require coding around. The primary benefit of an RST option is that the representation of the failure is removed from the datastream, guaranteeing that the only implementations who do anything with it are the implementations who know WHAT to do with it explicitly. A secondary benefit is that TEXT data is not required, but instead there is room for explicit codes/types in 2 bytes of option data (four bytes if you include all the option overhead which isn't necessary with options that are not variable-length). Trying to do this in the free-form datastream is a bad idea all around, I believe. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 17:28:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26966 for ; Wed, 2 Aug 2000 17:28:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA15829 for tcp-impl-outgoing; Wed, 2 Aug 2000 15:15:03 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA15795 for ; Wed, 2 Aug 2000 15:15:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA08397; Wed, 2 Aug 2000 15:14:59 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008332; Wed, 2 Aug 00 15:14:36 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 642; Wed, 2 Aug 2000 12:14:29 -0700 Message-ID: <39887314.78F21B2F@ehsco.com> Date: Wed, 02 Aug 2000 12:14:28 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bernie Volz CC: Ian Heavens , Jerry Toporek , david@kasey.umkc.edu, tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <63D30D6E10CFD11190A90000F805FE8602BEBFC7@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Likely, an option would be sent in a SYN to advertise the ability to > support the instrumentation option. Lack of a reply with a similar > option in the SYN/ACK would mean that the peer does not support the > option and hence it would not be used. (This is similar to how other > options, such as SACK, work.) In the case of RST being issued in response to the SYN request, there would be no successful negotiation. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 17:59:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08167 for ; Wed, 2 Aug 2000 17:59:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA27237 for tcp-impl-outgoing; Wed, 2 Aug 2000 16:18:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA27179 for ; Wed, 2 Aug 2000 16:18:27 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA17898; Wed, 2 Aug 2000 16:18:23 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017867; Wed, 2 Aug 00 16:18:13 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13K4q5-0000rr-00; Wed, 2 Aug 2000 21:10:05 +0100 Subject: Re: keep RST data nonstandardized for the future! To: ehall@ehsco.com (Eric A. Hall) Date: Wed, 2 Aug 2000 21:10:03 +0100 (BST) Cc: ian@spider.com (Ian Heavens), jt@mentat.com (Jerry Toporek), david@kasey.umkc.edu, Volz@ipworks.com, tcp-impl@grc.nasa.gov In-Reply-To: <398864C0.9D7D3A3E@ehsco.com> from "Eric A. Hall" at Aug 02, 2000 11:13:20 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > doing something that won't be appreciated. It is highly likely that > there are at least a few implementations which (1) use some format you > do not, (2) leave binary data as leftovers in the RST, or (3) will do > something else in the future since the spec allows it. Actually I am more concerned with (4) - corner cases Do we do PMTU discovery on RST frames that are now too long to fit through a gateway. Remember the RST can be the reply to the SYN so we have no prior history here. I guess the RST has to go out < 576 bytes long and not set DF ? Now next question: What language are the RST strings in. Are they UTF8 encoded, how do I use a TCP option to indicate the language I want the reply in [Or read] Why the hell are we sending random bits of western european language only text around anyway ? Alan From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 18:09:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11638 for ; Wed, 2 Aug 2000 18:09:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA26923 for tcp-impl-outgoing; Wed, 2 Aug 2000 16:16:31 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA26808 for ; Wed, 2 Aug 2000 16:16:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA17575; Wed, 2 Aug 2000 16:16:20 -0400 Received: from unknown(147.73.128.112) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016835; Wed, 2 Aug 00 16:11:01 -0400 Received: (from ietfuser@localhost) by wired-128-112.ietf.marconi.com (8.9.3/8.9.3) id QAA05076; Wed, 2 Aug 2000 16:07:45 -0400 From: IETF user Message-Id: <200008022007.QAA05076@wired-128-112.ietf.marconi.com> Subject: Doubletree RST 'BOF' meeting notes To: tcp-impl@grc.nasa.gov Date: Wed, 2 Aug 2000 16:07:44 -0400 (EDT) Cc: ian@spider.com, mankin@east.isi.edu, tgl@sss.pgh.pa.us X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Attendees: Ian Heavens ("chair"/minutes,Spider Software), William Gilliam (HP), Joe Touch (ISI), Bernie Volz (IPworks), Tom Lane (sss?), Scott Lawrence (Agranat) I hope these notes reflect the discussion - please add/correct if not! It was (as always at the IETF) a spirited discussion and I may have not always reflected the consensus accurately. 1. Error codes with RSTs Two approaches to this were apparent - useful diagnostic tool (just need to see these on the wire) - and whether the receiver could do anything useful with them. As pointed out on the mailing list, the RST data field is not appropriate for the latter - no API, and standardising this might (or will) overlap with other current uses. Joe Touch pointed out that what is really needed is a generic "Instrumentation Option" that can be carried in any segment. However, the "send RST error code" option would have to default to on (send it unless the receiver NAKs the option request), or the current usefulness of using the data field would be lost (until receiver TCP implementations supported the option). Instrumentation option could be passed to the application as SACK option implementation supports this. [the SACK people would like this option too - Matt Matthis told me afterwards however that currently SACK options must be sent with the SYN as some implementations fall over if the first TCP option is sent with a non-SYN segment. So this must be solved before the instrumentation option is generally useful. Two conclusions: [1] Instrumentation option generally useful and the only mechanism by which RST error codes can be standardised [2] RST error code taxonomy can still be published as an Informational RFC as it will be needed for use by the instrumentation option (and TCP implementations that send data with RSTs in this way can - at least - use agreed codes) [is anyone arguing that it is bad to use RST data in this manner? Or just that it cannot be reserved for this usage?]. I don't know if anyone wants to follow up the instrumentation option issue?? HP/Mentat/Spider/(Sun?) will complete and submit my RST error codes draft. 2. TIME-WAIT and RSTs There is no TIME-WAIT after RST (first submitted in expired draft by myself in 1994 I think..) and so no protection against acceptance of stale data by a new connection. Solutions discussed in that draft and Joe Touch's paper on using RSTs to transfer responsibility for TIME-WAIT from servers to clients. Basically TIME-WAIT after sending a RST (in ESTABLISHED and half-closed states) with 'soft and hard TIME-WAIT' indicating how RSTs are treated in TIME-WAIT (stemming from RFC 1337 and Joe's paper). We discussed the implementation issues in supporting many TIME-WAITS - as this was perceived at the time as an obstacle to solving the issue, since TIME-WAIT after RST will increase the number of connections in TIME-WAIT state: these are well documented and understood now. I will submit the "Problem Statement" again as an Informational RFC (to underline that application writers should not abort connections with a RST to circumvent TIME-WAIT: Scott Bradner suggested a few years ago that it could be a Best Current Practices to reinforce this). Joe/myself/Ted Faber will submit the solution as an internet draft (whether Informational or standards track will depend on whether it is perceived that the solution is preferable to the status quo). This will strongly reference work on implementation issues. 3. Miscellaneous application and API issues Tom Lane has highlighted a usage of RSTs that conflicts with RFC 1122 half duplex close recommendation (and emphasised in RFC 2525 - contributed by me). Bernie Volz and Tom discussed this after so I don't know whether the conclusion was that the application should avoid sockets close() and use shutdown() - thereby circumventing RFC 1122 completely (it only applying to use of APIs that close in both directions ). To be pursued on the list if appropriate, with possible clarification of RFC 1122 and RFC 2525. The Transport Area WG is appropriate for discussion of the above drafts and the authors will bring them to a future IETF meeting... Thanks to all those who participated ian (about to duck :-) PS I will put together a web page with the missing references above From owner-tcp-impl@lerc.nasa.gov Wed Aug 2 20:49:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25828 for ; Wed, 2 Aug 2000 20:49:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA12152 for tcp-impl-outgoing; Wed, 2 Aug 2000 18:42:57 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA12119 for ; Wed, 2 Aug 2000 18:42:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA05090; Wed, 2 Aug 2000 18:42:52 -0400 Received: from sss.pgh.pa.us(209.114.166.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005030; Wed, 2 Aug 00 18:42:00 -0400 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA01829 for ; Wed, 2 Aug 2000 18:41:52 -0400 (EDT) To: tcp-impl@grc.nasa.gov Subject: Re: Doubletree RST 'BOF' meeting notes In-reply-to: <200008022007.QAA05076@wired-128-112.ietf.marconi.com> References: <200008022007.QAA05076@wired-128-112.ietf.marconi.com> Comments: In-reply-to IETF user message dated "Wed, 02 Aug 2000 16:07:44 -0400" Date: Wed, 02 Aug 2000 18:41:52 -0400 Message-ID: <1826.965256112@sss.pgh.pa.us> From: Tom Lane Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Ian Heavens wrote: > Tom Lane has highlighted a usage of RSTs that conflicts with RFC 1122 > half duplex close recommendation (and emphasised in RFC 2525 - > contributed by me). Bernie Volz and Tom discussed this after so I > don't know whether the conclusion was that the application should > avoid sockets close() and use shutdown() - thereby circumventing RFC > 1122 completely (it only applying to use of APIs that close in both > directions ). To be pursued on the list if appropriate, with possible > clarification of RFC 1122 and RFC 2525. [ Hi folks. I just joined the list --- am not a TCP implementor, but got interested in this particular issue for reasons about to be stated. ] The situation that I am interested in is an application where data can flow asynchronously in both directions. Actually, it's mostly a client request/server response protocol, but the server can also send unsolicited messages at any time. In particular the server application can send an error message and immediately close the connection (indeed, it quits completely) without waiting around for the far-end app to get that message. Question for the list is, is this application misusing the TCP protocol, and if so why? Seems to me that once the TCP stack has accepted data to be sent, it ought to make a reasonable effort to deliver that data, whether the sending app is holding the connection open or not. The problem case arises when the far-end app is busy sending a new request just as the near-end app emits its final message and closes its socket FD. RFC 1122 (4.2.2.13) says A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. (See also 2.16 and 2.17 in RFC 2525.) Some, but not all, stacks appear to issue such an RST when they see incoming data from the far end, *even though they still have un-acked outbound data to transmit*. This results in loss of the outbound data. A variant is that even if the data has been transmitted and acked but not actually delivered to the far-end client app, the far-end TCP may discard the data from its buffer upon receiving the RST. Still a third variant (which seems to be what the current Linux stack does, at least when both ends are on the same machine) is that the far-end client may receive an ECONNRESET error from its next read() attempt, though not all the data has been delivered to it. If the client is loony enough to think that ECONNRESET is a soft error, it will indeed discover that it can read more data by trying again! I claim that all these behaviors are broken, and that the right thing to do if the TCP has noplace to deliver incoming data to is to ack and discard the data. It would be OK to send an RST to discourage the other end from sending more data *only* if there is no un-ACKed data remaining to be sent from this end. Without this, half-duplex connections are useless. TCPs should also be dissuaded from dropping buffered inbound data when they see inbound RST or delivering a report of incoming RST out-of-sequence from the data. The discussion at the Doubletree mostly focused on whether the app should deal with this situation by holding open its socket for some timeout period after sending its final outgoing message, so as to read and discard any data that might happen to arrive. That is certainly the only available answer if one needs an answer today, but I still think that it's a workaround for broken TCP behavior. Essentially, this is asking the app to take on the connection-shutdown duties that TCP ought to handle for it. (To take just one example, how should the app know what an appropriate timeout is? Seems like that's a concern the TCP layer should deal with, not the app. The app will also be unable to detect when the last outbound data has been ACKed, and will therefore have to hold the connection open much longer than would otherwise be necessary in most cases.) Anyway, that's my story. Is my app broken, or is the recommendation for issuing an RST in this scenario misguided? regards, tom lane From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 11:26:43 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14614 for ; Thu, 3 Aug 2000 11:26:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA10285 for tcp-impl-outgoing; Thu, 3 Aug 2000 09:37:58 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA10255 for ; Thu, 3 Aug 2000 09:37:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA23973; Thu, 3 Aug 2000 09:37:53 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023914; Thu, 3 Aug 00 09:37:49 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 09:37:48 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFC9@lespaul.process.com> From: Bernie Volz To: "'Eric A. Hall'" Cc: Ian Heavens , Jerry Toporek , david@kasey.umkc.edu, tcp-impl@grc.nasa.gov Subject: RE: keep RST data nonstandardized for the future! Date: Thu, 3 Aug 2000 09:37:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Eric: You are wrong about that. Think about it. If a SYN is RECEIVED with the option to enable this feature, then the RST from the SYN can be set back with the option (since you know the sender of the SYN is capable of supporting the option). - Bernie Volz IPWorks, Inc. -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Wednesday, August 02, 2000 3:14 PM To: Bernie Volz Cc: Ian Heavens; Jerry Toporek; david@kasey.umkc.edu; tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! > Likely, an option would be sent in a SYN to advertise the ability to > support the instrumentation option. Lack of a reply with a similar > option in the SYN/ACK would mean that the peer does not support the > option and hence it would not be used. (This is similar to how other > options, such as SACK, work.) In the case of RST being issued in response to the SYN request, there would be no successful negotiation. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 11:28:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15371 for ; Thu, 3 Aug 2000 11:28:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA07917 for tcp-impl-outgoing; Thu, 3 Aug 2000 09:22:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA07894 for ; Thu, 3 Aug 2000 09:22:21 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA22085; Thu, 3 Aug 2000 09:22:20 -0400 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022024; Thu, 3 Aug 00 09:21:40 -0400 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id JAA14972; Thu, 3 Aug 2000 09:21:28 -0400 (EDT) (envelope-from craig@aland.bbn.com) Message-Id: <200008031321.JAA14972@aland.bbn.com> To: ian@spider.com cc: tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting notes In-reply-to: Your message of "Wed, 02 Aug 2000 16:07:44 EDT." <200008022007.QAA05076@wired-128-112.ietf.marconi.com> Date: Thu, 03 Aug 2000 09:21:27 -0400 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >I don't know if anyone wants to follow up the instrumentation option issue?? >HP/Mentat/Spider/(Sun?) will complete and submit my RST error codes draft. Some of the email suggested the error codes should follow the SMTP/FTP convention (3 digit numbers where the different digits indicate the severity of error). I thought that was a nice idea. Is that still the plan? Thanks! Craig From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:00:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29040 for ; Thu, 3 Aug 2000 12:00:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA13843 for tcp-impl-outgoing; Thu, 3 Aug 2000 09:58:53 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA13831 for ; Thu, 3 Aug 2000 09:58:51 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA26655; Thu, 3 Aug 2000 09:58:51 -0400 Received: from mercury.spider.com(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026576; Thu, 3 Aug 00 09:57:54 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id OAA16281; Thu, 3 Aug 2000 14:57:42 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA27911; Thu, 3 Aug 2000 14:57:42 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id OAA00649; Thu, 3 Aug 2000 14:57:41 +0100 (BST) Date: Thu, 3 Aug 2000 14:57:41 +0100 From: Ian Heavens To: Craig Partridge , '@spider.com Cc: ian@spider.com, tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting note Message-ID: <20000803145741.A642@malatesta.spider.com> References: <200008022007.QAA05076@wired-128-112.ietf.marconi.com> <200008031321.JAA14972@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <200008031321.JAA14972@aland.bbn.com>; from craig@aland.bbn.com on Thu, Aug 03, 2000 at 09:21:27AM -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Thu, Aug 03, 2000 at 09:21:27AM -0400, Craig Partridge wrote: > > >I don't know if anyone wants to follow up the instrumentation option issue?? > >HP/Mentat/Spider/(Sun?) will complete and submit my RST error codes draft. > > Some of the email suggested the error codes should follow the SMTP/FTP > convention (3 digit numbers where the different digits indicate the > severity of error). I thought that was a nice idea. Is that still the > plan? Sounds a good approach...the only thing is I'm not sure how many severity levels one could define for a RST.... cheers ian From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:02:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00038 for ; Thu, 3 Aug 2000 12:02:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA13525 for tcp-impl-outgoing; Thu, 3 Aug 2000 09:56:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA13490 for ; Thu, 3 Aug 2000 09:56:52 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA26482; Thu, 3 Aug 2000 09:56:50 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026414; Thu, 3 Aug 00 09:56:47 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 09:56:45 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFCB@lespaul.process.com> From: Bernie Volz To: "'Tom Lane'" , tcp-impl@grc.nasa.gov Subject: RE: Doubletree RST 'BOF' meeting notes Date: Thu, 3 Aug 2000 09:56:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk If this situation is critical to your application, I'd recommend the following flow: Send the "end-of-connection" message. Issue a shutdown of the send side. Issue a read with a short time-out (short can be up to the application). Note that one option is to use a select, with timeout. If data is read (or available for the select, read it), restart the read (or select). If there is an error (timeout) or read returns end of connection, call close. This is the safest and surest way to close a connection on any stack. We should have the discussion on whether the RST behavior is correct or not, but that won't solve the problem for existing stacks that exhibit this behavior. When working on the "Known Problems" issues, I tested a bunch of stacks and they did exhibit this behavior (though I can't say whether there was always data flowing in both directions). I should also point out that even if one fixes the stacks regarding the RST behavior, there is still the question as to whether a stack should deliver all received data when it has received an RST on a connection or drop that data to notify the application as early as possible that the connection is gone. If the stack drops any received data, then just changing the sending of the RST doesn't solve the problem. Consider: Client Server ------ ------ Sends "large" buffer Sends "small" shutdown message ACKs "small" shutdown message Sends FIN ACKs "FIN" More of "large" buffer sent Sends RST Receives RST Now, if the client side drops all of received data, the application hasn't read the data and hence never gets the final message anyway. So, to fix the problem you describe requires TWO changes: 1) Don't send RST on incoming data if there is still outgoing data to deliver. 2) Don't drop received data when RST received on a connection. -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Wednesday, August 02, 2000 6:42 PM To: tcp-impl@grc.nasa.gov Subject: Re: Doubletree RST 'BOF' meeting notes Ian Heavens wrote: > Tom Lane has highlighted a usage of RSTs that conflicts with RFC 1122 > half duplex close recommendation (and emphasised in RFC 2525 - > contributed by me). Bernie Volz and Tom discussed this after so I > don't know whether the conclusion was that the application should > avoid sockets close() and use shutdown() - thereby circumventing RFC > 1122 completely (it only applying to use of APIs that close in both > directions ). To be pursued on the list if appropriate, with possible > clarification of RFC 1122 and RFC 2525. [ Hi folks. I just joined the list --- am not a TCP implementor, but got interested in this particular issue for reasons about to be stated. ] The situation that I am interested in is an application where data can flow asynchronously in both directions. Actually, it's mostly a client request/server response protocol, but the server can also send unsolicited messages at any time. In particular the server application can send an error message and immediately close the connection (indeed, it quits completely) without waiting around for the far-end app to get that message. Question for the list is, is this application misusing the TCP protocol, and if so why? Seems to me that once the TCP stack has accepted data to be sent, it ought to make a reasonable effort to deliver that data, whether the sending app is holding the connection open or not. The problem case arises when the far-end app is busy sending a new request just as the near-end app emits its final message and closes its socket FD. RFC 1122 (4.2.2.13) says A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. (See also 2.16 and 2.17 in RFC 2525.) Some, but not all, stacks appear to issue such an RST when they see incoming data from the far end, *even though they still have un-acked outbound data to transmit*. This results in loss of the outbound data. A variant is that even if the data has been transmitted and acked but not actually delivered to the far-end client app, the far-end TCP may discard the data from its buffer upon receiving the RST. Still a third variant (which seems to be what the current Linux stack does, at least when both ends are on the same machine) is that the far-end client may receive an ECONNRESET error from its next read() attempt, though not all the data has been delivered to it. If the client is loony enough to think that ECONNRESET is a soft error, it will indeed discover that it can read more data by trying again! I claim that all these behaviors are broken, and that the right thing to do if the TCP has noplace to deliver incoming data to is to ack and discard the data. It would be OK to send an RST to discourage the other end from sending more data *only* if there is no un-ACKed data remaining to be sent from this end. Without this, half-duplex connections are useless. TCPs should also be dissuaded from dropping buffered inbound data when they see inbound RST or delivering a report of incoming RST out-of-sequence from the data. The discussion at the Doubletree mostly focused on whether the app should deal with this situation by holding open its socket for some timeout period after sending its final outgoing message, so as to read and discard any data that might happen to arrive. That is certainly the only available answer if one needs an answer today, but I still think that it's a workaround for broken TCP behavior. Essentially, this is asking the app to take on the connection-shutdown duties that TCP ought to handle for it. (To take just one example, how should the app know what an appropriate timeout is? Seems like that's a concern the TCP layer should deal with, not the app. The app will also be unable to detect when the last outbound data has been ACKed, and will therefore have to hold the connection open much longer than would otherwise be necessary in most cases.) Anyway, that's my story. Is my app broken, or is the recommendation for issuing an RST in this scenario misguided? regards, tom lane From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:03:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00334 for ; Thu, 3 Aug 2000 12:03:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA16413 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:09:39 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA16341 for ; Thu, 3 Aug 2000 10:09:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA28137; Thu, 3 Aug 2000 10:09:30 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028044; Thu, 3 Aug 00 10:09:07 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 10:09:02 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFCD@lespaul.process.com> From: Bernie Volz To: "'Eric A. Hall'" Cc: Ian Heavens , Jerry Toporek , david@kasey.umkc.edu, tcp-impl@grc.nasa.gov Subject: RE: keep RST data nonstandardized for the future! Date: Thu, 3 Aug 2000 10:09:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk However, there is one case where there is no ability to send the RST reason code if we use this negotiation approach ... and that is when the TCP stack receiving a packet has NO knowledge of the connection (such as if it has just rebooted and connections were active when it crashed). So, we might need to consider an exception in this case ... if a TCP receives a packet for a connection it has no knowledge of, it MAY send a RST reason code (in the "TCP Instrumentation Option"). - Bernie Volz IPWorks, Inc. -----Original Message----- From: Bernie Volz [mailto:Volz@ipworks.com] Sent: Thursday, August 03, 2000 9:38 AM To: 'Eric A. Hall' Cc: Ian Heavens; Jerry Toporek; david@kasey.umkc.edu; tcp-impl@grc.nasa.gov Subject: RE: keep RST data nonstandardized for the future! Eric: You are wrong about that. Think about it. If a SYN is RECEIVED with the option to enable this feature, then the RST from the SYN can be set back with the option (since you know the sender of the SYN is capable of supporting the option). - Bernie Volz IPWorks, Inc. -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Wednesday, August 02, 2000 3:14 PM To: Bernie Volz Cc: Ian Heavens; Jerry Toporek; david@kasey.umkc.edu; tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! > Likely, an option would be sent in a SYN to advertise the ability to > support the instrumentation option. Lack of a reply with a similar > option in the SYN/ACK would mean that the peer does not support the > option and hence it would not be used. (This is similar to how other > options, such as SACK, work.) In the case of RST being issued in response to the SYN request, there would be no successful negotiation. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:08:53 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02689 for ; Thu, 3 Aug 2000 12:08:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA15166 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:04:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA15096 for ; Thu, 3 Aug 2000 10:04:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA27460; Thu, 3 Aug 2000 10:04:22 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027362; Thu, 3 Aug 00 10:03:51 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 10:03:50 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFCC@lespaul.process.com> From: Bernie Volz To: "'Craig Partridge'" , ian@spider.com Cc: tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: RE: Doubletree RST 'BOF' meeting notes Date: Thu, 3 Aug 2000 10:03:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I was one of the people that suggested that. However, I believe that the plan might be as follows: 1) The to be created "TCP Instrumentation" option will be used to carry a RST error code. This would likely be a 8 or 16 bit value (256 codes is probably more than enough). This code is meant to be available to an application such that it can issue an appropriate error message or otherwise react better to the cause of the RST if it wants to. 2) A stack would be free to include any error text it wanted (or other data) in the TCP data portion of the RST packet. However, as this will not be standardized, it is also possible that "junk" is there (for example, application data). The intent of this data would be for debugging purposes when doing packet traces and not something available to the TCP stack or application. It would also not be standardized. (Implementators might also be warned about making sure that the message fits within the maximum segment size being used by the connection and perhaps not setting the Don't Fragment bit in the IP header.) - Bernie -----Original Message----- From: Craig Partridge [mailto:craig@aland.bbn.com] Sent: Thursday, August 03, 2000 9:21 AM To: ian@spider.com Cc: tcp-impl@grc.nasa.gov; mankin@east.isi.edu; tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting notes >I don't know if anyone wants to follow up the instrumentation option issue?? >HP/Mentat/Spider/(Sun?) will complete and submit my RST error codes draft. Some of the email suggested the error codes should follow the SMTP/FTP convention (3 digit numbers where the different digits indicate the severity of error). I thought that was a nice idea. Is that still the plan? Thanks! Craig From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:18:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06265 for ; Thu, 3 Aug 2000 12:18:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA20636 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:32:23 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA20602 for ; Thu, 3 Aug 2000 10:32:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA01464; Thu, 3 Aug 2000 10:32:19 -0400 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001393; Thu, 3 Aug 00 10:31:38 -0400 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id KAA15150; Thu, 3 Aug 2000 10:31:31 -0400 (EDT) (envelope-from craig@aland.bbn.com) Message-Id: <200008031431.KAA15150@aland.bbn.com> To: Ian Heavens cc: Craig Partridge , tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting note In-reply-to: Your message of "Thu, 03 Aug 2000 14:57:41 BST." <20000803145741.A642@malatesta.spider.com> Date: Thu, 03 Aug 2000 10:31:31 -0400 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <20000803145741.A642@malatesta.spider.com>, Ian Heavens writes: >Sounds a good approach...the only thing is I'm not sure how many >severity levels one could define for a RST.... Well the existing scheme envisions two types: transient and permanent errors and then a bunch of subcodes. Now I'm not sure there's any transient condition that provokes an RST, but perhaps... Craig From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:23:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08485 for ; Thu, 3 Aug 2000 12:23:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA20475 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:31:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA20415 for ; Thu, 3 Aug 2000 10:31:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA01303; Thu, 3 Aug 2000 10:31:15 -0400 Received: from sss.pgh.pa.us(209.114.166.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001203; Thu, 3 Aug 00 10:30:21 -0400 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA07712; Thu, 3 Aug 2000 10:29:48 -0400 (EDT) To: Bernie Volz cc: tcp-impl@grc.nasa.gov Subject: Re: Doubletree RST 'BOF' meeting notes In-reply-to: <63D30D6E10CFD11190A90000F805FE8602BEBFCB@lespaul.process.com> References: <63D30D6E10CFD11190A90000F805FE8602BEBFCB@lespaul.process.com> Comments: In-reply-to Bernie Volz message dated "Thu, 03 Aug 2000 09:56:44 -0400" Date: Thu, 03 Aug 2000 10:29:48 -0400 Message-ID: <7709.965312988@sss.pgh.pa.us> From: Tom Lane Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Bernie Volz writes: > I should also point out that even if one fixes the stacks regarding the RST > behavior, there is still the question as to whether a stack should deliver > all received data when it has received an RST on a connection or drop that > data to notify the application as early as possible that the connection is > gone. I believe that would certainly be a bad way to operate (though I don't doubt that some stacks may do it, and the Linux kernel's current behavior is even worse). To take one example: one of the ideas that was discussed yesterday was having one side or the other send RST after the FIN handshake is completed, to allow the other side to drop its TIMEWAIT state. That would be completely unsafe if a TCP is allowed to discard received-but-undelivered data when it receives RST. > So, to fix the problem you describe requires TWO changes: > 1) Don't send RST on incoming data if there is still outgoing data to > deliver. > 2) Don't drop received data when RST received on a connection. Right, I thought I said that ... actually part of my question here is to what extent these actually are changes, and not existing behavior. regards, tom lane From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:25:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09025 for ; Thu, 3 Aug 2000 12:25:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA21304 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:35:31 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA21227 for ; Thu, 3 Aug 2000 10:35:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA01874; Thu, 3 Aug 2000 10:35:25 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001707; Thu, 3 Aug 00 10:34:22 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 635; Thu, 3 Aug 2000 07:34:18 -0700 Message-ID: <398982EA.D422FC8C@ehsco.com> Date: Thu, 03 Aug 2000 07:34:18 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bernie Volz CC: Ian Heavens , Jerry Toporek , david@kasey.umkc.edu, tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <63D30D6E10CFD11190A90000F805FE8602BEBFC9@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit It would certainly work for advertising availability. But in cases where "negotiation" was required (your word), it would not work (SYN/RST/RST is one example). I think the idea of an instrumentation option is a good one. I just wanted to point out that the act of negotiation would fail. You were right the first time; I should have held off on comment. Bernie Volz wrote: > > Eric: > > You are wrong about that. Think about it. > > If a SYN is RECEIVED with the option to enable this feature, then the RST > from the SYN can be set back with the option (since you know the sender of > the SYN is capable of supporting the option). > > - Bernie Volz > IPWorks, Inc. > > -----Original Message----- > From: Eric A. Hall [mailto:ehall@ehsco.com] > Sent: Wednesday, August 02, 2000 3:14 PM > To: Bernie Volz > Cc: Ian Heavens; Jerry Toporek; david@kasey.umkc.edu; > tcp-impl@grc.nasa.gov > Subject: Re: keep RST data nonstandardized for the future! > > > Likely, an option would be sent in a SYN to advertise the ability to > > support the instrumentation option. Lack of a reply with a similar > > option in the SYN/ACK would mean that the peer does not support the > > option and hence it would not be used. (This is similar to how other > > options, such as SACK, work.) > > In the case of RST being issued in response to the SYN request, there > would be no successful negotiation. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:25:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08994 for ; Thu, 3 Aug 2000 12:25:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA19222 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:25:01 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA19181 for ; Thu, 3 Aug 2000 10:24:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA00168; Thu, 3 Aug 2000 10:24:57 -0400 Received: from mercury.spider.com(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000072; Thu, 3 Aug 00 10:24:23 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id PAA16457; Thu, 3 Aug 2000 15:24:13 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA28711; Thu, 3 Aug 2000 15:24:13 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id PAA00672; Thu, 3 Aug 2000 15:24:13 +0100 (BST) Date: Thu, 3 Aug 2000 15:24:12 +0100 From: Ian Heavens To: Bernie Volz Cc: "'Craig Partridge'" , ian@spider.com, tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting notes Message-ID: <20000803152412.C642@malatesta.spider.com> References: <63D30D6E10CFD11190A90000F805FE8602BEBFCC@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBFCC@lespaul.process.com>; from Volz@ipworks.com on Thu, Aug 03, 2000 at 10:03:49AM -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk There's nothing to stop implementors including the RST error code + ASCII string in the data part of the RST field, purely as a debugging aid: a) pending standardisation of the TCP Instrumentation Option b) if the offer of the TCP Instrumentation Option must be disabled (presumably a TCP-Instrumentation-Option-permitted option analagous to the SACK-permitted option in SACK?) because it crashes the receiver. c) if the receiver refuses the TCP Instrumentation Option a) and b) mean that the current usefulness provided by the Mentat stack is maintained (and extended to other implementations if they so wish - though only those that don't allow the application to send data with a RST?). From what I hear, (b) could be true for quite a long time, at least with some implementations. ian On Thu, Aug 03, 2000 at 10:03:49AM -0400, Bernie Volz wrote: > I was one of the people that suggested that. > > However, I believe that the plan might be as follows: > 1) The to be created "TCP Instrumentation" option will be used to carry a > RST error code. This would likely be a 8 or 16 bit value (256 codes is > probably more than enough). This code is meant to be available to an > application such that it can issue an appropriate error message or otherwise > react better to the cause of the RST if it wants to. > 2) A stack would be free to include any error text it wanted (or other data) > in the TCP data portion of the RST packet. However, as this will not be > standardized, it is also possible that "junk" is there (for example, > application data). The intent of this data would be for debugging purposes > when doing packet traces and not something available to the TCP stack or > application. It would also not be standardized. (Implementators might also > be warned about making sure that the message fits within the maximum segment > size being used by the connection and perhaps not setting the Don't Fragment > bit in the IP header.) > > - Bernie > > -----Original Message----- > From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Thursday, August 03, 2000 9:21 AM > To: ian@spider.com > Cc: tcp-impl@grc.nasa.gov; mankin@east.isi.edu; tgl@sss.pgh.pa.us > Subject: Re: Doubletree RST 'BOF' meeting notes > > > > >I don't know if anyone wants to follow up the instrumentation option > issue?? > >HP/Mentat/Spider/(Sun?) will complete and submit my RST error codes draft. > > Some of the email suggested the error codes should follow the SMTP/FTP > convention (3 digit numbers where the different digits indicate the > severity of error). I thought that was a nice idea. Is that still the > plan? > > Thanks! > > Craig -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 12:52:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19668 for ; Thu, 3 Aug 2000 12:52:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA23192 for tcp-impl-outgoing; Thu, 3 Aug 2000 10:45:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA23169 for ; Thu, 3 Aug 2000 10:45:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA03496; Thu, 3 Aug 2000 10:45:52 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003399; Thu, 3 Aug 00 10:45:42 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 10:45:41 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFD0@lespaul.process.com> From: Bernie Volz To: "'Craig Partridge'" , Ian Heavens Cc: tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: RE: Doubletree RST 'BOF' meeting note Date: Thu, 3 Aug 2000 10:45:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk It depends how one defines transient. A RST in response to a SYN could well be considered transient because either there is no listener on the destination port or perhaps there is but the backlog is full (some stacks drop the SYN in this case rather than sending an RST, others send (or did send) an RST). That listener may appear at any time in the future. I'm also not sure what permanent means in this context either. A RST is always "permanent" for that connection. And, predicting whether the same condition will occur in the future is rather difficult. -----Original Message----- From: Craig Partridge [mailto:craig@aland.bbn.com] Sent: Thursday, August 03, 2000 10:32 AM To: Ian Heavens Cc: Craig Partridge; tcp-impl@grc.nasa.gov; mankin@east.isi.edu; tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting note In message <20000803145741.A642@malatesta.spider.com>, Ian Heavens writes: >Sounds a good approach...the only thing is I'm not sure how many >severity levels one could define for a RST.... Well the existing scheme envisions two types: transient and permanent errors and then a bunch of subcodes. Now I'm not sure there's any transient condition that provokes an RST, but perhaps... Craig From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 15:45:25 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14768 for ; Thu, 3 Aug 2000 15:45:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA29762 for tcp-impl-outgoing; Thu, 3 Aug 2000 13:34:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA29719 for ; Thu, 3 Aug 2000 13:34:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA28224; Thu, 3 Aug 2000 13:34:34 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028005; Thu, 3 Aug 00 13:33:42 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 677; Thu, 3 Aug 2000 10:33:25 -0700 Message-ID: <3989ACE4.2E14B8E7@ehsco.com> Date: Thu, 03 Aug 2000 10:33:24 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bernie Volz CC: "'Craig Partridge'" , Ian Heavens , tcp-impl@grc.nasa.gov, mankin@east.isi.edu, tgl@sss.pgh.pa.us Subject: Re: Doubletree RST 'BOF' meeting note References: <63D30D6E10CFD11190A90000F805FE8602BEBFD0@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit It might be better to break it into network-vs-application errors, where "Network" is the transport layer and below, while "Application" is the application layer and higher. For example, network class errors would be "out-of-sequence SYN" or "no listener" or "timeout" or whatever. Conversely, application class errors could be "disk space unavailable" or "unauthorized host" or the like. Bernie Volz wrote: > > It depends how one defines transient. > > A RST in response to a SYN could well be considered transient because either > there is no listener on the destination port or perhaps there is but the > backlog is full (some stacks drop the SYN in this case rather than sending > an RST, others send (or did send) an RST). That listener may appear at any > time in the future. > > I'm also not sure what permanent means in this context either. A RST is > always "permanent" for that connection. And, predicting whether the same > condition will occur in the future is rather difficult. > > -----Original Message----- > From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Thursday, August 03, 2000 10:32 AM > To: Ian Heavens > Cc: Craig Partridge; tcp-impl@grc.nasa.gov; mankin@east.isi.edu; > tgl@sss.pgh.pa.us > Subject: Re: Doubletree RST 'BOF' meeting note > > In message <20000803145741.A642@malatesta.spider.com>, Ian Heavens writes: > > >Sounds a good approach...the only thing is I'm not sure how many > >severity levels one could define for a RST.... > > Well the existing scheme envisions two types: transient and permanent > errors and then a bunch of subcodes. > > Now I'm not sure there's any transient condition that provokes an RST, > but perhaps... > > Craig -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 15:50:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16489 for ; Thu, 3 Aug 2000 15:50:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA00840 for tcp-impl-outgoing; Thu, 3 Aug 2000 13:39:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA00811 for ; Thu, 3 Aug 2000 13:39:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA29020; Thu, 3 Aug 2000 13:39:47 -0400 Received: from palrel1.hp.com(156.153.255.242) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028952; Thu, 3 Aug 00 13:39:14 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel1.hp.com (Postfix) with ESMTP id B4D43BD9 for ; Thu, 3 Aug 2000 10:33:56 -0700 (PDT) Received: from cup.hp.com (raj@localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA00857 for ; Thu, 3 Aug 2000 10:33:56 -0700 (PDT) Message-ID: <3989AD04.730C21A8@cup.hp.com> Date: Thu, 03 Aug 2000 10:33:56 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <63D30D6E10CFD11190A90000F805FE8602BEBFCD@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I should probably do a bit more math and message/RFC re-reading before I ask this but: Do we have enough space left on the head of the pin for this angel to dance upon along with the MSS, SACK, timestamp and window scale? We want folks to negotiate an MSS; asking for SACK is the current-big-thing (tm); and timestamps and window-scale are effectively "required options" for anything that wants to run much above (if not at) 100 Mbit/s (to avoid sequence wrap within MSL). Or so it seems. 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 Thu Aug 3 18:25:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03664 for ; Thu, 3 Aug 2000 18:25:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA16854 for tcp-impl-outgoing; Thu, 3 Aug 2000 15:06:57 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA16841 for ; Thu, 3 Aug 2000 15:06:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA11984; Thu, 3 Aug 2000 15:06:56 -0400 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011944; Thu, 3 Aug 00 15:06:14 -0400 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id PAA16125; Thu, 3 Aug 2000 15:02:27 -0400 (EDT) (envelope-from craig@aland.bbn.com) Message-Id: <200008031902.PAA16125@aland.bbn.com> To: Rick Jones cc: tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! In-reply-to: Your message of "Thu, 03 Aug 2000 10:33:56 PDT." <3989AD04.730C21A8@cup.hp.com> Date: Thu, 03 Aug 2000 15:02:26 -0400 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Good question -- indeed, I've been wondering if some of these essentially binary options could be reduced to a bit field -- offer the ones you support, get a bitmap of the ones supported. Craig In message <3989AD04.730C21A8@cup.hp.com>, Rick Jones writes: >I should probably do a bit more math and message/RFC re-reading before I >ask this but: > >Do we have enough space left on the head of the pin for this angel to >dance upon along with the MSS, SACK, timestamp and window scale? > >We want folks to negotiate an MSS; asking for SACK is the >current-big-thing (tm); and timestamps and window-scale are effectively >"required options" for anything that wants to run much above (if not at) >100 Mbit/s (to avoid sequence wrap within MSL). Or so it seems. > >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 Thu Aug 3 21:05:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21450 for ; Thu, 3 Aug 2000 21:04:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA07062 for tcp-impl-outgoing; Thu, 3 Aug 2000 17:24:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA07041 for ; Thu, 3 Aug 2000 17:24:39 -0400 (EDT) From: Kacheong.Poon@Eng.Sun.COM Received: by seraph3.lerc.nasa.gov; id RAA00972; Thu, 3 Aug 2000 17:24:38 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000845; Thu, 3 Aug 00 17:23:37 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27527 for ; Thu, 3 Aug 2000 14:23:35 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA24422 for ; Thu, 3 Aug 2000 14:23:35 -0700 (PDT) Received: (from kcpoon@localhost) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) id e73LNSa123738 for tcp-impl@grc.nasa.gov; Thu, 3 Aug 2000 14:23:28 -0700 (PDT) Date: Thu, 3 Aug 2000 14:23:28 -0700 (PDT) Message-Id: <200008032123.e73LNSa123738@jurassic.eng.sun.com> To: tcp-impl@grc.nasa.gov Subject: Re: TCP RSTs issues discussion Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Included message from Ian Heavens : >---- >Off the topic of this list, but I wonder if SCTP could benefit >from analysis of the experiences of TCP with RSTs, since it >is not widely deployed (e.g. an error code with the SCTP ABORT) >---- SCTP ABORT already has an error code. So are you suggesting TCP should adopt what is defined there? K. Poon kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Aug 3 21:50:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12818 for ; Thu, 3 Aug 2000 21:50:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA16317 for tcp-impl-outgoing; Thu, 3 Aug 2000 19:35:42 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA16206 for ; Thu, 3 Aug 2000 19:35:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA15025; Thu, 3 Aug 2000 19:35:32 -0400 Received: from smtp1.zocalo.net(157.22.1.67) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014842; Thu, 3 Aug 00 19:34:29 -0400 Received: from green.redback.com (66.161.131.zocalo.net [131.161.253.66] (may be forged)) by smtp1.zocalo.net (8.9.1/8.9.1) with ESMTP id QAA23457; Thu, 3 Aug 2000 16:36:16 -0700 (PDT) Received: from green.redback.com by green.redback.com (8.9.3) id QAA50867; Thu, 3 Aug 2000 16:33:56 -0700 (PDT) Message-Id: <200008032333.QAA50867@green.redback.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Craig Partridge Cc: Rick Jones , tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! In-Reply-To: Your message of "Thu, 03 Aug 2000 15:02:26 EDT." <200008031902.PAA16125@aland.bbn.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2067574980P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 03 Aug 2000 16:33:56 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --==_Exmh_2067574980P Content-Type: text/plain; charset=us-ascii historically, the reason for doing these SYN-attached options was because certain buggy TCP implementations (including my old TCP for the Mac) would die if they received unknown options anywhere *except* during SYN-time. one could have an option (i've thought that one should have an option) that says "can you receive random options without core dumping your kernel?". if *that* was negotiated, then you could just send the RST option thing, and the receiver would either drop it (if it was not understood) or "do the right thing" with it. (whether we have room even for *this* i'm not sure, but if i were going to do anything, i'd do this.) cheers, Greg --==_Exmh_2067574980P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: hAFaa4Id2HH96YWiAgzth8WgGrc9Xc2j iQA/AwUBOYoBZG1GBZxTyU5lEQLYggCfWW/c3ywvQ3Vgix1/qAq0TUQXZJ8Anj7b 1dQe0eVr/g4kJo5oFIBZFv4p =a5HX -----END PGP SIGNATURE----- --==_Exmh_2067574980P-- From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 15:50:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08540 for ; Fri, 4 Aug 2000 15:50:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA03942 for tcp-impl-outgoing; Fri, 4 Aug 2000 13:39:35 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA03903 for ; Fri, 4 Aug 2000 13:39:31 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA06206; Fri, 4 Aug 2000 13:39:29 -0400 Received: from mail.policyone.com(63.199.81.149) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006120; Fri, 4 Aug 00 13:39:09 -0400 Received: (from root@localhost) by duet.duettech.com (8.8.8/8.8.8) id KAA28145 for ; Fri, 4 Aug 2000 10:38:58 -0700 (PDT) Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1) id xma028140; Fri, 4 Aug 00 10:38:30 -0700 Received: from policyone.com ([199.172.181.91]) by casnt.ca.duettech.com (8.9.0/8.9.0) with ESMTP id KAA07986 for ; Fri, 4 Aug 2000 10:41:33 -0700 (PDT) Message-ID: <398AFED0.B0187A93@policyone.com> Date: Fri, 04 Aug 2000 10:35:13 -0700 From: Proneet Biswas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP List Subject: TCP timeout mechanism Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am interested in maintaining the TCP session information on my device. The number of sessions which I plan to support is around 1 million. For supporting this, I plan to keep a free pool and impement a hashed cache. However, it is not very clear to me how to implement an efficient timeout mechanism to remove the Session entries which have the TCP timeout and add them to the free pool. The simplest method is to iterate through all the entries , take the time difference between when a last packet was received in the session entry and the current time and see if the difference is greater than the TCP TIMEOUT value, If yes remove the entry and add it to the free pool. It would be great if anybody could suggest other better methods. Thanks. Proneet. From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 16:26:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16760 for ; Fri, 4 Aug 2000 16:26:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA18036 for tcp-impl-outgoing; Fri, 4 Aug 2000 14:43:40 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA17942 for ; Fri, 4 Aug 2000 14:43:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA15540; Fri, 4 Aug 2000 14:43:35 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015453; Fri, 4 Aug 00 14:43:02 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13KmLW-0005tj-00; Fri, 4 Aug 2000 19:37:26 +0100 Subject: Re: TCP timeout mechanism To: pbiswas@ipolicynet.com (Proneet Biswas) Date: Fri, 4 Aug 2000 19:37:24 +0100 (BST) Cc: tcp-impl@grc.nasa.gov (TCP List) In-Reply-To: <398AFED0.B0187A93@policyone.com> from "Proneet Biswas" at Aug 04, 2000 10:35:13 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > see if the difference is greater than the TCP TIMEOUT value, If yes > remove the entry and add it to the free pool. It would be great if > anybody could suggest other better methods. This is incorrect. A TCP session without keepalives has an infinite TCP_TIMEOUT. You need to take slightly more active approaches to session tracking From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 16:39:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19774 for ; Fri, 4 Aug 2000 16:39:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA19973 for tcp-impl-outgoing; Fri, 4 Aug 2000 14:53:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA19906 for ; Fri, 4 Aug 2000 14:52:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA16937; Fri, 4 Aug 2000 14:52:49 -0400 Received: from mail.policyone.com(63.199.81.149) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016908; Fri, 4 Aug 00 14:52:40 -0400 Received: (from root@localhost) by duet.duettech.com (8.8.8/8.8.8) id LAA29072; Fri, 4 Aug 2000 11:52:17 -0700 (PDT) Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1) id xma029063; Fri, 4 Aug 00 11:51:53 -0700 Received: from policyone.com ([199.172.181.91]) by casnt.ca.duettech.com (8.9.0/8.9.0) with ESMTP id LAA08347; Fri, 4 Aug 2000 11:54:55 -0700 (PDT) Message-ID: <398B1001.7480A776@policyone.com> Date: Fri, 04 Aug 2000 11:48:34 -0700 From: Proneet Biswas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox , TCP List Subject: Re: TCP timeout mechanism References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am currently tryng to investigate other approaches and it would be useful to know what are the existing alternatives ? Thanks. Proneet. Alan Cox wrote: > > see if the difference is greater than the TCP TIMEOUT value, If yes > > remove the entry and add it to the free pool. It would be great if > > anybody could suggest other better methods. > > This is incorrect. A TCP session without keepalives has an infinite TCP_TIMEOUT. > > You need to take slightly more active approaches to session tracking From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 17:09:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26497 for ; Fri, 4 Aug 2000 17:09:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA26486 for tcp-impl-outgoing; Fri, 4 Aug 2000 15:23:47 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA26434 for ; Fri, 4 Aug 2000 15:23:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA21826; Fri, 4 Aug 2000 15:23:40 -0400 Received: from mail.policyone.com(63.199.81.149) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021729; Fri, 4 Aug 00 15:23:13 -0400 Received: (from root@localhost) by duet.duettech.com (8.8.8/8.8.8) id MAA29511 for ; Fri, 4 Aug 2000 12:23:11 -0700 (PDT) Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1) id xma029504; Fri, 4 Aug 00 12:22:48 -0700 Received: from policyone.com ([199.172.181.91]) by casnt.ca.duettech.com (8.9.0/8.9.0) with ESMTP id MAA08461; Fri, 4 Aug 2000 12:13:29 -0700 (PDT) Message-ID: <398B145D.601733D1@policyone.com> Date: Fri, 04 Aug 2000 12:07:09 -0700 From: Proneet Biswas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox , TCP List Subject: Re: TCP timeout mechanism References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi Alan, I am sorry I had not been very specific. The device I intend to support is kind of a firewall which does not have a stack on it. It will create the session entries based on the packets which flow through it ot other machines. SO, it is the internal data structures which I need to clear. To put it a different fashion : There is a cache to which I add entries whenever a new session starts. The problem is identifying the sessions in the cache which have timed out without using a timer thread to go through all the entries. Thanks. Proneet. Alan Cox wrote: > Track state (remembering to allow for unreliability/retransmits) and also > generate faked probe acks _very_ carefully and with backoffs to test if the > socket has died after a timeout. > > Hardly rocket science. > > Once ipsec is standard you won't be much able to session track anything tho From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 18:07:41 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08110 for ; Fri, 4 Aug 2000 18:07:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA08449 for tcp-impl-outgoing; Fri, 4 Aug 2000 16:18:10 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA08397 for ; Fri, 4 Aug 2000 16:18:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA29219; Fri, 4 Aug 2000 16:18:03 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029131; Fri, 4 Aug 00 16:17:10 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 16:17:09 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFDB@lespaul.process.com> From: Bernie Volz To: "'Proneet Biswas'" Cc: "'tcp-impl@grc.nasa.gov'" Subject: RE: TCP timeout mechanism Date: Fri, 4 Aug 2000 16:17:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Why get rid of them? Limit the number of connections you track, overwrite old ones with new ones. That way, you never need a timer thread. It may be that occasionally you drop a good connection (because of hash collision), but that might not be a problem? (It isn't clear what you're doing with these connections.) Another method is to use a separate timer queue. Whenever you see packets for a connection, move that connection to the end of the timer queue (with doubling linked lists, this should be relatively inexpensive?). Now, your timer thread only needs to check if the first one on the list is "old" and if it is drop it (and look at the next until no more to drop). This approach is also nice if you need to limit the number of connections for once you reach the limit and you have a new connection, just drop the one at the head of the queue (it's the oldest connection). NOTE: As a performance boost, if you keep your timers fairly granular (say in 10 seconds chunks), you might also add an optimization to not move a the packet to end of the list if it has been moved recently (in the same timer chunk). That may occasionally cause problems, but it may save a lot of queue moves. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Proneet Biswas [mailto:pbiswas@ipolicynet.com] Sent: Friday, August 04, 2000 3:07 PM To: Alan Cox; TCP List Subject: Re: TCP timeout mechanism Hi Alan, I am sorry I had not been very specific. The device I intend to support is kind of a firewall which does not have a stack on it. It will create the session entries based on the packets which flow through it ot other machines. SO, it is the internal data structures which I need to clear. To put it a different fashion : There is a cache to which I add entries whenever a new session starts. The problem is identifying the sessions in the cache which have timed out without using a timer thread to go through all the entries. Thanks. Proneet. Alan Cox wrote: > Track state (remembering to allow for unreliability/retransmits) and also > generate faked probe acks _very_ carefully and with backoffs to test if the > socket has died after a timeout. > > Hardly rocket science. > > Once ipsec is standard you won't be much able to session track anything tho From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 18:31:04 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08134 for ; Fri, 4 Aug 2000 18:07:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA10007 for tcp-impl-outgoing; Fri, 4 Aug 2000 16:25:39 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA09975 for ; Fri, 4 Aug 2000 16:25:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA00213; Fri, 4 Aug 2000 16:25:34 -0400 Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000051; Fri, 4 Aug 00 16:24:38 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA26543; Fri, 4 Aug 2000 16:23:47 -0400 (EDT) Date: Fri, 4 Aug 2000 16:23:47 -0400 (EDT) From: der Mouse Message-Id: <200008042023.QAA26543@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Proneet Biswas Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP timeout mechanism Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > There is a cache to which I add entries whenever a new session > starts. The problem is identifying the sessions in the cache which > have timed out without using a timer thread to go through all the > entries. This really has nothing to do with tcp-impl as far as I can see; it looks to me more like a data structures question, so I'd recommend that it go somewhere else. Most briefly, though, my first suggestion is to use a heap. My second is to use a skip list. However, depending on the traffic statistics, there may be better ways - hybrid approaches, as it were. Since this is the wrong forum for discussing data structures, I sha'n't discuss them here; those interested in the issue are invited to contact me off-list. 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 Fri Aug 4 20:39:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03882 for ; Fri, 4 Aug 2000 20:39:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA26443 for tcp-impl-outgoing; Fri, 4 Aug 2000 18:48:06 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA26433 for ; Fri, 4 Aug 2000 18:48:04 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA17770; Fri, 4 Aug 2000 18:48:04 -0400 Received: from ren.netconnect.com.au(203.7.198.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017730; Fri, 4 Aug 00 18:47:59 -0400 Received: (qmail 16894 invoked from network); 4 Aug 2000 22:49:06 -0000 Received: from unknown (HELO cvs.com.au) (203.87.14.203) by mail.netconnect.com.au with SMTP; 4 Aug 2000 22:49:06 -0000 Message-ID: <398B0985.33BBC947@cvs.com.au> Date: Sat, 05 Aug 2000 04:20:54 +1000 From: Charles Esson X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Proneet Biswas CC: TCP List Subject: Re: TCP timeout mechanism References: <398B1001.7480A776@policyone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I know of no way of getting a guaranteed response from the other end of a TCP connection. I would love to hear of it if there is. Connections can definitely be abandoned, you can definitely be left with the resources tied up for no reason, and you will definitely not have unlimited resources. And for most OS work rebooting is not an option, though this doesn't seem to be a general rule. If you time-out TCP connections the time-out period has to be long ( I chose 24 hours), but with the option of making it indefinite. Having a low priority task going through a million connections in that time is no big deal. You could have the time-out task link inactive connections in inactivity order; and only kill the connection if you have to have the resources. The kill code using the linked list as the order to search for a connection to kill, the search would have to allow for the possibility the inactivity has stopped, but 99% of the time it would take the first connection in the list fins it is still inactive and claim the resources for the new connection. In fact you could use the inactivity list in the same way as your free resources list. Instead of thinking of the resources as in use or free, think of them as active or inactive, and only give up if the inactivity time of the resource your about to use falls below say an hour. The resource in question will have a flag to give the state of the connection just set them all to "closed" on start-up. The low level task just goes through the table linking the list in inactivity order and sets a global "load" value. The claiming task searches down the "inactivity list" until it finds one that has a time greater than that represented by the" load". At the head of the list you will only have two types of records, inactive connections, or connections that have recently become active and are not yet moved down by the time-out routine. I like it, might be a worthwhile change, problem I now have is how many connections am I going to allow. Regards Proneet Biswas wrote: > Hi, > I am currently tryng to investigate other approaches and it would be useful to > know what are the existing alternatives ? > > Thanks. > Proneet. > > Alan Cox wrote: > > > > see if the difference is greater than the TCP TIMEOUT value, If yes > > > remove the entry and add it to the free pool. It would be great if > > > anybody could suggest other better methods. > > > > This is incorrect. A TCP session without keepalives has an infinite TCP_TIMEOUT. > > > > You need to take slightly more active approaches to session tracking From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 20:44:39 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05038 for ; Fri, 4 Aug 2000 20:44:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA27150 for tcp-impl-outgoing; Fri, 4 Aug 2000 19:03:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA27146 for ; Fri, 4 Aug 2000 19:03:14 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA19130; Fri, 4 Aug 2000 19:03:13 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019100; Fri, 4 Aug 00 19:02:59 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13KqPE-0006Lo-00; Fri, 4 Aug 2000 23:57:32 +0100 Subject: Re: TCP timeout mechanism To: Volz@ipworks.com (Bernie Volz) Date: Fri, 4 Aug 2000 23:57:30 +0100 (BST) Cc: pbiswas@ipolicynet.com ('Proneet Biswas'), tcp-impl@grc.nasa.gov ('tcp-impl@grc.nasa.gov') In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBFDB@lespaul.process.com> from "Bernie Volz" at Aug 04, 2000 04:17:01 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Why get rid of them? Limit the number of connections you track, overwrite > old ones with new ones. That way, you never need a timer thread. It may be > that occasionally you drop a good connection (because of hash collision), > but that might not be a problem? (It isn't clear what you're doing with > these connections.) He said a firewall. A hostile can now potentially DoS the firewall. From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 20:58:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07894 for ; Fri, 4 Aug 2000 20:58:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA27108 for tcp-impl-outgoing; Fri, 4 Aug 2000 19:01:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA27094 for ; Fri, 4 Aug 2000 19:01:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA18988; Fri, 4 Aug 2000 19:01:12 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018942; Fri, 4 Aug 00 19:00:48 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13KqNE-0006Lh-00; Fri, 4 Aug 2000 23:55:28 +0100 Subject: Re: TCP timeout mechanism To: pbiswas@ipolicynet.com (Proneet Biswas) Date: Fri, 4 Aug 2000 23:55:27 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), tcp-impl@grc.nasa.gov (TCP List) In-Reply-To: <398B145D.601733D1@policyone.com> from "Proneet Biswas" at Aug 04, 2000 12:07:09 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > There is a cache to which I add entries whenever a new session starts. The > problem is identifying the sessions in the cache which have timed out without > using a timer thread to go through all the entries. You cannot do that without generating frames and tracking the packets Thats TCP, thats how it works. You dont need a TCP stack but you need to follow the tcp sequence space and the like Alan From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 21:52:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21290 for ; Fri, 4 Aug 2000 21:52:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA00318 for tcp-impl-outgoing; Fri, 4 Aug 2000 20:04:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA00311 for ; Fri, 4 Aug 2000 20:04:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA24661; Fri, 4 Aug 2000 20:04:56 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024631; Fri, 4 Aug 00 20:04:26 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id UAA20830 for ; Fri, 4 Aug 2000 20:04:26 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id 020F455C; Fri, 4 Aug 2000 20:04:24 -0400 (EDT) To: tcp-impl@grc.nasa.gov Subject: Re: TCP timeout mechanism References: <63D30D6E10CFD11190A90000F805FE8602BEBFDB@lespaul.process.com> From: stanislav shalunov Date: 04 Aug 2000 20:04:24 -0400 In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBFDB@lespaul.process.com> Message-ID: <87punotvxz.fsf@cain.internet2.edu> Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Bernie Volz writes: > It may be that occasionally you drop a good connection (because of > hash collision), but that might not be a problem? Wouldn't the users be able to artificially create hash collisions? -- Stanislav Shalunov Internet2 "Cells are diodes. Electrons only go one way. If you have both poles turned north, that will stop the traffic and will damage your health." --Alex Chiu http://www.alexchiu.com/affiliates/clickthru.cgi?id=shalunov From owner-tcp-impl@lerc.nasa.gov Fri Aug 4 22:34:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01648 for ; Fri, 4 Aug 2000 22:34:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA02204 for tcp-impl-outgoing; Fri, 4 Aug 2000 20:46:48 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA02196 for ; Fri, 4 Aug 2000 20:46:46 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA28240; Fri, 4 Aug 2000 20:46:45 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028219; Fri, 4 Aug 00 20:46:39 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13Ks1U-0006Xu-00; Sat, 5 Aug 2000 01:41:08 +0100 Subject: Re: TCP timeout mechanism To: charlese@cvs.com.au (Charles Esson) Date: Sat, 5 Aug 2000 01:41:06 +0100 (BST) Cc: pbiswas@ipolicynet.com (Proneet Biswas), tcp-impl@grc.nasa.gov (TCP List) In-Reply-To: <398B0985.33BBC947@cvs.com.au> from "Charles Esson" at Aug 05, 2000 04:20:54 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > I know of no way of getting a guaranteed response from the other end of a TCP > connection. I would love to hear of it if there is. Spoof a keepalive ACK a few times. From owner-tcp-impl@lerc.nasa.gov Sun Aug 6 01:14:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09961 for ; Sun, 6 Aug 2000 01:14:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA23178 for tcp-impl-outgoing; Sat, 5 Aug 2000 22:52:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA23170 for ; Sat, 5 Aug 2000 22:52:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA15527; Sat, 5 Aug 2000 22:52:09 -0400 Received: from orchard.hamachi.org(4.255.0.98) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015494; Sat, 5 Aug 00 22:51:45 -0400 Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 612BB2A40; Sat, 5 Aug 2000 22:51:43 -0400 (EDT) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 46E5F1F98; Sat, 5 Aug 2000 22:51:43 -0400 (EDT) To: stanislav shalunov Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP timeout mechanism In-Reply-To: Message from stanislav shalunov of "04 Aug 2000 20:04:24 EDT." <87punotvxz.fsf@cain.internet2.edu> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Sat, 05 Aug 2000 22:51:38 -0400 From: Bill Sommerfeld Message-Id: <20000806025143.612BB2A40@orchard.arlington.ma.us> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Wouldn't the users be able to artificially create hash collisions? You can get around this if you use a "keyed" hash function with a secret key. However, the internet is not the phone system.. putting unrecoverable state into the middle of the network is evil. A box of this form will be a source of annoyance to many end users.. it should be possible to suspend one or both ends of a connection, wake them up again 12 hours or two weeks later, and continue as if nothing had happened. - Bill From owner-tcp-impl@lerc.nasa.gov Sun Aug 6 21:43:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00185 for ; Sun, 6 Aug 2000 21:43:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA03821 for tcp-impl-outgoing; Sun, 6 Aug 2000 19:48:47 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA03814 for ; Sun, 6 Aug 2000 19:48:45 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA09555; Sun, 6 Aug 2000 19:48:44 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009524; Sun, 6 Aug 00 19:48:23 -0400 Received: (from braden@localhost) by boreas.isi.edu (8.9.3/8.9.3) id QAA13154; Sun, 6 Aug 2000 16:48:22 -0700 (PDT) Date: Sun, 6 Aug 2000 16:48:22 -0700 (PDT) From: Bob Braden Message-Id: <200008062348.QAA13154@boreas.isi.edu> To: tcp-impl@grc.nasa.gov Subject: Re: Doubletree RST 'BOF' meeting notes Cc: ian@spider.com, mankin@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> [the SACK people would like this option too - Matt Matthis told me *> afterwards however that currently SACK options must be sent with the *> SYN as some implementations fall over if the first TCP option is sent *> with a non-SYN segment. Is this actually still true? Are any of the TCPs with this bug still in significant use? Bob Braden From owner-tcp-impl@lerc.nasa.gov Mon Aug 7 10:04:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01157 for ; Mon, 7 Aug 2000 10:04:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA06102 for tcp-impl-outgoing; Mon, 7 Aug 2000 07:50:46 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA06082 for ; Mon, 7 Aug 2000 07:50:44 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA03012; Mon, 7 Aug 2000 07:50:43 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002975; Mon, 7 Aug 00 07:50:21 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13LlKn-0003VF-00; Mon, 7 Aug 2000 12:44:45 +0100 Subject: Re: Doubletree RST 'BOF' meeting notes To: braden@ISI.EDU (Bob Braden) Date: Mon, 7 Aug 2000 12:44:42 +0100 (BST) Cc: tcp-impl@grc.nasa.gov, ian@spider.com, mankin@ISI.EDU In-Reply-To: <200008062348.QAA13154@boreas.isi.edu> from "Bob Braden" at Aug 06, 2000 04:48:22 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > *> [the SACK people would like this option too - Matt Matthis told me > *> afterwards however that currently SACK options must be sent with the > *> SYN as some implementations fall over if the first TCP option is sent > *> with a non-SYN segment. > > Is this actually still true? Are any of the TCPs with this bug > still in significant use? If they do they are behind firewalls I suspect. People seem to spray arbitary IP's with every known tcp attack regularly nowdays From owner-tcp-impl@lerc.nasa.gov Mon Aug 7 13:11:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19352 for ; Mon, 7 Aug 2000 13:11:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA14724 for tcp-impl-outgoing; Mon, 7 Aug 2000 11:23:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA14688 for ; Mon, 7 Aug 2000 11:23:51 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA03993; Mon, 7 Aug 2000 11:23:49 -0400 Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003917; Mon, 7 Aug 00 11:23:43 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA03443; Mon, 7 Aug 2000 11:23:32 -0400 (EDT) Date: Mon, 7 Aug 2000 11:23:32 -0400 (EDT) From: der Mouse Message-Id: <200008071523.LAA03443@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: TCP timeout mechanism Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > However, the internet is not the phone system.. putting unrecoverable > state into the middle of the network is evil. > A box of this form will be a source of annoyance to many end users.. As someone who once was such an "end user", I can emphatically endorse this statement. At one of my jobs I was behind a "firewall" that, among other things, kept state for every TCP connection through it. This state timed out, and it was extremely annoying to find my remote login sessions locked up because I'd let them idle a little too long. Fortunately my desktop was running an OS I had source to; I ended up hacking the kernel to turn on keepalives for all connections, whether requested or not, and pulled the keepalive idle time down below the firewall's state expiration timeout. I shouldn't've had to go to lengths that extreme just to keep remote logins from locking up routinely. 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 Aug 7 17:49:25 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25543 for ; Mon, 7 Aug 2000 17:49:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA28692 for tcp-impl-outgoing; Mon, 7 Aug 2000 15:43:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA28661 for ; Mon, 7 Aug 2000 15:43:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA11130; Mon, 7 Aug 2000 15:43:08 -0400 Received: from starburst.demon.co.uk(194.222.114.233) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011024; Mon, 7 Aug 00 15:42:59 -0400 Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id UAA10046; Mon, 7 Aug 2000 20:41:52 +0100 From: Richard Wendland Message-Id: <200008071941.UAA10046@starburst.demon.co.uk> Subject: First SACK-permitted on To: braden@ISI.EDU (Bob Braden) Date: Mon, 7 Aug 2000 20:41:52 +0100 (BST) Cc: tcp-impl@grc.nasa.gov Reply-To: richard@wendland.org.uk (Richard Wendland) In-Reply-To: <200008062348.QAA13154@boreas.isi.edu> from "Bob Braden" at Aug 06, 2000 04:48:22 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > *> [the SACK people would like this option too - Matt Matthis told me > *> afterwards however that currently SACK options must be sent with the > *> SYN as some implementations fall over if the first TCP option is sent > *> with a non-SYN segment. > > Is this actually still true? Are any of the TCPs with this bug > still in significant use? Somewhat related I have noticed that a recent IRIX release sends SACK-permitted on despite not having received SACK-permitted on the . I've not heard of this causing any great problems. (I have no reason to think it would later send SACK on a non-SYN segment, but I haven't tested this directly.) Initially I assumed this behaviour did not comply with RFC 2018, in the way RFC 1323 explicitly disallows this for the timestamp and window-scale options. However on a close study of RFC 2018 I was surprised to find that this is not explicitly disallowed as in RFC 1323, despite not being able to see any useful reason to allow this and it having the potential to break some old implementations. RFC 2018 simply says "may be sent in a SYN", which must include both and for RFC 2018 to work. I assume this must be an oversight in the wording, but it is now the specification, so I suppose more implementations may start doing this. Is there any strong reason to try to change the spec to disallow this at a suitable opportunity? Richard -- Richard Wendland richard@wendland.org.uk From owner-tcp-impl@lerc.nasa.gov Tue Aug 8 22:03:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14035 for ; Tue, 8 Aug 2000 22:03:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA15889 for tcp-impl-outgoing; Tue, 8 Aug 2000 19:44:31 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA15869 for ; Tue, 8 Aug 2000 19:44:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA03831; Tue, 8 Aug 2000 19:44:27 -0400 Received: from mailer.psc.edu(128.182.58.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003751; Tue, 8 Aug 00 19:44:17 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer.psc.edu (8.9.3/8.9.3/psc) with ESMTP id TAA24331; Tue, 8 Aug 2000 19:44:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by tesla.psc.edu (8.9.3/8.9.3/psc) with ESMTP id TAA25849; Tue, 8 Aug 2000 19:44:14 -0400 (EDT) Date: Tue, 8 Aug 2000 19:44:14 -0400 (EDT) From: Matt Mathis To: Richard Wendland cc: tcp-impl@grc.nasa.gov Subject: Re: First SACK-permitted on In-Reply-To: <200008071941.UAA10046@starburst.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Mon, 7 Aug 2000, Richard Wendland wrote: > RFC 2018 simply says "may be sent in a SYN", which must include both > and for RFC 2018 to work. I assume this must be an > oversight in the wording, but it is now the specification, so I suppose > more implementations may start doing this. Oops, it was indeed an oversight. Well, I'm not sure - we were pretty careful to try to leave a trace of wiggle room in places where the community wanted us to be more restrictive than we felt absolutely necessary. However let me clarify: >> the SACK people would like this option too - Matt Mathis told me >> afterwards however that currently SACK options must be sent with the >> SYN as some implementations fall over if the first TCP option is sent >> with a non-SYN segment. > Is this actually still true? Are any of the TCPs with this bug > still in significant use? My conversation was slightly garbled. The problem is that 1323 timestamps must be committed (on or off) on the SYN and SYN-ACK. Once committed you are stuck if you got it wrong. Since timestamps so badly waste header compressed slow links, most vendors ship systems that default to RFC 1323 off. This adds yet another step for ordinary people to do wrong before they can get decent rates out of any well any connected workstation (e.g. almost any system at a university). It would be better if all connections could start w/o time stamps and automaticly turn them on when the data rate reaches some threshold. I believe that accepting such a late TS option is a 2 line code change (triggering it is harder of course). However, this was expressly forbidden by 1323 due to a couple of (now ancient) systems known to die horrible deaths on unexpected TCP options. Nobody has any reasonable estimates of the residual population of these system. In my copious spare time I would love to run a semi-production web server that always sent late experimental (unpublished) options to see if I could detect any systems with bugs. I would bet not, and would then consider proposing to revise 1323 to allow and even encourage late TS options. (In my spare time!) I wish that somebody would actually try this experiment or reconstruct more details of the history. Perhaps SGI has already done this well enough because SACK-enabled on the SYN-ACK is guaranteed to be unexpected. This prohibition on late TCP options is thwarting at least 2 reasonable proposals for TCP options, including the RST error code. --MM-- From owner-tcp-impl@lerc.nasa.gov Tue Aug 8 22:05:45 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15159 for ; Tue, 8 Aug 2000 22:05:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA17864 for tcp-impl-outgoing; Tue, 8 Aug 2000 20:13:36 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA17854 for ; Tue, 8 Aug 2000 20:13:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA08394; Tue, 8 Aug 2000 20:13:34 -0400 Received: from mail.policyone.com(63.199.81.149) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008347; Tue, 8 Aug 00 20:12:58 -0400 Received: (from root@localhost) by duet.duettech.com (8.8.8/8.8.8) id RAA05151 for ; Tue, 8 Aug 2000 17:12:56 -0700 (PDT) Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1) id xmaa05146; Tue, 8 Aug 00 17:12:32 -0700 Received: from policyone.com ([199.172.181.91]) by casnt.ca.duettech.com (8.9.0/8.9.0) with ESMTP id RAA02641 for ; Tue, 8 Aug 2000 17:15:34 -0700 (PDT) Message-ID: <3990A12C.8FCA56DB@policyone.com> Date: Tue, 08 Aug 2000 17:09:17 -0700 From: Proneet Biswas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Out Of Sequence Packets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I wanted to gather some statistics on how common Out of sequence packets are in the Internet domain and the usage of Fast Retransmit for handling Out of Sequence packets. Also what would be the effect if packets coming out of sequence are dropped ? Thanks. From owner-tcp-impl@lerc.nasa.gov Tue Aug 8 23:21:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24365 for ; Tue, 8 Aug 2000 23:21:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA20882 for tcp-impl-outgoing; Tue, 8 Aug 2000 21:11:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA20860 for ; Tue, 8 Aug 2000 21:11:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA14770; Tue, 8 Aug 2000 21:11:37 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014726; Tue, 8 Aug 00 21:10:53 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13MKIR-0007Yd-00; Wed, 9 Aug 2000 02:04:39 +0100 Subject: Re: First SACK-permitted on To: mathis@psc.edu (Matt Mathis) Date: Wed, 9 Aug 2000 02:04:37 +0100 (BST) Cc: richard@wendland.org.uk (Richard Wendland), tcp-impl@grc.nasa.gov In-Reply-To: from "Matt Mathis" at Aug 08, 2000 07:44:14 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > This prohibition on late TCP options is thwarting at least 2 reasonable > proposals for TCP options, including the RST error code. I think the prohibition should just be dropped given the hostile nature of the net today. Any box with that bug is basically unusable on the internet anyway From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 08:28:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14883 for ; Wed, 9 Aug 2000 08:28:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA03385 for tcp-impl-outgoing; Wed, 9 Aug 2000 01:24:04 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id BAA03375 for ; Wed, 9 Aug 2000 01:24:03 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id BAA06763; Wed, 9 Aug 2000 01:24:01 -0400 Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006732; Wed, 9 Aug 00 01:23:38 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e795NYf03856; Tue, 8 Aug 2000 22:23:34 -0700 (PDT) Message-Id: <200008090523.e795NYf03856@daffy.ee.lbl.gov> To: Proneet Biswas Cc: tcp-impl@grc.nasa.gov Subject: Re: Out Of Sequence Packets In-reply-to: Your message of Tue, 08 Aug 2000 17:09:17 PDT. Date: Tue, 08 Aug 2000 22:23:34 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I wanted to gather some statistics on how common Out of sequence > packets are in the Internet domain and the usage of Fast Retransmit for > handling Out of Sequence packets. Also what would be the effect if > packets coming out of sequence are dropped ? This is discussed in my paper "End-to-End Internet Packet Dynamics", IEEE/ACM TON 7(3) pp 277-292 June 1999, available from: ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-ton99.ps.gz (though that data in the paper is pretty stale, five years old) Vern From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 11:59:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10525 for ; Wed, 9 Aug 2000 11:59:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA17060 for tcp-impl-outgoing; Wed, 9 Aug 2000 10:01:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA16994 for ; Wed, 9 Aug 2000 10:01:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA21382; Wed, 9 Aug 2000 10:01:08 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020828; Wed, 9 Aug 00 10:00:20 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 10:00:19 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFF9@lespaul.process.com> From: Bernie Volz To: "'Alan Cox'" , mathis@psc.edu Cc: richard@wendland.org.uk, tcp-impl@grc.nasa.gov Subject: RE: First SACK-permitted on Date: Wed, 9 Aug 2000 10:00:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I agree (prohibition should be dropped). It will help to force people to fix the implementations. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] Sent: Tuesday, August 08, 2000 9:05 PM To: mathis@psc.edu Cc: richard@wendland.org.uk; tcp-impl@grc.nasa.gov Subject: Re: First SACK-permitted on > This prohibition on late TCP options is thwarting at least 2 reasonable > proposals for TCP options, including the RST error code. I think the prohibition should just be dropped given the hostile nature of the net today. Any box with that bug is basically unusable on the internet anyway From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 13:08:40 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13979 for ; Wed, 9 Aug 2000 13:08:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA26747 for tcp-impl-outgoing; Wed, 9 Aug 2000 10:55:29 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA26693 for ; Wed, 9 Aug 2000 10:55:26 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA14031; Wed, 9 Aug 2000 10:55:25 -0400 Received: from mailer.psc.edu(128.182.58.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013174; Wed, 9 Aug 00 10:54:32 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer.psc.edu (8.9.3/8.9.3/psc) with ESMTP id KAA09653; Wed, 9 Aug 2000 10:54:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by tesla.psc.edu (8.9.3/8.9.3/psc) with ESMTP id KAA00248; Wed, 9 Aug 2000 10:54:31 -0400 (EDT) Date: Wed, 9 Aug 2000 10:54:31 -0400 (EDT) From: Matt Mathis To: Alan Cox cc: Richard Wendland , tcp-impl@grc.nasa.gov Subject: Important question re: new TCP options on data segments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Wed, 9 Aug 2000, Alan Cox wrote: > > This prohibition on late TCP options is thwarting at least 2 reasonable > > proposals for TCP options, including the RST error code. > > I think the prohibition should just be dropped given the hostile nature of > the net today. Any box with that bug is basically unusable on the Internet > anyway Duh! Sometime it is real important to rethink old decisions in new contexts. Ok, lets ask the question the other way: Can anybody think of *any* compelling argument agaist droping the prohibition against new TCP options appearing after a SYN? Thanks, --MM-- From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 14:52:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16200 for ; Wed, 9 Aug 2000 14:52:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA15161 for tcp-impl-outgoing; Wed, 9 Aug 2000 12:45:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA15129 for ; Wed, 9 Aug 2000 12:45:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA05927; Wed, 9 Aug 2000 12:45:09 -0400 Received: from frantic.weston.bsdi.com(209.173.194.254) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005445; Wed, 9 Aug 00 12:44:47 -0400 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id LAA04364; Wed, 9 Aug 2000 11:43:23 -0500 (CDT) Date: Wed, 9 Aug 2000 11:43:23 -0500 (CDT) From: David Borman Message-Id: <200008091643.LAA04364@frantic.bsdi.com> To: alan@lxorguk.ukuu.org.uk, mathis@psc.edu, Volz@ipworks.com Subject: RE: First SACK-permitted on Cc: richard@wendland.org.uk, tcp-impl@grc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A couple of things about TCP options in non-SYN packets, in regard to the Timestamps option. o There were multiple reasons for requiring that the Timestamps be exchanged in the SYN packet, not just to protect buggy implementations. It also means that you don't waste bandwidth sending options that are just going to be ignored. o RFC 1323 doesn't require a timestamps option in every packet (but PAWS assumes that there is.) o Starting a connection without the Timestamps option, and then later turning on Timestamps is not a big problem. But stopping once you have started creates problems for PAWS... Also, RFC 1122 requires that TCPs must be able to handle TCP options in non-TCP segments, ignoring unknown options and not crashing if the option length is bogus (see section 4.2.2.5). The Timestamps option was the first TCP option to be passed in non-SYN packets, so even though RFC-1122 requires that hosts handle TCP options in non-SYN packets, at the time it was prudent to have the exchange on the initial SYN for interoperabilty reasons. I don't have any objections to allowing TCP options in non-SYN packets without prior negotiation in the SYN packets. And specifically with the Timestamps option, if we were to modify it to not require that Timestamps be exchanged on the SYN, then it should be done with the caveat that once Timestamps are enabled, they must remain enabled for the rest of the connection. You would probably only want to initiate the enabling of Timestamps on a data packet, because when you get the ACK for that data, it will contain a Timestamps option if the other side supports it. If it doesn't have a Timestamps option, then you know the other side doesn't support them and you stop sending them. -David Borman, dab@bsdi.com > From: Bernie Volz > Subject: RE: First SACK-permitted on > Date: Wed, 9 Aug 2000 10:00:18 -0400 > > I agree (prohibition should be dropped). It will help to force people to fix > the implementations. > > - Bernie Volz > IPWorks, Inc. > > -----Original Message----- > From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] > Sent: Tuesday, August 08, 2000 9:05 PM > To: mathis@psc.edu > Cc: richard@wendland.org.uk; tcp-impl@grc.nasa.gov > Subject: Re: First SACK-permitted on > > > > This prohibition on late TCP options is thwarting at least 2 reasonable > > proposals for TCP options, including the RST error code. > > I think the prohibition should just be dropped given the hostile nature of > the net today. Any box with that bug is basically unusable on the internet > anyway From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 15:33:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17627 for ; Wed, 9 Aug 2000 15:33:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19988 for tcp-impl-outgoing; Wed, 9 Aug 2000 13:18:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA19974 for ; Wed, 9 Aug 2000 13:18:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA06697; Wed, 9 Aug 2000 13:18:19 -0400 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006033; Wed, 9 Aug 00 13:17:49 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 44318A9C for ; Wed, 9 Aug 2000 10:17:46 -0700 (PDT) Received: from cup.hp.com (raj@localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA18552 for ; Wed, 9 Aug 2000 10:17:45 -0700 (PDT) Message-ID: <39919239.334178F9@cup.hp.com> Date: Wed, 09 Aug 2000 10:17:45 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Matt Mathis wrote: > Can anybody think of *any* compelling argument agaist droping the prohibition > against new TCP options appearing after a SYN? It means I have to be prepared to look for "unexpected" options in my mainline data path. I'm not certain it ensures there is enough space for all the options one might want to carry. True, it means that the options added in the middle would not have to fight for space with the MSS option or the window scale option, but it may still have to duke it out with a SACK option and timestamps. rick I cannot help but think about how planes like the B17 kept getting heavier, more complex, and (iirc) just a little slower as people added this feature and that feature... -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 16:18:29 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19144 for ; Wed, 9 Aug 2000 16:18:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA26340 for tcp-impl-outgoing; Wed, 9 Aug 2000 13:58:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA26325 for ; Wed, 9 Aug 2000 13:58:39 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id NAA11954; Wed, 9 Aug 2000 13:58:37 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011736; Wed, 9 Aug 00 13:58:27 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA05304; Wed, 9 Aug 2000 21:58:14 +0400 Message-Id: <200008091758.VAA05304@ms2.inr.ac.ru> Subject: Re: First SACK-permitted on To: mathis@psc.edu (Matt Mathis) Date: Wed, 9 Aug 2000 21:58:14 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: from "Matt Mathis" at Aug 8, 0 07:44:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > Since timestamps so badly waste header compressed slow links, most vendors > ship systems that default to RFC 1323 off. This adds yet another step for > ordinary people to do wrong before they can get decent rates out of any well > any connected workstation (e.g. almost any system at a university). > > It would be better if all connections could start w/o time stamps and > automaticly turn them on when the data rate reaches some threshold. Could you elaborate this? RFC1323 is not only PAWS yet, but also RTTM. PAWS is almost useless paranoia when latency is low, e.g. at "almost any system at a university" (or an enterprise). And they really affect performance (negatively, of course) in this case and can be disabled. RTTM (and another TS users sort of Eifel) are useful exactly for slow links with loss, high rtt and, especially, its variance. If those vendors, who disable it, really observe decrease in performance due to timestamps, they are _right_. It simply means that their TCP stack does not use timestamps in any case. That's all. > I believe > that accepting such a late TS option is a 2 line code change (triggering it is > harder of course). Idea is good, criterium is a bit strange. It seems to be more clever to modify compression protocols to compress timestamps instead. Alexey From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:03:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20320 for ; Wed, 9 Aug 2000 17:02:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA25561 for tcp-impl-outgoing; Wed, 9 Aug 2000 13:53:42 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA25557 for ; Wed, 9 Aug 2000 13:53:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA08059; Wed, 9 Aug 2000 13:53:35 -0400 Message-Id: <200008091753.NAA08059@seraph3.lerc.nasa.gov> Received: from be.be.com(208.243.144.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007719; Wed, 9 Aug 00 13:53:07 -0400 Received: (qmail 21724 invoked from network); 9 Aug 2000 17:53:03 -0000 Received: from gpz.be.com (10.113.216.32) by mail.be.com with SMTP; 9 Aug 2000 17:53:03 -0000 To: Matt Mathis Subject: Re: Important question re: new TCP options on data segments Cc: alan@lxorguk.ukuu.org.uk, richard@wendland.org.uk, tcp-impl@grc.nasa.gov Date: Wed, 09 Aug 2000 11:01:52 PDT From: "Howard Berkey" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: howard@be.com X-Mailer: BeOS Mail X-Spam-Rating: mail.be.com 1.6.2 0/1000/A Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >On Wed, 9 Aug 2000, Alan Cox wrote: > >> > This prohibition on late TCP options is thwarting at least 2 reasonable >> > proposals for TCP options, including the RST error code. >> >> I think the prohibition should just be dropped given the hostile nature of >> the net today. Any box with that bug is basically unusable on the Internet >> anyway > >Duh! Sometime it is real important to rethink old decisions in new contexts. > >Ok, lets ask the question the other way: > >Can anybody think of *any* compelling argument agaist droping the prohibition >against new TCP options appearing after a SYN? > Given that any new post-SYN options are (of course) optional and can be safely ignored by a receiving TCP, I see no reason why the restriction should be kept. From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:06:04 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20390 for ; Wed, 9 Aug 2000 17:06:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA08048 for tcp-impl-outgoing; Wed, 9 Aug 2000 15:09:04 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA08026 for ; Wed, 9 Aug 2000 15:09:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA14536; Wed, 9 Aug 2000 15:09:01 -0400 Received: from mailer.psc.edu(128.182.58.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013689; Wed, 9 Aug 00 15:08:05 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer.psc.edu (8.9.3/8.9.3/psc) with ESMTP id PAA15886; Wed, 9 Aug 2000 15:08:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by tesla.psc.edu (8.9.3/8.9.3/psc) with ESMTP id PAA02944; Wed, 9 Aug 2000 15:08:04 -0400 (EDT) Date: Wed, 9 Aug 2000 15:08:04 -0400 (EDT) From: Matt Mathis To: David Borman cc: tcp-impl@grc.nasa.gov Subject: RE: First SACK-permitted on In-Reply-To: <200008091643.LAA04364@frantic.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Wed, 9 Aug 2000, David Borman wrote: > I don't have any objections to allowing TCP options in non-SYN > packets without prior negotiation in the SYN packets. And specifically > with the Timestamps option, if we were to modify it to not require that > Timestamps be exchanged on the SYN, then it should be done with the > caveat that once Timestamps are enabled, they must remain enabled for > the rest of the connection. You would probably only want to initiate > the enabling of Timestamps on a data packet, because when you get the > ACK for that data, it will contain a Timestamps option if the other > side supports it. If it doesn't have a Timestamps option, then you > know the other side doesn't support them and you stop sending them. Yes, precisely! This has been on my wish queue for years..... Do we (you and I) have the cycles to push RFC1323bis? Although this is a relatively small code change, it is a fairly large document change because the current text is structured around the idea of always disallowing new TCP options on non-SYN packets. Thoughts? --MM-- From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:13:30 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20626 for ; Wed, 9 Aug 2000 17:13:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA05888 for tcp-impl-outgoing; Wed, 9 Aug 2000 14:57:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA05842 for ; Wed, 9 Aug 2000 14:56:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA03573; Wed, 9 Aug 2000 14:56:56 -0400 Received: from frantic.weston.bsdi.com(209.173.194.254) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002975; Wed, 9 Aug 00 14:56:16 -0400 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id NAA04678; Wed, 9 Aug 2000 13:52:20 -0500 (CDT) Date: Wed, 9 Aug 2000 13:52:20 -0500 (CDT) From: David Borman Message-Id: <200008091852.NAA04678@frantic.bsdi.com> To: raj@cup.hp.com, tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Date: Wed, 09 Aug 2000 10:17:45 -0700 > From: Rick Jones > Subject: Re: Important question re: new TCP options on data segments > > Matt Mathis wrote: > > Can anybody think of *any* compelling argument agaist droping the prohibition > > against new TCP options appearing after a SYN? > > It means I have to be prepared to look for "unexpected" options in my > mainline data path. That's already required by RFC 1122. > I'm not certain it ensures there is enough space for all the options one > might want to carry. True, it means that the options added in the middle > would not have to fight for space with the MSS option or the window > scale option, but it may still have to duke it out with a SACK option > and timestamps. If worse comes to worse, we can define a TCP option to extend the TCP option space in a backwards compatable manner. We did it for the window field, and there are several ways we can do it for the Data Offset field. But that's not to say that I'm advocating putting in oodles of TCP options... -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:18:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20771 for ; Wed, 9 Aug 2000 17:18:57 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA04957 for tcp-impl-outgoing; Wed, 9 Aug 2000 14:51:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA04923 for ; Wed, 9 Aug 2000 14:50:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA28777; Wed, 9 Aug 2000 14:50:55 -0400 Received: from palrel1.hp.com(156.153.255.242) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028643; Wed, 9 Aug 00 14:50:46 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel1.hp.com (Postfix) with ESMTP id 5628938EA for ; Wed, 9 Aug 2000 11:19:42 -0700 (PDT) Received: from cup.hp.com (raj@localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA19255 for ; Wed, 9 Aug 2000 11:18:50 -0700 (PDT) Message-ID: <3991A089.73B96E2F@cup.hp.com> Date: Wed, 09 Aug 2000 11:18:49 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments References: <39919239.334178F9@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Rick Jones wrote: > It means I have to be prepared to look for "unexpected" options in my > mainline data path. BTW, I meant that in the context of added path length in my "normal" data path... 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 Wed Aug 9 17:24:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20862 for ; Wed, 9 Aug 2000 17:24:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA08305 for tcp-impl-outgoing; Wed, 9 Aug 2000 15:10:05 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA08272 for ; Wed, 9 Aug 2000 15:10:03 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA15762; Wed, 9 Aug 2000 15:10:02 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014516; Wed, 9 Aug 00 15:09:28 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13Mayp-0000tn-00; Wed, 9 Aug 2000 19:53:31 +0100 Subject: Re: Important question re: new TCP options on data segments To: raj@cup.hp.com (Rick Jones) Date: Wed, 9 Aug 2000 19:53:29 +0100 (BST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <39919239.334178F9@cup.hp.com> from "Rick Jones" at Aug 09, 2000 10:17:45 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > It means I have to be prepared to look for "unexpected" options in my > mainline data path. Only if you support it > I'm not certain it ensures there is enough space for all the options one > might want to carry. True, it means that the options added in the middle > would not have to fight for space with the MSS option or the window > scale option, but it may still have to duke it out with a SACK option > and timestamps. Actually you made me realise a worse problem. It isnt the options and option space that is a pain, its the sudden change of MSS relative to the MTU due to additional header overhead From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:39:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21410 for ; Wed, 9 Aug 2000 17:39:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12319 for tcp-impl-outgoing; Wed, 9 Aug 2000 15:36:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA12286 for ; Wed, 9 Aug 2000 15:36:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA11581; Wed, 9 Aug 2000 15:36:09 -0400 Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011379; Wed, 9 Aug 00 15:36:00 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 15:35:59 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFFF@lespaul.process.com> From: Bernie Volz To: "'Alan Cox'" , raj@cup.hp.com Cc: tcp-impl@grc.nasa.gov Subject: RE: Important question re: new TCP options on data segments Date: Wed, 9 Aug 2000 15:35:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The MSS/MTU change isn't that difficult to deal with since this is an issue for the SENDER, not the receiver. The sender knows (or should be able to know) in advance what options it might send and thus can adjust the maximum "data" size accordingly. -----Original Message----- From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] Sent: Wednesday, August 09, 2000 2:53 PM To: raj@cup.hp.com Cc: tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments > It means I have to be prepared to look for "unexpected" options in my > mainline data path. Only if you support it > I'm not certain it ensures there is enough space for all the options one > might want to carry. True, it means that the options added in the middle > would not have to fight for space with the MSS option or the window > scale option, but it may still have to duke it out with a SACK option > and timestamps. Actually you made me realise a worse problem. It isnt the options and option space that is a pain, its the sudden change of MSS relative to the MTU due to additional header overhead From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:45:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21604 for ; Wed, 9 Aug 2000 17:45:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA14367 for tcp-impl-outgoing; Wed, 9 Aug 2000 15:49:16 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA14344 for ; Wed, 9 Aug 2000 15:49:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA21253; Wed, 9 Aug 2000 15:49:12 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021174; Wed, 9 Aug 00 15:49:05 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10762; Wed, 9 Aug 2000 12:49:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA05741; Wed, 9 Aug 2000 12:49:00 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e79JmxH991404; Wed, 9 Aug 2000 12:48:59 -0700 (PDT) Date: Wed, 9 Aug 2000 12:49:05 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Important question re: new TCP options on data segments To: tcp-impl@grc.nasa.gov Cc: mathis@psc.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Can anybody think of *any* compelling argument agaist droping the prohibition > against new TCP options appearing after a SYN? I guess this question should also be sent to the ROHC group. I don't know if they are prepared to handle this kind of things... K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 17:48:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21705 for ; Wed, 9 Aug 2000 17:48:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12332 for tcp-impl-outgoing; Wed, 9 Aug 2000 15:36:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA12292 for ; Wed, 9 Aug 2000 15:36:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA11579; Wed, 9 Aug 2000 15:36:09 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011439; Wed, 9 Aug 00 15:36:01 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03883; Wed, 9 Aug 2000 12:35:34 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA02183; Wed, 9 Aug 2000 12:35:31 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e79JZUH989576; Wed, 9 Aug 2000 12:35:30 -0700 (PDT) Date: Wed, 9 Aug 2000 12:35:36 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Important question re: new TCP options on data segments To: Alan Cox Cc: Rick Jones , tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Actually you made me realise a worse problem. It isnt the options and option > space that is a pain, its the sudden change of MSS relative to the MTU due > to additional header overhead Because of SACK option, TCP needs to deal with that anyway... And for stacks which handle the case when one end suddenly stops sending timestamp option so that TCP also stops sending it, they should handle the change of MSS also... K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 18:07:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21987 for ; Wed, 9 Aug 2000 18:07:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA15471 for tcp-impl-outgoing; Wed, 9 Aug 2000 15:56:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA15426 for ; Wed, 9 Aug 2000 15:56:12 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA26652; Wed, 9 Aug 2000 15:56:12 -0400 Received: from tnt.isi.edu(128.9.128.128) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026119; Wed, 9 Aug 00 15:55:24 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA27360; Wed, 9 Aug 2000 12:55:19 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA18317; Wed, 9 Aug 2000 19:55:19 GMT Date: Wed, 9 Aug 2000 19:55:19 GMT Message-Id: <200008091955.TAA18317@gra.isi.edu> To: raj@cup.hp.com, alan@lxorguk.ukuu.org.uk Subject: Re: Important question re: new TCP options on data segments Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> *> Actually you made me realise a worse problem. It isnt the options and option *> space that is a pain, its the sudden change of MSS relative to the MTU due *> to additional header overhead *> *> *> Why should a "sudden" change of MSS by a few bytes matter to TCP dynamics? Bob Braden From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 18:24:10 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22127 for ; Wed, 9 Aug 2000 18:24:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20742 for tcp-impl-outgoing; Wed, 9 Aug 2000 16:26:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA20670 for ; Wed, 9 Aug 2000 16:26:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA20039; Wed, 9 Aug 2000 16:26:22 -0400 Message-Id: <200008092026.QAA20039@seraph3.lerc.nasa.gov> Received: from be.be.com(208.243.144.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019603; Wed, 9 Aug 00 16:25:54 -0400 Received: (qmail 10573 invoked from network); 9 Aug 2000 20:25:53 -0000 Received: from gpz.be.com (10.113.216.32) by mail.be.com with SMTP; 9 Aug 2000 20:25:53 -0000 To: Rick Jones Subject: Re: Important question re: new TCP options on data segments Cc: tcp-impl@grc.nasa.gov Date: Wed, 09 Aug 2000 13:34:25 PDT From: "Howard Berkey" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: howard@be.com X-Mailer: BeOS Mail X-Spam-Rating: mail.be.com 1.6.2 0/1000/A Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >Matt Mathis wrote: >> Can anybody think of *any* compelling argument agaist droping the prohibition >> against new TCP options appearing after a SYN? > >It means I have to be prepared to look for "unexpected" options in my >mainline data path. To be robust (and follow the spirit of "be liberal in what you accept"), you already have to anyway. Remember, you don't have to actually DO anything with the later options; you just have to not die when they arrive. Options are, in general, optional. > >I cannot help but think about how planes like the B17 kept getting >heavier, more complex, and (iirc) just a little slower as people added >this feature and that feature... > Continuing your analogy, by being robust the B17 could take a lot of punishment fired at it before it went down :-) From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 18:34:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22279 for ; Wed, 9 Aug 2000 18:34:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA21676 for tcp-impl-outgoing; Wed, 9 Aug 2000 16:33:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA21630 for ; Wed, 9 Aug 2000 16:33:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA24506; Wed, 9 Aug 2000 16:33:22 -0400 Received: from frantic.weston.bsdi.com(209.173.194.254) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024387; Wed, 9 Aug 00 16:33:12 -0400 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id PAA05174; Wed, 9 Aug 2000 15:30:27 -0500 (CDT) Date: Wed, 9 Aug 2000 15:30:27 -0500 (CDT) From: David Borman Message-Id: <200008092030.PAA05174@frantic.bsdi.com> To: alan@lxorguk.ukuu.org.uk, raj@cup.hp.com Subject: Re: Important question re: new TCP options on data segments Cc: tcp-impl@grc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Subject: Re: Important question re: new TCP options on data segments > Date: Wed, 9 Aug 2000 19:53:29 +0100 (BST) > From: Alan Cox ... > Actually you made me realise a worse problem. It isnt the options and option > space that is a pain, its the sudden change of MSS relative to the MTU due > to additional header overhead Without going into the whole "MSS is not MTU" discussion... Assuming an MSS based on the MTU, the advertised MSS value is MTU - 40, you *do not* adjust your advertised MSS value to account for either TCP or IP options that you think the other side might send. Instead, the sender is responsible for adjusting down the amount of TCP data that it puts into the packet to account for any TCP and IP options that are also being included. -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 19:12:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22559 for ; Wed, 9 Aug 2000 19:12:52 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA26624 for tcp-impl-outgoing; Wed, 9 Aug 2000 17:08:35 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA26576 for ; Wed, 9 Aug 2000 17:08:32 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA12483; Wed, 9 Aug 2000 17:08:31 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012029; Wed, 9 Aug 00 17:07:27 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Md40-000219-00; Wed, 09 Aug 2000 22:07:00 +0100 Date: Wed, 9 Aug 2000 22:06:41 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Matt Mathis cc: Alan Cox , Richard Wendland , tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Wed, 9 Aug 2000, Matt Mathis wrote: > Can anybody think of *any* compelling argument agaist droping the prohibition > against new TCP options appearing after a SYN? What about: 1. it being an indication that you've just been spoofed and that transmissions are now being received by a different host? 2. Interactions with max segment size, jumbo payload computations, etc.? btw, there's no extra SYN negotation procedure for the new RFC2883 D-SACK. That might be some sort of precedent here. L. PGP From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 19:38:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22771 for ; Wed, 9 Aug 2000 19:38:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA01047 for tcp-impl-outgoing; Wed, 9 Aug 2000 17:44:45 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA01019 for ; Wed, 9 Aug 2000 17:44:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA28281; Wed, 9 Aug 2000 17:44:40 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028251; Wed, 9 Aug 00 17:44:35 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13MdYl-0001GX-00; Wed, 9 Aug 2000 22:38:47 +0100 Subject: Re: Important question re: new TCP options on data segments To: braden@ISI.EDU (Bob Braden) Date: Wed, 9 Aug 2000 22:38:46 +0100 (BST) Cc: raj@cup.hp.com, alan@lxorguk.ukuu.org.uk, tcp-impl@grc.nasa.gov In-Reply-To: <200008091955.TAA18317@gra.isi.edu> from "Bob Braden" at Aug 09, 2000 07:55:19 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > *> space that is a pain, its the sudden change of MSS relative to the MTU due > *> to additional header overhead > *> > *> > Why should a "sudden" change of MSS by a few bytes matter to TCP > dynamics? It depends how people implement delayed ack handling. Traditionally you play guess the MSS in order to skip delayed ack on smaller frames so Nagle doesnt bite you hard. Alan From owner-tcp-impl@lerc.nasa.gov Wed Aug 9 19:49:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22883 for ; Wed, 9 Aug 2000 19:49:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA00646 for tcp-impl-outgoing; Wed, 9 Aug 2000 17:40:45 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA00604 for ; Wed, 9 Aug 2000 17:40:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA27049; Wed, 9 Aug 2000 17:40:41 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026929; Wed, 9 Aug 00 17:40:02 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 367; Wed, 9 Aug 2000 14:39:59 -0700 Message-ID: <3991CFAF.8946B865@ehsco.com> Date: Wed, 09 Aug 2000 14:39:59 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox CC: Rick Jones , tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Actually you made me realise a worse problem. It isnt the options and > option space that is a pain, its the sudden change of MSS relative to > the MTU due to additional header overhead Accounting for an on-the-fly options should be roughly the same for RST options as it is for SACK options (unless you're reserving MSS space in every segment for a possible SACK that is). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Thu Aug 10 16:53:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13694 for ; Thu, 10 Aug 2000 16:53:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA18999 for tcp-impl-outgoing; Thu, 10 Aug 2000 14:32:23 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA18995 for ; Thu, 10 Aug 2000 14:32:22 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id OAA11257; Thu, 10 Aug 2000 14:32:16 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010991; Thu, 10 Aug 00 14:31:30 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA20150; Thu, 10 Aug 2000 22:30:28 +0400 Message-Id: <200008101830.WAA20150@ms2.inr.ac.ru> Subject: Re: Important question re: new TCP options on data segments To: L.Wood@eim.surrey.ac.uk Date: Thu, 10 Aug 2000 22:30:28 +0400 (MSK DST) Cc: mathis@psc.edu, alan@lxorguk.ukuu.org.uk, richard@wendland.org.uk, tcp-impl@grc.nasa.gov In-Reply-To: from "Lloyd Wood" at Aug 9, 0 10:06:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > btw, there's no extra SYN negotation procedure for the new RFC2883 > D-SACK. That might be some sort of precedent here. It is not a precedent. D-SACK is really backward compatible in all the respects. If you receive it, you use it. With timestamps the situation is different. Some stacks (I will not show with finger) are optimized yet. And if peer starts to send timestamps after some obscure criteria is satisfied (sort of rate), you will fall to maximally suboptimal way exactly at high rate. Besides that connection will be aggressively delacked, because mss estimation also relies on the fact, that TS is persistent option. Nothing will break, but all the things contradicting to original specs will result in either fall to slow path or to failure of existing heuristics. Lots of second order effects. So, negotiation phase for timestamps is required. No matter, when it occurs. Stacks, which dislike enabling timestamps in the middle of connection, will refuse the negotition. Alexey From owner-tcp-impl@lerc.nasa.gov Thu Aug 10 18:03:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14924 for ; Thu, 10 Aug 2000 18:03:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA04625 for tcp-impl-outgoing; Thu, 10 Aug 2000 16:11:01 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA04598 for ; Thu, 10 Aug 2000 16:10:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA22104; Thu, 10 Aug 2000 16:10:54 -0400 Received: from mailer.psc.edu(128.182.58.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022012; Thu, 10 Aug 00 16:10:42 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer.psc.edu (8.9.3/8.9.3/psc) with ESMTP id QAA15214; Thu, 10 Aug 2000 16:10:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by tesla.psc.edu (8.9.3/8.9.3/psc) with ESMTP id QAA17763; Thu, 10 Aug 2000 16:10:41 -0400 (EDT) Date: Thu, 10 Aug 2000 16:10:40 -0400 (EDT) From: Matt Mathis To: kuznet@ms2.inr.ac.ru cc: tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments In-Reply-To: <200008101830.WAA20150@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Thu, 10 Aug 2000 kuznet@ms2.inr.ac.ru wrote: > With timestamps the situation is different. Some stacks > (I will not show with finger) are optimized yet. > And if peer starts to send timestamps after some obscure > criteria is satisfied (sort of rate), you will fall to > maximally suboptimal way exactly at high rate. > Besides that connection will be aggressively delacked, > because mss estimation also relies on the fact, > that TS is persistent option. > > Nothing will break, but all the things contradicting to original > specs will result in either fall to slow path or to failure > of existing heuristics. I think your argument boils down to this: There are other reasons to do timestamps besides PAWS. If a stack is using one of these other algoritms, then it may want to turn on timestamps earlier than needed by PAWS. Fine. Not a problem. So the choice is timestamps [off, on, or auto] and it is our mission to make "auto" smart enough where future vendor defaults will always be auto, and TCP will "just do the right thing". Except for the ability to change timestamps mid connection, these details are not protocol specifications and for the most part are allowed under current standards. Thanks, --MM-- From owner-tcp-impl@lerc.nasa.gov Thu Aug 10 20:29:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17297 for ; Thu, 10 Aug 2000 20:29:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA20313 for tcp-impl-outgoing; Thu, 10 Aug 2000 18:35:48 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA20293 for ; Thu, 10 Aug 2000 18:35:46 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA19579; Thu, 10 Aug 2000 18:35:44 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019514; Thu, 10 Aug 00 18:35:28 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13N0uo-00028O-00; Thu, 10 Aug 2000 23:35:06 +0100 Date: Thu, 10 Aug 2000 23:34:59 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: kuznet@ms2.inr.ac.ru cc: tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments In-Reply-To: <200008101830.WAA20150@ms2.inr.ac.ru> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Thu, 10 Aug 2000 kuznet@ms2.inr.ac.ru wrote: > > btw, there's no extra SYN negotation procedure for the new RFC2883 > > D-SACK. That might be some sort of precedent here. > > It is not a precedent. D-SACK is really backward compatible > in all the respects. If you receive it, you use it. That's not quite the case. SACK senders may not be D-SACK aware, and may not use the DSACK information they receive. (I think there's lots of future scope for algorithms based on D-SACK info, but not on this list.) L. PGP From owner-tcp-impl@lerc.nasa.gov Fri Aug 11 15:02:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00341 for ; Fri, 11 Aug 2000 15:02:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA13310 for tcp-impl-outgoing; Fri, 11 Aug 2000 13:03:40 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA13257 for ; Fri, 11 Aug 2000 13:03:36 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id NAA27375; Fri, 11 Aug 2000 13:03:35 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026893; Fri, 11 Aug 00 13:03:05 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA03652; Fri, 11 Aug 2000 21:02:54 +0400 Message-Id: <200008111702.VAA03652@ms2.inr.ac.ru> Subject: Re: Important question re: new TCP options on data segments To: L.Wood@eim.surrey.ac.uk Date: Fri, 11 Aug 2000 21:02:54 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: from "Lloyd Wood" at Aug 10, 0 11:34:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > That's not quite the case. SACK senders may not be D-SACK aware, and > may not use the DSACK information they receive. And nothing happens in this case, that's point. Moreover, _using_ D-SACK info at sender is not so easy task, it is difficult to expect that vendors will be able to make this soon. But generating D-SACK is really easy task and sender, receiving D-SACK and not understanding them does not suffer of them. They are not more than usual SACKs for it. > of future scope for algorithms based on D-SACK info, but not on > this list.) A bit out of topic, yes. But genarally this list is not so bad place to discuss tcp yet. 8) Alexey From owner-tcp-impl@lerc.nasa.gov Fri Aug 11 15:16:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00343 for ; Fri, 11 Aug 2000 15:02:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA12363 for tcp-impl-outgoing; Fri, 11 Aug 2000 12:56:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA12322 for ; Fri, 11 Aug 2000 12:56:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA22796; Fri, 11 Aug 2000 12:56:23 -0400 Received: from mail.toplayer.com(216.90.225.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022314; Fri, 11 Aug 00 12:55:28 -0400 Received: from TopLayer.com (fenway.toplayer.com [216.90.225.14]) by tlnmail1.toplayer.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QVXLAT8K; Fri, 11 Aug 2000 12:55:27 -0400 Message-ID: <39942FFD.CD8AA52A@TopLayer.com> Date: Fri, 11 Aug 2000 12:55:25 -0400 From: Frank Solensky Organization: Top Layer Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bob Braden CC: tcp-impl@grc.nasa.gov Subject: Re: Important question re: new TCP options on data segments References: <200008091955.TAA18317@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: > > *> > *> Actually you made me realise a worse problem. It isnt the options and option > *> space that is a pain, its the sudden change of MSS relative to the MTU due > *> to additional header overhead > *> > Why should a "sudden" change of MSS by a few bytes matter to TCP > dynamics?  Some implementations may break up the transmit window into MSS-sized blocks so that transmission just becomes a matter of dropping the headers in front. As you say, though, that's just an implementation detail -- the sender could just as easily assume worst-case and fragment into MSS - (IPv* + 20) for the life of the connection. -- Frank From owner-tcp-impl@lerc.nasa.gov Fri Aug 11 15:24:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00850 for ; Fri, 11 Aug 2000 15:24:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA17833 for tcp-impl-outgoing; Fri, 11 Aug 2000 13:33:21 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA17808 for ; Fri, 11 Aug 2000 13:33:19 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id NAA18585; Fri, 11 Aug 2000 13:33:18 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018199; Fri, 11 Aug 00 13:32:38 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA03732; Fri, 11 Aug 2000 21:32:32 +0400 Message-Id: <200008111732.VAA03732@ms2.inr.ac.ru> Subject: Re: Important question re: new TCP options on data segments To: mathis@psc.edu (Matt Mathis) Date: Fri, 11 Aug 2000 21:32:32 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: from "Matt Mathis" at Aug 10, 0 04:10:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > There are other reasons to do timestamps besides PAWS. If a stack is using one > of these other algoritms, then it may want to turn on timestamps earlier than > needed by PAWS. Not quite. To use or not to use timestamps and when to use them is choice of OS, user and/or administator yet. [ Side note. I just tried to remind you that TS are useful not only for PAWS, so that you criterium of enabling TS after achieving some rate is highly dubious. ] My point is that nobody is allowed to stop or to start sending some persistent option without explicit negotiation. They will be considered as "random jitter" sort of SACKs and will move input process to slow path, which is appropriate for SACK and absolutely inappropriate with persistent options. Of course, smart OS would change its prediction algorithm without special reminder. But it does not this now. And it looks really silly to add some new flaky heuristics to stateful protocol in the place, where explicit negotiation can be made. Classic TCP has enough of such silly places to be bothered about avoiding adding new ones. > Fine. Not a problem. So the choice is timestamps [off, on, or auto] and it is > our mission to make "auto" smart enough where future vendor defaults will > always be auto, and TCP will "just do the right thing". Provided those vendors, who do not have time machine and cannot upgrade already sold OSes, will not see "auto" options without "auto" negotiation, which will fail. Let this negotiation will be made in the middle of connection, it does not matter. Alexey From owner-tcp-impl@lerc.nasa.gov Mon Aug 14 15:56:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17937 for ; Mon, 14 Aug 2000 15:56:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24038 for tcp-impl-outgoing; Mon, 14 Aug 2000 13:17:36 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA24017 for ; Mon, 14 Aug 2000 13:17:34 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA28185; Mon, 14 Aug 2000 13:17:34 -0400 Received: from starburst.demon.co.uk(194.222.114.233) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027208; Mon, 14 Aug 00 13:16:35 -0400 Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id SAA08439; Mon, 14 Aug 2000 18:14:54 +0100 From: Richard Wendland Message-Id: <200008141714.SAA08439@starburst.demon.co.uk> Subject: Re: First SACK-permitted on To: mathis@psc.edu (Matt Mathis) Date: Mon, 14 Aug 2000 18:14:53 +0100 (BST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: from "Matt Mathis" at Aug 08, 2000 07:44:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > In my copious spare time I would love to run a semi-production web server that > always sent late experimental (unpublished) options to see if I could detect > any systems with bugs. I would bet not, and would then consider proposing to > revise 1323 to allow and even encourage late TS options. (In my spare time!) > > I wish that somebody would actually try this experiment or reconstruct more > details of the history. Your wish has been partly granted! A number of HTTP load balancing devices or firewalls do some odd (if not evil) things with TCP. One particular device indeed seems particularly broken, in that it removes all TCP options from SYN-ACK, and then in-effect sends them on the next ACK! Thus for example MSS or window-scale options are on a plain ACK; so although these aren't experimental options, they would be thoroughly unexpected, potentially breaking TCP stacks. This particular device is in use on at least something like 30 IP addresses, running about 50 websites, worldwide. I don't recognise any of these sites as especially well-known, but some do seem serious websites that probably have significant use. So although this device isn't in widespread use, it probably has non-trivial use, fairly successfully we must assume. However the operators of these sites aren't likely to be very TCP knowledgeable, so maybe there are problems with clients which they don't recognise and report. A point to bear in mind though, as Alan Cox pointed out, is that Internet connected devices will often see odd TCP effects from hostile actions. But it may be that off-Internet devices will show significant problems with unexpected TCP options. I recall that when FreeBSD enabled T/TCP by default, there were some reported problems with terminal servers, and maybe these intranet devices should be the area of most concern. Some tcpdump output from websites using the above mentioned device are below. Note another oddity of the device is a zero window on the SYN-ACK. This isn't the only such odd device. Another, in widespread use, seems in effect to remove all TCP options other than MSS from SYN-ACK. But later segments are allowed with all TCP options in place, so TCP stacks will see non-negotiated options, like late TS options; but these would only go to TCP stacks that knew about them as they would be in response to those offered on the SYN. Both these devices seem to me, by removing window-scale on SYN-ACK, to have the potential to make the two ends think that different window-scale factors are agreed; but I have not demonstrated this. So maybe they break TCP in this regard, even if they get away with the rest of what they do. Here's some trimmed tcpdump output from the first-mentioned device. www.allegiancehealth.com: CLIENT1.6170 > www.allegiance.net.http: S 420261394:420261394(0) win 512 www.allegiance.net.http > CLIENT1.6170: S 2893365979:2893365979(0) ack 420261395 win 0 CLIENT1.6170 > www.allegiance.net.http: . ack 1 win 32472 (DF) www.allegiance.net.http > CLIENT1.6170: . ack 1 win 8856 (DF) ^^^^^ ^^^^^^^^^^ CLIENT1.6170 > www.allegiance.net.http: P 1:18(17) ack 1 win 32472 (DF) www.allegiance.net.http > CLIENT1.6170: . ack 18 win 8839 (DF) ... www.chuden-cs.co.jp: CLIENT2.3355 > ccsgw1.chuden-cs.co.jp.http: S 2013930150:2013930150(0) win 16384 (DF) ccsgw1.chuden-cs.co.jp.http > CLIENT2.3355: S 351095432:351095432(0) ack 2013930151 win 0 CLIENT2.3355 > ccsgw1.chuden-cs.co.jp.http: . ack 1 win 16384 (DF) ccsgw1.chuden-cs.co.jp.http > CLIENT2.3355: . ack 1 win 10136 (DF) ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CLIENT2.3355 > ccsgw1.chuden-cs.co.jp.http: P 1:18(17) ack 1 win 16384 (DF) ccsgw1.chuden-cs.co.jp.http > CLIENT2.3355: . ack 18 win 10220 (DF) ... Richard -- Richard Wendland richard@wendland.org.uk From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 19:22:10 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06204 for ; Thu, 17 Aug 2000 19:22:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA05428 for tcp-impl-outgoing; Thu, 17 Aug 2000 17:12:39 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA05406 for ; Thu, 17 Aug 2000 17:12:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA26324; Thu, 17 Aug 2000 17:12:35 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026164; Thu, 17 Aug 00 17:12:04 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05805; Thu, 17 Aug 2000 14:11:23 -0700 (PDT) Message-ID: <399C54EF.20917984@isi.edu> Date: Thu, 17 Aug 2000 14:11:11 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ignacio Goyret CC: Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Ignacio Goyret wrote: > > At 06:54 PM 8/1/00 -0400, Bernie Volz wrote: > >Some that I could think of are: > >- No listener (for a SYN segment) > >- Unknown connection > >- Receiver discard connection (data received on a connection with no higher > >level receiver available) > >- Application abort (application requested RST on connection instead of > >closing it) > > I'm sure that your reasons are well-meant and quite honest, but I have to > wonder out loud if these codes won't be of great help to a hacker. Only if they're trying to hack your statistics or debugging. I don't think (pls correct me if this is not the case) that anyone is proposing different receiver actions based on these codes; it's just for diagnoses, right? > I also hope that all those vendors mentioned have knobs to enable these codes > only when desired (they should default to disabled). That seems like it would make diagnoses harder; if they're just informational, they could default to 'on'. Joe From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 20:47:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07090 for ; Thu, 17 Aug 2000 20:47:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA13434 for tcp-impl-outgoing; Thu, 17 Aug 2000 19:00:35 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA13415 for ; Thu, 17 Aug 2000 19:00:32 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA21974; Thu, 17 Aug 2000 19:00:30 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021929; Thu, 17 Aug 00 19:00:13 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA25286; Thu, 17 Aug 2000 16:00:03 -0700 (PDT) Message-ID: <399C6E67.E0035F85@isi.edu> Date: Thu, 17 Aug 2000 15:59:51 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ignacio Goyret CC: Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Ignacio Goyret wrote: > > At 02:11 PM 8/17/00 -0700, Joe Touch wrote: > > > >Ignacio Goyret wrote: > >> > >> At 06:54 PM 8/1/00 -0400, Bernie Volz wrote: > >> >Some that I could think of are: > >> >- No listener (for a SYN segment) > >> >- Unknown connection > >> >- Receiver discard connection (data received on a connection with no higher > >> >level receiver available) > >> >- Application abort (application requested RST on connection instead of > >> >closing it) > >> > >> I'm sure that your reasons are well-meant and quite honest, but I have to > >> wonder out loud if these codes won't be of great help to a hacker. > > > >Only if they're trying to hack your statistics or debugging. > >I don't think (pls correct me if this is not the case) that > >anyone is proposing different receiver actions based on these > >codes; it's just for diagnoses, right? > > Any information shot back to the sender of a SYN is potential information > for a hacker. Yes! A SYN/ACK is info, the window size is info, etc. If you're that worried about hackers, use IPSEC. How does this _add_ compromises, is the question... Joe From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 20:48:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07110 for ; Thu, 17 Aug 2000 20:48:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA13205 for tcp-impl-outgoing; Thu, 17 Aug 2000 18:57:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA13187 for ; Thu, 17 Aug 2000 18:57:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA21502; Thu, 17 Aug 2000 18:57:29 -0400 Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021434; Thu, 17 Aug 00 18:56:35 -0400 Received: from russet.ascend.com (h-c6045c34.ascend.com [198.4.92.52]) by drawbridge.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA19737; Thu, 17 Aug 2000 15:48:56 -0700 (PDT) Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA01212; Thu, 17 Aug 2000 15:55:57 -0700 (PDT) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [135.140.53.42]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id PAA05693; Thu, 17 Aug 2000 15:55:57 -0700 (PDT) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id PAA01087; Thu, 17 Aug 2000 15:55:54 -0700 (PDT) Message-Id: <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 17 Aug 2000 15:24:42 -0700 To: Joe Touch From: Ignacio Goyret Subject: Re: keep RST data nonstandardized for the future! Cc: Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov In-Reply-To: <399C54EF.20917984@isi.edu> References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk At 02:11 PM 8/17/00 -0700, Joe Touch wrote: > >Ignacio Goyret wrote: >> >> At 06:54 PM 8/1/00 -0400, Bernie Volz wrote: >> >Some that I could think of are: >> >- No listener (for a SYN segment) >> >- Unknown connection >> >- Receiver discard connection (data received on a connection with no higher >> >level receiver available) >> >- Application abort (application requested RST on connection instead of >> >closing it) >> >> I'm sure that your reasons are well-meant and quite honest, but I have to >> wonder out loud if these codes won't be of great help to a hacker. > >Only if they're trying to hack your statistics or debugging. >I don't think (pls correct me if this is not the case) that >anyone is proposing different receiver actions based on these >codes; it's just for diagnoses, right? Any information shot back to the sender of a SYN is potential information for a hacker. For example, if the code says something like "too busy" (or something that might indicate that), then Joe Hacker knows that your server is on the brink: just keep pumping SYNs until it keels over. If it says something like "bad security" or "bad precedence", well, you are just asking for it. :-) On typical servers, a new incoming connection usually implies that a daemon will be spawn or something like that, in other words, resources will be consumed. If that malicious person can get a view into how you are denying his SYN attack, he might be able to tune the attack and kill your server/router/etc. All I say is "let's be careful". The less information you provide back to the potentially malicious instigator, the lesser the chances that it will know how to affect you worst. In fact, I would almost argue that an RST in response to a SYN or SYN/ACK should not contain any information whatsoever (unless a kernel flag was turned on) to minimize this potential. I have no problem with info on RSTs which are sent elsewhere in the cycle, ie, from established onwards. >> I also hope that all those vendors mentioned have knobs to enable these codes >> only when desired (they should default to disabled). > >That seems like it would make diagnoses harder; if they're just >informational, they could default to 'on'. What I'm saying is that you only want to turn them on when you are actively debugging something. Until then, leave them off. There is no need to provide extra tools to the intruders out there. -Ignacio "Just because I'm paranoid it doesn't mean they are not after me" :-) From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 21:28:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07547 for ; Thu, 17 Aug 2000 21:28:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA15638 for tcp-impl-outgoing; Thu, 17 Aug 2000 19:41:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA15625 for ; Thu, 17 Aug 2000 19:41:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA27341; Thu, 17 Aug 2000 19:41:56 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027261; Thu, 17 Aug 00 19:41:45 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02246; Thu, 17 Aug 2000 16:40:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id QAA07756; Thu, 17 Aug 2000 16:40:18 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7HNeGK415295; Thu, 17 Aug 2000 16:40:16 -0700 (PDT) Date: Thu, 17 Aug 2000 16:40:24 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: keep RST data nonstandardized for the future! To: Ignacio Goyret Cc: Joe Touch , Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > On typical servers, a new incoming connection usually implies that a daemon > will be spawn or something like that, in other words, resources will be > consumed. If that malicious person can get a view into how you are denying > his SYN attack, he might be able to tune the attack and kill your > server/router/etc. I think you need to be more specific on why the extra info can be used by an attacker to do more harm than without the info. In the example above, does an attacker need to know whether a server is busy or not before an attack can be launched? Well, if it is not busy, make it busy by the attack! This is a DoF attack afterall. If it is busy, will the attacker not launch a DoF attack? > All I say is "let's be careful". The less information you provide back to the > potentially malicious instigator, the lesser the chances that it will know > how to affect you worst. I will say that it really depends on what info it is. For example, there may be a security problem if the RST is sent because of a duplicate SYN with wrong sequence number. But let's postpone this discussion of potential security problem after the list of RST code is finalized. Then we can talk about specific issues, not wasting time on some "generic info..." IMHO, I don't believe that any extra info provided in a RST in reponse to a SYN or SYN/ACK is automatically a security hole. We'll discuss that later, for sure (-: K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 22:01:29 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08803 for ; Thu, 17 Aug 2000 22:01:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA17380 for tcp-impl-outgoing; Thu, 17 Aug 2000 20:13:20 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA17370 for ; Thu, 17 Aug 2000 20:13:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA02160; Thu, 17 Aug 2000 20:13:18 -0400 Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002061; Thu, 17 Aug 00 20:12:23 -0400 Received: from russet.ascend.com (h-c6045c34.ascend.com [198.4.92.52]) by drawbridge.ascend.com (8.9.1a/8.9.1) with ESMTP id RAA25820; Thu, 17 Aug 2000 17:04:50 -0700 (PDT) Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id RAA26571; Thu, 17 Aug 2000 17:11:52 -0700 (PDT) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [135.140.53.42]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id RAA09910; Thu, 17 Aug 2000 17:11:52 -0700 (PDT) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id RAA04062; Thu, 17 Aug 2000 17:11:48 -0700 (PDT) Message-Id: <3.0.5.32.20000817163936.0129e7d0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 17 Aug 2000 16:39:36 -0700 To: Joe Touch From: Ignacio Goyret Subject: Re: keep RST data nonstandardized for the future! Cc: Ignacio Goyret , Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov In-Reply-To: <399C6E67.E0035F85@isi.edu> References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >> > >> >Only if they're trying to hack your statistics or debugging. >> >I don't think (pls correct me if this is not the case) that >> >anyone is proposing different receiver actions based on these >> >codes; it's just for diagnoses, right? >> >> Any information shot back to the sender of a SYN is potential information >> for a hacker. > >Yes! A SYN/ACK is info, the window size is info, etc. > >How does this _add_ compromises, is the question... The info you listed is non-critical. What I meant were the specific codes that have been suggested, such as "application abort", "bad precedence", "bad security", "low memory", etc. This type of information is quite interesting for someone trying to do damage. All he would need to do is repeat the same SYN ad nauseum, and if he keeps getting "application abort", he is well on his way to crash your server. Is this compromise enough? Responding with "bad precedence" or "bad security" is synonymous with inviting him to try a few other values. This _adds_ compromise. A simple empty RST doesn't give him any of this information so he doesn't know if you are just not listening on that port or that you rejected his attempt. He can't use the information of why you rejected a particular connection attempt against you because he doesn't know it. Adding a code to the RST provides this attacker with the information he needs to fine-tune his attack to bring your server down. >If you're that worried about hackers, use IPSEC. Regarding IPSEC, remember that there are many reasons to use TCP _without_ IPSEC, a web server is a good example. We (or at least I) want to be able to build boxes that are sturdy enough and can withstand some attacks. A code in an RST sent in response to a SYN or SYN/ACK as suggested just adds vulnerabilities. Again, sending RST information elsewhere in the state machine doesn't bother me as much. I _do_ see the debugging value in the idea, but I worry that it opens Pandora's box. Cheers, -Ignacio From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 22:08:22 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08835 for ; Thu, 17 Aug 2000 22:08:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA18010 for tcp-impl-outgoing; Thu, 17 Aug 2000 20:25:27 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA17992 for ; Thu, 17 Aug 2000 20:25:26 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA03795; Thu, 17 Aug 2000 20:25:26 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003662; Thu, 17 Aug 00 20:24:27 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA08839; Thu, 17 Aug 2000 17:24:13 -0700 (PDT) Message-ID: <399C8222.F1F66795@isi.edu> Date: Thu, 17 Aug 2000 17:24:02 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ignacio Goyret CC: Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Ignacio Goyret wrote: > > At 02:11 PM 8/17/00 -0700, Joe Touch wrote: > > > >Ignacio Goyret wrote: > >> > >> At 06:54 PM 8/1/00 -0400, Bernie Volz wrote: > >> >Some that I could think of are: > >> >- No listener (for a SYN segment) > >> >- Unknown connection > >> >- Receiver discard connection (data received on a connection with no higher > >> >level receiver available) > >> >- Application abort (application requested RST on connection instead of > >> >closing it) > >> > >> I'm sure that your reasons are well-meant and quite honest, but I have to > >> wonder out loud if these codes won't be of great help to a hacker. > > > >Only if they're trying to hack your statistics or debugging. > >I don't think (pls correct me if this is not the case) that > >anyone is proposing different receiver actions based on these > >codes; it's just for diagnoses, right? > > Any information shot back to the sender of a SYN is potential information > for a hacker. For example, if the code says something like "too busy" (or > something that might indicate that), then Joe Hacker knows that your server > is on the brink: just keep pumping SYNs until it keels over. If it says > something like "bad security" or "bad precedence", well, you are just asking > for it. :-) Agreed. "too busy" is a foolish place to send a RST, however. The message needs to have meaning in the TCP-sense; bad precedence means something, but bad security doesn't (that message would come in other layers, or not at all. why would you tell someone about that?). > All I say is "let's be careful". The less information you provide back to the > potentially malicious instigator, the lesser the chances that it will know how > to affect you worst. The primary purpose I saw was to send "where in the TCP stack the RST came from". I wouldn't suggest 'different application reasons'; it seems to me TCP's job is over once you tell be why _TCP_ did something. > In fact, I would almost argue that an RST in response to a SYN or SYN/ACK should > not contain any information whatsoever (unless a kernel flag was turned on) to > minimize this potential. I have no problem with info on RSTs which are sent > elsewhere in the cycle, ie, from established onwards. It could say "SYN rejected", or "SYN/ACK rejected". There are different reasons for the SYN/ACK rejection, including precedence. But that doesn't seem like information that's particularly useful. Either _you_ changed the precedence (in which case this is helpful) or a hacker did (in which case they can change the RST anyway). This is the reason I caution about _USE_ of the information, e.g., used for diagnostics only. > What I'm saying is that you only want to turn them on when you are actively > debugging something. Until then, leave them off. There is no need to provide > extra tools to the intruders out there. If it's turned off by default, it may be impossible to debug. I don't always have control over both ends. Joe From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 22:10:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08872 for ; Thu, 17 Aug 2000 22:10:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA18360 for tcp-impl-outgoing; Thu, 17 Aug 2000 20:31:34 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA18347 for ; Thu, 17 Aug 2000 20:31:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA04688; Thu, 17 Aug 2000 20:31:31 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004656; Thu, 17 Aug 00 20:31:07 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA09813; Thu, 17 Aug 2000 17:30:59 -0700 (PDT) Message-ID: <399C83B7.C3E93172@isi.edu> Date: Thu, 17 Aug 2000 17:30:47 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ignacio Goyret CC: Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov Subject: Re: keep RST data nonstandardized for the future! References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> <3.0.5.32.20000817163936.0129e7d0@scamp.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Ignacio Goyret wrote: > > >> > > >> >Only if they're trying to hack your statistics or debugging. > >> >I don't think (pls correct me if this is not the case) that > >> >anyone is proposing different receiver actions based on these > >> >codes; it's just for diagnoses, right? > >> > >> Any information shot back to the sender of a SYN is potential information > >> for a hacker. > > > >Yes! A SYN/ACK is info, the window size is info, etc. > > > >How does this _add_ compromises, is the question... > > The info you listed is non-critical. > > What I meant were the specific codes that have been suggested, such as > "application abort", "bad precedence", "bad security", "low memory", etc. > This type of information is quite interesting for someone trying to do > damage. All he would need to do is repeat the same SYN ad nauseum, and > if he keeps getting "application abort", he is well on his way to crash > your server. Is this compromise enough? Any response means he is succeeding. > Responding with "bad precedence" or "bad security" is synonymous with inviting > him to try a few other values. This _adds_ compromise. Bad precedence just means subsequent packets didn't match the precedence bits. We already know that they can be changed, and sending two packets with different values is sufficient to guarantee a crashed connection in that case. This isn't particularly interesting. Bad security makes no sense; TCP has no security (SSL does, so does IPSEC, but then _THEY_ should carry that info, or not. not TCP :-) It'd be inappropriate to send a RST in response to failed SYN authentication (to counter DOS attacks); silence is the best response there anyway. > A simple empty RST doesn't give him any of this information so he doesn't know > if you are just not listening on that port or that you rejected his attempt. No. He knows you're listening, and that you've responded. Otherwise, you'd have to have been spamming the world with RSTs. > He can't use the information of why you rejected a particular connection attempt > against you because he doesn't know it. Adding a code to the RST provides this > attacker with the information he needs to fine-tune his attack to bring your > server down. There is no new information here that is useful. So he tries again. He can do that now. The RST has to have information that CHANGES how he attacks you; there isn't enough info (at least in my view of what's included) to do that. > >If you're that worried about hackers, use IPSEC. > > Regarding IPSEC, remember that there are many reasons to use TCP _without_ IPSEC, > a web server is a good example. Web servers can use IPSEC for authentication. A web server wouldn't get too many RSTs in response to SYNs, because they typically answer (not initiate) connections. Sure, it could get RSTs in response to SYN/ACKs, but it can do that now. Joe From owner-tcp-impl@lerc.nasa.gov Thu Aug 17 23:14:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10281 for ; Thu, 17 Aug 2000 23:14:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA21547 for tcp-impl-outgoing; Thu, 17 Aug 2000 21:29:18 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA21537 for ; Thu, 17 Aug 2000 21:29:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA12656; Thu, 17 Aug 2000 21:29:15 -0400 Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012614; Thu, 17 Aug 00 21:28:47 -0400 Received: from russet.ascend.com (h-c6045c34.ascend.com [198.4.92.52]) by drawbridge.ascend.com (8.9.1a/8.9.1) with ESMTP id SAA00288; Thu, 17 Aug 2000 18:21:14 -0700 (PDT) Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id SAA07859; Thu, 17 Aug 2000 18:28:16 -0700 (PDT) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [135.140.53.42]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id SAA13224; Thu, 17 Aug 2000 18:28:16 -0700 (PDT) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id SAA06434; Thu, 17 Aug 2000 18:28:15 -0700 (PDT) Message-Id: <3.0.5.32.20000817175504.009e94b0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 17 Aug 2000 17:55:04 -0700 To: Joe Touch From: Ignacio Goyret Subject: Re: keep RST data nonstandardized for the future! Cc: Ignacio Goyret , Bernie Volz , "'Ian Heavens'" , "David L. Nicol" , tcp-impl@grc.nasa.gov In-Reply-To: <399C83B7.C3E93172@isi.edu> References: <3.0.5.32.20000801190155.03ef77b0@scamp.eng.ascend.com> <3.0.5.32.20000817152442.01258dd0@scamp.eng.ascend.com> <3.0.5.32.20000817163936.0129e7d0@scamp.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk At 05:30 PM 8/17/00 -0700, Joe Touch wrote: >> >> What I meant were the specific codes that have been suggested, such as >> "application abort", "bad precedence", "bad security", "low memory", etc. >> This type of information is quite interesting for someone trying to do >> damage. All he would need to do is repeat the same SYN ad nauseum, and >> if he keeps getting "application abort", he is well on his way to crash >> your server. Is this compromise enough? > >Any response means he is succeeding. Not necessarily. Simple responses that don't tell him the failure reason prevents him to tailor his attack. >> Responding with "bad precedence" or "bad security" is synonymous with inviting >> him to try a few other values. This _adds_ compromise. > >Bad precedence just means subsequent packets didn't match the precedence >bits. We already know that they can be changed, and sending two packets >with different values is sufficient to guarantee a crashed connection in >that case. This isn't particularly interesting. > >Bad security makes no sense; TCP has no security (SSL does, so does >IPSEC, but then _THEY_ should carry that info, or not. not TCP :-) It'd >be inappropriate to send a RST in response to failed SYN authentication >(to counter DOS attacks); silence is the best response there anyway. I'm not disagreeing with you. Both of these are examples of bad codes. They are just two examples of the codes that have been suggested on this list by some people. I'm guessing (since I don't know the reason why they were initially suggested) that they were probably inspired by the text in page 67 of rfc793. >> A simple empty RST doesn't give him any of this information so he doesn't know >> if you are just not listening on that port or that you rejected his attempt. > >No. He knows you're listening, and that you've responded. Otherwise, >you'd have to have been spamming the world with RSTs. RFC 793, page 36, 'Reset Generation', item #1 seems to say otherwise. BTW, I use the term "listening" meaning that there is a TCB in the LISTEN state for that port. Is that you what you meant? And why would I (or anybody else for that matter) be spamming the world with RSTs? If I telnet to a port that nobody is listening on, or if inetd fails to spawn the proper daemon, I'll get an RST. >> He can't use the information of why you rejected a particular connection attempt >> against you because he doesn't know it. Adding a code to the RST provides this >> attacker with the information he needs to fine-tune his attack to bring your >> server down. > >There is no new information here that is useful. So he tries again. He >can do that now. The RST has to have information that CHANGES how he >attacks you; there isn't enough info (at least in my view of what's >included) to do that. It all depends on the kind of information that is included and that's where the issue hinges. It has been suggested to add codes indicating "application failure" or "bad security/precedence". These are clearly bad (at least to me) because they can tell him how to make his attack more efficient. When the list of codes is finally compiled, it should be carefully scrutinized to make sure that this attacker is not given golden information. >> >If you're that worried about hackers, use IPSEC. >> >> Regarding IPSEC, remember that there are many reasons to use TCP _without_ IPSEC, >> a web server is a good example. > >Web servers can use IPSEC for authentication. A web server wouldn't get >too many RSTs in response to SYNs, because they typically answer (not >initiate) connections. Sure, it could get RSTs in response to SYN/ACKs, >but it can do that now. Huh? Web servers wouldn't be receiving RSTs: they would be _sending_ RSTs with potentially juicy information. The attacker would be receiving the RSTs, not sending them. That's what makes it easier for him to attack the server. The other way around is not interesting at all. From owner-tcp-impl@lerc.nasa.gov Fri Aug 18 00:39:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11439 for ; Fri, 18 Aug 2000 00:39:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA25378 for tcp-impl-outgoing; Thu, 17 Aug 2000 22:52:06 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA25361 for ; Thu, 17 Aug 2000 22:52:04 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA20731; Thu, 17 Aug 2000 22:52:02 -0400 Received: from mentat.com(192.88.122.129) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020682; Thu, 17 Aug 00 22:51:59 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA16002; Thu, 17 Aug 2000 19:49:50 -0700 (PDT) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id TAA10061; Thu, 17 Aug 2000 19:49:50 -0700 (PDT) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id TAA04067; Thu, 17 Aug 2000 19:50:03 -0700 Date: Thu, 17 Aug 2000 19:50:03 -0700 From: jt@mentat.com (Jerry Toporek) Message-Id: <200008180250.TAA04067@rock.mentat.com> To: touch@ISI.EDU, igoyret@lucent.com Subject: Re: keep RST data nonstandardized for the future! Cc: Volz@ipworks.com, ian@spider.com, david@kasey.umkc.edu, tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > >Bad security makes no sense; TCP has no security (SSL does, so does > >IPSEC, but then _THEY_ should carry that info, or not. not TCP :-) It'd > >be inappropriate to send a RST in response to failed SYN authentication > >(to counter DOS attacks); silence is the best response there anyway. > > I'm not disagreeing with you. Both of these are examples of bad codes. They are > just two examples of the codes that have been suggested on this list by some > people. I'm guessing (since I don't know the reason why they were initially > suggested) that they were probably inspired by the text in page 67 of rfc793. Yes... Yes... That's exactly correct, and I should never have let these appear on the list that I gave to Ian, because to my knowledge these have never really been active. Code was written ten years ago to hypothetically implement the precedence and security checks suggested on page 67 of RFC 793. The code was never actually compiled into anyone's product, and no longer exists. jt From owner-tcp-impl@lerc.nasa.gov Wed Aug 23 04:02:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06138 for ; Wed, 23 Aug 2000 04:02:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA07217 for tcp-impl-outgoing; Wed, 23 Aug 2000 01:33:53 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id BAA07204 for ; Wed, 23 Aug 2000 01:33:51 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id BAA11457; Wed, 23 Aug 2000 01:33:50 -0400 Received: from jindo.cisco.com(171.69.11.73) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011432; Wed, 23 Aug 00 01:33:15 -0400 Received: (from mynam@localhost) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id WAA10059; Tue, 22 Aug 2000 22:33:14 -0700 (PDT) From: Satish Mynam Message-Id: <200008230533.WAA10059@jindo.cisco.com> Subject: Any test programs to test issues in RFC 2525? To: tcp-impl@grc.nasa.gov Date: Tue, 22 Aug 2000 22:33:14 -0700 (PDT) Cc: mynam@cisco.com (Satish Mynam) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was wondering if someone wrote or modified any existing test pograms like ttcp or any test TCP programs to test all/some of the different scenarios of the problems (with the current TCP implementations) as mentioned in RFC 2525? RFC2525 Known TCP Implementation Problems http://andrew2.andrew.cmu.edu/rfc/rfc2525.html Also I was wondering if there is any UNIX based test tool to do some ipv4 TCP protocol conformance testing? Any pointers or URL or info will be highly appreciated. Thank you, Satish From owner-tcp-impl@lerc.nasa.gov Wed Aug 23 04:36:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06334 for ; Wed, 23 Aug 2000 04:36:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA11038 for tcp-impl-outgoing; Wed, 23 Aug 2000 02:46:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA11028 for ; Wed, 23 Aug 2000 02:46:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id CAA16862; Wed, 23 Aug 2000 02:46:13 -0400 Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016820; Wed, 23 Aug 00 02:45:14 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e7N6jDN21132; Tue, 22 Aug 2000 23:45:13 -0700 (PDT) Message-Id: <200008230645.e7N6jDN21132@daffy.ee.lbl.gov> To: Satish Mynam Cc: tcp-impl@grc.nasa.gov Subject: Re: Any test programs to test issues in RFC 2525? In-reply-to: Your message of Tue, 22 Aug 2000 22:33:14 PDT. Date: Tue, 22 Aug 2000 23:45:13 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I was wondering if someone wrote or modified any existing test > pograms like ttcp or any test TCP programs to test all/some of > the different scenarios of the problems (with the current TCP > implementations) as mentioned in RFC 2525? See RFC 2398. Vern From owner-tcp-impl@lerc.nasa.gov Thu Aug 24 20:45:14 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25886 for ; Thu, 24 Aug 2000 20:45:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA08649 for tcp-impl-outgoing; Thu, 24 Aug 2000 18:14:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA08629 for ; Thu, 24 Aug 2000 18:14:14 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA00685; Thu, 24 Aug 2000 18:14:13 -0400 Received: from boron.cs.washington.edu(128.95.2.210) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000620; Thu, 24 Aug 00 18:13:52 -0400 Received: from localhost (ely@localhost) by boron.cs.washington.edu (8.9.3/8.9.3/0.4) with ESMTP id PAA05693; Thu, 24 Aug 2000 15:13:51 -0700 (envelope-from ely@cs.washington.edu) X-Authentication-Warning: boron.cs.washington.edu: ely owned process doing -bs Date: Thu, 24 Aug 2000 15:13:51 -0700 (PDT) From: David Ely To: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov Subject: Alpine: a new protocol development tool Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Over the past few months I've been working with David Wetherall and Stefan Savage on a tool that allows an unaltered kernel networking stack to run in a user-level library. It's called Alpine (Application-Level Protocol Infrastructure for Network Experimentation). Probably the most unique feature of this package is that an alternate network stack can be used and/or debugged without modifying either the kernel or any application binaries. Developing protocols at user-level is much easier than traditional kernel develop because source-level debugging is available and no reboots are required between revisions. It has turned out to be a useful tool for us, so I thought some of you might also benefit from using it. It's currently only available for FreeBSD 3.x on Intel x86 platforms. This is an alpha release, and there are bound to be things that don't work perfectly. Please email me if you run into any problems. I will do my best to correct them. Check out http://alpine.cs.washington.edu/ for more information. Cheers, David P.S. I will be at SIGCOMM next week if you're interested in talking to me about Alpine. From owner-tcp-impl@lerc.nasa.gov Thu Aug 24 21:05:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26085 for ; Thu, 24 Aug 2000 21:05:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11210 for tcp-impl-outgoing; Thu, 24 Aug 2000 18:54:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA11200 for ; Thu, 24 Aug 2000 18:54:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA07424; Thu, 24 Aug 2000 18:54:21 -0400 Received: from tnt.isi.edu(128.9.128.128) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007399; Thu, 24 Aug 00 18:54:14 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22982; Thu, 24 Aug 2000 15:54:12 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA23709; Thu, 24 Aug 2000 22:54:12 GMT Date: Thu, 24 Aug 2000 22:54:12 GMT Message-Id: <200008242254.WAA23709@gra.isi.edu> To: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov, ely@cs.washington.edu Subject: Re: Alpine: a new protocol development tool X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> *> Over the past few months I've been working with David Wetherall and *> Stefan Savage on a tool that allows an unaltered kernel networking *> stack to run in a user-level library. It's called Alpine *> (Application-Level Protocol Infrastructure for Network *> Experimentation). *> *> Probably the most unique feature of this package is that an alternate *> network stack can be used and/or debugged without modifying either the *> kernel or any application binaries. Developing protocols at *> user-level is much easier than traditional kernel develop because *> source-level debugging is available and no reboots are required *> between revisions. *> A very useful technique. There is NO WAY I could have ever developed and debugged T/TCP without doing this for BSD Unix. Bob Brade