Subject: "Lower overhead" iSCSI

From: [email-masked]
Date: Tue, 29 Jan 2002 16:29:44 -0600

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")?

Thanks,
Dan

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 30 Jan 2002 08:33:53 +0200

Dan,

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.

Julo

[email-masked]
Sent by: [email-masked]
30-01-02 00:29

        To:     [email-masked]
        cc: 
        Subject:        "Lower overhead" iSCSI

                 The attempt here is to maintain low CPU utilization at 
high
performance rates.  While I realize that these TOE devices are moving 
along
received out of order and the ULP (SCSI) must resend the cmd/data sequence 
-
                 So my question is:  is this feasible?, and why not 
implement an

Thanks,
Dan

---

From: [email-masked]
Date: Thu, 31 Jan 2002 10:34:40 -0500

Some comments from an IETF perspective:

(1) The IETF does not standardize protocols that are intended only
	for use in private networks, especially when the topology of
	those private networks has to be limited to ensure proper
	operation.
(2) The best intentions to restrict use of a protocol to
	such private networks often go awry - if the protocol is
	seriously useful, it will get used in other places.
(3) IETF will only consider standardization of an iSCSI over UDP
	protocol when TCP-equivalent/friendly congestion control
	is included.  This is not negotiable - don't even ask.
(4) The NFS experience should be considered - NFS was originally
	specified to run over UDP, but most NFS servers in use
	today run over TCP due to its better behavior on real
	networks.  The TCP vs. UDP performance deltas for NFS
	are not that large even when the CPU is saturated.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 5:30 PM
> To: [email-masked]
along
-