RE: iSCSI: No Framing

["Douglas Otis" <dotis@sanlight.net>]

David,

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

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

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

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

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

Doug

>
> 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
> black_david@emc.com         Cell: +1 (978) 394-7754
> ---------------------------------------------------
>