RE: iSCSI: No Framing

["John Hufferd" <hufferd@us.ibm.com>]

Somesh,
I usually give higher weight to the opinions of folks that take their
opinions and put their money on it, than the folks that do not.   So I am
not sure you can so easily dismiss the ideas of folks that are committed
with actual money.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Somesh Gupta" <somesh_gupta@silverbacksystems.com> on 02/05/2002 10:25:45
AM

Please respond to <somesh_gupta@silverbacksystems.com>

To:    "Jim Pinkerton" <jpink@microsoft.com>, John Hufferd/San
       Jose/IBM@IBMUS
cc:    "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>, <ips@ece.cmu.edu>
Subject:    RE: iSCSI: No Framing



Jim,

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Jim Pinkerton
> Sent: Tuesday, February 05, 2002 6:53 AM
> To: John Hufferd; somesh_gupta@silverbacksystems.com
> Cc: Mukund, Shridhar; ips@ece.cmu.edu
> Subject: RE: iSCSI: No Framing
>
>
>
> In reviewing the mail alias, and after having many conversations with
> various folks, I would like to retract my prior opinion on ripping out
> markers. It appears to me as though _every_ NIC vendor is in support of
> markers.

  Every NIC vendor may implement markers (or as is obvious from
  interoperability results, may have the capability to implement
  markers). On whether every (person who works at a) NIC/Chip vendor
  supports it from a technical perspective (i.e. whether it solves
  anything, or is a useful solution, or whether the analysis people
  are using is correct) supports it, I think the count seems to be
  evenly split.
>
> To me the evidence in support of keeping in "Sync and Steering with
> Fixed Interval Markers" is pretty compelling (now that I've been
> re-educated). Without going into proprietary issues - how often do NIC
> vendors agree unanimously on something? Also, a software implementation
> of markers is tractable.
>
> I have not heard a single NIC vendor in support of COWS, and I
> personally don't support COWS either. Thus I would recommend that COWS
> be "ripped out".
>
>
> Jim
>

  Julian indicates in his message that we are not really sure what
  a good solution is and if we put something in, we are likely
  to get to a better one in the second draft. I also concur that
  the whole problem/solution space is experimental in nature, and
  ought to be treated as such.

  I think it is meaningless to assume that one person or another
  has a magic solution here. The problems are fairly well understood.
  One can talk about it from an algorithmic perspective (like
  error recovery) which will expose some of the assumptions/compromises
  behind this. Of course, whether that will pass muster with
  the community at large is another issue.
>
>
>
> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Friday, February 01, 2002 11:31 PM
> To: somesh_gupta@silverbacksystems.com
> Cc: Mukund, Shridhar; ips@ece.cmu.edu
> Subject: RE: iSCSI: No Framing
>
>
> Somesh,
> This is not fair, we asked for Chip Vendors that were planning on using
> it,
> to make themselves known and to tell us why.  Without exposing internal
> designs, he has tried to do that, likewise Trebia, and some others have
> said they want FIMs.  You may not want FIMs for your design, but you
> should
> respect these folks that have been following our spec and found it to be
> valuable in their designs.  They are putting their money on it not just
> talk, so we should at least give them the credit which their position
> deserves.  Yes, of course they are disappointed with the rhetoric around
> this issue, since they and others have been following the spec, and can
> not
> understand why others haven't, since they have determined it to be of
> significant value.
>
> His note does speak to the issues. (And clearly has some silly parts :-)
>
> In fact he has found it of enough value to use now, since he believes
> they
> can not wait for iWARP to happen before the issue is addressed (and he
> really wants iWARP).  It should be useful to listen to folks that are
> willing to put their money where their mouth is.
>
> OK, that said: don't you think we can find a way to address both your
> position and their position, since they both seem strong and heart felt.
> I
> would think that the "Should Implement" or at least "May Implement"
> would
> give both sides enough reasonable room to meet on an even business
> plane.
>
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
>
>
> "Somesh Gupta" <somesh_gupta@silverbacksystems.com>@ece.cmu.edu on
> 02/01/2002 07:10:13 PM
>
> Please respond to <somesh_gupta@silverbacksystems.com>
>
> Sent by:    owner-ips@ece.cmu.edu
>
>
> To:    "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>, "'WENDT,JIM
>        \(HP-Roseville,ex1\)'" <jim_wendt@hp.com>, <ips@ece.cmu.edu>
> cc:
> Subject:    RE: iSCSI: No Framing
>
>
>
> Mukund,
>
> With all due respect, taking on the mantle of
> the noble engineer being denied by politically
> motivated people, belittles the technical expertise
> and strengths of the people who have expressed an
> opinion against having any of the proposed schemes
> at this time in the spec.
>
> I would be very happy to work alongside a number of
> the people on both sides of the issue (and that does
> include you).
>
> None of your arguments below refutes the technical
> and some non-technical opinions expressed against
> FIM.
>
> Somesh
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Mukund, Shridhar
> > Sent: Friday, February 01, 2002 5:24 PM
> > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu
> > Subject: RE: iSCSI: No Framing
> >
> >
> > Dear Colleagues,
> >
> > PART 1 of 3 :
> >
> > The pertinent points that "I" see in Jim's email are:
> >
> > A. Need to hear from iSCSI chip implementers ...
> >    The issues that you raise for e.g. in #2&#4 are simply
> >    circumstantial( See PART 2 ). Answers to those questions
> >    unnecessarily call for data flows and implementation
> >    details that silicon vendors are not allowed to share
> >    in public. While I do not know of many silicon vendors
> >    in the multi gig space, clearly one of the competitions
> >    I respect, namely Trebia, point to FIM as well. Granted,
> >    no matter what, we are going to see several
> >    trebia-on-the-other-end and adaptec-on-the-other-end
> >    type of cost optimizations.
> >
> > B. The iWARP/TUF/SCTP under-current ...
> >    The "only" message of significance in Jim's email is #5.
> >    It seems like the iWARP/SCTP/TUF enthusiasts somehow feel
> >    threatened that FIM-iSCSI will dilute the perceived value
> >    proposition of iWARP :-) I for one am an enthusiast of
> >    iWARP ideals myself, barring the proposed mechanics. I
> >    would love to make a buck or two along with you in
> >    building iWARP NICs, "at the right time". In the
> >    meanwhile, iSCSI is the flag ship effort that has the
> >    unique opportunity to make a dent in enabling IP Storage
> >    visions. ( See PART 3 )
> >
> > My assertions are :
> >     i) TUF/SCTP/iWARP is ruled out in the near term. The
> >        mechanics are unclear as hell.
> >     ii) FIM is the least intrusive, TCP transparent, means for
> >        enabling low-cost(power,b/w,latency,memory,space,CPU)
> >        RDMA transport of bulk data.
> >     iii) I do not see significant technical reasons that
> >        merit major changes to the iSCSI draft at this late
> >        date.
> >     iii) Making it OPTIONAL to use, and SHOULD only on send
> >        provides a graceful and incremental deployment path
> >        for "real":-) providers and users to succeed.
> >
> > I have personally contributed nothing to the iSCSI effort
> > and do applaud the pains that several of you are taking to
> > pull it all together. In that very same spirit, I respect
> > David's decision w.r.t. consensus, whatever that turns out
> > to be.
> >
> > Thanks.
> >
> > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ...
> >
> > ------------------------------------------------------------
> > PART 2 of 3 : MUST delete, SHOULD read
> >
> > Dear Jim,
> >
> > Congratulations Jim! Seems like when you bowl, pins
> > roll, unintentional as they may be. You make a "seemingly"
> > well balanced set of arguments and "tactfully" tilt the
> > balance towards your chosen side. I would love to be on
> > your side ... maybe in another effort :-)
> >
> > I would like to introduce you to my respectable friend,
> > who "vehemently" contradicts you on all accounts. One of
> > his numerous quotes goes as follows:
> > http://groups.yahoo.com/group/rdma/message/486
> > "Much of today's usage of the Internet and IP networks
> > is for buffer-to-buffer data transfers, often in the
> > form of bulk data ... Gigabit and faster network transfers
> > incur 'heavy' system resource costs, including both CPU
> > use and system bus bandwidth, particularly on the
> > receiving side ... The costs incurred on hosts for protocol
> > processing and management has 'inhibited' the use of IP
> > in the high speed bulk data domain. ... Bulk data transfer
> > is dominated by the costs of copying and validating
> > incoming data in order to place it at its ultimate
> > destination."
> >
> > The good friend I quote above is none other than Jim
> > Wendt himself!!! I REST MY CASE.
> >
> > Thanks.
> >
> > -Shridhar Mukund
> >
> > ----------------------------------------------------------------
> > PART 3 of 3: MUST delete, OPTIONAL read
> >
> > On the lighter side ... since the opponents have "no" technical
> > arguments whatsoever against FIM and it is all turning out to
> > be a pure political gimmick, I will put on my rusting tin
> > politician hat :-)
> >
> > My dear fellow iSCSI country (wo)men: If our goals are anything
> > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of
> > the world in globalization of storage for McDonald's and Macy's
> > from Kabul to Somalia, via iSCSI, we have lost our identity!
> > ( \insert APPLAUSE for 13 seconds )We are no more protected by
> > the vast oceans between us and other Storage efforts. The
> > freedom of iSCSI America is threatened from within by elements
> > who will not blink twice when it comes to using the world's most
> > potent BOO-bombs ... and grinnn while we end up sifting through
> > the rubbles for iSCSI, youSCSI and theySCSI.
> > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that
> > sleep with "our" very ideals in their privacy(burkha clad
> > though) and yet attempt to destabilize us, only to accomplish
> > their mutated agenda.( \insert APPLAUSE for 57 seconds )
> >
> > No offense folks. I respect each and every one of you and
> > especially Jim. I think that he was only attempting to
> > question, "are we sure ... should we commit ...".
> > I disagree with him anyway!
> >
> > - the running(actually limping) mate :-) :-) :-)
> >
> > -----Original Message-----
> > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com]
> > Sent: Tuesday, January 29, 2002 10:47 PM
> > To: ips@ece.cmu.edu
> > Subject: iSCSI: No Framing
> >
> >
> > Perhaps we should discuss the possibility of not
> > specifying any framing mechanism (FIM or COWS) in the
> > first version of iSCSI.
> >
> > The arguments for not specifying framing include
> > (there may be others as well):
> > 1) The brute force approach of putting TCP receiver
> > reassembly memory on the iSCSI NIC will work for both
> > 1Gbps and 10Gbps. Cost is incurred for memory chips,
> > ASIC pins, power, and board space. But, it is a
> > feasible approach.
> >
> > 2) I/O bus latency (or bandwidth limitations) could
> > mandate inbound buffering (as a 'smoothing' buffer)
> > from the iSCSI NIC to the host system. If this buffer
> > memory is large enough to have to be off-chip, then
> > it will require some minimum number of memory chips
> > to provide the necessary bandwidth, and the
> > memory/pins/power/space costs will be incurred
> > anyway.
> >
> > 3) Very large receive buffering on the NIC is only
> > required for high-bandwidth links traversing large
> > geographic distances (which may not be the
> > predominate case). These specialized implementations
> > can cost more (e.g. more memory/power/pins/etc) and
> > customers will likely be willing to pay accordingly.
> >
> > 4) Many NICs will likely aspire to be combo
> > iSCSI+TOE+Ethernet NICs allowing the host system to
> > use a single Ethernet port for all of its network
> > communications. The TOE function on this combo NIC
> > will already require TCP receive buffering and off-
> > chip buffer memory to support the existing sockets
> > interface receive model.  More importantly, to allow
> > senders to assume ownership of the buffer upon return
> > from a socket send call, the TOE NIC would need to
> > copy application send buffers into NIC memory as
> > well.
> >
> > 5) The framing/marker mechanism will be an iSCSI-only
> > solution. It is quite possible that the problem will
> > be solved via a different, and hopefully more
> > general, mechanism for other ULPs.
> >
> > 6) Both FIM and COWS are poor solutions for software
> > implementation. COWS requires, at a minimum, the
> > sender to read every word in the buffer. FIM either
> > imposes additional sender gather processing (iovecs)
> > or requires a data buffer copy (on systems that don't
> > support HW gather on sends).
> >
> > 7) Unless all senders thoroughly test framing/markers
> > now (i.e. unless the framing method is a MUST
> > implement), there is potential for future
> > interoperability problems as framing/marker receivers
> > are deployed in the future.
> >
> > 8) Neither FIM nor COWS is an elegant solution. Are
> > we comfortable with the legacy we are creating under
> > the umbrella of state-of-the-art IP networked
> > storage?
> >
> > 9) Is it essential to build in forward compatibility
> > now, or will there be a different solution in the
> > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI-
> > 2?  Will it be reasonable to update or bridge initial
> > 1Gbps deployments?
> >
> >
> > So, it would be good to hear from several iSCSI
> > NIC/chip implementors who:
> > - have or plan to implement FIM or COWS (or some
> > other framing mechanism) and take advantage of it to
> > minimize demands on on-NIC buffer memory
> > bandwidth/quantity.
> > - believe that all-buffers-on-chip solutions are
> > feasible and valid (wrt the points above, including
> > #2)
> > - can quantify the memory/pin/power/space cost
> > savings for all-buffers-on-chip solutions
> >
> > Jim
> >
>
>
>
>