RE: [Tsvwg] RE: iSCSI: No Framing

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

> David,
>
> On Tue, 05 Feb 2002, Black_David@emc.com wrote:
>
> > 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.
>
> What's the matter with that?  I would say that 80-90% of
> those lurking on these working groups are doing exactly that:
> working in secret on proprietary solutions; forming trade
> secrets to embed in their implementations; and patenting
> whatever the can to encumber the competition.  That's just the
> way of the world.
>
> As with any other standard body, IETF standards represent a
> tenuous balance between interoperability and proprietary
> implementation.  Even so, the number of proprietary (and
> patented) protocols proliferate the RFC servers as
> "Informational" and some even as proposed standards with
> Intellectual Property claims.

By placing these concepts into the public forum, that marks the end in which
"invented here" can be claimed and those organizations participating are
expected to volunteer aspects they consider "proprietary."  You are right
that such is often the case and hence the general agreement for disclosure.

> I find it hard to believe that a tortuous approach that has
> only short-term viability is going to have such a deterious
> effect in an industry that holds the trade secret and
> intellectual property rights in so high an etseem.
>
> (I would invite Doug to re-read the copyright disclaimer
>  on all RFCs.)

I am aware of the disclaimer.  I am also aware of the need for review.
There are many other applications clamoring for this "useful" dodge.  It can
be done in a haphazard fashion, or this transition toward Direct Data
Placement can be done with little disruption to existing software and
equipment.  There is already an RDMA group wishing to form as well as other
clustering schemes that desire this ability, in addition to iSCSI.

> What will this market be fractured into?  Those with trade
> secrets and those without?  Or is this a Beta vs. VHS thing?

There will always be trade secrets or proprietary information regarding any
solution offered by a vendor.  Each has their investment to protect.  The
greatest danger regarding something as basic as a network interface comes
from the vendors.  Should a vendor lay claim to a means of accomplishing the
interface to this beneath TCP "synchronization and steering" layer, then
applications will be forced to modify their interface significantly between
systems.  In essence, it would be Beta vs VHS with respect to something that
should remain ubiquitous.

> At least the draft provides some basis for interoperability
> and addresses the extent to which those taking this short-term
> blind alley are willing to reveal their plans to each other.
>
> So how will it be fractured?--Into those up the blind alley
> and those in the traffic jam?

There are already many proprietary schemes in the market and the IETF has
not prevented any vendor from entering that arena whether they are blind
allies or not.  The IETF should take the long view and strive to prevent
unnecessary disruption to existing technology used within IP.  SCTP offers
the necessary features and protections to allow Direct Data Placement to be
deployed without disruption.  A clever state machines running beneath TCP
attempting to anticipate TCP will likely work in the general case, but then
fail completely when confronting a new and untried piece of equipment that
does something unexpected.  In that case, who would be at fault?  You would
have nothing upon which to judge the cause of the failure.  Was it due to
the application not properly monitoring this undefined status coming for the
"synchronization and steering" layer beneath TCP?  Was it the state machine
within the S&S layer?  There is nothing like complexity to allow a large
company to dominate however. : )

> Please Doug, if there is a technical (not political) basis
> on which this draft is somehow flawed, please express it.
> You seem so vehemenently opposed to this draft over the
> last number of months: surely there is some technical basis
> upon which your first aversions were based.

I think that the concept of network layering where functions are concisely
defined is a technical aspect and not a political one.  That does not mean,
there are not politics at play.  When you introduce a layer below the
transport that manipulates a partial data stream on behalf of the
application, you have thrown the concept of layering out the window.  This
goes well beyond techniques already on the fridge such as packet filters or
ALGs within NATs.  Here you would have continuous interchange between this
S&S layer and the application.  I must admit I am not surprised by the
opposition to a ready made solution that preserves network layering while
offering virtually every possible innovation.

The storage industry rightfully considers themselves an industry unto
themselves.  It is also not surprising the zeal in their attacking perceived
problems.  It has been my privilege to work in this industry and networking
for a quarter of a century.  Working within the tape industry, I have also
learned that it is difficult to make a difference in the direction the disk
industry takes.  The disk cadre and their barbs require a relatively thick
skin if you wish to oppose their consensus.  My resource in this effort is
an annoying persistence.  It may take a prolonged period for what may appear
as a minor detail.

> If it is the protocol layer boundary violations that concern
> you, what is the technical (rather than preceived market)
> disadvantages of such violation?

This new layering concept is not without its risks as it devises placement
of information prior to the protections offered by the transport.  It does
so in perhaps a dangerously predictable manner in that the location of the
marking scheme may easily be spoofed later in time.  This S&S layer through
the use of a highly predictable marker is intended to allow "out of
sequence" segments to be placed.  Depending on how a duplication problem is
handled within this S&S layer, evidence of this event may be obscured.
There is also opportunity for information to be diverted by means of the
communication sent to the S&S layer.  As this layer is below the transport,
this link may suffer weaknesses not present at the more robust API for the
transport itself.  If this communication is present at the transport API, it
should be documented to allow applications consistent essential constructs
when supporting this feature.

> It is only on the basis of technical or procedural error that
> an appeal can be honestly and successfully lodged under the
> IETF process anyway and you had certainly better air those
> technical objections within the WG first.

I see the function of the IETF in broad terms.  There is a general
architecture that is being created in addition to individual protocols.
This process should not opt for a proprietary solution (sorry David)
especially making such a Must, Should, or even Recommended within a draft
when the IETF has already provided a technically superior competing
solution.  SCTP is years ahead on this curve, and although the IPS wg is
good, there is no doubt which is the technically superior solution.
Although David has done an admirable job point out the lines I should not
cross, I too feel there have been some lines crossed.

> Could you provide a summarized list of your technical
> objections with proposed solutions so that others in the
> WG can comment?

I think that I have indicated my concerns and these areas are judgment calls
for those responsible perhaps should framing remain within the iSCSI draft.
More than a year ago my opposition to the use of the TCP Urgent Pointer for
framing caused a similar conflict between David and myself and perhaps set
the stage for this friendly give and take.  One might say that necessity is
the mother of invention, but in this case, it is not necessity as SCTP is a
ready made solution for this framing and layering problem.  I think that if
the IPS wg could see past creating new solutions for a problem already
solved, they would be months, if not years, ahead.  It is a minor point,
remove the FIM from the iSCSI draft and forego use of a layer beneath TCP
for the reasons stated.

Doug

> There might be several solutions that might
> lead to improvements even at this late a stage.  It is
> normally only a technical argument that will lead to concensus
> here.  (I doubt that the WG chair could ask for comments on
> a question concerning market fragmentation and trade secret
> plots.)
>
> --brian
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/