Re: iSCSI: No Framing

["Mallikarjun C." <cbm@rose.hp.com>]

> 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.

Comments?
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747

----- Original Message -----
From: "Douglas Otis" <dotis@sanlight.net>
To: <ips@ece.cmu.edu>
Cc: "Tsvwg" <tsvwg@ietf.org>
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
>
>