TCP vs. UDP on SMP

Black_David@emc.com Sat, 16 September 2000 20:47 UTC

Return-Path: <owner-ips@ECE.cmu.edu>
Received: from ECE.CMU.EDU by cnoc.pdl.cs.cmu.edu id aa00073; 16 Sep 2000 16:47 EDT
Received: by ece.cmu.edu (8.9.2/8.8.8) id PAA01666 for ips-outgoing; Sat, 16 Sep 2000 15:53:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.9.2/8.8.8) with ESMTP id PAA01662 for <ips@ece.cmu.edu>; Sat, 16 Sep 2000 15:53:50 -0400 (EDT)
From: Black_David@emc.com
Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <SYT6MXP3>; Sat, 16 Sep 2000 15:53:06 -0400
Message-ID: <0F31E5C394DAD311B60C00E029101A0704C3568D@corpmx9.isus.emc.com>
To: cslee@FalconStor.com.tw, hufferd@us.ibm.com
Cc: ips@ece.cmu.edu
Subject: TCP vs. UDP on SMP
Date: Sat, 16 Sep 2000 15:53:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

>    A multithread program will use different cpu in different thread. For
example, we use one
> cpu for receving packets to receive queue and the other CPU for sending
packets from sending
> queue. Hence we can have more CPU power in iSCSI path. An UDP program with
its sending
> and receiving can archive this situation. I think this will give a
significant performance than TCP if
> TCP can't use both CPUs proccesing power.
> 
>   TCP process its own queue in kernel mode. And will this TCP queue is
processed with 2 CPU?

The situation is somewhat more complex than this.  iSCSI is REQUIRED to
implement
congestion control (for more information, see draft-floyd-cong-04.txt, which
is about to 
be issued as a Best Current Practice RFC).  UDP by itself does not implement
congestion
control, and adding this to UDP may affect SMP efficiency because congestion
control solutions
use information from the network (receive queue) to control transmission
(send queue);
this couples the receive and send processing in a way that tends to reduce
SMP
effectiveness.  My recollection of published results on using multiple
processors for
TCP in Unix-like operating systems is that the big gains come from using
different
processors for different connections rather than handling send and receive
on a single
connection on different processors due in part to the send/receive coupling
required
by congestion control ... but it's been a while since I've checked/read this
literature.

So, I think the summary Q&A is approximately:
Q1: Can a single TCP connection be processed by multiple CPUs?
A1: Yes.
Q2: Will this work as well as using separate CPUs to handle UDP send and
receive?
A2: Not in all cases, because TCP couples send and receive processing in a
way that
	UDP does not.
Q3: Is the UDP solution with independent send and receive processing on two
CPUs
	applicable to iSCSI?
A3: Probably not. It does not implement congestion control, and implementing
congestion
	control will result in some coupling of send and receive processing.

Let me remind everyone that while congestion control and flow control may
be implemented in roughly the same area of protocol code, they are rather
different functions.  Flow control is concerned with the effective (e.g.,
reliable
and high performance) delivery of individual flows of traffic.  Congestion
control
is concerned with the response of the entire network as a system to overload
conditions in which the network as a whole cannot deliver all of the offered
traffic.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------