FW: 99-233r2 - SAM-2 TASK SET FULL Clarifications

Peterson, Gary gpeterson at clariion.com
Wed Oct 13 06:39:23 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "Peterson, Gary" <gpeterson at clariion.com>
*
I agreee with Dan - Although a BUSY respsonse is a catch-all for
many situations, it does free the initiator or retry at his
convenience (i.e. after a 'short' delay).
 
The TASK SET FULL should be used when the target is unable to
accept the command from that initator at that time, where another
initiator might be able to get a command through. I would think
the initiator would then wait for a current outstanding command 
to return before attempting it again.

Also, I don't follow Tom's comment of noticable overhead -- returning
either status is equally as fast, isn't it?

----------------------------------------------------------------------
Gary S. Peterson                     
CLARiiON Storage Systems (An EMC Business Unit)
Phone: 508/480-7150	FAX: 508/480-7913
EMail: gpeterson at clariion.com



-----Original Message-----
From: Coughlan, Tom [mailto:Tom.Coughlan at COMPAQ.com] 
Sent: Wednesday, October 13, 1999 8:51 AM
To: Lewis, Dan; 't10 at t10.org'
Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications


* From the T10 Reflector (t10 at t10.org), posted by:
* "Coughlan, Tom" <Tom.Coughlan at compaq.com>
*
Dan,

I did not intend to equate Task Set Full with Busy.  (I was saying that
generating either one can require a noticeable amount of overhead in the FC
target.)

I don't think there is wide-spread agreement with your view that the
initiator should delay after receiving Busy status.  The reason is because
Busy is something of a catch-all status that includes conditions not related
to congestion.  Examples include contingent allegiance with another
initiator, or the device is busy on another port.  The initiator can
justifiably re-issue the command after a very short delay in these cases.

Given the current non-specificity of the standard, I think we have to assume
that initiators interpret Busy as "retry with little or no delay", and Task
Set Full as "retry after a delay that is adequate for the target to clear
the congestion".  Eventually I think the standard should specify the Task
Set Full backoff policy, and the policy should also require the initiator to
reduce the number of commands outstanding to the logical unit, and implement
a gradual ramp-up.

Tom

-----Original Message-----
From: Lewis, Dan [mailto:DLewis at clariion.com]
Sent: Tuesday, October 12, 1999 6:55 PM
To: Coughlan, Tom; 't10 at t10.org'
Cc: 'ralphoweber at CompuServe.COM'; Elliott, Robert (Hou)
Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications


* From the T10 Reflector (t10 at t10.org), posted by:
* "Lewis, Dan" <DLewis at clariion.com>
*
Tom, regarding this new restriction, I don't believe it weakens the only
method we have for congestion control because Task Set Full is not the
*only* method.  Somewhere in your message, you casually equate Task Set Full
with  Busy.  I think there is a profound difference.  

The way I see it, an initiator that receives Busy status should recognize
this to mean that the target is congested AND should re-issue the operation
after some (arbitrary) delay.  But when an initiator receives Task Set Full,
that means *that initiator* has reached a water mark that the target does
not want it to exceed.  This judgement by the target can vary from one
implementation to another, but the initiator can be sure that re-issuing the
operation after one of it's tasks has completed is the right policy.

-Dan Lewis-


> -----Original Message-----
> From: Coughlan, Tom [mailto:Tom.Coughlan at COMPAQ.com]
> Sent: Tuesday, October 12, 1999 5:07 PM
> To: 't10 at t10.org'
> Cc: 'ralphoweber at CompuServe.COM'; Elliott, Robert (Hou)
> Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Coughlan, Tom" <Tom.Coughlan at compaq.com>
> *
> The latest revision of 99-233 creates a new restriction on 
> logical units,
> allowing them to return Task Set Full to an initiator only if there is
> already a task in the task set from that initiator. I believe this
> restriction is a bad idea, because it weakens the only method 
> we have for
> congestion control, and congestion control is much more 
> important for the
> operation of large SANs than the goals of this proposal.
> 
> I think there is a consensus that the logical unit sends Task Set Full
> status to indicate that it is congested, and that the receipt of any
> additional work while it is in this state will be 
> counter-productive.  If
> initiators continue to send task requests, the logical unit may become
> consumed with returning failure status, and will be unable to make any
> progress on its backlog. I've been told that some FC 
> implementations are
> particularly prone to this scenario, because the number of 
> open exchanges
> they support is fairly small, and the amount of processing required to
> return a Task Set Full (or Busy) is fairly high.
> 
> We need two things to be able to control congestion:  1) the 
> logical unit
> must return Task Set Full to any initiator that issues a task 
> while the
> logical unit is congested, and 2) all initiators must observe 
> an adequate
> backoff when they receive the Task Set Full status.  If we 
> restrict the
> logical unit's ability to return Task Set Full, then we are 
> likely to create
> scenarios where congestion can persist for extended periods of time,
> resulting in low efficiency and the possibility of command timeouts.
> 
> A second problem with the proposal is that it can be very difficult to
> implement in some designs.  In the FC example described 
> above, for example,
> the congestion is in the target, not the logical unit.  With 
> the proposed
> behavior, the congested target must conditionalize its 
> behavior on the state
> of the logical unit's task set. This is awkward to implement 
> and consumes
> scarce processing time. 
> 
> The original goal of proposal 99-233 was to prevent the Task 
> Set Full status
> from being returned to an initiator that does not implement 
> tagged queuing.
> Along the way, this proposal picked up a second goal, namely, 
> to encourage
> initiators to implement a particular backoff policy. The 
> favored policy is
> "if you get a Task Set Full then wait for at least one of 
> your tasks to
> complete before issuing a new task". 
> 
> I do not agree with the original goal, because I think that managing
> congestion is much more important than allowing initiator 
> implementations
> that do not understand Task Set Full.  As I have said, this 
> is fundamental
> to large multi-initiator SANs.
> 
> I do not agree with the second goal, because 1) I have not 
> seen evidence
> that this backoff policy is the best for controlling congestion while
> maintaining fairness, 2) any initiator worth its salt already 
> knows how many
> tasks it has issued to the logical unit, 3) no initiator that 
> will be used
> in the open market can rely on a restriction that has been so 
> recently added
> to the standard, and 4)the difficulty of implementing this in 
> some initiator
> designs is greater than the benefit gained.  
> 
> I recommend a change to the original text (contained in the attached
> message)  as follows:
> 
> TASK SET FULL.  This status shall be implemented if the logical unit
> supports the creation of tagged tasks (see 4.9).  This status shall
> be returned when the logical unit receives a task and does not
> have enough resources to enter the task in the task set. The logical 
> unit shall return this status regardless of whether the task 
> is tagged or untagged.  It is strongly recommended that the initiator 
> perform a delay before issuing or re-issuing a task to this 
> logical unit.  
> 
> Tom Coughlan
> OpenVMS SCSI & FC Project Leader
> Compaq Computer Corporation
> 110 Spit Brook Rd. ZKO3-4/U14
> Nashua, New Hampshire 03062-2698
> Phone:	603-884-0933 
> Fax.:		603-884-0189
> Mail: 	tom.coughlan at compaq.com
> 
> -----Original Message-----
> From:	Ralph Weber [SMTP:ralphoweber at CompuServe.COM]
> Sent:	Sunday, September 19, 1999 2:58 PM
> To:	T10, Reflector
> Subject:	99-233r2 - SAM-2 TASK SET FULL Clarifications
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <ralphoweber at compuserve.com>
> *
> A proposal for consideration at the November meetings has
> been placed on the T10 FTP site as:
> 
> < ftp://ftp.t10.org/t10/document.99/99-233r2.pdf >
> 
> The text of the proposal is as follows. Underline and strikeout
> formatting has been removed for ASCII text compatibility.  See the
> PDF for a fully formatted presentation of the proposal.
> 
> Doc:  T10/99-233r2
> Date: 17 September 1999
> To:   T10 Technical Committee
> From: Ralph Weber, LSI Logic Alternate Member of T10
> Subj: SAM-2 TASK SET FULL Clarifications
> 
> During the May General SCSI Working Group meeting I was asked to
> investigate the SAM-2 definition of the TASK SET FULL status.  The
> results of this investigation and proposed changes were reviewed and
> enhanced by the July Working Group meeting.
> 
> After reviewing the proposal twice at the September General SCSI
> Working Group meeting, I believe that the changes shown with
> strikeouts and underlines below may be acceptable.  Please review and
> comment, if sufficient comments are received before the November
> meeting, I'll revise the proposal again.  Also, discussion of 99-232
> has been removed since that proposal has been approved.
> 
> The problem is that the definition of the TASK SET FULL status (5.2)
> does not state whether it can be returned for untagged tasks.  The
> following proposed changes reflect the majority sentiment of the July
> Working Group.
> 
> Old text:
> 
> TASK SET FULL.  This status shall be implemented if the logical unit
> supports the creation of tagged tasks (see 4.9).  This status shall
> be returned when the logical unit receives a command and does not
> have enough resources to enter the associated task in the task set.
> 
> New text minus strikeouts and underlines:
> 
> TASK SET FULL.  This status shall be implemented if the logical unit
> supports the creation of tagged tasks (see 4.9).  This status shall
> not be implemented if the logical unit does not support the creation
> of tagged tasks.  When the logical unit has at least one tagged task
> in the task set from an initiator and that same initiator sends a
> task that cannot be entered in the task set due to a lack of task set
> resources, TASK SET FULL shall be returned, otherwise BUSY shall be
> returned.
> 
> Note: Receipt of a second untagged task from the same initiator is an
> error case covered in 5.6.2.
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org






More information about the T10 mailing list