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

Lewis, Dan DLewis at clariion.com
Wed Oct 13 06:46:36 PDT 1999


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

Your view of Task Set Full vs. Busy is opposite of mine.  I think your
suggested back off policy for Task Set Full (reduce the number of commands
outstanding to the logical unit) would be more appropriate with my retry
policy (re-issuing after one of it's tasks has completed).

SAM-2 does specify a policy for Busy (issue command again at a later time).
I think the standard should specify a policy for Task Set Full so as to
avoid misinterpretation. 

I won't speak for the rest of the industry, but encourage others associated
with T10 to chime in.  

- Dan -

> -----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
> 
> 
> 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






More information about the T10 mailing list