Subject: [Tsvwg] RE: iSCSI: No Framing

From: David Robinson <[email-masked]>
Date: Wed, 6 Feb 2002 10:29:38 -0600 (CST)

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

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.

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.

	-David

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 6 Feb 2002 09:18:01 -0800

David,

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

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.

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

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