Implementer's Guide - Task Management Issue

To make sure we actually have some content to talk about in
this WG Last Call, I'm going to reraise an issue that came
up earlier on the mailing list, but (as far as I can recall)
never got resolved.  This is done with my WG chair hat OFF,
and it is a proposal for further discussion.

Section 4.1.3 changes task management, and is a non-transparent
change - it requires negotiating a new key so that both sides
agree that they support the change as it uses a round-trip
exchange of a new message (AsyncEvent 5) between initiator and
target to abort in-progress data transfers rather than completing
them.  Absent this message, the target expects the initiator(s)
to complete all in-progress transfers, and is entitled to be
unhappy or worse if that doesn't happen.

For task management functions that affect tasks from more than
one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
RESET)  Section 4.1.3 also allows the task management function
(TMF) to complete while the in-progress data transfers are still
being dealt with, which has the useful effect of avoiding a
situation in which an uncooperative initiator can stall the
progress of a TMF sent by another initiator.  This property is
useful even if the new key is not negotiated (and hence the
AsyncEvent 5 message is not used for fast abort of data transfers)
although I think the target behavior is subtly different between
the initiator that sent the TMF and other initiators in this case:
- For the TMF sender, the target must wait for all outstanding
	transfers to complete before completing the TMF, otherwise
	the TMF completion comes back too early for an unmodified
	initiator.
- For the other initiators, the data transfers can be immediately
	redirected to bit buckets so the TMF can be completed without
	waits beyond that for the TMF sender.  This is approximately
	what is described in the Implementation Note at the end of
	Section 4.1.3, although that note may have been intended to
	be iSER-specific - if so, this is a proposal to apply it to
	iSCSI without the RDMA extensions.

High Availability clustering environments in which TMFs are being
used to determine cluster membership (yes, there's code out there
that does this, even though everyone should be using PERSISTENT
RESERVE) are a specific situation where this helps, as having to
wait for a dead initiator to expire (the TCP connection(s) have
to timeout and get torn down) slows down cluster recovery from a
failure.  This change in target behavior (to complete a TMF faster
if other initiators don't cooperate) should be transparent to
RFC 3720-compliant initiators, but RFC 3720 has to be modified
in order to allow it; the Implementer's Guide is a vehicle that
can make that modification.

This is proposed for further discussion.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips