[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: [Tsvwg] RE: iSCSI: No Framing

    > David,
    > On Tue, 05 Feb 2002, 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.
    > 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


Last updated: Wed Feb 06 12:17:58 2002
8672 messages in chronological order