How to Enable the Windows Vista Network Map

wndpteam — Fri, 03 Nov 2006 14:00:00 GMT

As Gabe mentioned in his blog post titled “Xbox 360 Fall Update Includes LLTD,” the Xbox 360 now includes the Link Layer Topology Discovery (LLTD) protocol. At a basic function level, LLTD gives users a graphical representation of their home network topology. In addition to the network map, LLTD offers network device manufacturers a standard way of ensuring that their devices are easily viewed and accessible to their users. Windows Vista enables the Network Map by default when a user is in a location designated as “Home.” However, LLTD and, therefore, the Network Map are both disabled by default in “Work” and “Public” locations. Check out this Cable Guy article for more information on Network Location Types in Windows Vista.

You will receive a message inside the Network Map (Control Panel -> Network and Sharing Center -> Network Map) if the map is disabled. As long as your network policy (group policy) does not prohibit it, enabling the Network Map on a local machine is simply a matter of enabling the right setting in the local computer policy.

“Network mapping is disabled by default on domain networks. Your network administrator can use Group Policy to enable mapping.”

The first step in locally enabling the network map is to run the Group Policy Object Editor (gpedit.msc) as an administrator on the local machine. With User Account Control (UAC) enabled, just right-click “Command Prompt” (Start Menu->All Programs->Accessories) and select “Run as administrator” to open an elevated command prompt. From the elevated command prompt, run the command “gpedit.msc” (no quotes). This will start the group policy editor for the local machine.

Inside of the Group Policy Object Editor, navigate the tree to Local Computer Policy -> Computer Configuration -> Administrative Templates -> Network -> Link-Layer Topology Discovery.

Once you are in the Link-Layer Topology Discovery section of the editor, simply Right-click and open properties for “Turn on Mapper I/O (LLTDIO) driver” and enable the “Allow operation while in domain” option.

You should now be able to see your network mapped out in all of its graphical glory! If you would also like to use the network map on a public network, you can enable the “Allow operation while in public network” option. Network domain administrators who want to enable the Network Map across a group of machines should follow these same instructions and, additionally, link the policy to the desired Active Directory container.

I would be remiss if I did not touch on the “Turn on Responder (RSPNDR) driver” option that sits just below the LLTDIO option in the UI. The LLTD Responder driver allows PCs and network devices, like the Xbox 360, to present device details to the network such as the device’s manufacturer, model #, configuration URL, etc.

Beyond offering users the convenience of having a visual representation and providing right-click access to information about the devices, the LLTD Responder also plays an important role in responding to, and taking part in, network diagnostics. LLTD helps to make distributed and coordinated network diagnostics possible, and if you are creating home network devices, you should strongly consider implementing an LLTD responder. I use the word implement loosely here, because, very soon we will make an LLTD porting kit generally available that gives you everything that you need to incorporate LLTD into your devices. More information on LLTD, including the LLTD QoS Extensions, is available on the Windows Rally site. We will announce the general availability of the LLTD porting kit here on our blog.

-Billy Anders

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

Windows Core Networking : congestion control

How to Enable the Windows Vista Network Map

Advances in Windows TCP/IP Networking