SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: "Lower overhead" iSCSI



    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: Dan_McConnell@Dell.com [mailto:Dan_McConnell@Dell.com]
    > Sent: Tuesday, January 29, 2002 5:30 PM
    > To: ips@ece.cmu.edu
    > 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")?
    > 
    > Thanks,
    > Dan
    > 
    


Home

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