SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    
    
    I agree that QoS (and the way storage will want to define SLAs) will be
    important to this group and there is no other forum where we can leverage
    QoS better than IETF.
    
    However I think that for practical reasons we should postpone this until
    after we are able to outline our discovery, basic management interaction
    with "control points" etc.
    
    The SLA issue is getting more mature and IETF is better positioned to
    handle it
    than any other standards body.
    
    I think that our chairmen would like to add a "Phase 3" to our schedule to
    do this.
    
    Regards,
    Julo
    
    "Mark A. Carlson" <mark.carlson@central.sun.com> on 23/07/2000 18:44:15
    
    Please respond to mark.carlson@central.sun.com
    
    To:   hhall@ultranet.com
    cc:   "'Michael Krause'" <krause@cup.hp.com>, ips@ece.cmu.edu (bcc: Julian
          Satran/Haifa/IBM)
    Subject:  Re: storage-device QoS [was: IPS Draft Charter update]
    
    
    
    
    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
    
    
    
    


Home

Last updated: Tue Sep 04 01:08:06 2001
6315 messages in chronological order