Re: storage-device QoS [was: IPS Draft Charter update]

["Mark A. Carlson" <mark.carlson@central.sun.com>]

While adding storage QoS to the SCSI mode pages would have the
advantage of working both with IP and FC transports, I would
hope that we could leverage some of the network QoS that has
already been done in the Policy Framework group with models.

This is what I hope is in scope for our charter, even though
we obviously wouldn't do it in the first deliverable.

-- mark

Howard Hall wrote:
> 
> Mike,
> 
> Focusing on the interfaces to communicate QoS to the iSCSI layer sounds like
> a good first step to me.  I agree that attributes of the fabric extended
> through the network is a desirable addition to those I listed. It is also
> clear the TOS or TClass fields will not cut it in the more complicated (and
> desirable) QoS concepts.
> 
> -Howard
> Howard Hall
> Pirus Networks
> www.pirus.com
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Michael Krause
> Sent: Saturday, July 22, 2000 9:33 AM
> To: Hall, Howard
> Cc: ips@ece.cmu.edu
> Subject: Re: storage-device QoS [was: IPS Draft Charter update]
> 
> At 11:04 PM 7/21/00 -0400, Howard Hall wrote:
> >We too have been looking into this issue, but have come to a different
> >conclusion.   The propagation of QoS information through SCSI ignores the
> >transport protocol, the network layer, all the IP aware devices and QoS
> >magic that may allow for the reduction of latency that certain
> >applications demand.    I can envision lots of iSCSI aware devices out
> >there that don't care about the encapsulated protocol, but sure may want
> >to get involved at the network/transport layer and do their value add.
> >These devices may know far better than the SCSI layer queue depths,
> >windows, session loading, lan/wan bandwidth utilization, etc.  I can also
> >envision initiator application software that is iSCSI aware.  These
> >applications may know far better than anyone the block content and its
> >significance.
> >
> >The scope of QoS inclusions could be as simple as a guideline for the
> >setting of TOS bits or a high priority channel, or the ability to push
> >real flow control and apply end-to-end priority queuing between the target
> >and the initiator through the iSCSI protocol.  We won't know unless we
> >explore it.
> 
> For many of the items mentioned, it will take some time to develop the
> modeling and prototypes to validate the concepts proposed by a given QoS
> policy.  If QoS needs to be addressed within the first version, then
> perhaps the focus should be on the interfaces to communicate QoS to the
> iSCSI layer.  This would allow designs to include QoS information in a
> standard way while not being locked into a model that may not be suitable
> for all of the implementations envisioned - perhaps being too simplistic or
> overly complex.  As such the actual QoS policies would be better
> implemented within a separate specification while the QoS interface to
> iSCSI is defined within this spec.
> 
> Note: You might want to expand the concept of QoS to also include
> attributes of the fabric that can make a difference in these policies
> beyond what you had listed, e.g. there may be N paths between endnodes
> which support different bandwidths, have different congestion (response
> times), have different costs, etc.  QoS might want to address how one
> arbitrates commands across a set of paths, how it changes should a
> hot-plug/removal occur, etc.  The workgroup will need to define what QoS
> means which I would contend is much more than a mapping of priority reqs to
> the TOS or TClass fields.
> 
> Mike