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