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

    Re: iSCSI: No Framing

    > To prevent fracturing of the market and creating standards competition
    > within IETF, FIM should be removed from the iSCSI draft.
    Just to make my original comment (about the potential for fracturing) clear -
    I *do not* believe defining FIM in iSCSI draft itself fractures the market.
    IMO, a market fracture can happen only if two conditions are met -
        a) if FIM is not mandated to implement (i.e. required as a SHOULD), AND
        b) if % of NICs is evenly split between those that can and those that can not
            (that a SHOULD enables) do framing.
    Perhaps we should consider mandating FIM just for iSCSI *hardware*
    implementations (similar to what we did for Node Name configurability, and
    ISID partition) if all NIC vendors are going to do it anyway - while leaving
    the software aside.  That essentially ensures that (b) above is not ever satisfied.
    I am not unduly concerned about software_senders->NIC_receivers delivering
    lower performance (than NIC->NIC combination) - since that's true anyway.
    As Julian implied earlier, the evolution of this for iSCSI-2 could be to mandate a
    better generic alternative - if one exists by then.
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard MS 5668
    Roseville CA 95747
    ----- Original Message -----
    From: "Douglas Otis" <>
    To: <>
    Cc: "Tsvwg" <>
    Sent: Tuesday, February 05, 2002 11:01 AM
    Subject: 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


Last updated: Tue Feb 05 19:18:00 2002
8656 messages in chronological order