RE: [Tsvwg] RE: iSCSI: No Framing

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

Brian,

>
> Douglas,
>
> On Wed, 06 Feb 2002, Douglas Otis wrote:
>
> > Brian,
> >
> > > Lloyd,
> > >
> > > On Wed, 06 Feb 2002, Lloyd Wood wrote:
> > >
> > > > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote:
> > > >
> > > > > What is lost by throwing layering out the window?
> > > >
> > > > modularity, ease of understanding, and portability.
> > >
> > > Modularity can be acheived without layering.  The entire
> > > field of OOAD proves this.
> > >
> > > Ease of understanding is acheived through accurate
> > > interface description.  Again OO shows this.
> > >
> > > Portability can also be acheived through OO approaches.
> > >
> > > The classical layering of communications functions
> > > into functional groupings is not a necessary condition
> > > for any of these benefits.
> >
> > Unlike a typical play dough program, this stuff is more like
> > working with concrete.  A portion of each application demanding
> > a direct placement feature would be included in hardware or
> > intelligent adapters if using FIM and TCP, or framing and TCP,
> > for the most part.  SCTP allows layering for this "clean
> > modularity" needed if one is to design an adapter that need not
> > understand the complexities and structures of every application
> > that desires this function.  The adapter interface only needs to
> > understand SCTP and not the application.  By using the unordered
> > delivery mode, a shim would be able to implement generalized
> > structures for including Direct Data Placement or even a full
> > implementation of RDMA.  It would be possible for more elaborate
> > interfaces to built upon this foundation, but at least this
> > establishes the modularity, ease of understanding, and portability
> > desired, if one is going to start working in concrete.
>
> Not necessarily...  Nowadays entire OS's and applications are embedded on
> the adapter.  The adtapter can have full knowledge of all applications
> which it supports and provide only higher level application interfaces
> to app blades.  This is the preferred architecture for scalability and
> redundancy as well as proving a clean separation between applications
> and the application engine.

The rationale for FIM was to avoid the rather modest use of adapter buffer
space.  Now you are suggesting that the adapter will include the entire OS
and application.  It sounds as if you are describing clustering where I
think RDMA is an attempt to standardize this type of interface.

> If some want to agree on how this embedding is going to occur with some
> vestige of interoperability, what does it matter?  Would not your time be
> better spent furthering DDP/SCTP?  It is certainly not the first time that
> IETF has had competing approaches: ultimately the market decides.

This change in architecture is profound with respect to impact on competing
approaches.  I would not wish to under estimate leverage found from storage
as it can be used to wrest control away from standards into an array of
vendor unique solutions.  This FIM/TCP scheme adds a layer beneath the
transport and either modifies the layer above or adds a new interface to
this added layer.  Either way, the definition of what is included within a
transport is greatly diminished.  You are asking me to turn my back to this
while I see it in my interest to keep this interface open and I see SCTP as
a viable solution for doing so.  Restricting iSCSI to TCP would not prevent
future use of SCTP for this application provided this interface remains
open.  If you are right about what can be included within an adapter, then
justification for FIM/TCP vanishes.

Doug

> --brian