SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Status summary on multiple connections



    
    
    Dear colleagues,
    
    I am attempting to summarize where we stand with regard to the multiple
    connection issue
    and to the two possible models - Symmetric (S) and Asymmetric (A).
    
    Many of us feel strongly that the multiple connection issue is central to
    the whole design
    and cannot be added as an afterthought.  Moreover designing the hooks to
    allow it later
    will certainly already force us to make a decision. And both the hardware
    and the software designers will be ill-served if we hand them a half-backed
    solution.
    
    However this is not an invitation to reiterate positions that where already
    stated.
    If you feel that I have grossly misstated anything in this note please
    write me and use
    the mailing list only if my answer is not satisfying.
    
    And yes - like the chairman - I would like to make progress but I don't see
    any way to
    do it without satisfactorily closing this issue.
    
    The reasons for multiple connections where discussed at some length and
    where very nicely summarized in a series of notes by Michael Krause
    (beginning of August).
    
    The core reasons for having multiple connections where the need for more
    bandwidth and availability than a single link can supply with a level of
    complexity affordable for simple
    installations and with a traffic engineering and management clearly
    separated from the transport users (SCSI).
    
    The session is embodying this requirement.
    
    The only major objections I have heard against this where those requiring
    to go all
    the way in having one TCP connection/LU - and after a short debate this
    objection
    was practically removed.
    
    The other objections we heard where that this is basically a transport
    issue and it should be
    solved at transport level.
    That might be true - but since many, if not most, of TCP applications do
    not have this
    requirement it is highly unlikely that TCP is going to do connection
    trunking in the foreseeable
    future.
    
    iSCSI can be designed to use multiple TCP connections in one of two ways:
    
    -Asymmetric - one TCP flow only carries commands the others carry only data
    
    -Symmetric - every flow carries both commands and their associated data
    
    The S version is designed in the I-D version 01
    The S version requires an command ordering scheme and that is provided by a
    command counter and a sliding window scheme. It was argued that ordering
    needs might be more prevalent than usually thought and a good conservative
    design should preserve ordering.
    Ordering-per-LU (as it is designed in FCP-2 version 4)  was considered
    impractical as it
    required initiators to maintain state for each LU - while the rest of the
    design required initiators only to maintain state for outstanding commands.
    Several comments on this list suggested that this windowing mechanism could
    also be used as a command-flow-control mechanism and that is a "bonus" of
    the scheme.
    
    The A version - comes in two flawors:
    
    - pure A (PA) in which ONLY commands  flow on one TCP connection while data
    flow
       on DIFFERENT connections (with only one data connection being selected
    for a
       command);   this scheme requires a minimum of 2 TCP connections although
    not
       necessarily on  different physical links.
    
    - collapsed A (CA) in which commands flow one a single TCP connection while
    data
       flow on ANY connection; this scheme requires as a minimum 1 TCP
    connection.
    
    Here is first attempt to list the benefits and drawbacks of all of them:
    
    
    - S - benefits
            - well understood
            - simple hardware setup and/or TCP API activation
            - window mechanism can be also used for flow control
            - the minimum required is a single TCP connection
    
         - drawbacks
           - need to maintain a window mechanism
           - a multiplexing mechanism has to be carefully crafted to avoid
              closing TCP windows to severely affect command flow and
    performance
    
    
       - PA - benefits
              - TCP will both order the commands and provide for flow control
                 through the TCP window mechanism
              - the multiplexing mechanism is simpler as closing TCP windows
    will
                 never affect command flow
              - data flow can use a streamlined header (and processing)
    
            - drawbacks
               - more complex hardware and/or software API activation
               - need for a minimum of two TCP connections (not links)
    
        - CA - benefits
                - TCP will order the commands
                - needs a single TCP connection as a minimum
    
           - drawbacks
               - more complex hardware and/or software API activation
               - need for a minimum of two TCP connections (not links)
               - if command flow control is required counters and the sliding
    window mechanism
                  are required
               - a multiplexing mechanism has to be carefully crafted to avoid
                  closing TCP windows to severely affect command flow and
    performance
    
    
    From the above it should be apparent - as was already pointed out by Matt
    Wakeley -
    that the CA inherits the drawbacks of S and PA and as such the choice is
    really
    between S and PA.
    
    Julo
    
    
    


Home

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