WebTransports's WebLog

Migrating

This blog is migrating to the WNDP blog. This one will stick around but won't be updated.

Cookies and P3P

Microsoft Monitor discusses a little bit about cookies and P3P after a Mossberg Wall Street Journal Column

David Wang discusses http.sys's kernel response cache.

Check out David Wang's recent post about http.sys's response cache. He describes the configurable registry keys and how the scavanger works.

Longhorn Networking Stack: NAP

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

Network Access Protection:

Khaja_MSFT (Expert):
Q: oh yes = tell us more about NAP - this going to hit longhorn client???

A: The idea behind NAP is that we create a framework that allows IT admins to ensure policy compliance of their systems. In essense, a computer has to prove that it is healthy (compilant with policy) before it is allowed to connect to the network. Of course, the IT admin has the option of using strong enforcemnet or not.

Khaja_MSFT (Expert):
Q: oh yes = tell us more about NAP - this going to hit longhorn client???

A: By the way, more info is available at http://www.windows.com/nap

Khaja_MSFT (Expert):
Q: oh yes = tell us more about NAP - this going to hit longhorn client???

A: NAP is indeed giong to be in Longhorn client. It will ship with some out of box capabilities to enforce policy compliance. Additionally we are working with 40+ partners who are industry leades in Anti-virus, intrusion detection / prevention, network access devices and much more to support the NAP architecture.

Jawad_Khaki_MSFT (Expert):
Q: The new networking stack will integrate with various vendors endpoint security technologies (like CISCO NAC or Check Point Integrity)? Will it be integrated with Microsoft NAP?

A: NAP support planned for Longhorn will take advantage of the new stack in LH. Can't comment of 3rd party plans.

Khaja_MSFT (Expert):
Q: In addition to enhanced NAP support and an IPv6 GUI, will Longhorn have another other security features from a netowrking perspective built in (i.e., improved ICF, antivirus, etc)?

A: There are certainly improvements in usability and manageablity of the components you name. Network security is handled at multiple levels so I will answer from the perspective of NAP. Properly used, NAP will be the framework that protects you network. This is the 'wholistic' solution to protect both your network as well as the devices / end points connnected to the network. When I say NAP I am not talking about just the NAP agent and serer that comes in LH client and Server. I am also including the server side and client site elements that come from MS and other third parties. The client side agents are called SHAs, system health agents and each SHA will have a corresponding SHV (System Health Validator) on the infrastructure side. These pairs can address various aspects of network securiyt, policy compliance, and other network / ssytem health parameter. As an example one pair may address the anti-virus health aspect, another may address the configuration management; yet another may address patch lvl.

Joe_MSFT (Expert):
Q: Will NAC/NAP be standard in LH for network access and WS health prior to allowing network access.

A: The current plan is to include client and server support for Network Access Protection (NAP) in Longhorn, which performs system health checks prior to allowing various levels of access to a managed network. Cisco NAC integration in Longhorn is under development. See http://www.microsoft.com/nap for more information.

Jawad_Khaki_MSFT (Expert):
Q: Will NAC/NAP be standard in LH for network access and WS health prior to allowing network access.

A: NAP enhancements will enable IT network managers to enforce health check prior to networkn access. It will depend on the IT policies.

Jawad_Khaki_MSFT (Expert):
Q: Will PolicyNAT and PolicyRouting could be supported in LH timeframe ?

A: there will be some level of policy based configuration and we are eager to feedback from you in this space.

Khaja_MSFT (Expert):
Q: Will the SHA component of NAP work withour the SHV piece such as in the Windows Security Center in XP SP2?

A: Depending on the particular aspect of system health a SHA deals with, there may be no requirement for a correspoding SHV. So this has more to do with the nature of the SHA than the architecture of NAP. As an example, if the SHA reports on the Anti-virus configuration you pretty much need a server side way (an SHV) that can affirm / validate that the virus signature file being used is really the latest, the configuration is as required by policy etc. Some other SHA may simply be a binary state check about whether or not a particualr parameter that is required by policy has the right value.

Khaja_MSFT (Expert):
Q: What improvements in security point of view will Longhorn's networking component present?

A: A significant improvement in LH from a network health as well as a end-point (Desktop and serever) health perspective is NAP. It is a suite of components in the client and the server that works in a coordinated fashion with other MS and third party applications to ensure policy compliance of systems that connect to the network. This should do a great deal to improve security and mangeability of security for your desktops and the network.

Wendy [R2 Tech Beta] (Expert):
Q: Will R2 Beta Participants get an early look on Longhorn/Longhorn Networking?

A: While there are many criteria that MS Beta programs use when selecting beta applicants, one of the best ways to make yourself more visible to Beta PMs is to actively participate in current betas of similar products.

If you would like to be considered as a candidate for Beta 2 of Windows Server “R2”, please complete the following steps:

1. Go to http://beta.microsoft.com
2. Enter a valid .Net Passport
3. Click on GuestID
4. Enter 'R2B2Beta' (case-sensitive)
5. Complete the survey in the left-hand pane

Successful participants will be notified within ~2 weeks.

Longhorn Networking Stack: Firewall Platform

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

Firewall:

Henry_MSFT (Expert):
Q: Will Longhorn feature iptables like firewall with support for 3rd party plugins?

A: Support for 3rd party firewalls/filtering plugins will be available for the new Windows Filtering Platform.

Jawad_Khaki_MSFT (Expert):
Q: Tell us more about Longhorns' netowrking vision - and how it's gonna be secure

A: Our longterm vision is towards a seamless network that provides authenticated, authorized, private communications required for pervasive collaborative computing. IPSec and host-firewall are important aspects from a security standpoint.

Arvind_MSFT (Expert):
Q: Will the network stack be able to work at Layer2 and by the way provide and infrastructure for a future version of ISA working as a transparent Firewall ?

A: The LH network stack will operate over NDIS (IM) drivers at layer 2.

Arvind_MSFT (Expert):
Q: As I understand it, Windows Filtering Platform will expose a common filtering methods to 3rd party firewalls. Does this extend to improved logging functionality, either built in, or with a 3rd party tool?

A: There will be improved built-in logging functionality in Longhorn, and WFP will support logging by 3rd party products as well.

Henry_MSFT (Expert):
Q: How much easier will LH make firewall development? Will we get an up-to-date C++ interface to work with?

A: It will make it significantly easier. That's the whole goal of the WFP (Windows Filtering Platform) effort. There will be up to date, clearly documented interfaces. We're also investing in improving LSP and NDIS filter driver support, which are also often used by host firewalls.

Arvind_MSFT (Expert):
Q: What with the LH firewall, are you planning to make something like iptables?

A: Can you please elaborate on the functionality you are looking for?

Arvind_MSFT (Expert):
Q: When will we first get to play with WFP? WinHEC? PDC?

A: We plan to make WFP documentation and samples available with WinHEC.

Longhorn Networking Stack: P2P and Upnp

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

UPnP:

Harish_msft (Expert):
Q: "web serviices for network devices " <--- whats this?

A: in LH we are making a significant enhance to discovery and configuration of network devices. This work will allow a network device to connect to the PC much like a USB device. They will be enumerated, discovered installed via extensions to PnP. This support is protocol agnostic. Web Services for devices is a rich protocol framework that allows for network devices to better describe themselves. It affords greater security and reliability than upnp 1.0. Additionally it enables scenaiors that are beyond a single subnet.

Harish_msft (Expert):
Q: Are there any plans to include/extend UPnP capabilities in LH?

A: LH will have support for Upnp 1.0. Additionally we are extending existing PnP to include network devices including upnp 1.0 devices. Customers will be able to "connect" a upnp 1.0 device to their PC and have a similar experience they have connecting a USB device in terms of the device being easily and securely available to the user. We are supporting the needs of our upnp 1.0 customers.

Harish_msft (Expert):
Q: Will the LH home networking utilize both UPnP and WS* or just UPnP ?

A: LH will support both. Upnp 1.0 for extisting and backward compatbilty and WS for future network devices.

Harish_msft (Expert):
Q: will there be measures to make UPnP more safe?

A: we are actively looking into inproving the security issues in upnp 1.0. We hope to finalize by WinHEC.

Jawad_Khaki_MSFT (Expert):
Q: Any improvements to come from networked printers ?

A: Longhorn will support printers that use the web services framework. Harish can fill in more.

gursharan MSFT (Expert):
Q: Do you have plans to include some peer-to-peer enabled apps in LH, eg. P2P update management, file sharing?

A: Yes we plan to provide some out of the box user experience that is based on use of P2P platform capabilities.

gursharan MSFT (Expert):
Q: Will networking be easier for home users, eg auto discover each computer on the network then create secure connections for sharing data ? I know many that have so many problems sharing files on a home network

A: Making home networking easier is a key focus in Longhorn; among the aspects made simpler are setup, discovery of network resources, access and use of networked resources, diagnostics, roaming, etc. Considerable effort is going into making file sharing simple.

Peer to Peer:

gursharan MSFT (Expert):
Q: Regarding peer-to-peer applications, there was that Advanced Network Whatsit package that added P2P libraries to the system, which 3Degrees also used. There will be in Longhorn by default? Will there be managed versions of such libraries?

A: P2P platform functionality provides application developers with a suite of powerful capabilities to register named entities, to resolve names into addresses, to determine presence of endpoints, to connect and initiate activities in a peer-to-peer fashion. Multipoint messaging capabilities are also being made available to service the needs of a group of endpoints. In addition Longhorn will include some out of box experiences that exploit the underlying peer-to-peer infrastructure

Dave_MSFT (Expert):
Q: Regarding peer-to-peer applications, there was that Advanced Network Whatsit package that added P2P libraries to the system, which 3Degrees also used. There will be in Longhorn by default? Will there be managed versions of such libraries?

A: Yes the P2P capabilities that appeared in the Advanced Networking Pack for XP will be in Longhorn by default.

Jawad_Khaki_MSFT (Expert):
Q: Can you talk about the new peer to peer functions in longhorn

A: P2P platform functionality provides application developers with a suite of powerful capabilities to register named entities, to resolve names into addresses, to determine presence of endpoints, to connect and initiate activities in a peer-to-peer fashion. It will also support multi-group communication.

Dave_MSFT (Expert): Q: Regarding peer-to-peer applications, there was that Advanced Network Whatsit package that added P2P libraries to the system, which 3Degrees also used. There will be in Longhorn by default? Will there be managed versions of such libraries?
A: Yes the P2P capabilities that appeared in the Advanced Networking Pack for XP will be in Longhorn by default, along with additional P2P capabilities. We plan to provide managed versions in the future.

Henry_MSFT (Expert):
Q: Since Longhorn'll be doing a lot with managed code, will there be managed interfaces to hook into the network stack, to e.g. create a managed firewall and similar?

A: We are doing a bunch of managed code work in LH - the .NET Frameworks Net Classes (System.Net) are in my group. Our current hooks for getting into the stack to do a firewall though are all in kernel mode, and managed code isn't supported in the kernel. Going forward we will extend these to user mode and at that point there will be managed code interfaces.

Longhorn Networking Stack: Wireless and Bluetooth

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

After Ipv6 and the new stack, wireless was on people's minds:

Christian_MSFT (Expert):
Q: what changes are in store for wireless networking within Longhorn?

A: The WIFI stack is being rewritten for Longhorn, to allow for extensibility. This includes a new driver model, that exposes 802.11 concepts rather than trying to just "look like Ethernet". The extensibility features allow harware developers to add support for extra features. There will be a public API for configuration of wireless networks, as well as support for group policy, scripting, and diagnostics.

Christian_MSFT (Expert):
Q: Christian, will 802.11n be supported in nearly betas of LH?

A: The WIFI stack is being rewritten for Longhorn, to allow for extensibility. As such, it will be ready to support 802.11n. However, you will only get 11n support if it is also supported in the NIC and in the driver.

Harish_msft (Expert):
Q: Which improvements are planned for Bluetooth networking in Longhorn? Windows XP does not support a device certification to date.

A: The main investment we are making in LH for BT support is we are opening up the DDI for BT. This will allow 3rd partys to develop profiles on the DDI. We are working to provide support for a critical set of profiles inbox. That is not finalized yet.

Christian_MSFT (Expert):
Q: what about wireless mesh support?

A: We do not plan explicit support for wireless mesh in Longhorn, but the extensibility features will allow addition of wireless mesh in the future, either by Microsoft or by 3rd parties.

Christian_MSFT (Expert):
Q: Can you elaborate on "Centralized scripting support for 802.1x enterprise wireless configuration"?

A: We will support a scripting interface based on netsh, so that every wireless configuration that can be set by the GUI can also be set with scripts. Scripting by itself is not centralized, but if the entreprise has a way to push scripts to every station, then it can use the scripting service for configuration. Note that we will also support group policy.

Harish_msft (Expert):
Q: By opening up the DDI for BT doesnt make it more open to security problems?

A: We are working to ensure that we have a set of guidelines and validation tools that will ensure that security is not compromised as we allow greater extensibility of the stack. We would love for you to get a copy of the specs and the code at WinHEC/DDC and give us your feedback.

gursharan MSFT (Expert):
Q: Q: for Christian - can you describe how setting up secure and safe wireless networks for residential users will work in LH? Will it be easy and transparent and build on Windows Connect Now type technologies?

A: I will answer this instead of Christian since this is in my area of responsibility. One of the directions that we are taking with effortless, secure setup in Longhorn is to extend the flash memory based out-of-band transport of settings to include other mechanisms such as over Ethernet, USB, etc. The solution will be easy and transparent (effortless) and convenient for residential users.

Christian_MSFT (Expert):
Q: Wireless personally the future for a lot of network, can you explain how Wireless will be improve with Longhorn?

A: Our principal focus in Longhorn is to "make WIFI a great experience", both for users and for managers. We are investing a lot on a great diagnostic service, so that users can quickly understand and correct issues with wireless services. EWe are also investing a lot on a configuration and management. Finally, the extensibility of the stack paves the way for future innovation.

Jawad_Khaki_MSFT (Expert):
Q: Jawad - what is low speed wireless (as opposed to high speed wireless) by definition?

A: GPRS is a type of high latency low-speed wireless network. These networks have bandwith in the order of 10's of kbits per second and several multi-hundred milisecond latencies.

Christian_MSFT (Expert):
Q: How will Longhorn deal with lossy or intermitent wireless (CDMA/GSM) connections?

A: We are addressing that in multiple ways. We are updating the TCP stack to incorporate better support for lossy networks. We are also making sure that the system has good support for "multi-homing", so that if there are multiple networks available, a connection is directed to the right one. And we are indeed working on the wireless connections support, to enhance quality...

Christian_MSFT (Expert):
Q: Christian - scripting api available? or only selling out to netsh executions? for the scripting support you have outlined?

A: The netsh scripts calls the wireless autoconfiguration API, which will be publicly available.

Jawad_Khaki_MSFT (Expert):
Q: Will Longhorn support ActiveSync over Bluetooth syncronization and browsing from mobile devices?

A: Can be done today with sp2. User experience can and will be improved.

Christian_MSFT (Expert):
Q: What can you share of ad hoc networks, which is exciting area, but likely will also excite the cracker crowd - seems like MS will need to innovate to make this simple yet safe.

A: We are doing several things. We will make it easy to safely create a secure ad hoc network. We will also make sure that ad hoc networks will not be confused with infrastructure networks, and that administrators can easily control the list of networks to which stations should or should not connect.

Christian_MSFT (Expert):
Q: Regarding adhoc networks, will they be local network only, or can I set up an arbitrary host list that'll make up the adhoc network? E.g. multiple hosts across the internet?

A: Wireless ad hoc networks will by definition be local -- all stations must be in radio range.

Christian_MSFT (Expert):
Q: do you plan to make public the current wireless zero configuration API to manage WIFI networks ? or something at the same abstraction level ?

A: The wireless autoconfiguration client is being rewritten. It will have an open configuration API.

Harish_msft (Expert):
Q: will LH support audio profiles for bluetooth?

A: This is a high priority profile for us. We will support it, but we are still determing whether it will be inbox or not. We will make a decision soon by beta 1.

Henry_MSFT (Expert):
Q: Will Longhorn implement any measures to remedy the performance implications of asymmetric bandwidth connections (e.g. ADSL broadband), e.g. as described in RFC 3449?

A: We are looking at this....We are focusing a lot of perf in lossy, low b/w wireless environments and many of the improvements will help with asymmetric links.

gursharan MSFT (Expert):
Q: In order to make in home wireless networks more secure how will LH address wide open wireless networks

A: We have been addressing this quite aggressively since the release of Windows Connect Now effortless and secure WiFi network setup shipped with XP SP2. Longhorn will provide several other mechanisms for effortless, setup of secure wireless networks as I have already indicated in prior answers. The goal is that all wireless networks become secured since it is easy to do so.

Longhorn Networking Chat: Ipv6 and the new TCP/IP stack

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

There was a massive number of questions about IPv6 and the new stack in Longhorn:

Henry_MSFT (Expert):
Q: Will Longhorn have a IPv6 GUI as all systems have for IPv4? What kind of support for IPv6 Longhorn will have?

A: Yes, there will be a common UI control for IPv6. In Longhorn, all components will support IPv6, and if they have a choice of IPv4 and IPv6 addresses they will prefer IPv6 addresses.

Henry_MSFT (Expert):
Q: Hey MSFT's... Question concerning IPV6. What are we looking at in terms of support and visual interface for configuration?

A: We will have complete support for IPv6 in Longhorn. All (network aware) components in Longhorn will support IPv6 addresses. We will have common UI controls for IPv6, and support comparable to IPv4 for configuration.

Arvind_MSFT (Expert):
Q: Will Longhorn have a IPv6 GUI as all systems have for IPv4? What kind of support for IPv6 Longhorn will have?

A: Yes, we plan to include a UI for IPv6 configuration similar to the current IPv4 UI.

Henry_MSFT (Expert):
Q: What is the status of IPv6?

A: IPv6 is a key piece of our networking support in LH. Everything in LH will be fully IPv6 enabled - browsing, name, CIFS, P2P, etc. IPv6 will be on by default and will be the preferred transport if multiple options are available.

Arvind_MSFT (Expert):
Q: Will Longhorn have a IPv6 GUI as all systems have for IPv4? What kind of support for IPv6 Longhorn will have?

A: Hit send too soon... Longhorn will support all infrastructure requirements for IPv6 (DHCP, DNS).

Harish_msft (Expert): we are also working to focus our efforts on certifying the quality of driver code. Even if we do not have a certification program for a specific device category all drivers will be able to participate in the code quality program. More details at WinHec.

Arvind_MSFT (Expert):
Q: Will be possible to run LH with IPv6 only? without IPv4?

A: Yes, it will be possible to run LH with IPv6 only, i.e. with IPv4 disabled.

Henry_MSFT (Expert):
Q: How far will reach Longhorns IPv6 support? Will it be supported throughout the system and all it's services, or again some halfbaked attempt like in Windows 2003?

A: Think I've answered this a couple of times....  The IPv6 support in LH will be complete, and all components and services will support it.

Henry_MSFT (Expert):
Q: When you say 'new integrated stack' what do you mean. Is this really a brand new stack??

A: Yes, it's a brand new stack, written from the group up. It supports both Ipv4 and Ipv6 in one binary (as opposed to the current implementation which has two). It will be possible to listen on both IPv4 and IPv6 simulataneously with a single listening socket.

Joe_MSFT (Expert):
Q: Will I be able to run an IPv6 only system? I mean absolutely without the IPv4, unlike now?

A: You can actually run IPv6-only with current versions of Windows by disabling the "Internet Protocol (TCP/IP)" component in Network Connections. However, lots of applications and services don't use IPv6 in current versions of Windows so you have limited functionality. To answer your question, yes, the current plan (subject to change) is to allow you to disable all use of IPv4 and run IPv6 only, with wide support for IPv6 in Windows applications and services.

Henry_MSFT (Expert):
Q: will it be possible to configure IPv6 in LH, all windows system with IPv6 up to now don't have this possibility ?

A: Yes, it will have configuration support.

Arvind_MSFT (Expert):
Q: Will the IPv6 stack optimized for each bitwidth on x86 and x86-64 on the respective Windows build, or will it just plain make use of 64bit integer ops where the 32bit CPUs have to rely on compiler optimizations?

A: In general, the IPv6 stack uses compiler optimizations where available. We do attempt to make use of 64-bit operations where possible.

Henry_MSFT (Expert):
Q: Will the new TCP/IP stack run in kernel mode, or is it implemented as a 'user mode' process?

A: It's in kernel mode.

Arvind_MSFT (Expert):
Q: Oooh, both protocols on single socket. Will older applications be able to accept inbound IPv6 connections if they're listening on 0.0.0.0? Or do they additionally listed on :: too?

A: No to the first question, and yes to the second. "Older" applications need to be using the correct sockaddr structures as well in order to work over IPv6.

Christian_MSFT (Expert):
Q: What level of effort are you extending to test for security bugs in the new IP stack and 802.11 stack? Threat modeling, manual testing, fuzzing - there's tons to do with networking stacks.

A: All Longhorn components are required to undergo threat modelling, code inspections, and extensive testing to ensure the best possible quality and security. Critical components like TCP-IP and 802.11 get special attention, and we will definitely study and test them as much as we can!

Henry_MSFT (Expert):
Q: What is MSFT doing to help assist the transition in the IT industry to IPV6 ? And... when do you expect to see corporate take up of IPV6?

A: We are pushing transition technologies (6to4, ISATAP, Teredo) heavily. Our message to the industry is "move the applications, get them IPv6 ready, rely on transition techologies until the infrastructure is in place". We are working with IGD vendors to get them to support 6to4 in their consumer products, for example. We believe there is a lot of value in IPv6 in a transition environment and that application demand will drive infrastructure upgrade.

As for corporate uptake of IPv6 - this will be driving by compelling applications and user demand. Longhorn will be a big piece of this as it supports IPv6 completely and the peer-to-peer framework that is part of Longhorn will require IPv6 to run.

Joe_MSFT (Expert):
Q: Will the IP stack auto configure to IPV4 or V6 if the network supports it ?

A: The current behavior being considered for Longhorn is to enable both the IPv4 and IPv6 stacks by default and to attempt to configure both stacks based on the presence of DHCP servers, local advertising routers, and the autoconfiguring behavior for both IPv4 and IPv6.

Dave_MSFT (Expert):
Q: In IPv6, will be available to select source address when making a connection? Currently not available in Windows 2003.

A: At the sockets layer, it is possible to select the source address when making a connection, including in XP and 2003, by binding to the source address prior to the connect call.

Jawad_Khaki_MSFT (Expert):
Q: will there be any IPv6 -> IPv4 'Gateway' maybe in LH Server RRAS?

A: Not clear what kind of gateway you are asking. gateways take many forms.We will support several transitional technologies that will enable migrating to IPv6 applications on existing IPv4 networks. Things like 6to4, Teredo, ISATAP

Joe_MSFT (Expert):
Q: Wil this new stack require me to learn the Networking Core for the MCSE all over again? Or are we talking about minor modifications?

A: The new TCP/IP stack is planned to have integrated IPv4 and IPv6 support. While I do not know what the current plans for the MCSE courseware are, you will need to know much more about IPv6 to understand basic network connectivity.

Jawad_Khaki_MSFT (Expert):
Q: Will there be a "real" IPSec client in Longhorn, or just the PPTP / L2TP vpn clients?

A: Windows supports IPSec for host-to-host as well as remote access scenarios since windows 2000. Support is pretty standard. What do you consider "real" ipsec? We will add support for IPv6 IPSec support.

Longhorn Networking Chat: Http, Winsock and QoS

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

Http, winsock and QoS are the areas closest to me organizationally so I'll start here.
There were a two http stack questions:

Henry_MSFT (Expert):
Q: Windows XP reduces simultanious connections to a HTTP (Web) server by default to 2-4. Will this be changed in Longhorn? (e.g. 5 simultanious connections allowed)

A: You are referring to the client connection limit, correct? We are conformant to the HTTP standard RFC which specifies the 2 connections/client/server limit. It is possible to change the limit programatically but the default will be standards conformant.

Henry_MSFT (Expert):
Q: Is WinInet going to be depricated at somepoint for something more reliable?

A: We currently have WinHTTP, which is our preferred unmanaged client API. We are also investing in improving the stability of WinInet for browsing experiences.

A bunch of QoS questions:

Henry_MSFT (Expert):
Q: What about QOS in the home or even DRM based access control for consumer scenarios?

A: We will have support for QoS in the home - some of this has already shipped in Media Center versions of the OS. This includes bandwidth measuring & monitoring, admission control, & QoS diagnostics.

Henry_MSFT (Expert):
Q: Thansk Henry .. can you expand on QOS diagnostics ? is that more just self healing/event response kind of scenarios? (e.g. network slows down .. do action x ) or ..

A: More about telling you why your application doesn't work. For example, if you're trying to stream video off a server but the network bandwidth is chewed up for some other reason (a game, another video stream, etc) we'd like to be able to inform the user/application that they can't get the bandwidth they need, but if they shut down the activity on machine X they should be able to.

Of course, we're also investing in cooperative admission control protocols, so participating devices & machines will be able to avoid this problem.

Henry_MSFT (Expert):
Q: Are we seeing more adoption of QOS tagging in consumer devices ?

A: This will be more important as consumer networking devices become more important. We think this is key thing going forward and we are working with the industry to try and accelerate this.

Henry_MSFT (Expert):
Q: Will be there a possibility to easely configure bandwith limitations for applications, or if the pc is an ics host for computers?

A: Yes, programatically, or via group policies. Are you interested in a specific UI configuration for this?

Henry_MSFT (Expert):
Q: If I am streaming audio or video over the net and downloading will the download interupt the streaming or will it be clever enough to reduce the speed of the download ?

A: We are looking at this...some of this is dependent on the applications. We certainly support the APIs and framework needed to do this in LH if applications use them. This is part of our QoS support.

... and a winsock question:

Henry_MSFT (Expert):
Q: In LH, will Layered Service Providers (LSP) be done away with?

A: No, they will still be supported. However, we are making efforts to clean up the architecture, make it more stable & secure, and make it easier to write solid LSPs.

Longhorn Networking Chat: Opening Remarks

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

First off was some opening remarks from Jawad:

Jawad_Khaki_MSFT (Expert):

Longhorn will offer a new integrated IPv4/IPv6 stack optimized for low-speed wireless and multi-gigabit networks. The new stack will have extensibility to enable easy integration with 3rd party products such as firewalls, parental controls & virus products. We will also have enhancements to provide easy diagnostics to help users and network managers to easily trouble shoot problems.

Home Networking. Our focus here is to enable effortless secure networks that will support state of the art technologies to enable new experiences in the home. Things like streaming of audio/video media streams for entertainment and real-time communications.

Wireless. Wireless will have the latest 802.11i security support. Furthermore we will have extensibility in the stack to support rapid innovation in the industry. Many issues related to Wireless authentication integration with Windows logon will be addressed. For enterprise customers we will provide centralized scripting support for 802.1x enterprise Wireless configuration.

Network infrastructure services (DHCP, RRAS/VPN, RADIUS) will be enhanced to enable IT Pros to enforce system health check. IPSec support will be enhanced to support for server-server communications, domain isolation, and network access protection. All networking infrastructure services DHCP, DNS, RRAS/VPN, RADIUS will be rev’ed to fully supprt IPv6.

Then the grilling began :)

Upcoming Executive Chat with Windows Networking VP Jawad Khaki

There is an upcoming online chat with Jawad Khaki regarding Longhorn Networking features on March 22 at 11:30. Want to be first to know what is changing (and there are years worth of work here) in the networking stack? This is the place to be. Or maybe that you have a favorite issues regarding the tcp/ip stack, winsock, firewall, UPNP, wireless, NDIS, home networking, Peer-to-Peer, IPV6? Here's your chance to tell the man in charge.

You can go read more about Jawad in his executive bio. Also, he is going to have many of his General Managers come to the talk including, Christian Hutima (of "Routing on the Internet" and IPV6 fame) and Henry Sanders (Transports General manager where the web transports and the TCP/IP stack live).

Update: The transcript of the event is up on Channel 9 thanks to ZippyV

Http.sys makes the news (not in a good way)

InformationWeek has an article about a reliability update posted to Windows Update for http.sys. The problem was that http.sys plus a recent update to a certain vendor's anti-virus software leads to a blue screen. Because of the type of failure, it took a while for the Windows Error Reporting crashes to get debugged back to us. We released a fix for the bug and attached it to the Error Reporting bucket. This meant that after the crash occured and you reported it to Microsoft, the UI would inform you of a patch, and let you install it. Still the crashes continued to come in, in bigger numbers. It was time to do something more, so we decided that the best thing for our customers was to get it released on windows update for everyone.

What can cause Wininet to return ERROR_INTERNET_CANNOT_CONNECT?

Glad you asked.
The following winsock errors get translated into ERROR_INTERNET_CANNOT_CONNECT:

• WSAENETDOWN
• WSAECONNREFUSED
• WSAENETUNREACH
• WSAENOTCONN

Learn more about these errors on the Windows Sockets Error Code page.

IE7 comming soon to Windows XP SP2

Bill Gates annouced IE 7 today at the RSA Conference:

Building on those advancements, Gates announced Internet Explorer 7.0, designed to add new levels of security to Windows XP SP2 while maintaining the level of extensibility and compatibility that customers have come to expect. Internet Explorer 7.0 will also provide even stronger defenses against phishing, malicious software and spyware. The beta release is scheduled to be available this summer.

It'll be great to get much of the realiability work we've done in WinInet out to the public.

Firefox and Mozilla to disable IDN till next version

Netcraft points out the annoucement from the Mozilla development team that they are disabling IDN support until a longer term solution to this phishing vuln can be done. " it is hoped that a better fix can be developed in time for Firefox 1.1".