OIT filters WS-Discovery (Web Services Dynamic Discovery) traffic on the wireless networks operated by OIT. We do so because WS-Discovery degrades campus network service while being unnecessary for the network functionality OIT supports.
WS-Discovery is a protocol intended to allow devices to advertise services they wish to offer, and to discover services offered by other devices on the network. WS-Discovery operates only on the local link (IP subnet).
WS-Discovery query and announcements packets are (by default) "multicast" to the network. Unlike unicast traffic, multicast packets are flooded to large segments of the network, so every device interested in the requests and announcements can hear them.
WS-Discovery's default use of multicast packets is designed to work within a single IP subnet. That is, WS-Discovery multicast traffic does not ordinarily cross from one IP subnet to another. As a result, WS-Discovery can be used among a set of devices that are all attached to a single IP subnet, but cannot be used among devices attached to different IP subnets. Princeton University's campus network is composed of hundreds of IP subnets, so with its default behavior, WS-Discovery only allows a device to exchange WS-Discovery information with devices that happen to be attached to the same IP subnet. This limitation is not a bug. This is part of the design of WS-Discovery.
In addition to being designed for use within a single IP subnet, WS-Discovery's default behavior appears to be best used on relatively small network, consisting of dozens (or perhaps a few hundred) of devices, not thousands of devices. Examples of places for which WS-Discovery's default behavior is best used include homes, small private offices, and ad hoc collections of devices connected to each other but possibly not to the Internet. In such environments, WS-Discovery works to provide a "plug and play" environment; individuals can simply connect a set of computers, printers, and other devices together, then use WS-Discovery to look up (or browse) the services available on their local network.
WS-Discovery is designed to switch from using IP multicast to using IP unicast, so it can scale for use on large networks. But to take advantage of that feature, the University would need to operate a WS-Discovery proxy server (on each IP subnet). This does not appear practical in our environment at this time; we operate hundreds of subnets, and the number continues to grow.
WS-Discovery's default behavior (to use multicast) is not suitable for use on larger networks. Besides the fact that it does not normally span multiple IP subnets, WS-Discovery by default is a very "chatty" protocol. As each device multicasts to the network announcements of the services it is providing, and each device multicasts queries for services, WS-Discovery generates a significant volume of multicast traffic.
Additionally, the WS-Discovery multicast traffic in turn triggers ARP broadcast traffic. Apparently as devices acting as servers try to respond to WS-Discovery queries, they may need to broadcast an ARP request for the queryer. And once queryers discover devices acting as server, the queryers may broadcast ARP requests for the discovered devices.
Multicast (and broadcast) traffic is a vital part of the network; its existance is not inherently bad. However, when there are high rates of multicast traffic which most clients wish to receive (or high rates of broadcast traffic), this presents a problem. The network is forced to flood multicast traffic to all clients that wish to receive it (broadcast traffic is also flooded to all clients). And each client that receives the traffic is forced to examine these packets to decide what to do with each packet. Even when the actual bit rate for multicast (and broadcast) traffic may miniscule relative to the University's network capacity, our experience is that when the packet rate of such traffic gets too large, individual network-attached devices must consume excessive resources handling these packets. Workstations may be become unresponsive; network infrastructure may stop responding to management requests. Any networks with constrained bandwidth (e.g. wireless) may perform poorly. Eventually workstations become unusable and the network becomes unmanageable. As a result, we must take care that multicast (and broadcast) traffic on the network does not grow unecessarily large.
As the number of devices on a single IP subnet grows, and as those devices make increasing use of WS-Discovery, the volume of WS-Discovery multicast traffic and the ARP broadcast traffic it triggers grows to a point that adversely affects network service for all devices on that network. This problem doesn't arise in the environment for which WS-Discovery was designed (a small network), since that environment doesn't have many devices; it is a problem if many devices attached to single network try to use WS-Discovery.
This in fact is the situation we find at Princeton University. Recent versions of Microsoft Windows include WS-Discovery capabilites. They often have WS-Discovery turned on by default, to make these devices easy to "plug and play" in small network environments. This results in unecessary WS-Discovery multicast traffic and ARP broadcast traffic on significant portions of the campus network.
WS-Discovery is not a protocol OIT has ever recommended for use on campus, or has ever supported. While there are many OIT-supported uses of the campus network, none of them rely on WS-Discovery.
At first, WS-Discovery was just one of many kinds of traffic that OIT didn't explicitly support; we didn't need to restrict because it wasn't causing any harm. As the volume of WS-Discovery multicast and related ARP broadcast traffic on the campus network has grown, that's changed. By Fall 2010, the volume of this traffic on some parts of the campus network had grown to the point where it was degrading network performance. If the use WS-Discovery is left unchecked, we expect that network service will degrade further.
At the time we filtered WS-Discovery multicast traffic, we found that it accounted for 3% of all broadcast/multicast traffic on our wireless networks. By filtering the WS-Discovery multicast traffic, we reduced the broadcast/multicast traffic on our wireless networks by that amount.
OIT began filtering WS-Discovery multicast traffic in December 2010. We filter WS-Discovery multicast traffic because it degrades network service while at the same time is unnecessary for any of the network functionality OIT supports.
OIT filters WS-Discovery multicast traffic at the core of the campus network. It's installed in such a way as to apply only to those networks supporting wireless services provided by OIT. Specifically, any IP traffic destined to IPv4 multicast address 239.255.255.250 UDP port 3702 is discarded as it tries to cross the core of the network. Due to network topology, this usually means that the WS-Discovery traffic is blocked as it tries to enter or leave a campus building (because to do so it must cross the network core), but the traffic is not blocked within the building. We say usually because there may be some buildings that share a single connection to the campus core, and conversely some buildings that have more than one connection to the core; the extant to which WS-Discovery traffic can flow before it is blocked will vary depending on the topology. Also keep in mind that even within a single building, OIT Ethernet Service and OIT Wireless Service are on different IP subnets, so WS-Discovery has never worked between the two.
The filter is also applied at the edge of the wireless services provided by OIT, so it also applies to traffic sent by a wireless client as that traffic arrives at the wireless access point or the wireless controller. This filters the traffic before it would be flooded to other clients (wireless or wired), even if those clients are on the same leg of the network, or behind the same wireless access point.
We do not filter WS-Discovery unicast traffic, only the multicast traffic. However, with the WS-Discovery multicast traffic filtered, we expect to see little or no WS-Discovery unicast traffic, given the way the protocol works.
It is possible that in the future, the filter installed at the network core might be expanded to also include the wired (non-wireless networks).
Our filtering of WS-Discovery does not indicate that OIT disapproves of WS-Discovery, or that there is anything inherently wrong with WS-Discovery. We don't require customers to turn off WS-Discovery on their devices, or forbid the use of WS-Discovery. But we don't provide support for WS-Discovery or any functionality that relies upon WS-Discovery, and we filter it to limit its ability to degrade network performance.