This chapter describes the Common Internet File System (CIFS) protocol optimization module on the SteelHead. This chapter includes the following sections:

CIFS, also referred to as the Server Message Block (SMB) protocol, has been in existence since the early 1990s. The protocol provides shared access to files and printers, along with other communication between hosts on a network, including an authenticated Inter-Process Communication (IPC) mechanism. It is one of the most common protocols used for network file access by Microsoft operating systems.

The protocol originated as SMB and was created by combined work from IBM and Microsoft. SMB was initially designed to run on top of NetBIOS/NETBEUI but has run directly on top of TCP since the Microsoft Windows 2000 version. SMB was primarily a LAN-based protocol, which accounts for some of the challenges you see when it is used across WAN links. The rename and relaunch from SMB to CIFS occurred in 1996, which was the same time that Sun Microsystems announced WebNFS.

Although CIFS is known as the generic name for the protocol, technical discussions and documents continue to use the term SMB. Since the initial release of SMB, Microsoft has continued to change and enhance the protocol, each time assigning a new version number to SMB. The most recent versions are SMB2, SMB 2.1, SMB3, SMB 3.02, and SMB 3.1.1.

For information about SMB versions, see Overview of SMB Versions 2, 2.1, 3, 3.02, and 3.1.1.

RiOS has provided CIFS optimization since version 1.0, with ongoing enhancements in each subsequent version. CIFS optimization focuses on reducing the impact of WAN round-trip latency of common application and system behavior, including the Microsoft Office product suite, general file access, and remote printing. Ongoing work has been necessary to adjust to new incremental changes introduced to the protocol from Microsoft, typically with each new Microsoft operating system version. Additionally, new features have been added that enhance and broaden the applicability of the CIFS optimization.

RiOS includes optimization for SMB signed traffic. SMB signed refers to an optional feature in which the client and server, using the CIFS protocol, use cryptographic techniques to sign each protocol datagram exchanged in a CIFS session. This technique does not encrypt data passing through the network; it merely authenticates that the client and server receive datagrams that have not been modified by unauthorized middle devices. Through specific configuration and integration into the Windows security domain, RiOS can perform full latency and bandwidth optimization securely for SMB signed traffic, while still maintaining the end-to-end authentication that SMB signing was designed to achieve.

While SMB signing does not encrypt the data, SMB3 can encrypt traffic. If you use the correct RiOS release with the appropriate configuration settings, RiOS can continue to provide full-latency and bandwidth optimization while maintaining a secure client-server communication.

For information about configuring CIFS optimization, see the SteelHead Management Console User’s Guide.

This section describes the base CIFS protocol and how RiOS performs CIFS optimization. For example, for a client to access a file on a CIFS server, the following steps generally occur on the client:

After a connection to the server is established, client systems tend to leave the connection open for some amount of time, even when there are no open files by the client. This has an impact on CIFS optimization, because RiOS can optimize CIFS connections only when it detects the beginning of the CIFS connection. This is due to the negotiation of SMB options and SMB dialect that allow RiOS to understand what client and server operating systems are in use, which revision of the CIFS protocol is in use, and other options relevant to optimizing the connection.

The following table shows CIFS protocol commands that traverse the network during a session set up and subsequent simple file read.

This sequence represents the example protocol flow for a specific use case. Notice that SMB_COM_SESSION_SETUP_ANDX contains the user's authentication information. This is also particularly relevant when there are signed SMB sessions and Windows domains as part of the client-server environment. For details, see Windows Security Concepts.

READ_ANDX and other commands can be used (in some cases) several hundreds of times before the end of file is reached. There are many additional round trips across a WAN link that contribute to the overall performance degradation compared to the same operation across a LAN.

The CIFS protocol allows for different types of file locking and concurrent access to be used by client and servers. Separately, the CIFS protocol allows servers to notify clients (when requested) when they are the only client accessing a file, or when all clients for a file are performing only reads.

Requesting an oplock is when a client opens a potentially shared file and requests to be notified by the server when it is the only client accessing the file, or when it is accessing the file with other clients that are performing only reads (and no writes). When a client is granted an oplock on a file, it can perform some types of actions on the file completely locally, without notifying the server. Oplock breaks occur when servers notify a client if additional clients request access to the file and remote operations performed at the client must be synchronized with the server before granting that access.

The following types of oplocks are available:

Clients can request a specific type of shared-access control for a file when they open it. Examples of the types of shared access are do not share, share for read only, share for write only, or share for read/write. Clients can also apply more granular control by requesting locks on specific portions of a file, known as byte-range locks. The CIFS server tracks all of the access requests that it detects, and it grants or denies operations based on the requests from live clients. The shared access control, or shared mode access, is the most prevalent in most user applications. Typically, only database and similar applications can make use of byte range locks.

RiOS registers these concurrency controls: file locks, share access controls, and oplocks. The RiOS CIFS module tracks the state of every file opened between the client and server, and it uses this state to determine what types of optimized connections can safely be applied to file requests on the clients.

For example, when a client is granted an exclusive oplock on a file, RiOS can safely perform read-ahead and write-behind of file data because it is the only client accessing the file. Some of the CIFS features in RiOS enable more in-depth recognition of concurrency control, like the overlapping open optimization and the applock optimization feature.

The concurrency controls—file locks, shared-access controls, and oplocks—ensure that clients can coordinate their reads and writes in an orderly fashion. In particular, when a client wants to read from a file, it knows that reading from a local cache is safe (for example, through oplocks), or that its reads and writes are coordinated with other clients (for example, through byte range locks).

When a client wants to write data to a file, there are two modes of writing that are supported in CIFS environments: write-through and write-back. The application using CIFS can decide which of these two modes to use every time it needs to write.

For write-through mode, the process falls into a pattern in which the client sends data to the server for writing, waits for an acknowledgment from the server, sends some more data, waits, and repeats this process, until all the data is written and acknowledged. At this point the client sends a CIFS command to close the file on the server. The acknowledgment from the server that the file is closed signals that all data is safely written to disk. The server releases any lock on the file and makes it available for read-write access to other clients. Although this might be the safest way when writing data, when sending data across the WAN, it is not the most efficient method because the round-trip time across the WAN is typically several magnitudes higher than across the LAN.

Write-back mode is a form of optimization in which the client does not need to wait until the write is acknowledged before proceeding with the next operation. Synchronization is forced by the client flushing its cache or closing the file. Microsoft Word and Excel are good examples of applications that use CIFS in a write-back mode. If for any reason there is a problem when the file is closed, the user is informed and the data is recovered using the automatic save mechanism.

In write-back mode, there are several places where data can linger on its way to the disk: the client machine can gather writes, the server file system can delay pushing to disk, and even the server's physical disk subsystem can cache writes in RAID cards or on memory in the disk itself. RiOS provides another place for this temporary buffering between client and long-term storage to occur during write-back mode.

RiOS honors the client-specified write-back or write-through mode for each write operation. In general, most clients use write-back mode, because the performance of write-through mode—even on local disks, without the added performance impact of WAN based usage—is unacceptable to end users. RiOS can deliver fast write performance over the WAN in a way that is analogous to how file servers and network attached storage (NAS) appliances deliver fast write performance.

The CIFS protocol includes a feature to cryptographically sign every CIFS protocol datagram between the client and server. The file data that traverses the network is still sent in the clear, even when this option is used, so this CIFS feature does not protect against network snooping. However, it does protect against man-in-the-middle attacks.

The security signature feature is typically controlled through Windows group policy settings, with a separate client-side and server-side three-way setting that controls whether signing is used or not. This policy setting is then used during the initial CIFS session by the client and server to determine whether or not to sign their CIFS sessions. The following table shows the result when a client attempts to connect to a server—either the connection fails due to incompatible settings, or the session can sign the CIFS datagrams.

Several options are available for RiOS to optimize connections that are signed:

Since the initial release of SMB, Microsoft has continued to change and enhance the SMB protocol. These changes have usually coincided with the release of a new version of the Windows client and server operating system:

Using the appropriate version of RiOS, you can configure your environment so that full-latency and bandwidth optimizations are possible regardless of the SMB version or dialect.

Not all SMB features are relevant when considering optimizing SMB traffic with RiOS; however, consider the following features:

For more information about SMB3, see SMB3 Optimization with Windows 8, Windows 2012 Server, and Later Operating Systems.

Although the low-level detail of the CIFS protocol is beyond the scope of this document, there are many public reference materials available. For a starting point, go to http://media.server276.com/codefx/CIFS_Explained.pdf.

The CIFS optimization module comprises many separate techniques. Many of these techniques are enabled by default, so when configuring a new SteelHead (or creating a new SteelCentral Controller for SteelHead Mobile package), minimal, if any, CIFS-specific configuration is required.

Modern CIFS servers generally listen on TCP port 445; for compatibility, they also listen to port 139. The CIFS optimization module within RiOS is designed to intercept traffic on these two ports for acceleration of file-sharing and remote Windows printing traffic.

After a CIFS connection is intercepted for optimization, the RiOS CIFS optimization module monitors the negotiation and session setup commands to detect which client and servers are in use and what types of CIFS options are understood by each. As clients initiate requests to the server, RiOS applies its optimization techniques to reduce the time that the client awaits a response from the server.

For specific information about CIFS optimization features, see the SteelHead Management Console User’s Guide.