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

[Howard Hall <howard@pirus.com>]

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.

Howard Hall
Pirus Networks
www.pirus.com

john wilkes wrote:

> Mark,
>
> Like you, I believe that defining - and controlling - the QoS
> specification for a storage device is indeed an interestingly
> different problem than doing the same thing for network traffic.
> Indeed, we've been researching this topic for some time now :-).  (See
> <http://www.hpl.hp.com/SSP> for a little more data.)
>
> However, I'd suggest that storage device QoS specification seems to be
> outside the immediate scope of the IPS work.  This seems clearly
> focussed on achieving transport of existing block storage protocols
> (such as SCSI) across an IP-based network.
>
> Expressing - and controlling - storage device QoS seems to be
> something that might better be pursued in the T10 forum, where it
> would probably show up as extensions to the SCSI device mode pages.
> Given that changing SCSI itself is expressly outside the scope of the
> IPS WG charter, this seems to place this issue outside it's scope too.
>
>   john