SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI Autosense Consensus, Connection next steps



    Steph,
    I certainly agree with your first point.  However, we need to focus a
    little more on the second point.
    
    You talked about Transport layer and Wedge layers.  I guess I do not know
    exactly what to call iSCSI if given these two options, other then to
    consider iSCSI part of the SCSI Transport (layer).  It is a device specific
    driver, which in this case deals with iSCSI Devices.
    I do not think we should call iSCSI a Wedge Driver.  In fact if you do not
    have iSCSI supporting the balancing of commands and data across the
    multiple connections (and perhaps some generic Alternate Path Retry), you
    will have to have a Wedge Driver Do it.  In was David Black's point when he
    said that Wedge Drivers are needed anyway to handle a number of vendor
    specific functions.
    
    I think that David is correct the only point that I was making was that if
    iSCSI was able to do the load balancing and some Generic Alternate Path
    recovery, that the Vendor Specific Wedge Drivers will be much simpler.
    
    Having said all that, I think the point you wanted to make was: if the
    command load balancing functions can not be done in the xxxx/IP transport
    then no one should do it.  That is clearly NOT an option, since the various
    Wedge Drivers do that today and will do that in the future.  So the
    remaining point is: considering only the iSCSI & xxxx/IP layers, do we want
    load balancing to be done only in the xxxx/IP layer or can it be done in
    the iSCSI layer.  The iSCSI Device Driver might be easier to create, if the
    xxxx/IP layer did the Balancing.  But, I think a number of vendors of iSCSI
    will be willing to do this balancing if the xxxx/IP does not do it.
    
     As long as it is not required for every one to build multiple connections
    per session (remember: the default in Synchronous is a single connection
    per Session) then Synchronous permits those that want to build a balancing
    and generic Alternate Path Retry function, to do so.
    
    .
    .
    .
    John L. Hufferd
    
    
    
    Stephen Bailey <steph@cs.uchicago.edu>@ece.cmu.edu on 09/05/2000 02:44:21
    PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI Autosense Consensus, Connection next steps
    
    
    
    > Second, on connections, I haven't seen enough discussion to call
    > consensus, but I am going to try to narrow the option space and
    > structure the discussion.  Four models for sessions have been
    > proposed:
    >
    > (1) Symmetric - all connections usable for command and data.
    > (2) Asymmetric - single command connection, others are data.
    > (3) Split - assign LUN sets to specific connections or pools of
    >    connections.
    > (4) SCTP - use SCTP's support for multiple connections.
    
    For the purposes of shaping the consensus, here's my stance:
    
      1) SCTP should only be pursued if TCP does not admit a viable
         solution to the iSCSI requirements.
    
    
    Given that there are many iSCSI community participants expressing the
    belief that iSCSI on TCP IS possible, I believe iSCSI on SCTP
    proponents are just going to be stuck holding an `I told you so'
    card.
    
    This gates my second statement:
    
      2) multiple connections per session should only be supported if the
         underlying transport (e.g. SCTP) layer supports it.
    
    Obviously, TCP does not presently support this abstraction, so
    assuming SCTP gets killed for now, I am against multiple connections
    per session.
    
    In general, I am dubious that connection bundling above the transport
    layer, but below some more application-informed layer (e.g. a wedge
    driver) will work acceptably.  However, if the transport layer
    provides it, then, by definition, it must work (ha, ha), or at least
    it's not iSCSI's place to say that it won't.
    
    Steph
    
    
    


Home

Last updated: Tue Sep 04 01:07:35 2001
6315 messages in chronological order