Subject: [tcpm] RST drop and session closure

From: "Vishal Study" <[email-masked]>
Date: Sat, 24 Mar 2007 04:24:00 -0700

Hi:

Need some inputs on following scenario:

Scenario:
- Host A and B have a TCP session established.
- The data traffic is one-way from A to B.
- Host A sends RST to B.
- RST gets dropped somewhere in the path.
- Host A has closed and freed resources tied to TCP session on its
end. It won't transmit RST.
- Host B doesn't know the other end is gone

Since the traffic is one way, B will never know that its peer A has
closed the session.

How does B recover from this?
Is Keepalive the only option that could let B know that its peer has
closed the session?

Thanks,
Vishal.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Mar 2007 10:21:19 -0300

>Is Keepalive the only option that could let B know that its peer has

In the scenario you describe, yes.

If B happens to be a server (i.e., it was the side that performed the 
passive open), then if some other client tries to establish a new 
connection with the same four-tuple, the half open connection would 
be discovered, too. (The client's SYN would likely trigger an ACK 
from B, which would elicit a RST from the client. This RST would 
signal B that the connection was aborted by the other end).

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Mar 2007 11:19:20 -0700

> - Host B doesn't know the other end is gone

B doesn't care until B tries to send data to A. TCP doesn't - as a rule
- clean up state UNTIL it interferes with other things.

> Is Keepalive the only option that could let B know that its peer has

If B cares to know within a certain timeframe, even if no data is sent,
then B can use keepalive.

Otherwise, B will find out when it sends data; A will return with a RST
at that point, since the connection is gone.

Joe

---

From: David Borman <[email-masked]>
Date: Mon, 26 Mar 2007 09:28:45 -0500

B would care if it was expecting data from A and was hung on a read.   
But that doesn't change anything, B would still need to have some  
mechanism for discovering that A had gone away; in addition to  
sending a keep-alive, two other methods could be generating data  
traffic (probably not if you are hung in the read), or having a user- 
level timeout that aborts the read attempt.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Mar 2007 07:46:30 -0700

> B would care if it was expecting data from A and was hung on a read. 

B's TCP doesn't care about whether a read is pending or not; it doesn't
behave differently. The app at B would care, but, as you note, would
either timeout (if configured appropriately) or not. Neither behavior is
dictated by this scenario, since B can't tell the difference between A
sending a lost RST and just not having any data to send.

> mechanism for discovering that A had gone away; in addition to sending a
> keep-alive, two other methods could be generating data traffic (probably
> not if you are hung in the read), or having a user-level timeout that
> aborts the read attempt.

It seems like you'd need either the keep-alive at the TCP layer, or the
equivalent at the app layer. The latter would require both generating
constant background traffic AND having timeouts to abort reads. In that
case, though, you'd be using application semantics (expectation of a
continuous stream of sent data) to provide meaning to the timeout.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment