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

    RE: iSCSI: No Framing

    > Julian,
    > > 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".
    > Doug is within bounds, but not by much.  He's basically correct that:
    > > Discussion regarding the concept of framing using FIM within iSCSI is a
    > > valid topic at this time.  [... snip ...]  With this topic to be decided
    > > shortly, now is my opportunity to speak.
    > On the other hand, Doug continues to engage in flawed reasoning that shows
    > a lack of respect for other members of the WG.  His very next sentence,
    > for example:
    > > A generalized scheme for implementing DDP is relevant as opposed to one
    > > that is proprietary and application specific.
    > The word "proprietary" is an unfortunately typical of Doug:
    > (1) assuming that standardization of certain components and/or interfaces
    > 	is/are necessary to the use of FIM,
    FIM makes absolutely no sense following TCP.  Advantages for FIM are
    realized if done prior to placement within system memory as typified by the
    general understanding this scheme is for NIC vendors.  Whether it is done
    using specialized hardware, intelligent adapters, or software, the goal, as
    often stated, is to reduce buffering required in the event of packet loss.
    TCP is unable to deliver network traffic during such an event, and FIM is a
    scheme to allow a layer prior to TCP to interpret "as an application" the
    expected byte stream "out of sequence" as a means to steer encapsulated
    payloads.  A generalization of this would be described as direct data
    If done using a protocol employing the TCP transport, a layer must be added
    ahead of TCP, which would be, without documentation, a "privately owned"
    layer.  Privately owned as such details of this layer are not shared
    publicly.  This layer may be hardware or an intelligent adapter, or it could
    be a software solution within a memory starved CPU.  Without documentation
    describing the information exchanged between the application and TCP,
    together with the states involved in this process, any efforts to
    extrapolate the details of this layer are likely to venture into proprietary
    areas.  A means of avoiding this problem would be to document the basics and
    thereby make such a process public.  It would also afford an ability for
    > (2) failing to acknowledge the existence of implementation approaches that
    > 	may not require such components or interfaces, AND
    Proprietary does not imply hardware although in this case it is a high
    probability that hardware or an intelligent adapter would implement this
    layer.  Unfortunately, the use of TCP will also require that actions of this
    "synchronization and steering" layer will be unique for each application.
    This is a significant problem that is completely overcome through the use of
    > (3) failing to consider the possibility that standardization of such
    > 	components or interfaces may not be necessary to interoperability.
    This is difficult to determine due to the lack of details.  It is also
    difficult to judge security risks for the same reason.  At this point, it is
    a black box.  As this layer must anticipate the behavior of TCP, it would be
    wise to expose techniques used for doing so and this should be done within
    the tsvwg for a broader range of expertise.  There is also a requirement for
    associations to be made between buffers and application specific structures
    communicated in some fashion from the application to this layer.
    > The result is that here and elsewhere when the IPS WG avoids Doug's
    > invitation to unnecessary standardization, Doug accuses the IPS WG
    > of working in secret on proprietary solutions.
    The IPS wg has demonstrated a desire to institute a scheme for incorporating
    direct data placement as a generalization of this feature allowed through
    the use of FIM.  A noble goal.  This desire has manifested itself as drafts
    designed to implement framing using Urgent Pointers, Fixed Interval Markers,
    Byte Stuffing, to an all out mandated framing of TCP as detected by segment
    length.  This "improvement" to TCP was initiated at the pre-BOF for IPS and
    has not relented.  I have never invited change to TCP, but rather strongly
    urged the wg to consider SCTP as an alternative solution for DDP versus
    these "improvements" to TCP.  My continued opposition to these ideas have
    not won me any popularity as I still view these concepts as a kludge and a
    corruption of network layering.
    My reasoning for pressing this issue is not to prevent framing, but to
    suggest a better practice for achieving this feature.  Failing that, have
    the iSCSI draft document the interface and states involved in this
    "synchronization and steering" layer to assist efforts in the creation of a
    generalized scheme for DDP using SCTP.  This would ensure migration from
    this application specific layer if it were to become used in practice.  The
    benefits of FIM would be marginal at this time as targets can use techniques
    to avoid the need for relocating buffers without the use of framing.  This
    should allow time for deployment of generalized schemes at the clients using
    SCTP.  NIC vendors would reap a larger return on their investment when
    offering a generalized feature as there would be a greater opportunity for
    its use.  DDP could be employed in many protocols such as RPC as one
    example, in addition to SCSI without introducing complex layers beneath the
    > Needless to say such accusations are not only groundless, but have also
    > become boring due to excessive repetition.  Doug might get more respect
    > for his ideas if he showed more respect for the ideas of others.
    > Nonetheless, it is fair for Doug to advocate that SCTP is the right
    > long-term solution and that FIM is not a step in that direction:
    > > 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.
    > One's personal filters are ones own concern - I have a responsibility to
    > pay attention to the contributions of all, but it would help if Doug
    > would remove the words "proprietary" and "secret" from the vocabulary
    > he uses when posting to this list.
    I should have started my response at the bottom and worked my way up.  By
    "proprietary", I am referring to private.  If you see private, think
    proprietary and vice versa.  I believe I am using this word correctly.  I
    have not used the word "secret" except to comment about the NDT header
    offered by Julian.  In that header is a "shared secret" field.  My comment
    was that CRC does not mask the "shared secrets" or something to that effect.
    I apologize if this is becoming boring, but do not think my concerns are
    groundless.  It has been a long process, however.  Again, thank you for your
    > 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: Wed Feb 06 12:17:58 2002
8672 messages in chronological order