Subject: RE: iSCSI: No Framing

From: "Douglas Otis" <[email-masked]>
Date: Thu, 31 Jan 2002 20:33:15 -0800

David,

As this was an interim measure as expressed by many, it would seem unlikely
FIM would gain support in a stand alone draft at this time.  There did seem
to be several expressing a desire in finding a generic means.  I am in favor
of removing the section regarding FIM to reduce initial complexity and
thereby offering a cleaner legacy moving forward.

Doug

> I would note that the most likely approach to "Rip the sucker out"
> would be to declare framing to be experimental, allowing the framing
> text to be moved to a draft that could become an experimental RFC -
> it would not be necessary to bit-bucket the text and lose the
> work invested in it.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> [email-masked]         Cell: +1 (978) 394-7754
> ---------------------------------------------------
>
>
> > -----Original Message-----
> > From: Jim Pinkerton [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2002 6:22 PM
> > To: Amir Shalit; Mark S. Edwards; [email-masked]
> > Subject: RE: iSCSI: No Framing
> >
> >
> >
> >
> > I also agree with this approach. Consensus is still a way out,
> > significant work is being done on various fronts to solve some of the
> > fundamental issues blocking consensus, and we should not
> > block the iSCSI
> > spec waiting for consensus.
> >
> > Rip the sucker out.
> >
> >
> > Jim
> >
> >
> >
> > -----Original Message-----
> > From: Amir Shalit [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2002 12:29 PM
> > To: Mark S. Edwards; [email-masked]
> > Subject: RE: iSCSI: No Framing
> >
> > In second thought this is the preferred solution for now. Not
> > selecting any type of framing until more progress at the transport
> > level which may include running iSCSI on a modified TCP protocol etc.
> >
> > Amir
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Mark S. Edwards
> > Sent: Thursday, January 31, 2002 9:49 AM
> > To: [email-masked]
> > Subject: Re: iSCSI: No Framing
> >
> >
> > At 10:46 PM 1/29/2002 -0800, WENDT,JIM (HP-Roseville,ex1) wrote:
> > >Perhaps we should discuss the possibility of not
> > >specifying any framing mechanism (FIM or COWS) in the
> > >first version of iSCSI.
> >
> > Nicely put Jim.  My current opinion is that this issue has contributed
> > to a
> > delay in getting this spec out in to the wild.  This issue MUST be
> > closed
> > next week and I don't see anything close to a consensus.  My preferred
> > approach is to drop this issue now and to look at it at a
> > later date in
> > terms of an IPS re-charter when we get to thinking about version 2 of
> > iSCSI
> > or have some good approaches proposed by the tsvwg or the RDMA WG.
> >
> > Mark.
> >
>

---

From: "Rod Harrison" <[email-masked]>
Date: Fri, 1 Feb 2002 13:26:53 -0000

Wind River is in favour of this also.

	- Rod

  >  From: [email-masked] 
  >  [mailto:[email-masked]]On Behalf Of
  >  Jeff Fellin
  >  Sent: Thursday, January 31, 2002 11:30 PM
  >  To: [email-masked]; [email-masked]
  >  I agree with Amir's idea about removing the marking and 
  >  message sync and
  >  recovery is no where near resolution. Removal should 
  >  allow the rest of the
  >  iSCSI draft to reach consensus.
  >  
  >  Jeff Fellin

---

From: "Prasenjit Sarkar" <[email-masked]>
Date: Sun, 3 Feb 2002 19:22:55 -0800

Hi Pat,

I had a few questions about your 10 Gbps example. If we assume that this is
a single TCP stream, I would like to know which application in the near and
forseeable future can sustain a 10 Gbps data rate for a reasonable amount
of time? Or if they are multiple TCP streams, are you assuming packet drops
in all streams simultaneously?

Thanks,

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                      "THALER,PAT                                                                          
                      (A-Roseville,ex1)        To:       "WENDT,JIM (HP-Roseville,ex1)"                    
                      "                         <[email-masked]>, [email-masked]                        
                      <pat_thaler@agile        cc:                                                         
                      nt.com>                  Subject:  RE: iSCSI: No Framing                             
                      Sent by:                                                                             
                      [email-masked]                                                                    
                      .edu                                                                                 

                      02/03/2002 03:01                                                                     
                      PM                                                                                   

Jim,

In answer to your questions:

Agilent is planning to implement framing. We view both FIM and
COWS as having about the same utility so we would implement
whichever one went into the standard.

A smoothing buffer on the chip is feasible wrt your point 2.
There are some configurations that would use external memory.

Also, one concern is that the very situation where one would
need large window size for efficiency - high bandwidth long
distance communication - is where out of order receipt becomes
increasingly likely so the amount of memory for this situation
could push up cost to an excessive extent.

Reducing the amount of traffic that has to be shunted to an
external memory affects the bandwidth that needs to be provided
for that memory. If we can handle most PDUs internally then the
external memory doesn't have to be as wide and as fast. For
instance, if a drop means that the iSCSI PDU with the drop
is put into external memory then that takes less memory bandwidth
than if a drop means the whole data stream for that session will
be going into the buffer until the hole is filled.

This decision also effects latency after a drop and required
backplane bandwidth.

Let's say one is on a 10 Gbit/s extreme long distance WAN
connection and that there is a drop. If the round trip delay
for getting the whole filled is 100 ms, then without framing,
one could have about 1 Gbit stored in the local buffer memory
by the time the hole is filled. One will have to process all
of this through iSCSI and across the backplane before one can
deal with the new traffic coming in. If the backplane data rate
is closely sized to the external data rate, an extra 100 ms latency
has just been inserted into the path until traffic slacks off.
(Congestion control might mitigate this to the extent that one
is talking to just one source, but with multiple sessions, one
will still have to keep up.) To get the buffer emptied to make
space for further drops and to get the latency back down, one
will have to size the backplane bandwidth wider and have the
iSCSI engine process at a higher data rate.

With FIM or COWS, one can end the incident with much less data
in the buffer as one processes PDUs after the hole while waiting
for it to be filled. Then, when the hole is filled one just has
to process a small amount of data to catch up.

Regards,
Pat Thaler

-----Original Message-----
From: WENDT,JIM (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 10:47 PM
To: [email-masked]
Subject: iSCSI: No Framing

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

---

From: Dennis Young <[email-masked]>
Date: Mon, 4 Feb 2002 11:02:05 -0800

Hi Rod,
Your are correct for the situation where there is only one iSCSI session.
One of the benefits of framing is that when there are multiple sessions, 
a hole in one session won't hold up the other sessions.
Dennis

>From: Rod Harrison [mailto:[email-masked]]
>Sent: Monday, February 04, 2002 8:36 AM
>To: THALER,PAT (A-Roseville,ex1); WENDT,JIM (HP-Roseville,ex1);
>[email-masked]
>	Framing of any kind is not a panacea allowing for 
>almost buffering
>free target implementations, it can only move the buffering from the
>transport layer up to the iSCSI layer. Remember that the target MUST
>guarantee commands are delivered to SCSI in the command sequence
>number order. This means if a dropped packet contains an iSCSI command
>PDU you are going to have to buffer until the CmdSN hole is plugged.
>
>	Consider the example of an initiator filling the command window,
>perhaps sending CmdSNs 1 through 100, possibly along with immediate or
>unsolicited data for some of the commands. If the packet dropped
>contained the command PDU for CmdSN 50 then the target iSCSI layer
>must buffer CmdSNs 51 through 100 and their associated DATA_OUT PDUs.
>Since you can continue to process any DATA_OUT PDUs for CmdSNs 1
>through 49 the buffering required is reduced, but not eliminated,
>
>	Only if the packet dropped contains DATA_OUTs and no 
>command PDUs can
>you continue processing past the hole while waiting for it to be
>filled. You can R2T for data associated with commands after the hole
>but that serves only to potentially decrease recovery time, not reduce
>buffer requirements.
>
>	Don't get me wrong, I'm not saying framing isn't a good 
>thing but it
>is only one piece of the puzzle.
>
>	- Rod
>
>THALER,PAT (A-Roseville,ex1)
>Sent: Sunday, February 03, 2002 11:01 PM
>To: WENDT,JIM (HP-Roseville,ex1); [email-masked]

---

From: "ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 5 Feb 2002 08:00:31 -0800

Not trying to be obtuse but how does it help if only the NIC vendors
implement it? (I know you didn't precisely say that)

It sounds like we may end up with NIC vendors implementing it and storage
vendors ignoring it or some mix. In the end we will have a fracture in the
market place and/or all vendors will be forced to implement FIM to satisfy
customer demands ("my NIC supports FIMs, you don't, things are SLOW, you
must be at fault", etc.).

To me it sounds like FIMs needs to be SHOULD/MUST or not in the standard at
all (moved to a secondary document).

I personally would like to see FIM (and COWS) moved from the standard to a
secondary document but that is just my gut level opinion on this issue. I do
think FIM blurs the layering of TCP/IP, which is not normally desirable.

Regardless it would be worthwhile for a document describing how to fire
iSCSI over SCTP or other IP backed transports that are better suited for
iSCSI style data and high speed/long distance links. (Please excuse my
ignorance is such drafts already exist)

-Shawn

-------------------------------------------------------
 Shawn Carl Erickson

> Sent: Tuesday, February 05, 2002 6:53 AM
> To: John Hufferd; [email-masked]
> Cc: Mukund, Shridhar; [email-masked]
> 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. 
> 
> 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

---

From: "Mukund, Shridhar" <[email-masked]>
Date: Tue, 5 Feb 2002 09:42:37 -0800

Shawn,

We would love to sell FIM enabled HBA's to you :-)

-Shridhar Mukund

-----Original Message-----
From: ERICKSON,SHAWN (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 8:01 AM
To: [email-masked]
Subject: RE: iSCSI: No Framing

-Shawn

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 5 Feb 2002 21:56:42 +0200

Not exacly markers - those appeared in Haifa-summer of 2000 but something 
similar - aligned PDUs.

Julo

"Somesh Gupta" <[email-masked]>
Sent by: [email-masked]
05-02-02 21:20
Please respond to somesh_gupta

        To:     John Hufferd/San Jose/IBM@IBMUS
        cc:     "Jim Pinkerton" <[email-masked]>, "Mukund, Shridhar" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: iSCSI: No Framing

John,

I have to point for the record, that I was the one
that proposed markers over a year ago (not that many
other did not also have this idea). I have also tried
to keep this debate at a technical level. There
are reasonable folks on both sides of the debate,
and we should just continue in that spirit.

Somesh

> From: John Hufferd [mailto:[email-masked]]
> Sent: Tuesday, February 05, 2002 10:55 AM
> To: [email-masked]
> Cc: Jim Pinkerton; Mukund, Shridhar; [email-masked]
> 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: [email-masked]
>
>
> "Somesh Gupta" <[email-masked]> on 02/05/2002 
10:25:45
> AM
>
> Please respond to <[email-masked]>
>
> To:    "Jim Pinkerton" <[email-masked]>, John Hufferd/San
>        Jose/IBM@IBMUS
> cc:    "Mukund, Shridhar" <[email-masked]>, 
<[email-masked]>
> > Jim Pinkerton
> > 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.
> >
implementation
>   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.
> >
> >
> >
> > From: John Hufferd [mailto:[email-masked]]
> > Sent: Friday, February 01, 2002 11:31 PM
> > To: [email-masked]
> > 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: [email-masked]
> >
> >
> > "Somesh Gupta" <[email-masked]>@ece.cmu.edu on
> > 02/01/2002 07:10:13 PM
> >
> > Please respond to <[email-masked]>
> >
> > Sent by:    [email-masked]
> >
> >
> > To:    "Mukund, Shridhar" <[email-masked]>, "'WENDT,JIM
> >        \(HP-Roseville,ex1\)'" <[email-masked]>, <[email-masked]>
> > cc:
> > 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
> >
> > > Mukund, Shridhar
> > > Sent: Friday, February 01, 2002 5:24 PM
> > > To: 'WENDT,JIM (HP-Roseville,ex1)'; [email-masked]
> > > 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 :-) :-) :-)
> > >
> > > 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?
> > >
> > >

---

From: "Uri Elzur" <[email-masked]>
Date: Tue, 5 Feb 2002 15:38:26 -0800

Jim

I'd like to add our input to the "live discussion" (hoping we can reach
broader consensus and closure in the Interim):

We've analyzed the various proposals for long time. As the fundamentals of
iSCSI is transmitting  messages on top of a byte stream mechanism i.e. TCP,
we share the views it needs to be addressed in a standard way. The preferred
way to do it has been a generic Framing on top of TCP, but the recent IETF
decisions has made it clear that this will not be available for some time,
at least not on top of TCP.

Therefore, we're back to square zero. iSCSI is better served with a Framing
support that enjoys vendors support and that can also prevent a slow
Initiator from placing high buffering requirements on a fast Target, running
at 1Gb/s or 10Gb/s. So my conclusion has to be that IPS is better off with
adoption of Markers that are not hard for HW or SW.

FIM vs. COWS: FIM is preferred. COWS will drag the group to even more
discussions on mode selection and impact on SW Initiators. We should leave
room for negotiation of another Framing mechanism in the future, that may be
the result of the TSVWG group efforts.

SHOULD vs. MAY vs. MUST: we may have enough support in the WG for a MUST,
but it seems to me that the bare minimum is to make sure FIM is supported
without introducing interoperability risks. But if there isn't enough
support for a MUST, at least we need to make sure the spec is very clear on
Framing. Hence, the bare minimum is that Framing support is integrated into
the Login negotiation and the all mechanics nailed down (e.g. FIM
initialization, edge cases e.g. Marker inside the iSCSI PDU header etc.)

thx

Uri
-----Original Message-----
From: WENDT,JIM (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 10:47 PM
To: [email-masked]
Subject: iSCSI: No Framing

Jim