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