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

    RE: iSCSI: No Framing

    > > Those advocating a portion of the iSCSI application be in hardware
    > > below the TCP transport should be willing to document information
    > > exchanged between layers, and the states held within this layer.
    > > You wish the IETF to endorse a scheme within a standards draft and
    > > yet not be allowed to understand its implementation.
    > That is a level of implementation detail that the IETF has historically
    > not demanded the exposure of, and it would certainly be inappropriate to
    > standardize.  To the extent that there are open source implementations of
    > this form, the information will be disclosed in due course, other
    > implementers will make their own decisions about what to make available.
    I am not requesting a detailed API, but rather essential information
    exchanged between this layer beneath TCP supporting framing and the
    application.  An essential aspect of any application interchange is the
    information exchanged with network related layers.  Keeping this information
    proprietary does not allow a review.  I suspect the reason for keeping this
    information private is to prevent an understanding of the scope of change
    being advocated or to ensure proprietary solutions.
    > > This scheme so modifies the application attempting FIM utilization, it
    > > would be impractical to describe this as not altering TCP.  TCP is not
    > > just a wire specification.  Changing the receive packet into a memory
    > > array needs additional clarification beyond a claim this does not
    > > change TCP.
    > That is unfortunately a waste of list bandwidth.  With my WG chair hat
    > firmly on, it is my conclusion that Doug Otis has failed to provide
    > sufficient technical support for his argument that FIM alters TCP, and
    > hence I hereby reject the procedural request that FIM be removed from the
    > iSCSI draft as being a modification of TCP that would be outside the IPS
    > WG's charter. Discussion of the merits of FIM is fine, and FIM may yet be
    > removed from the iSCSI draft for good technical reasons (or may not) but
    > debating whether FIM alters TCP is a waste of list bandwidth at this
    Any scheme that introduces a new network layer that directly or indirectly
    interfaces with the application would be a modification of any transport.  I
    do not feel I am obligated to offer technical details of this scheme, but
    rather those that advocate its use should feel such obligations.
    > I also state that it is the rough consensus of the IPS WG that TCP will be
    > used for the first version of iSCSI, and this is stated over Doug Otis's
    > continuing objections.  Doug would be better advised to work on using SCTP
    > for iSCSI rather than complaining about the fact that others are not doing
    > so.
    I have had no objections to the use of TCP.  I have steadfastly rejected
    alteration of TCP to accommodate various schemes designed to introduce
    framing within or below TCP however, especially those that introduce
    application specific layers below the transport.  My principle objection is
    that such a scheme is possible using SCTP without alteration of network
    layering.  Your continued endorsement of such a scheme is troubling.  If one
    is allowed to create a new layer below and above the transport, then any
    alteration of the transport becomes possible.  Granting this abuse in
    principle makes any attempt by the IETF to regulate a transport meaningless.
    Here you are advocating that this new layer does not require any details
    offered and yet you have concluded it does not alter TCP in the absence of
    public information.
    > These decisions are appealable in accordance with RFC 2026, but should not
    > be further discussed on this list.
    My objections to this framing scheme remains unchanged.  Your endorsement of
    an undocumented scheme is in violation of several principles expressed
    within RFC 2026.  One being clear and concise documentation, and the other
    openness and fairness.  The IPS wg has made an incorrect technical choice
    through the addition of this new layer below TCP which places the integrity
    of the iSCSI draft in jeopardy.  I am willing to continue this through an
    appeals process, but my hope would be that this aspect of the draft is
    struck prior to that exercise.
    > Thanks,
    > --David
    > ---------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 42 South St., Hopkinton, MA  01748
    > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    >         Cell: +1 (978) 394-7754
    > ---------------------------------------------------


Last updated: Mon Feb 04 17:17:58 2002
8626 messages in chronological order