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

["Howard Hall" <hhall@ultranet.com>]

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