SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: No Framing



    Julian,
    
    Discussion regarding the concept of framing using FIM within iSCSI is a
    valid topic at this time.  I disagree strongly with your statement about the
    market not becoming fractured.  With this topic to be decided shortly, now
    is my opportunity to speak.
    
    A generalized scheme for implementing DDP is relevant as opposed to one that
    is proprietary and application specific.  Yes, I know it is using the four
    letter word SCTP.  There is about to be a document released illustrating DDP
    using SCTP.  It removes the application specific nature of this endeavor and
    does not impact existing TCP implementations or network layering.  SCTP
    provides a far superior solution when attempting Direct Data Placement, the
    rational for FIM within iSCSI.  iSCSI APIs need not change to introduce SCTP
    as an alternative transport if implementing this DDP feature in the future.
    To prevent fracturing of the market and creating standards competition
    within IETF, FIM should be removed from the iSCSI draft.  Transition to SCTP
    for this feature and do not add layers to TCP.
    
    Doug
    
    David,
    
    Dough is continuing his rumblings - whether they are relevant to us or not.
    I wonder if there is some administrative measure you can take to save us
    some bandwidth or we should install our own
    "Otis filters".
    
    Julo
    
    Julian,
    
    Implementing a scheme for doing direct data placement by means of an
    application specific, undocumented or proprietary layer below TCP will
    fracture the market.  This will result in an unacceptable outcome having
    hardware created for each application, limited by various vendors making as
    yet unknown claims, if implementing the DDP feature using TCP.  In the
    future, should this feature become desired, iSCSI can adopt a generic method
    that is possible through the use of SCTP.  An eventual adoption of SCTP
    would also simplify much of the existing complexity found with the
    multi-connection TCP standard now proposed for iSCSI.  Use of SCTP would
    allow common hardware for many protocols desiring Direct Data Placement
    without modification of the SCTP transport as it can deliver objects
    unordered.  A shim providing the DDP feature could ensure objects are
    disclosed in the order sent if desired, independent of the reception at the
    shim while not modifying SCTP or adding layers beneath this transport as
    would be required for TCP.
    
    Only when constrained to conventional memory allocation, does DDP become
    beneficial.  The concept of placing a layer beneath TCP that structures an
    array to hold each individual packet based on application specific
    structures is fundamentally flawed.  This presumes the layer beneath TCP
    knows before hand the content of the byte stream prior to TCP composing the
    stream.  This lower layer will also need to create exceptions for handling
    duplicates, for placement information not aligned with the TCP segment, and
    for application informational errors.  SCTP can easily avoid these
    exceptional cases making such development less disruptive.  In addition, an
    SCTP stack that does not offer DDP in hardware need not change the API
    behavior to the application nor modify any layer functionality.
    
    The ability of SCTP to support many different higher level protocols comes
    from the capability of SCTP to deliver objects unordered.  TCP's restriction
    on ordered delivery mandates that any direct data placement is done prior to
    TCP through the addition of a new and application unique layer between IP
    and TCP.  The saving caveat has been that disclosure to TCP of these packets
    are sequential but the application interface to TCP will change as a result
    of this modification in some undefined way to associate the steering
    information with the desired buffers.  This change impacts the interface
    between this new layer, as well as the application and TCP.  The desire to
    keep this DDP scheme for TCP proprietary will ensure a fractured market in
    terms of hardware, OS services, and perhaps interchange not to mention that
    each application then also needs unique hardware.  The security risks
    involved in creating this new and highly complex layer below TCP is yet
    unknown as details are lacking.  In essence, an attempt to implement DDP by
    creating a new layer beneath TCP in a proprietary fashion is in direct
    competition with the far better practice of using SCTP to implement DDP.
    
    Doug
    
    


Home

Last updated: Tue Feb 05 17:17:55 2002
8654 messages in chronological order