< draft-ietf-tcpm-persist-06.txt		draft-ietf-tcpm-persist-07.txt >
	TCP Maintenance and Minor Extensions M. Bashyam		TCP Maintenance and Minor Extensions M. Bashyam
	Working Group Ocarina Networks, Inc		Working Group Ocarina Networks, Inc
	Internet-Draft M. Jethanandani		Internet-Draft M. Jethanandani
	Intended status: Informational A. Ramaiah		Intended status: Informational A. Ramaiah
	Expires: March 12, 2012 Cisco		Expires: March 18, 2012 Cisco
	September 9, 2011		September 15, 2011
	Clarification of sender behavior in persist condition.		TCP sender clarification for Persist Condition.
	draft-ietf-tcpm-persist-06.txt		draft-ietf-tcpm-persist-07.txt
	Abstract		Abstract
	This document clarifies the Zero Window Probes (ZWP) described in		This document clarifies the Zero Window Probes (ZWP) described in
	Requirements for Internet Hosts [RFC1122]. In particular, it		Requirements for Internet Hosts [RFC1122]. In particular, it
	clarifies the actions that can be taken on connections which are		clarifies the actions that can be taken on connections which are
	experiencing the ZWP condition. This draft clarifies what has been		experiencing the ZWP condition. This draft clarifies what has been
	till now a misinterpretation of the standard as specified in RFC 1122		till now a misinterpretation of the standard as specified in RFC 1122
	[RFC1122] rather than making a change to the standard.		[RFC1122] rather than making a change to the standard.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 12, 2012.		This Internet-Draft will expire on March 18, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says:		Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says:
	"A TCP MAY keep its offered receive window closed indefinitely.		"A TCP MAY keep its offered receive window closed indefinitely.
	As long as the receiving TCP continues to send acknowledgments in		As long as the receiving TCP continues to send acknowledgments in
	response to the probe segments, the sending TCP MUST allow the		response to the probe segments, the sending TCP MUST allow the
	connection to stay open."		connection to stay open.
	DISCUSSION:		DISCUSSION:
	It is extremely important to remember that ACK (acknowledgment)		It is extremely important to remember that ACK (acknowledgment)
	segments that contain no data are not reliably transmitted by		segments that contain no data are not reliably transmitted by
	TCP.		TCP."
	Therefore zero window probing needs to be supported to prevent a		Therefore zero window probing needs to be supported to prevent a
	connection from hanging forever if ACK segments that re-opens the		connection from hanging forever if ACK segments that re-opens the
	window is lost. The condition where the sender goes into the Zero		window is lost. The condition where the sender goes into the Zero
	Window Probe (ZWP) mode is typically known as the 'persist		Window Probe (ZWP) mode is typically known as the 'persist
	condition'.		condition'.
	This guidance is not intended to preclude resource management by the		This guidance is not intended to preclude resource management by the
	operating system or application, which may request connections to be		operating system or application, which may request connections to be
	aborted regardless of them being in the persist condition, and the		aborted regardless of them being in the persist condition, and the
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	which the printer runs out of paper and is waiting for the user		which the printer runs out of paper and is waiting for the user
	intervention to reload the paper tray. The printer may not be		intervention to reload the paper tray. The printer may not be
	reading data from the printing application during this time.		reading data from the printing application during this time.
	Although this may result in a prolonged ZWP state, it would be		Although this may result in a prolonged ZWP state, it would be
	premature for TCP to take action on its own and close the printer		premature for TCP to take action on its own and close the printer
	connecting merely due to its lack of progress. Once the printer's		connecting merely due to its lack of progress. Once the printer's
	paper tray is reloaded (which may be minutes, hours, or days later),		paper tray is reloaded (which may be minutes, hours, or days later),
	the print job needs to be able to continue uninterrupted over the		the print job needs to be able to continue uninterrupted over the
	same TCP connection.		same TCP connection.
	Systems that misinterpret the above section of Requirements for		However, systems that misinterpret the above section of Requirements
	Internet Hosts [RFC1122] may fall victim to DoS attacks, by not		for Internet Hosts [RFC1122] may fall victim to DoS attacks, by not
	supporting sufficient mechanisms to allow release of system resources		supporting sufficient mechanisms to allow release of system resources
	tied up by connections in the persist condition during times of		tied up by connections in the persist condition during times of
	resource exhaustion. For example, if we take the case of a busy		resource exhaustion. For example, if we take the case of a busy
	server where multiple (attacker) clients can advertise a zero window		server where multiple (attacker) clients can advertise a zero window
	forever (by reliably acknowledging the ZWPs). This could eventually		forever (by reliably acknowledging the ZWPs). This could eventually
	lead to the resource exhaustion in the server system. In such cases		lead to the resource exhaustion in the server system. In such cases
	the application or operating system would need to take appropriate		the application or operating system would need to take appropriate
	action on the TCP connection to reclaim their resources and continue		action on the TCP connection to reclaim their resources and continue
	to maintain legitimate connections.		to maintain legitimate connections.
End of changes. 6 change blocks.
	9 lines changed or deleted		9 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/