RE: iSCSI: No Framing

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

David,

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

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.

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