Subject: [tcpm] regarding draft-kitamura-tcp-sharp-close

From: Joe Touch <[email-masked]>
Date: Mon, 16 Nov 2015 14:19:24 -0800

Hi, all,

This doc was never posted to this list (although it was presented at
Yokohama), so I figured I'd start a thread with some feedback (that IMO
probably should have happened online before the meeting).

Lars already pointed out a paper that Ted Faber and I wrote on this
issue at Infocom 1999. Here's a link to that:
http://www.isi.edu/touch/pubs/infocomm99/

Some other info. below.

Joe

------

	- I don't think the doc is correct on the purpose of SO_LINGER
	See: http://developerweb.net/viewtopic.php?id=2982

	SO_LINGER focuses on half-closed connections, and how long to
	wait to deliver remaining information.TIME-WAIT is a state
	that occurs only after both sides have closed the connection.

	- TIME-WAIT's primary purpose is to avoid the impact of old
	packets from a previous connection corrupting the data
	of a new connection.

		I.e., it's primary purpose is to ensure that *data*
		packets from an old connection are not accepted
		by a new connection that reuses the port numbers.

		The only connection resource that isn't released
		is the socket pair - i.e., the pair of IP addresses
		and port numbers that uniquely identify the connection.
		TIME-WAIT need not consume other resources.

		TIME-WAIT has nothing to do with resending FINs. It
		can be entered only when the closing three-way FIN
		handshake completes.

	- "sharp close" appears to reinvent simultaneous close

		However, this doesn't avoid TIME-WAIT; in current
		TCP, it would require that both sides enter TIME-WAIT.

		The issue is that the port numbers can't be reused
		while there might be old data packets that could still
		arrive (e.g., duplicates from the previous connection
		that are floating around). TCP requires that these old
		packets be discarded when a new connection starts.

		Normally this would happen by the use of the ISN, but
		a quick enough connection might end up wrapping the
		sequence numbers around fast enough that the old data
		could end up in the valid incoming data window.

		As per RFC 6191, timestamps can be used to avoid this
		problem as well.

	- it's not clear how both sides would know to issue the FINs
	concurrently
		i.e., this cannot be achieved by user-level operations
		unless the application coordinates the close in-band;
		even then, TCP might exchange the FIN/FIN-ACK/ACK before
		the other side has a chance to start its FIN anyway.

	- we also already have other ways to deal with TIMEWAIT,
		e.g., RFC 6191, using lower TIME-WAIT timers because
		of known properties of port reuse or the willingness
		to "take a risk" on old data coming in late

----