Steelhead Appliance

[philrzewski]

We've been doing testing with Vista since it was released and have also been testing with each Windows Server 2008 (Longhorn) beta as they come out. From what we've seen nothing has changed with regards to how signing is handled in SMB2. That is, just like with SMB1, in default client/server configs, signing will not occur between clients and member servers, but would occur between clients and domain controllers. We've also not seen any documentation from Microsoft that would indicate that these defaults are set to change. If you've seen anything from Microsoft that contradicts this please do post a link. Thanks!

[uptime]

Hello,

I've also heard that SMB2 would provide security enhancement as SMB signing. Apparently, this security check will be applied by default in Vista and Longhorn. However, I do not know currently if the security level will be set to ENABLED or set to REQUIRED (??)

My company already planned a longhorn migration next year. I would like to be sure we can still provide optimization for file sharing or if I MUST modify GPO in Active Directory to disable SMB Signatures.

Thank you
Carmen.

[bgilbert]

Interesting write-up in Network World covering the topic of Vista performance over the WAN

http://www.networkworld.com/supp/2007/ndc4...erformance.html

[philrzewski]

Regarding SMB2 traffic with current RiOS versions (such as v4.0.1), the Steelhead recognizes that it's SMB2 and backs off from trying to do any app-level (CIFS) optimizations. Depending on the log level you have configured, you can expect to see this message in the log when first making an SMB2 connection (such as when connecting to a share):

May 14 21:55:57 Got SMB2 pkt during INITIALIZING state. Turning OFF CIFS optimizations.

At this point the SMB2 traffic will still be optimized, but using only Data Streamlining and Transport Streamlining. In general the degree to which this approach is effective is somewhat dependent on the app protocol. For instance, with bulk TCP trasnfer protocols like FTP, Data Streamlining and Transport Streamlining alone are enough to give LAN-like performance. While SMB2 is less chatty than most app-level protocols (way less chatty than, say, Novell Netware Core Protocol) it's still not quite as "WAN-friendly" as something like FTP, so the improvements will be good but still not quite "LAN-like".

I'll illustrate this with yet another chart. Using the same GigE / 100 ms RTT simulated WAN and drag & drop test case, I performed Steelhead-optimized cold/warm cycles. Whereas the Unoptimzed runs came in at 5-10 seconds as we revealed earlier, we found the optimized Cold runs came in at a steady 3.5 seconds and the Warm runs at 2.5 seconds (these results averaged across 5 runs). The WAN utilization is shown in the following plot:



As you can see, the Cold and Warm optimizations to SMB2 are definitely an improvement to the Unoptimized runs (and we use less bandwidth in the process, of course), but we're still not quite as "LAN-like" as for when we could do Application Streamlining for CIFS in the XP/2003 environment. For instance, a true Unoptimized LAN speed GigE run (no latency) of this same test clocks in at 0.5 seconds. That means there's still room for improvement, and that's why we intend to address it.

As you agreed, the "bandwidth is free" argument only goes so far, so for sake of comparison I also took Unoptimized, Cold, and Warm runs with my bandwidth capped at T1 (still 100 ms RTT latency). Because of the bandwidth constraint, the Unoptimized run took about 73 seconds. Since we could do some Data Streamlining in the Cold run (first-pass compression) we were able to bring that down to 8.2 seconds and then 2.8 seconds in the Warm run. Once again, the WAN utilization plot is included to illustrate this.



As usual, some "it depends" applies here, since variations in bandwidth, latency, file compressibility, and use case (e.g. inside-the-app vs. drag & drop) may all contribute to different results both in the Unoptimized and Optimized cases. However, I think the results shown here are representative of a simple use case we can all relate to.

Regarding time frame to address Application Streamlining for SMB2, we're currently planning a two-phase approach with the first phase coming this year and the next phase in 2008. If you need more detail it would be best to set up a roadmap presentation under NDA with the Riverbed regional sales manager in your area.

Let me know if you have any additional questions.

Message Edited by bgilbert on 01-28-2009 04:14 PM

[fendesj]

Phil, thanks for the info. SMB2 sounds like a step in the right direction from a protocol point of view although the variability in your results is curious. The Steelhead still provides great results. As you correctly point out most of us still deal with T1 or less so bandwidth reduction and performance improvements are important. I am interested in what will happen when a current Steelhead sees SMB2 traffic and what the time frame is for supporting SMB2.

[philrzewski]

Apologies for the delay before continuing this thread. A lot of my previous testing had been performed using the "February 2007 CTP" Longhorn release as my server platform, but the Longhorn "Beta 3" had come out just as this thread was starting up. I had presented some of my prior results to Microsoft and one of their suggestions was that I re-run my tests on the Longhorn Beta 3. So far, my re-runs seem to show similar performance, so it seems reasonable to start sharing numbers.

Many of the papers published by Microsoft and referenced by analysts point to improvements in the TCP stack and reduction in the chattiness of SMB2. In a world where TCP could always make use of available bandwidth and app protocols are not chatty, you'd be able to get LAN-like performance only if you had unlimited WAN bandwidth. Despite the predictions for some time that "bandwidth is free" (or soon will be), I can say that the T1 (1536 kbit/sec) remains the standard for branch office connectivity for most customers I speak with, so it looks like bandwidth still isn't free and won't be for some time. Therefore, while it's a valid exercise to consider TCP/SMB2 efficiency improvements without regard for bandwidth, I'd like to note for the record that the results may not be directly applicable to many environments.

Nevertheless, for the sake of argument let's assume the "bandwidth is free" premise. I set up a test lab with client systems running XP and Vista and server systems running Windows 2003 Server and Longhorn Server Beta 3. For my WAN I simulated a GigE pipe (so, effectively unlimited bandwidth) but with 100 ms round-trip latency (typical of a cross-oceanic link).



As a simple first test, I performed drag & drop operations of a 6.3 MB Excel file in both the XP/2003 environment and the Vista/Longhorn environments. What we found in the XP/2003 environment is that the transfer time was about 20 seconds, and this is due in large part to the fact that the chattiness of CIFS prevents the use of the available bandwidth. Performing the same operation in the Vista/Longhorn environment, we saw some improvement, though it was not dramatic and in fact somewhat inconsistent. While we found that the SMB2 protocol seemed to "ramp up" to use available bandwidth where CIFS did not, by no means did it ramp up as aggressively as we'd expect with a truly "WAN-friendly" TCP protocol. In fact, we found that sometimes this ramp-up was somewhat timid (resulting in a total transfer time of ~10 seconds) and sometimes more aggressive (resulting in a total transfer time of ~5 seconds). The charts below include four sample runs for the Vista/Longhorn case (showing two instances of the "timid" behavior and two "aggressive" runs).



We found this strange enough that we repeated the drag & drop 30 times and found this to always be the case: Sometimes it would take 10 seconds, sometimes 5 seconds, and it didn't seem to make any difference how long we waited between transfers.



Overall, the Vista/Longhorn results show improvement compared to XP/2003, but it's not what we'd call dramatic improvement, and in my opinion would be a stretch to consider 2-4x improvement "LAN-like". By comparison, introducing Steelheads into the XP/2003 (CIFS) environment, a cold (first pass) run with Steelhead optimization came in at 1.6 seconds and a warm (second pass) run came in at 0.5 seconds. This speaks to the power of an approach that not only removes all unnecessary TCP and app-level chattiness but performs Data Streamlining to minimize how much has to traverse the WAN. Indeed, because so much Data Reduction was performed on the warm pass, the sub-second result would be as true for a tiny link as it was for this GigE link, while the same cannot be said for the 2-4x improvement we saw from Vista/Longhorn.

Finally, as for the question of whether supporting SMB2 would be a large effort for Riverbed, you can be sure it's not an overnight job, but we're obviously proud of our engineering talent and we think we have a record of delivering . If you look at the RiOS v1.0 product, our Application Streamlining support basically consisted of CIFS and MAPI2000. In subsequent releases we've delivered support for MAPI2003, MS-SQL, NFS, HTTP, and so forth. While SMB2 is in many ways "new", our existing expertise in working with CIFS puts us in a good position to extend our support to SMB2.

I have some other results that include "inside-the-app" operations for MS Office and AutoCAD, but rather than flood the board, I'd be interested to hear if folks have questions or comments on these results before I post more. Thanks!

Message Edited by bgilbert on 01-28-2009 04:12 PM

Message Edited by bgilbert on 01-28-2009 04:13 PM

[fendesj]

Not sure if they were referring to the new "sync" feature or not. I would be interested in any SMB2 lab results you have. I would imagine supporting SMB2 must be a fairly large effort for Riverbed?

[philrzewski]

Steve,

Based on your description, a Vista feature that rings a bell is the new & improved "sync". There's a description of it here:

http://windowshelp.microsoft.com/Windows/e...5769971033.mspx

If you think that's what your vendor was talking about, I can offer some analysis on the pros and cons of such an approach.

[philrzewski]

not-a-network-guy,

As you're no doubt aware, Vista/Longhorn is a potentially huge topic. While Riverbed has been asked on occasion for our "response to Vista/Longhorn", there's no one-line answer that's as easy as the one-line question. It really needs to be broken down, and a lot of it still needs to play out because the ink isn't even dry: Longhorn just went into Beta 3 and isn't due to be released until the late in 2007.

I'll try to sum up in the shortest answer possible. We at Riverbed certainly do acknowledge that Microsoft has made a number of improvements in Vista/Longhorn, and some of those improvements touch the area of WAN performance. However, we do not see those improvements fully solving the general issue of WAN performance, and so we see Vista/Longhorn and the associated protocols/apps as yet another set of performance challenges to address, and you can count on us to address them.

Allow me to expand on that with a little historical perspective. Riverbed's RiOS v1.0 initially focused on Data Streamlining (to help all TCP apps), Transport Streamlining (again, for all TCP apps), and Application Streamlining for CIFS and MAPI2000 (Windows File Sharing/Exchange e-mail). A short time later, the release of Outlook/Exchange 2003 saw the arrival for the MAPI2003 protocol, and this was accompanied by similar fanfare that the WAN performance issues of Exchange were solved forever. However, customers and their IT departments told a different story. This led Riverbed to create our Application Streamlining module for MAPI2003, and since that time customers have seen great benefits from it. You can assume that Riverbed sees Vista/Longhorn and the coming of SMB2 in a similar way: While SMB2 claims performance improvements (and our early tests have shown it can provide some benefit in some cases), we can already tell that SMB2 alone will not provide customers with the LAN-like performance they've come to expect from the combination of CIFS+Steelheads. As a result, you can be certain that Riverbed will be addressing SMB2 performance issues just as we've done for CIFS, MAPI2000, MAPI2003, MS-SQL, NFS, ...

That's a short answer and somewhat specifically directed at the question as relates to SMB2. In fact, I haven't even gotten into specific SMB2 use cases, and you can imagine there's plenty. If there's particular use cases/protocols/scenarios on your mind, let me know and I'll tell you what we've found thus far. In fact, I have some SMB2 lab test results I could post if folks want to see, but I did not want to overwhelm in my first post.

[fendesj]

I had this same piece of FUD dropped on me by a Vendor trying to sell boxes that sort of do what the Steelheads do except for the SDR part (no data store). They do QoS and TCP optimizations and made the point they don't need a data store because Longhorn/Vista will have this built in. The most I could get out of them was that client Vista machines would cache large amounts of data. I don't think they really knew all the details. If this is the case it still doesn't address data access by by multiple users (if one user has cached data how do the others benefit), or data accessed by non-CIFS protocols. I would be interested in more details about this and in a response from Riverbed about how it may impact CIFS and Steelheads. Anyone have details?