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

    Re: "Lower overhead" iSCSI


    We don't want start this discussion - it is out of the charter of this group.
    A bit of advise - before even getting to the public - we at IBM did run a testbed with the following results:
    • no advantage for UDP on any relevant performance metric (including CPU utilization) even before considering the effects or recovery code
    • on most stacks it performed worse (rumor has it that stacks have TCP very well tuned, not so UDP)

      Adding to that the lack of congestion control took it out of our vocabulary.

      DCP if successful and widely deployed may change that in the future. Or SCTP may.


      Sent by:

      30-01-02 00:29

              Subject:        "Lower overhead" iSCSI


      Let me start off by saying that I am interested in doing "iSCSI" protocol
      over UDP.  Now I realize that this is an old issue and will probably start
      some "religious" battles, but let me state the scenarios before I receive
      death threats.  The planned environment that this will go into is a small
      one with say 10 servers connected through a "non-blocking" switch to the
      storage device (ie no routers, gateways, etc...just direct point-to-point
      connections).  This is assuming that the switch is really non-blocking and
      hopefully implements flow control or pause frames.  So technically all you
      should have to worry about is port/device contention.  However, when you
      think about it...this is similar to FC.  FCP runs on class 3 FC which is a
      non-reliable transport protocol such as UDP and handles contention, also
      some of the early "SAN interconnect" guys are doing this today with
      relatively good performance and few issues.
                      The attempt here is to maintain low CPU utilization at high
      performance rates.  While I realize that these TOE devices are moving along
      rapidly, there are some situations where they are not feasible, such as a
      blade server environment (no PCI slots, and no real estate/power available
      for onboard TOE).  Worst case scenario is that a packet is dropped or
      received out of order and the ULP (SCSI) must resend the cmd/data sequence -
      still no data lost, just a temporary performance hit.
                      So my question is:  is this feasible?, and why not implement an
      "iSCSI" protocol layer that can run over TCP or UDP(though I realize it
      won't be considered "standards compliant")?



Last updated: Thu Jan 31 11:17:59 2002
8574 messages in chronological order