Windows Core Networking : WinHEC

From WinHEC to Black Hat USA 2006

wndpteam — Sat, 19 Aug 2006 01:24:00 GMT

It’s been several weeks now since WinHEC, and we’ve been hard at work on RC1 work for the NetIO networking stack in Windows Vista and Windows Server Code-Name Longhorn. It was really great to meet with so many of the folks who’ve been partnering with us in changing the face of networking!

I was at Black Hat USA 2006 in Las Vegas earlier this month, where I got a chance to talk about some of the work we’ve been putting into the Windows Filtering Platform (WFP) which makes the NetIO stack’s activity more transparent, and provides more direct control over its operation. While I was there, I met Tim Newsham, who is one of the authors of a Symantec report on the security of the NetIO stack in Windows Vista. Their initial work was done on build 5270 where they found a few issues. When they moved to the Beta 2 build of Windows Vista to update the report, they found that virtually all of the issues had been addressed as part of our routine ongoing Security Development Lifecycle (SDL) process! Tim is at iSEC Partners now, a firm that has also done some work with us on the IP security capabilities in Windows. Tim’s colleague Jim Hoagland is still at Symantec, working on an update to the report, and we’ll be helping him out as that develops.

Tim and I both laughed about some of the feedback that followed from their report. For me, it was particularly interesting to read stories where the NetIO stack is referred to as “new”. We’ve had the stack up and running since 2003, so for us it’s already old and familiar. In that time the stack has been maturing and running in a wide variety of environments that, put together, probably equate to several years of operational experience for any other networking stack.

Even more interesting is the little-known fact that several of the security improvements that we shipped for networking in Windows XP SP2 were actually back-ported to XP from the NetIO stack. As a result, what we’re doing in Windows Vista really predates, continues and deepens the security focus that went into Windows XP SP2. We’ve got lots more to come, so stay tuned and, as always, keep the feedback coming.

-Abolade Gbadegesin

The NDIS 6.0 Driver Model

wndpteam — Mon, 15 May 2006 21:00:00 GMT

NDIS 6.0 was introduced to the independent hardware vendor (IHV) and developer community at last year’s WinHEC. It brings the promise of greater performance, improved manageability, reduced complexity for NDIS miniports, and simpler models for writing intermediate and filter drivers. Are you curious how much of the promise has been realized?

At WinHEC this year, I’ll demonstrate network adapters which maximize network throughput with lower CPU utilization—all by moving to the NDIS 6.0 model. NDIS 6.0 miniport drivers have demonstrated 20% performance improvements over NDIS 5.1 miniport drivers!

Here are some examples of the feedback we’ve heard from some of our partners inside Microsoft, citing how NDIS 6.0 has made a difference in their scenarios.

Example 1: Pacer, the packet scheduling and shaping component of the Policy-based Quality of Service feature

The old Windows Packet Scheduler (PSched) was originally an NDIS 5.0 intermediate miniport. The new Windows Packet Scheduler (Pacer) uses the NDIS 6.0 lightweight filter model, resulting in better performance with lower overhead. In previous releases, enabling PSched in passive mode resulted in a 10% increase in CPU utilization. On Windows Vista, by contrast, enabling Pacer in passive mode results in an increase of only 0.5% in CPU utilization.

Example 2: Network Load Balancing (NLB)

The NLB development team told us that porting NLB from the intermediate miniport model to the lightweight filter model resulted in simpler code that was much easier to debug.

Example 3: Media Streaming and Interrupt Moderation

As the Quality of Service development team can attest, the OIDs for enabling and disabling interrupt moderation make a big difference in accurately measuring available bandwidth, which is key for smoother media streaming in home networks.

Want to see the improvements for yourself? Drop by the WinHEC Hardware showcase at the NDIS 6.0 booth to learn more about what the NDIS 6.0 model has to offer. Have questions for us on how the model works? Leave us a comment in response to this posting.

Aarti Bharathan

Program Manager, Core Networking

Extend Windows Vista Wireless

wndpteam — Fri, 12 May 2006 16:00:00 GMT

As we worked on the Windows Vista Wireless Stack, extensibility was one of our key design goals. On previous releases, we’ve gotten a lot of feedback from hardware and software developers on how they’d like to be able to extend the wireless experience. With the new stack, we’ve tried to address as much of that feedback as possible, and we’d really like to hear what you think on how we’ve done.

The new stack supports two levels of extensibility: extensions for independent hardware vendors (IHVs) and Wireless LAN API for application developers or independent software vendors (ISVs).

IHV Extensions

These enable IHVs to implement new features and standards within the Native Wi-Fi framework at a pace which is in line with the rate of innovation in the industry.

IHV Extensions can control IHV specific connectivity settings, such as transmission power control, WMM admission control, 802.11n aggregation control, and so on.

IHV Extensions can also implement IHV specific wireless security protocols, which can be either 802.1x based or non-802.1x based. For 802.1x based authentication, IHVs can choose to implement IHV-specific cipher key derivation modules or reuse the Windows Vista 802.1x implementation.

IHV-specific settings are managed on a per-network profile basis. Therefore, IHVs can use different settings when connecting to different wireless networks.

Wireless LAN API

The Wireless LAN Win32 API enables developers to build applications that manage wireless adapters, wireless connections, and wireless profiles. The APIs consist of the following functionalities:

Profile Management API: Applications can enumerate wireless LAN profiles, add new profiles, replace/delete existing profiles, change profile order, and retrieve profile settings.

Notification API: Applications can register for wireless event notifications such as radio on/off change, scan completion, visible network changes, connection, and roaming.

Operational API: Applications can request the adapter to scan, connect/disconnect to/from a wireless network and query attributes of the current connection.

In the WinHEC 2006session “Extending Windows Vista Native Wi-Fi Capabilities”, we’ll describe the Wireless LAN APIs in details. We plan to have a demo “Site Survey” that illustrates the use of the APIs, and walks through real live code. To learn more, just post comments here, and be sure to come and join us at WinHEC 2006. Right away, you can start thinking about cool wireless applications that you want to build with the new wireless APIs, as well as API enhancements that you want to see in the future.

Jiandong Ruan

Software Development Engineer, Wireless Networking

Providing 802.1x Enforcement for Network Access Protection

wndpteam — Wed, 10 May 2006 23:30:00 GMT

We’re living in a highly connected world, where a large number of diverse devices gain access to the corporate environment using diverse technologies like wireless, wired 802.1x, virtual private networks (VPN), and more. Though this diversity is a great enabler allowing end users to always have up-to-date information at their fingertips, it creates a very challenging situation for enterprise IT administrators. Enterprise IT administrators don’t want to prevent access to their users, but they also don’t want to leave their networks exposed to threats. Often, these threats are not from malicious hackers, but from users who inadvertently bring authorized but unhealthy machines into corporate networks. Network Access Protection (NAP – http://www.microsoft.com/nap) addresses this by enabling IT administrators to govern a machine’s network access based on its compliance with corporate security policies.

NAP provides an extensible platform that enables both independent software vendors (ISVs) and independent hardware vendors (IHVs) to provide differentiated value in NAP deployments. NAP enables two kinds of extensions. First, it allows endpoint security software (e.g. patch management, anti-virus, anti-spyware, etc.) to flexibly define what it means for an endpoint to be compliant. Second, it enables network and security systems to provide restrictions on non-compliant endpoints. It accommodates a wide variety of enforcement mechanisms, including wireless protocols, firewalls, gateways, switches, routers, bump in the wire devices or even unique mechanisms that you might conceive of. In fact my challenge to you is to come up with answers for:

1. What would be some new ways in which you would want to enforce NAP?

2. What are some different mechanisms that you would want to be considered as part of the definition of health of a system?

My talk at WinHEC primarily focuses on NAP as relates to 802.1x (both wired and wireless). I will be talking about how both ISVs and IHVs can leverage our NAP platform to provide unique value to their customers. In Windows Vista and Windows Longhorn Server, we are making it easy to extend our platform, by leveraging the Extensible Authentication Protocol (EAP – http://www.microsoft.com/eap). We are introducing EapHost as well, which further simplifies extensibility by allowing 802.1x vendors to easily participate in NAP by plugging in their own EAP methods and writing unique EAP based supplicants.

This should be an awesome session, and I am looking forward to engaging in a healthy (pun intended) discussion over these features with you during and after the WinHEC session.

Mudit Goel

Development Manager

Network Access Protection

Advances in Windows Vista TCP/IP

wndpteam — Fri, 05 May 2006 21:00:00 GMT

The Windows Vista TCP/IP stack has made tremendous improvements in its efficiency, taking full advantage of hardware advances (e.g. gigabit networking). As explained by Murari in a previous posting (Advances in Windows TCP/IP Networking), there are a number of bottlenecks that affect TCP throughput. Here, I will give some examples of how we’ve addressed these bottlenecks in the Windows Vista TCP/IP stack.

TCP auto-tuning: At any given time, the amount that TCP can send is governed by three factors: the congestion window, the receive window and the number of bytes available to send. Without using TCP window scaling (which is disabled by default in previous versions of Windows), the maximum receive window a receiver can advertise is 64K bytes. Since the congestion window is usually greater than 64K bytes in high-bandwidth/high-latency networks, the receive window is often the limiting factor if the application is submitting enough data.

In previous versions of Windows, users can work around this problem by setting the TcpWindowSize registry key value. However, TcpWindowSize is a global setting applied to all connections, and it’s often hard for users to know the appropriate window size to set.

To address this issue in Windows Vista, we implemented TCP auto-tuning. It enables TCP window scaling by default and automatically tunes the TCP receive window size based on the bandwidth delay product (BDP) and the rate at which the application reads data from the connection. With TCP auto-tuning, we have seen 1000% (10x) throughput improvements in internal testing over underutilized wide-area network links.

Receive-Side Scaling: Networking stacks face a number of challenges in scaling their receive processing across processors on multi-processor systems. For instance, on previous versions of Windows all packets indicated in a single interrupt service routine (ISR) are typically processed in a single deferred procedure call (DPC) queued to a specific processor to avoid packet reordering. Until the outstanding DPC completes, no more receive indication interrupts can be triggered. As a result, only one processor can be used at any given time for processing received packets for a single network adapter.

Receive-side scaling (RSS) is our solution for this issue in the new networking stack: it enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It achieves parallelism by allowing ISRs to queue DPCs on multiple processors, enabling packet processing on multiple processors at the same time. It avoids packet reordering by separating packets into flows, and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. Using TCP as an example, this approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.

TCP offload: Previous Windows releases already support network task offload for stateless per-packet operations (e.g. LSO, checksum offload etc). In Windows Vista, in addition to the offloads supported on previous Windows releases, we’ve also introduced support for TCP chimney offload. TCP chimney offload enables Windows to offload all TCP processing for a connection to a network adapter. Offloads are initiated on a per-connection basis, based on heuristics. Compared to task offload, TCP chimney offload further reduces networking-related CPU overhead, enabling better overall system performance by freeing up the CPU for other tasks.

We have also responded to customer feedback by making the Windows Vista TCP/IP stack much smarter and more adaptive in a number of scenarios. One such improvement we’ve made is to enable TCP black-hole detection by default in Windows Vista.

Historically, problems due to the presence of black-hole routers have been among the highest product support call generators for the previous Windows networking stacks. To understand why, it’s important to know that TCP/IP relies on ICMP packet-too-big error messages to discover the maximum transmission unit (MTU) for any given connection’s path, so that it can reduce the size of the packets that it sends if they’re too large. If a router along the path does not send back ICMP error messages, or if a firewall drops ICMP error messages, TCP will never find out that its packets are too big. As a result, it will retransmit the packets repeatedly with the same size, up to its maximum number of retransmissions and, when it gets no responses, it will terminate the connection.

Black hole router detection is a mechanism used in this scenario to automatically reduce the size of the packets sent for a connection, based on the current status of the connection, in the absence of feedback from ICMP packet too big error messages. This mechanism was disabled by default in previous versions of Windows, because previous approaches would often yield too many false positives, lowering the packet size unnecessarily and reducing performance. In Windows Vista, our improvements have reduced the likelihood of false positives and, consequently, minimized the adverse performance impact, enabling us to turn on black hole detection by default in the upcoming Beta 2 release.

There are many, many more innovations that we’ve made in the network stack, far more than I can write about in this one posting. Stay tuned for more…

Xinyan Zan

Software Development Engineer, TCP/IP Networking

Network Programming with Winsock Kernel (WSK)

wndpteam — Thu, 04 May 2006 16:00:00 GMT

Winsock Kernel (WSK) is the latest network programming interface introduced by the WNDP team in Windows Vista. As evident by its name, WSK can be used by kernel-mode drivers for sending and receiving data over the network. But less evident to many developers, WSK is not an interface for performing network “filtering”. Hence, to clarify a common misconception up front, if all you want is to perform some form of network traffic filtering or interception, then you are strongly advised to look at the Windows Filtering Platform (WFP) interface first. WFP is the one-stop shop for network filtering in Windows Vista.

As we have first presented in last year’s Driver DevCon and WinHEC 2005, our main goal with WSK is to provide a programming interface which is easier-to-use and has higher performance relative to its predecessor Transport Driver Interface (TDI) for kernel-mode network applications. Since last year, we have considerably improved the WSK documentation in the Windows Driver Kit (WDK), and have also added a WSK sample driver to the WDK. A preview version of the pre-Beta2 WSK documents and sample is available as described in a previous blog on this site by Mike Flasko.

In WinHEC 2006, the session on WSK will be geared more towards the guidelines and best practices to follow in WSK to achieve optimal performance and stability. For those of you planning to attend the WSK session in WinHEC 2006, we encourage you to get familiar with the available WSK documents and the sample prior to the session to get the most out of the presentation. We have identified a number of areas in WSK over the past year based on feedback from both external and internal WSK clients that require more explanation and guidance. These include how to start and stop using WSK (WSK registration and deregistration), IRP handling, building and processing WSK_BUFs, when to use socket callbacks, how to achieve optimal throughput when sending stream data, how transport address security works, and how to use a single IPv6 socket for both IPv6 and IPv4 traffic. We will discuss all of these areas in depth in the WSK session in WinHEC 2006.

An important question I would like to address here is when to use WSK. Let’s look at this starting with a Winsock2 application in user-mode. If your Winsock2 application is working fine in the user-mode land, then you have no reason to consider a WSK-based implementation for that application. An important misconception here is to assume that a kernel-mode implementation will automatically provide much better performance than a user-mode implementation, which is not true. Remember also that kernel-mode programming has much stricter requirements in order to ensure a high degree of system stability and robustness; if your kernel-mode code is not rock solid, then moving your application into the kernel will cause more grief than good. Lastly, user-mode Winsock2 interface is a richer higher-level interface while, even though we have made it relatively simple and easy-to-use, WSK is still quite a low-level interface which sometimes requires an intimate familiarity of protocol-specific behavior from its clients to avoid pitfalls. To give a few concrete examples, Winsock2 does have dedicated routines for complex tasks like transmitting a file or connecting by name to remote peers whereas WSK doesn’t. Also as another less obvious example, Winsock2 performs buffering in the send direction, which allows even simple applications using blocking send requests to achieve decent throughput whereas WSK does not perform any “socket-level” buffering, hence requires the application to know about and account for things like Nagling, delayed-ack, bandwidth-delay product, etc to achieve decent throughput.

My personal guidance on implementing anything in kernel is to ask this question first: Is there a significant performance, stability, robustness, or security benefit in a kernel-mode implementation for a given functionality that can not otherwise be achieved by a user-mode implementation? This guidance may sound a bit abstract without a concrete example. So, let’s take a look at a real example. The HTTP.sys component in Windows Vista implements a kernel-mode HTTP stack by using the WSK interface. Prior to HTTP.sys, HTTP applications like Internet Information Services (IIS) used to use Winsock2 directly. The move to the HTTP.sys model was driven by several important factors. First, multiple HTTP applications running on the same system often needed to share a single TCP port (e.g. 80). Implementation of this sharing by keeping a clean and secure isolation between multiple HTTP application instances was not straight-forward via Winsock2 in user-mode. HTTP.sys has brought a robust solution to this problem by taking on the responsibility of managing multiple HTTP connections in kernel over a single WSK socket. This allowed applications like IIS to support multiple 3^rd party plug-ins running in user-mode, in isolation, and with least-privilege in order to achieve better system stability and security. Second, HTTP.sys has a kernel-mode cache implementation that allows it to satisfy incoming HTTP requests directly in the kernel without making a user-mode transition. A kernel-mode cache for HTTP.sys makes sense due to the static nature of HTTP content. The full benefit of this cache is made possible by receiving and sending data over a WSK socket in kernel directly. This boosts the overall performance. However, note that this performance factor alone can not be the sole reason for implementing an HTTP stack in kernel without the former factor.

I hope what was stated so far above gives you a pretty good idea about when to use WSK. As for how to use WSK in the best possible way, we will address that topic in the WSK session in WinHEC 2006. We hope to see all of you there!

-Osman N. Ertugay

Network security made richer and simpler

wndpteam — Wed, 03 May 2006 16:00:00 GMT

What if you could filter IPsec encrypted traffic? What if you could easily filter both IPv4 and IPv6 traffic? What if you could write just a few lines of user-mode code to filter applications based on port, protocol and application ID?

To do all this and much more, Windows Vista exposes a set of user and kernel-mode programming interfaces for implementing firewalls, anti-virus, anti-spyware, intrusion detection, and more. This set of interfaces makes up our new Windows Filtering Platform (WFP) in Vista. WFP will be the basis of Windows Vista-compliant security products built by leading security companies around the world.

Here’s a sneak preview to WFP’s value-add for Windows Vista through the eyes of Abolade Gbadegesin, Networking Architect:

For Windows Vista we’ve rethought the way that components integrate with the networking stack, and how they extend its behavior. In the past it’s been necessary for such components to examine frames passing through the NDIS layer, or examining I/O request packets passing through the TDI layer. The new networking stack now allows such components to instead participate in the state machines at multiple layers, providing notifications of significant internal state transitions, eliminating the need for guesswork, and making it easier to extend the stack in a robust way.

Extensions to the stack allow developers to perform rich stream and packet filtering. Here’s what Anupama Vasanth, automation developer/tester for WFP, has to say:

WFP enables inspection and modification of stream and packet data coming in. A stream can be paused and later resumed; parts of the stream can be permitted, blocked or replaced with different data. There can be multiple stream modifiers performing stream modification. The stream can be pended if more data is needed to make a filtering decision on the stream. A typical use of this would be an application that needed to screen the stream for unwanted words.

Packet modification is also supported by different re-injection APIs. In this case, the packet is cloned, modified and re-injected either in the send, receive or forward path. Packet modification can involve header modification (e.g. port, source, destination addresses for NAT scenarios) or payload modification (both content and size can change). Packets can also be pended and then injected at a later time or discarded at a later time depending on the filtering policies.

While WFP provides a rich filtering interface, it also exposes a new set of socket-level security APIs that enable Windows Sockets applications to leverage with IPsec for securing traffic. Kartik Murthy, IPsec developer, has the following comments on these new secure socket APIs:

Traditionally, IPsec has been used to protect network traffic via central administrative configuration using local or Active Directory group policy. The Secure Sockets API is an extension to the Windows Sockets API that allows socket applications to directly control security of their traffic over a network. The API extension allows applications to provide security policy and requirements for their traffic, and query the security settings applied on their traffic. For instance, applications can use this API to query a remote peer’s security token and use it to perform application-level access checks, or client applications can simply specify the Server Principal Name (SPN) of the server to prevent any man-in-the-middle attacks. Today, applications can already secure their traffic by using SSL, etc. But in comparison, the Winsock extension has been designed to make it very easy for a network application to secure its traffic, with minimal additional code, while letting Windows Sockets abstract away the complexity.

If you wish to learn more, I will be presenting a WFP session at WinHEC 2006 in Seattle (May 23-25). It will cover different filtering technologies supported to date, and how WFP takes filtering to the next level. The session will also illustrate the use of WFP APIs in different scenarios.

Madhurima Pawar

Program Manager, Core Networking

What is NetDMA?

wndpteam — Tue, 02 May 2006 21:00:00 GMT

The NetDMA term was coined by the networking team to imply a DMA (Direct Memory Access) engine that is used for moving networking data in memory. During WinHEC I will present the NetDMA architecture but for now I will give you the problem that NetDMA is trying to address.

When the networking card receives data from the wire, it performs a DMA transfer to copy it into system memory. It then informs the networking stack that a certain number of received packets are ready for processing, most commonly by raising an interrupt. When the networking stack processes the packets, it copies the data into buffers posted by the application waiting for it. This second copy operation is performed by the CPU, which means that receive processing can be a CPU-intensive task. NetDMA tries to address the following question: how can we reduce CPU utilization when doing the second copy?

Besides presenting the NetDMA architecture, I will present (in another talk) the networking test tools that are integrated in the Windows Driver Kit. This will be a great opportunity to see how network devices will be tested for the “Designed for Windows Vista” logo program, to ask questions, and to provide us with feedback.

There is something for everyone, so come and join us at WinHEC 2006 in Seattle.

Rade Trimceski

Program Manager

Enabling Diagnostics for Network Performance Tuning

wndpteam — Sun, 30 Apr 2006 04:38:00 GMT

In Windows Vista Home Premium and Ultimate editions, Media Center will be available to all. Xbox 360 has integrated Media Center Extender (MCX) functionality, and a lineup of additional MCX devices will be comming soon from a number of partners, making it simple to extend TV (standard and high definition), videos, music, pictures, and rich web content (via Online Spotlight), from your Windows Vista PC to every television in the home; wired or wirelessly. The latter of connectivity methods (wireless) poses a number of headaches for consumers; especially 802.11g which operates in the 2.4GHz spectrum. Given that Media Center and myriad Media Center Extenders will be easily attainable when Vista releases, the core networking team has invested heavily in diagnostics to ensure users can take action whenever possible. The top issues impacting audio/video (AV) streaming over wireless networks are exposed through the Network Performance Tuner, which is integral to the MCX experience.

I previously blogged about connecting your digital home, where I discussed a number (not all) of common problems faced when using WiFi to connect media extenders, but didn't go into any detail about what is technically required from vendors to enable diagnosing these situations such that users can take action. During WinHEC this year, I'll be doing a session that clearly highlights each of these top issues, the impact to users, and what vendors must support in their access points and NIC drivers to ensure diagnosability. This session will be a lot of fun, so I look forward to seeing everyone. Additionally, Mathias Jourdain (who has blogged a number of times about QoS topics) and I will be joining a number of folks from the core networking team in an "Ask the Experts" session to dive deep on any questions you have related to QoS and Windows Networking in general.

- Gabe Frost

Advances in Windows TCP/IP Networking

wndpteam — Tue, 25 Apr 2006 22:00:00 GMT

Significant advances have been made, both in hardware and in software, over the past few years that have enabled gigabit networking. From being unavailable just a few years back, it has become mainstream technology with GigE NICs available in an increasing number of clients and servers today. The ever increasing networking capacity and the need for high throughput over long distance transfers makes it imperative that we develop software which functions efficiently while taking advantage of all the available bandwidth. There are several bottlenecks that prevent high performance transfers end-to-end: host system on the sender and receiver, the network and of course the applications themselves. For Windows networking stack to deliver high throughput in gigabit networks and beyond, we have to alleviate some or all of these bottlenecks.

Let’s try and analyze some of these bottlenecks.

CPU bottleneck: Sending and receiving data at gigabit speeds requires a tremendous amount of processing: to compute checksums, form TCP/IP headers, validate received packets, copy data across buffers, and so on. Doing all this processing in software has significant processing demands with most of the CPU consumed in just sending and receiving data even with the fastest available off the shelf processors. Technologies like task offload have helped alleviate some of CPU load by offloading tasks like checksum computation. However, the CPU continues to be the bottleneck.

Scalability bottleneck: Due to physical limitations, scalability in processing power has been made possible by using multiple processors or multi-core processors. Most servers ship with multiple processors these days. However, the networking stack has always supported processing of received packets on a single processor only. This implies that for servers with significant network load, performance is limited to the processing power of one CPU and does not scale even when more processors are added.

TCP congestion control: the TCP protocol was designed in late 1980s when the bandwidths were fairly low. Principles of congestion control were developed to ensure that the end systems cooperate and do not cause congestion collapse on the network. TCP has scaled amazingly well to several hundred Mbps bandwidth as well as to millions of host using it across the Internet. However, as bandwidth continues to increase, inherent limitations in TCP are becoming evident. TCP was designed to be quite conservative in probing for spare bandwidth but quite aggressive to responding to any congestion indication. Congestion indications are derived based on packet losses. This imposes a theoretical limit on the throughput of TCP connection for a given loss rate. This is problematic for high bandwidth scenarios e.g. In data intensive grids and networks for high energy and nuclear physics, led by CERN, and projects like Terraservice for astronomy research, there is a need to move huge amounts of data across high bandwidth links. TCP faces challenges in scaling to such bandwidths.

TCP receive window limitations: Applications that use TCP are limited in throughput by the maximum default receive window. Traditionally, different implementations of TCP have used a maximum default receive window value of 64KB. (The receive window field in the TCP header is a 16-bit field.) This effectively limits the amount of data the sender can send, thereby directly impacting the maximum throughput achievable on the connection. Although it is possible to change this value in the registry on Windows, it is really not easy to guess what the correct value is for a given connection. The optimal receive window size varies by connection and it is usually dependent upon the bandwidth-delay product and the application’s consumption capacity, none of which can be pre-configured in the registry.

Application bottlenecks: For gigabit throughputs, applications must be optimized so as to minimize overhead in sending and receiving data. They must also ensure that there is always enough data to send to keep the pipes full, and enough buffers posted to receive incoming data in time. Today this requires a lot of manual tuning, something that’s clearly not an option as we go forward.

In the coming days and weeks we will discuss the advances made in the networking stack in Windows Vista and for the Longhorn Server to solve some of these problems.

Please stay tuned…

Murari Sridharan

TCP/IP Networking, Internet Protocols Team

Network Access Protection

wndpteam — Tue, 18 Apr 2006 22:00:00 GMT

Network Access Protection (NAP) is an exciting new solution that will be included in Windows Vista and Windows Longhorn Server. You can find out some basic information about NAP here: http://www.microsoft.com/nap.

The world is becoming increasingly interconnected. This is great because it enables us to access our information on more devices, in more locations and at all times. However, these benefits require new approaches to access control. They require us to go beyond securing the network perimeter to securing the internal network and the hosts themselves. That’s what NAP is all about – providing integrated access controls across multiple layers in the network and on the hosts.

One thing that really sets NAP apart as a solution is the platform approach it takes. With NAP, customers can provide access controls across virtually any product from any vendor. Any product that can isolate a non-compliant endpoint can participate in a NAP deployment: VPN gateways, perimeter firewalls, internal firewalls, host firewalls, 802.1x switches, routers, DHCP servers, bump-in-the-wire network security appliances and more.

We are starting to showcase NAP integration with the ecosystem. Bill Gates demonstrated NAP in his RSA keynote in February. On the floor at RSA, NAP was demonstrated in 14 partner booths in addition to the Microsoft booth. We also recently participated in iLabs where we got NAP working with 802.1x switches from several vendors.

Mudit Goel, the NAP Development Manager, is busy preparing his presentation for WinHEC. He’ll provide a deep technical review of Network Access Protection. Then, he’ll discuss ways that NAP can be extended by network and security ISVs and IHVs. He’ll focus on 802.1x integration but will cover other kinds of integration as well. This will be a great session. We hope to see you there.

-Paul Mayfield

Group Program Manager

Network Access Protection

An Interview with Alireza Dabagh, NDIS development lead

wndpteam — Tue, 18 Apr 2006 04:37:00 GMT

Tell us about what you do in Windows.

I’m NDIS development lead. I lead a team which works on NDIS and related components, and I also contribute to the architecture, coding and design of our components.

How long have you been participating in WinHEC?

Quite some time! Maybe 4 or 5 years.

What are the challenges and opportunities you see ahead for core networking and the connectivity technologies that you work on?

One of the biggest challenges that we have is supporting multigigabit networking. As the raw bandwidth increases, the role of the entire stack becomes an obstacle to taking advantage of that bandwidth. It wasn’t an issue at 10/100Mbps, but it used to be an issue at 1Gbps. Today it’s not an issue anymore for 1Gbps but its an issue for 10Gbps. The challenge is to make sure we can take advantage of all the capacity that the network has to offer.

The other challenge is manageability and diagnosability. In today’s environment, many of the people who rely on networking are new to networking and they need a way to understand what’s going on, why connectivity is lost,or why performance isn’t what they expect, in a way that they can act on rather than through some cryptic error message. They need clearer explanations of these problems. For example, if you lose Internet connectivity at home, it’s hard to tell if it’s because your cable is disconnected, or if your cable or DSL modem is hung, or because your router needs to be reset, or because your provider isn’t giving you an address. It’s really hard for a regular user to diagnose these problems.

The third thing I’d mention is scalability. By that I mean being able to use multiple links, with features link load-balancing and fail-over. Today we have multiple solutions from various vendors, which behave in different ways and are often hard to use and managed. We’ve heard a lot of requests for supporting these features natively as part of the platform to provide a consistent experience.

How does virtualization affect the area that you work on?

I should have mentioned that as one of the challenges! When you only have one real interface in the system, but you want each guest OS to see its own virtual interface, you run into various issues. For example, how do you get the real NIC to receive packets for all the virtual interfaces? Today each NIC has one unicast MAC address. If you want to get frames for all those virtual MAC addresses, today you have to put the hardware into promiscuous mode which has its own implications. Dispatching those incoming packets to multiple virtual machines has its own performance and security implications. Having resources like DMA engines, I/OAT engines and being able to use it in multiple virtual machines is also challenging particularly with security. It’s challenging to take advantage of offloads like TCP chimney offload and task offload in virtual machines without any conflicts. Remember that you can only have one driver running the hardware, and that driver is ignorant of there being multiple virtual interfaces running over it. So you need a layer that manages virtualization requirements on top of the driver.

Any messages for the WinHEC audience?

Be sure to follow the progress of our NDIS APIs closely, particularly what we’re doing with IPsec offload, TCP chimney offload and task offload. We don’t want anyone to be left behind, so the WinHEC attendees should make sure they can take advantage of that. It’s no longer enough to just provide plain vanilla hardware, because competitors can provide these cool new capabilities with minimal expense. Networking hardware that doesn’t offer these capabilities will be at a great disadvantage. Getting this functionality isn’t the difference between $10 and $100 hardware for OEMs; it’s the difference between $10 and $12 hardware. So my advice is: don’t be left behind!

-Abolade Gbadegesin

Get Ready for the WinHEC 2006 Guest Blogger Series

wndpteam — Fri, 14 Apr 2006 12:00:00 GMT

Starting Monday April 17th the WinHEC 2006 Guest Blogger Series begins right here on the WNDP blog The series is comprised of technical content from speakers and developers whose feature areas Microsoft will be highlighting during this year’s conference. WinHEC 2006 runs May 23rd- 25th at the Washington State Convention and Trade Center here in Seattle, WA.

This year Bill Gates, Will Poole and Bob Muglia will keynote the conference. For those that may not be familiar with WinHEC here is a quote from BillG about the conference:

"WinHEC is a key annual milestone for Microsoft. This is where we sit down with our many partners who build innovative hardware and talk about the directions we're taking. Talk about what we're looking at in software, hear from them about what they are doing in hardware, and make sure those two come together."

Bill Gates

Chairman and Chief Software Architect

Microsoft Corporation

The guest blogger series is also a great opportunity for those people not attending the conference who are interested in learning about the technologies that we will be presenting. So, whether you are attending the conference or not, this series will be rich with information.

We want to hear your thoughts about the content of the series, so, please be sure to leave feedback in the comments section. We will be adding new series content to the blog throughout the week. Stay tuned…

-Billy Anders