SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Flow Control



    
    
    Jim,
    
    As I said in earlier note - the host has to have it in login and there is
    no trouble adding it
    although to do it right (i.e. target initiated) we will have to invent
    something like:
    
    -T-2-I - AE parameter change - buffering
    - I-2-T- Text MaxBuffers = That-Is-what-I-Want
    - T-2-I - Text MaxBuffers = That-Is-what-I-Have
    
    This would be also a generic way for a target to request a parameter change
    
    However - any buffer change towards a smaller buffer space will have to
    take into
    account the fact that it might be too late for things in flight.
    
    And obviously only one such exchange can be active at a time - and that
    raises
    the issue of what to do with AEs received in the midst of an exchange.
    
    Julo
    
    Jim McGrath <Jim.McGrath@quantum.com> on 05/10/2000 05:36:56
    
    Please respond to Jim McGrath <Jim.McGrath@quantum.com>
    
    To:   John Hufferd/San Jose/IBM@IBMUS, IPS@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  RE: iSCSI: Flow Control
    
    
    
    
    
    I agree that there is a difference in the degree of buffer requirements
    based on true internet vs machine room application.  However, I don't think
    vendors will necessarily design their products differently for the two
    applications.  And even in a machine room setting (e.g. today's parallel
    SCSI and Fibre Channel), people have requested immediate data on writes
    (which is what this feature is designed to provide).
    
    I don't think leaving this out of the iSCSI protocol is wise - we have
    already had a market failure (i.e. an experience where a desired feature
    could not be supported by the vendors) in this area with Fibre Channel, and
    it just looks worse going forward.  I fear coupling to sessions sounds too
    much like coupling to login, which did not work in FC-AL.
    
    BTW, the burden here is almost entirely on the target.  The target is the
    one responsible for allocating the buffers - the hosts just have to respond
    to changes in the amount available.  Unless this is really hard for the
    host
    to do(?)
    
    Jim
    
    
    -----Original Message-----
    From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
    Sent: Wednesday, October 04, 2000 2:58 PM
    To: IPS@ece.cmu.edu
    Subject: RE: iSCSI: Flow Control
    
    
    
    OK,
    I can buy that Peer to Peer Session stuff.  So we, at least we seem to be
    in agreement on these items. (The length of "normal" Sessions, the length
    of Peer to Peer Sessions, and the Dynamic Buffering requirements for
    Storage Controllers.)
    
    So let me push this slightly.  I also believe that when Storage Controllers
    are sold as iSCSI Internet (by that I mean long distance connect) capable,
    there will be a RAM Storage Feature that is recommended by the Vendor.  Any
    one that just wants to use the Storage Controller in areas where SCSI Buss
    or FC distances apply today, might not need the additional RAM feature.
    
    I think that is the way this stuff will be sold (and need to be sold) and
    vendors will then compete on their more optimum ways of using the RAM
    buffers.
    
    There may be a variant of the above where the Vendor Sells the RAM Storage
    Feature based on the number of Concurrent Sessions the customers wants to
    sustain.  And of course there will be combinations of RAM Storage Features
    for number of Sessions and Distance.  Vendors will compete on how simple
    (in relationship to Cost and performance) their approach is viewed relative
    to the Distance and number of Sessions needed.
    
    If others believe this, then the stuff we have been talking about with
    regards to  Flow Control is Mute and can be left up to TCP/IP and the
    various vendors implementations of the iSCSI/SCSI buffering algorithms.
    
    .
    .
    .
    John L. Hufferd
    
    
    Michael Krause <krause@cup.hp.com>@ece.cmu.edu on 10/04/2000 01:44:25 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   IPS@ece.cmu.edu
    cc:
    Subject:  RE: iSCSI: Flow Control
    
    
    
    At 12:34 PM 10/4/00 -0700, John Hufferd/San Jose/IBM wrote:
    
    >Michael Krause,
    >First, a session usually lasts from Boot Time till it is Booted again or
    >stopped.  The variant to this is a Storage Device being used in a manor
    >like a Mount or Map done with NAS.  Even then, most folks, have that setup
    >so the Mounting and Mapping is done at bring up, though it is sometimes
    >done at other times, but even then it is left around.  So I think the
    thing
    >you can say about Session Time as the term is used in the iSCSI context is
    >that it is LONG.
    >
    >I do not think we have consensus about the notification of available
    >buffers.  With the way many systems work, is (as stated above), all
    devices
    >are set up at startup of the Host, and the Session is kept around by the
    >Host, even if there hasn't been anything which use that device all
    >day/week, etc.  So I am not sure if having a certain amount of buffer
    space
    >reserved for each Host (which could be 100s-1000s) would be an especially
    >good idea.
    
    I believe we are in agreement both in terms of duration and the need to
    have dynamic buffer management.  I will clarify that there will also be
    sessions that are not host focused, e.g. the peer-to-peer direction of a
    storage object to another device, e.g. multi-media streaming and these
    sessions will be shorter lived - possibly on a per transaction basis where
    a transaction is something of reasonably large in value (e.g. 100's MBs of
    data movement).
    
    Mike
    
    
    
    
    
    
    


Home

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