SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Requirements specification



    
    
    
    Mike,
    
    I think we need some convergence here.
    
    There is no denial that there are applications that can take
    advantage of multiple connections. However, none of them
    are particularly simple (they go way beyond round-robin and
    a lot require router assistance as you say) and the point
    being made here is that a reasonable place for managing
    the complexity of multiple connections is above the transport layer.
    
    This also does not mean that you need to change application
    software - inserting SCSI filter drivers to handle
    multiple connections can make this transparent to applications.
    
    In summary, this is a layering issue - you can have one iSCSI
    layer handling multiple connections, availability, etc. or you
    could put the multiple connections layer on top of a simpler
    iSCSI layer. Either way, the application is unaware of what is
    going on. Furthermore, if you did not want multiple connections,
    you could just remove the multiple connections layer.
    
    I personally prefer the simpler iSCSI layer approach as it
    would cater to the common case.
    
    Regards,
    Prasenjit
    
    
       Prasenjit Sarkar
       Research Staff Member
       IBM Almaden Research
       San Jose
    
    
    Michael Krause <krause@cup.hp.com>@ece.cmu.edu on 08/04/2000 07:02:22 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Prasenjit Sarkar/Almaden/IBM@IBMUS, ips@ece.cmu.edu
    cc:
    Subject:  RE: Requirements specification
    
    
    
    At 10:58 AM 8/4/00 -0700, psarkar@almaden.ibm.com wrote:
    
    >Two points:
    >
    >1.  The iSCSI presenters seem to imply that having 'n' connections through
    >the IP fabric will automatically give you 'n' (or close to 'n') times the
    >bandwidth if you round-robin your packets across the connections. This is
    >probably true only in the very ideal case and in the real world, the
    >situation is far less rosy to make such an assertion so confidently.
    
    Not true that this has to be the ideal world - there are numerous
    applications that maintain high-bandwidth through multiple connections on
    the same path or across several paths.  Also, network routers often
    implement RED / WRED schemes which may only impact a subset of the sessions
    connections.
    
    
    >2. Fault-tolerance currently is (and should be) layered above the SCSI
    >transport layer. There are enough solutions from several vendors in the
    >market which deal with this,
    >so there is no use in reinventing the wheel.
    
    Fault tolerance is a highest level of availability there are other levels
    that allow one to recover from a variety of failure types without requiring
    to implement to this level.  Most of these can be simply implemented below
    the iSCSI level.  Also, dynamic changes in the network composition can be
    dealt with without resorting to high-level changes to the
    applications.  The objective of improving the availability is to not be
    required to use this overly complex solutions but to create simple,
    low-implementation costs solutions that will benefit the majority of the
    customers.
    
    >Based on the "Keep It Simple and Stupid" and "Optimize for the Common
    Case"
    >principles,I would appeal to the iSCSI "design team" to forgo multiple
    >connections per
    >session and use specialized solutions for remote mirroring and remote tape
    >backup (the apps that require multiple connections).
    
    Multiple connections can be done using a KISS principle and more robust
    solutions can be built on top of this solution to expand the functional
    capabilities without requiring the architecture to be radically permuted in
    the process.
    
    Mike
    
    
    
    
    


Home

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