OIT filters SSDP (Simple Service Discovery Protocol) traffic on the wireless networks operated by OIT. We do so because SSDP degrades campus network service while being unnecessary for the network functionality OIT supports.
SSDP 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. SSDP operates only on the local link (IP subnet).
SSDP query and announcements packets are "multicast" to the network. (SSDP response packets are sent via "unicast.") 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.
SSDP's use of multicast packets is designed to work within a single IP subnet. That is, SSDP traffic does not cross from one IP subnet to another. As a result, SSDP 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 as designed, SSDP only allows a device to exchange SSDP 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 SSDP; the protocol is intended for use on relatively small networks, rather than across large networks composed of multiple IP subnets.
In addition to being designed for use within a single IP subnet, SSDP 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 SSDP is designed include homes, small private offices, and ad hoc collections of devices connected to each other but possibly not to the Internet. In such environments, SSDP works to provide a "plug and play" environment; individuals can simply connect a set of computers, printers, and other devices together, then use SSDP to look up (or browse) the services available on their local network.
SSDP was not designed for use on larger networks. Besides the fact that it does not span multiple IP subnets, SSDP 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, SSDP generates a significant volume of multicast traffic.
Additionally, the SSDP multicast traffic in turn triggers ARP broadcast traffic. Apparently as devices acting as servers try to respond to SSDP 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 SSDP, the volume of SSDP 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 SSDP 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 SSDP.
This in fact is the situation we find at Princeton University. Recent versions of Microsoft Windows include SSDP capabilites. They often have SSDP turned on by default, to make these devices easy to "plug and play" in the small network environments where SSDP was designed to function. This results in unecessary SSDP multicast traffic and ARP broadcast traffic on significant portions of the campus network.
SSDP 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 SSDP.
For several years years, SSDP 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 SSDP 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 SSDP is left unchecked, we expect that network service will degrade further.
At the time we filtered SSDP multicast traffic, we found that it accounted for over 38% of all broadcast/multicast traffic on our wireless networks. (3% of the traffic was the actual SSDP traffic, and another 35% or more was ARP traffic triggered by the SSDP traffic). By filtering the SSDP multicast traffic, we reduced the broadcast/multicast traffic on our wireless networks by over 38% compared to what it had been prior to installing this filter.
OIT began filtering SSDP multicast traffic in December 2010. We filter SSDP multicast traffic because it degrades network service while at the same time is unnecessary for any of the network functionality OIT supports.
OIT filters SSDP 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 1900 is discarded as it tries to cross the core of the network. Due to network topology, this usually means that the SSDP 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 SSDP 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 SSDP 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 SSDP unicast traffic, only the multicast traffic. However, with the SSDP multicast traffic filtered, we expect to see little or no SSDP 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 SSDP does not indicate that OIT disapproves of SSDP, or that there is anything inherently wrong with SSDP. We don't require customers to turn off SSDP on their devices, or forbid the use of SSDP. But we don't provide support for SSDP or any functionality that relies upon SSDP, and we filter it to limit its ability to degrade network performance.