RE: [Tsvwg] RE: iSCSI: No Framing

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

David,

> > > 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,
>
> > 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.
>
> What I am failing to understand is how what you describe is any
> different than the variablity of the design of existing NIC
> cards. Virtually every NIC card needs its own custom driver
> for each OS that is supported. Implementing FIM is no different
> than the multitude of existing checksumming offload NICs. It
> is true that the hardware is using knowledge of the upper layer
> protocols, but it is all within the confines of the implementation
> details. There is no wire protocol implication here.

I think you have quickly glossed over the difference.  The interface created
will need to include a portion of the application.  This is very different
than virtually ever NIC card interface.

> In order to "standardize" these techniques the IETF will be
> dictating hardware design and/or protocol stack design. While
> this might be useful for an industry consortium to make
> portability of software easier, it is not a fundemental IETF
> issue. In what is essentially an implementation specific communications
> between layers of a software stack, how can you standardize
> something that will be uniquely different depending on if
> the OS uses STREAMS, BSD sockets, Windows XYZ, or custom OS frozbits.
> This doesn't make sense for the IETF, you may consider going
> to SNIA to standardize implemenation details.

Again, you are touching on the problem.  Why should the application dictate
the NIC interface?  If this were the common practice, every protocol would
need a portion of the application built into every NIC.  Worse yet, you will
then see this complexity repeated for OS STREAMS, BSD, Windows XYZ and OS
Frozbits.  You will also be required to modify your NIC to accomodate the
next wonderful version of iSCSI.

> If I am not understanding your point, I suggest that it would
> be useful for you to write a couple paragraphs suitable for
> inclusion in a standards document that describes how you
> would standardize the FIM specification. Without such a concrete
> proposal I believe we are all just flailing at amorphous
> ideas and making no progress on this issue.

There is such a document.  At this point it is waiting for feedback from
Stephen Bailey and Allyn Romanow of the RDMA for their edits.  It has been
awhile, so I guess they are fighting other problems.


> 	-David
>