Re: Frequency of RST terminated connections (fwd)

[Marc Slemko <ma...@znep.com>]

Wondering if the connection being terminated by a RST instead of a more
normal FIN may be part of the lingering_close() problems?

Need to think.

---------- Forwarded message ----------
Date: Tue, 21 Jan 1997 19:52 -0500
From: Bernie Volz <VO...@PROCESS.COM>
To: vern@ee.lbl.gov, END2END-INTEREST@ISI.EDU
Subject: Re: Frequency of RST terminated connections

>Ah!, an excellent point.  I took a closer look at the trace data and found
>that the prominent pattern is not the client sending a RST out of the blue
>to terminate the connection - that only happened for 15% of connections
>terminated by a client RST.  The other 85% looked like:
>
>	server --FIN--> client
>	[lengthy pause]
>	client --RST--> server
>
>The [lengthy pause] had a median duration of 200 msec - not any sort of delay
>timer spike, though, the distribution is smooth all the way.  (I only evaluated
>the duration for those clients local to the tracing point, so the delay is
>all in the application, not in the network).  Pretty suggestive of an
>application doing a bunch of work after receiving all of the data from the
>server, and then just blowing away the connection so it doesn't need to keep
>any additional state around.
>
>So most of the RST terminations look like they're due to the TCP implementation
>itself and not user connection aborts.
>

No. I bet if you looked more closely at this (especially for Web
traffic), you'll find that the Netscape browser sends the RST on purpose
(this is true of the Windows 95/NT version). I think Netscape realized
that this was more efficient and they do this all of the time. Perhaps
someone from Netscape can comment? Note that the Netscape browser
doesn't do this on all implementations since it can't do it on some
platforms.

I don't know whether Microsoft's IE does this as well.

So, it may well be the APPLICATION doing this; not the TCP
implementation itself.

- Bernie Volz
  Process Software Corporation



---------- Forwarded message ----------
Date: Tue, 21 Jan 1997 15:11:54 PST
From: Vern Paxson <ve...@ee.lbl.gov>
To: Greg Minshall <mi...@ipsilon.com>
Cc: Ian Heavens <ih...@fore.co.uk>, ses@tipper.oit.unc.edu,
    end2end-interest@ISI.EDU
Subject: Re: Frequency of RST terminated connections 

> I *suspect* that one of the issues here is in some TCP's (maybe on PCs, say), 
> the "kernel" doesn't keep hold of TIME_WAIT, etc., connections by itself: it 
> forces the application to hang around till all of the state is out of the 
> kernel.  Thus, if the application wants to "get on with life", it needs to do 
> a RST rather than a close.

Ah!, an excellent point.  I took a closer look at the trace data and found
that the prominent pattern is not the client sending a RST out of the blue
to terminate the connection - that only happened for 15% of connections
terminated by a client RST.  The other 85% looked like:

	server --FIN--> client
	[lengthy pause]
	client --RST--> server

The [lengthy pause] had a median duration of 200 msec - not any sort of delay
timer spike, though, the distribution is smooth all the way.  (I only evaluated
the duration for those clients local to the tracing point, so the delay is
all in the application, not in the network).  Pretty suggestive of an
application doing a bunch of work after receiving all of the data from the
server, and then just blowing away the connection so it doesn't need to keep
any additional state around.

So most of the RST terminations look like they're due to the TCP implementation
itself and not user connection aborts.

		Vern



---------- Forwarded message ----------
Date: Tue, 21 Jan 1997 12:47:46 -0800
From: Greg Minshall <mi...@ipsilon.com>
To: Vern Paxson <ve...@ee.lbl.gov>
Cc: Ian Heavens <ih...@fore.co.uk>, ses@tipper.oit.unc.edu,
    end2end-interest@ISI.EDU
Subject: Re: Frequency of RST terminated connections 

Vern, et al,

> Yep, RST termination of HTTP connections is very widespread.  Poking
> through logs of last Thursday's HTTP traffic into and out of LBNL, out of
> 342,693 established connections, 40% were terminated by the client sending
> a RST, instead of a FIN handshake.

I *suspect* that one of the issues here is in some TCP's (maybe on PCs, say), 
the "kernel" doesn't keep hold of TIME_WAIT, etc., connections by itself: it 
forces the application to hang around till all of the state is out of the 
kernel.  Thus, if the application wants to "get on with life", it needs to do 
a RST rather than a close.  But, maybe people currently involved in PC-type 
TCPs may have better information on this.

Greg



---------- Forwarded message ----------
Date: Tue, 21 Jan 1997 12:10:54 PST
From: Vern Paxson <ve...@ee.lbl.gov>
To: Ian Heavens <ih...@fore.co.uk>
Cc: ses@tipper.oit.unc.edu, end2end-interest@ISI.EDU
Subject: Re: Frequency of RST terminated connections

> Are there current statistics on this?  I can only find HTTP logs at the 
> Internet Traffic Archive, or older TCP logs.

Yep, RST termination of HTTP connections is very widespread.  Poking
through logs of last Thursday's HTTP traffic into and out of LBNL, out of
342,693 established connections, 40% were terminated by the client sending
a RST, instead of a FIN handshake.

		Vern