Before the Federal Communications Commission Washington, DC 20554

In the Matter of )

Protecting the Privacy of Customers of Broadband ) WC Docket No. 16‐106 and Other Telecommunications Services )

)

To: The Commission

COMMENTS OF

SANDVINE INCORPORATED

May 27, 2016 Sandvine Incorporated 408 Albert Street Waterloo, Ontario Canada N2L 3V3

Introduction Sandvine is grateful to participate in the FCC’s Notice of Proposed Rulemaking, In the Matter of Protecting the Privacy of Customers of Broadband and Other Telecommunications Services (the NPRM).

Sandvine makes network policy control equipment and software. We have over 300 BIAS provider customers headquartered in over 100 countries around the world. Approximately 60 of those customers are in the United States. Five of the six largest (or seven of the top ten) cable MSOs in North America use Sandvine’s solutions. The traffic of hundreds of millions of Internet subscribers flows through our solutions every day.

Sandvine’s solutions:

1. Enable the rapid creation, update and charging behind innovative application‐specific (or agnostic) service plans that enhance consumer control and choice, like you may see with offerings like T‐Mobile’s Binge On for video streaming (not a Sandvine customer); 2. Let BIAS providers understand the traffic on their networks, down to the application level; 3. Manage traffic when the network is congested and to meet subscribers’ quality expectations; 4. Protect the network and subscribers from malicious cyber‐attacks; 5. Let BIAS providers engage with their subscribers at critical moments to improve service, such as through context sensitive alerts about usage levels, security warnings, roaming charges, and quality of experience issues. The alerts are interactive to allow subscribers to immediately take action to control their service;

All these use cases are supported in part by (DPI) technology. The NPRM, in paragraph 256, calls for DPI to be used only in the context of reasonable network management. This proposal is flawed and reflects an essential misunderstanding of the breadth of legitimate and critical use cases that DPI supports. In fact, only 17% of Sandvine’s software order value (each use case is represented as a software load) related to reasonable traffic management, and we are the acknowledged leader in DPI, according to IHS Infonetics1.

DPI‐based solutions are critical to help operators plan their business, manage costs, compete more effectively as traditional revenue streams erode, charge for services, offer subscribers more choice and control and help subscribers enjoy a dramatically improved Internet experience.

Despite the proposal in paragraph 256 to restrict the use of DPI, the NPRM actually carves out a number of DPI’s most important use cases, like charging (solution 1 above, covered by paragraph 115) and

1 IHS Infonetics, “Service Provider Deep Packet Inspection Products, Biannual Worldwide and Regional Market Share, Size and Forecasts: 2nd Edition”

security (solution 4 above, covered by paragraph 117), as being expressly allowed. To deploy application‐based subscriber service plans (such as T‐Mobile’s Binge On) at all and to create an accurate bill for it, DPI is a requirement as it is currently the most reliable technique to accurately identify (and then bill for) the video traffic. Using DPI for this type of use case alone represented 62% of Sandvine’s software order value in 2015.

Further Sandvine would argue that all of the solutions above are necessary in the BIAS provider’s “provision of the telecommunications service from which such information is derived, or services necessary to, or used in, the provision of such telecommunications service,” and as such are covered under NPRM paragraph 112.

In other words the NPRM simultaneously wants to restrict the use of DPI to traffic management but simultaneously identifies all of DPI’s primary use cases as ones that BIAS providers are free to deploy in a manner that does not require further consent from subscribers to use customer PI, because of their very centrality to operations. Sandvine assumes that the reason for this is that the FCC is simply unaware of the ubiquity of DPI in the infrastructure of the Internet.

DPI is a critical, time‐tested and ubiquitous technology embedded across an incredibly wide variety of networking equipment, software and solutions. DPI is, from a network engineering and architectural perspective, the act of any network equipment which is not an endpoint of a communication using any field other than the Layer 3 header information for any purpose. Any credible definition of DPI would recognize that all of the following equipment and solutions incorporate DPI:

● Netflow and its equivalents (found in every network switch or router from Cisco, Juniper, Ericsson, etc.), which are cornerstones of every BIAS provider’s capacity planning activities ● IPFIX ● IPDR ● Home routers ● Gateways ● Security appliances such as Firewalls, Intrusion Prevention Systems and Intrusion Detection Systems ● Network Address Translation ● Among other building blocks of the Internet

To prohibit the use of DPI other than for reasonable network management would, quite simply, and without hyperbole, threaten the very functioning of the Internet itself. The IETF and 3GPP have certain standards that implicitly or explicitly require the use of DPI.

Sandvine submits that paragraph 256 of the NPRM suffers from a common mistake: it is focusing on a specific technology rather than its use. Technologies aren’t the issue, but their uses can be. Accurate charging, effective network planning and protecting subscribers from malicious traffic aren’t suddenly

transformed into concerning use cases when they are implemented via DPI versus any other technology. They are always essential. A core principle of the FCC’s Open Internet Order is that BIAS providers don’t pick winners or losers amongst edge providers. Similarly, it is not the FCC’s role to pick winners and losers amongst network solutions providers or their technologies.

Privacy is about the nature of data collected, how and with whom it is shared and used, and the appropriate permissions required in each case. It is not about the technology used to collect the data. A given piece of data is equally sensitive‐‐ and requires special permissions or not ‐‐ whether collected by DPI or a browser (HTTP) cookie, or any other technology. A given use case either requires protection or does not.

Privacy is about use cases, not technologies.

Focus on the Use Case not the Technology Regulation and legislation has often struggled to keep up with technology. Where technology has enabled access to new information or new use cases for existing information, and a perceived need for rules followed, regulators and legislators have often tended to focus on the technology itself, rather than the enabled use cases. In essence, they focus on writing the letter of the law when they should focus on the spirit.

Take for example the case of American jurist Robert Bork, who was a candidate to the US Supreme Court. During the debate of his nomination, Bork’s video rental history was leaked to the press, which in turn led to the enactment of the Video Privacy Protection Act. In this case, the law clearly did not stay abreast of technology, and was enacted for the narrow purpose of preventing information about VHS tape rentals from reaching the public, anticipating neither DVD rentals 10 years later, nor over cable, nor Internet‐based video distribution. If instead society had acted to place guidelines on “dissemination of entertainment preference information”, which was the actual intent, we would have been better served, rather than having legislation narrowly targeted to a specific technology. Such a law would also not have created an unlevel playing field amongst technologies.

Similarly, digital Single Lens Reflex (SLR) technology underlies cameras that can be used to take photos at family birthday parties or applied for surveillance of individuals and public spaces. One use of the technology raises privacy issues, the other does not. Nobody suggests that SLR technology be banned. We create “peeping tom” or voyeurism laws to isolate unacceptable use cases. Rules and laws should not focus on DPI technology either. Privacy concerns properly attach to applications or uses of technologies, not to the technologies themselves.

Privacy is all about the expectations of those involved. As a consumer, I expect the content of my email message to be private between me and my intended recipient, regardless of whether I send it via my residential Internet service provider’s mail server, or via a web‐based service such as Google’s Gmail. If this email were to be used by anyone other than my intended recipient, my expectation of privacy

would not be met, regardless of whether this unauthorized use was facilitated by my BIAS provider or by a web‐based service I am using. The societal expectation of privacy applies to the use of the information, not the method (technology) or point of interception. Privacy use cases should be viewed through the expectations of the information originator, not through the specific narrow methods which are used to gather the information.

The FCC is proposing in paragraph 256 of the NPRM to only allow DPI technology when used for reasonable network management. In so doing, it is making the same mistake as in the Bork case and something as inconceivable as banning digital SLR technology – it is focusing on a technology rather than the use cases of it. If the FCC continues down this path, the result will be threefold:

1. A broad variety of ubiquitously deployed network equipment and solutions, all of which employ DPI technology (and have through history) could no longer be used. Such equipment and solutions are integral to the proper functioning of the Internet, and beneficial to subscribers.. 2. A “technology gap” would be created for other technologies to exploit. Technology changes all the time. New technologies can be created to gather the same information as DPI (certain existing technologies already gathers some of the same information), but through a different approach, which could then be used unfettered by any rules. 3. The creation of an un‐level playing field between network solutions providers that already use different technology to gather the same (or more) information as DPI‐based solutions, but for which there is no restriction on use. A core principle of the FCC’s Open Internet Order is that BIAS providers don’t pick winners or losers amongst edge providers. Similarly, it is not the FCC’s role to pick winners and losers amongst network solutions providers or their technologies .

Ironically, by allowing the use of DPI for reasonable network management the FCC is acknowledging the central place that the “use case” should hold when determining its privacy rules. However, it contradicts its own understanding of that point by subsequently proposing that DPI can’t be used for other purposes, even those like charging and cyber security, for which the NPRM otherwise explicitly allows collection and use of customer PI without subscriber consent.

Does the FCC understand that DPI is a central technology for accurate charging under subscriber service plans? For cyber security? For planning and implementing innovative, consumer‐friendly service plans? For network capacity planning? For detecting fraud? For important, real‐time communications that give control and choice to subscribers? Are any of these use cases transformed into prohibited ones when they are implemented via DPI versus any other technology?

Privacy is about the nature of data collected, how and with whom it is shared and used, and the appropriate permissions required in each case. It is not about the technology used to collect the data. A given piece of data is equally sensitive‐‐ and requires special permissions or not for a given use case ‐‐ whether collected by DPI or a cookie. A given use case either requires protection or does not.

Privacy is about use cases, not technologies.

Nebuad and Phorm: the Use Case that Shamed DPI’s Good Name Sandvine suspects that the genesis of the proposals in paragraph 256 of the NPRM dates back as far as 2008 when DPI’s good name was dragged through the cyber mud by two behavioural targeted advertising companies: Nebuad in the United States and Phorm in the United Kingdom.

Looking at the U.S. case, Nebuad’s solutions monitored all Web surfing habits of subscribers in order to form profiles of users to direct more targeted advertising to them, which could solicit higher ad rates than less targeted approaches. The solution was also alleged to insert packets into web pages to aid with monitoring. The technology was deployed in BIAS providers’ networks with at‐best “opt‐out” permission, but also in some instances alleged to have been deployed with no notice to subscribers whatsoever.

The controversy rose to the attention of the House Subcommittee on Telecommunications and the Internet, which (following the same flawed tradition as the Bork video rental debacle) held a hearing on the privacy implications of DPI (when it should have focused on the privacy implications of behavioural targeted advertising, however it is achieved). In the mind of regulators, legislators and the public, DPI was inextricably linked with this single highly‐privacy‐sensitive use case.

Make no mistake: targeted advertising is not a common use case for DPI among BIAS providers.

Targeted advertising is largely the domain of services like Google and Facebook. Other technologies, like cookies, dominate their online advertising activities. If privacy rules are needed to protect consumers from targeted advertising (and Sandvine believes that they are), then the rules need to address all approaches to it, not just DPI, which is a very minor approach in a massive industry.

Not surprisingly given the circumstances, both Nebuad and Phorm failed.

Again, the lesson: focus on the use case, not the technology.

DPI is a Traffic Classification Technology One definition2 of DPI:

“DPI functionality is invoked when a device looks or takes other action, based on information beyond Layer 3 of the OSI model”, where OSI is the Open Systems Interconnection (OSI) Reference Model.

A slightly more refined definition would identify any inspection activity beyond that necessary to route packets in the network:

2 https://en.wikipedia.org/wiki/Deep_packet_inspection

“DPI is, from a network engineering and architectural perspective, the act of any network equipment which is not an endpoint of a communication using any field other than the Layer 3 header information for any purpose.”

Sandvine subscribes to the latter, but either is useful for the purpose of this submission.

By looking beyond the header information in Layer 3, DPI can give insight into important traffic information that a BIAS provider can use to improve subscribers’ Internet experience as well as its competitiveness in the market. Most notably, DPI provides information about application usage, which is critical to several use cases that are central to a BIAS providers’ business, including the ability to plan capacity, plan and execute new service offerings, measure and manage subscriber quality of experience, detect fraud and many others.

Solutions that incorporate DPI are often mistakenly believed to be looking at the “content” of personal Internet data. For Sandvine’s solutions that use DPI, the following can be stated unequivocally. They:

● Do not read the words in your e‐mail; ● Do not listen to your voice calls; ● Do not watch your video conferences; ● Do not know what particular video you are streaming; ● Do not look at files you’ve downloaded or uploaded; ● Etc.

Quite simply, none of our cases require that information so we don’t look for it, nor collect it. Any use cases that do would certainly require subscriber permission.

When necessary for the use case, Sandvine knows the URL a subscriber is visiting. For example, when we’re deployed for cyber security or regulatory compliance purposes the URL is critical to determine whether a subscriber is about to visit a known phishing or child pornography site. Even then, the solution does not keep track of the legitimate web sites that subscribers have visited (which could later be used for marketing purposes) because it is not germane to the use case.

For reporting purposes we can report on Top URLs in a network, but this is aggregated data that is built upon fully anonymized individual data. The use case itself determines what data is needed for action to be taken and we look for and collect nothing more than what is needed.

Traffic Classification Techniques For the purposes of traffic classification, Sandvine complements DPI, which looks for “signatures” in a packet, with behavioural inspection techniques, which looks at the behavior of a traffic flow. The techniques can be used separately or together – whichever most efficiently and effectively achieves the appropriate level of accuracy in application identification.

With behavioural flow‐based inspection, which Sandvine commonly uses to identify malicious traffic and certain encrypted protocols, the packet itself is not inspected – at all. Instead, the behaviours of packets in a flow are analyzed to identify matches with known application behaviours. For example, a denial of service attack can be readily recognizable by the pattern of “hits” on its target destination. As no inspection of the actual packets takes place, the solution does not come in contact with customer PI.

On its own, behavioural flow‐based inspection has limitations. It is only sufficiently accurate in identifying certain specific classes of applications that demonstrate unique behaviours (e.g., bulk applications, like P2P or FTP for file‐sharing, or interactive applications, like video gaming or VoIP) rather than down to the individual protocol level (such as SIP and RTP). Additionally, any network reporting that relied solely on behavioural flow‐based inspection would not be able to identify a number of application classes that aren’t uniquely identifiable by their flow behaviour and as a result would be too vague to allow for useful network planning and other use cases.

With signature‐based DPI, a library of known application “signatures” is compared to a packet to identify matches. By way of example, the diagram below shows the breakdown of a SIP VoIP packet OSI Reference Model.

TCP/IP Layer Addressing Equipment Reading SIP Invite

Layer 1 Wire type, location Provisioning tools (wire)

Layer 2 Ethernet address, Ethernet type, 802.1p Ethernet address, Ethernet type, 802.1p Ethernet switch (link tags, vlan tags tags, vlan tags

Layer 3 src IP address: caller IP address, DSCP, protocol Router (internetwork) dst IP Address: SIP Server

Layer 4 src port: X (random) TCP, UDP ports Router, SBC, stateless firewall, NAT (transport) dst port: 5060 (default SIP)

INVITE VIA SIP/2.0 Layer 7 URL, SMTP address, POP3 mailbox Router, SBC, stateful firewall, NAT, IDS ….. (application) Contact:

(content) Web page, email body Anti-Virus, content-accelerator Voice Info

In most cases for SIP, the caller will contact the SIP server over port 5060. However, a SIP server can, and often is, configured to work on different ports. Thus, to accurately identify this traffic, a signature based on the IETF RFC standard for the SIP protocol is applied to the packet. In this example, and as shown in the fourth column of the diagram at Layer 7, the solution looks for the presence of “INVITE” followed by some server address then “VIA SIP/2.0”. By examining this protocol’s header, the solution is able to determine whether the flow is SIP. The solution does not look at the flow’s contents, i.e., the voice information, as it is not required to make the protocol identification.

If there is no match, then the solution immediately forgets the inspected data and compares the next signature definition in its library to the packets being inspected. The entire packet is not scanned, as if browsing through a magazine. Instead, only those locations that hold identifying signature characteristics are inspected and only to the extent necessary to see if there is a match with the signature profile in the library.

In this example, DPI identifies the protocol and uses this information as an input to decide whether it is relevant for the application of a network policy. The process is similar to a mail‐sorting machine: the address is matched, the decision is made and the address is then forgotten.

For both behavioural flow‐based and signature‐based inspection, once identification has occurred further inspection not only stops, but the attributes examined in the process of arriving at that identification are discarded.

(Note: Separately, for our Business Intelligence solutions, we only report application usage information on an aggregate level, such as the number of VoIP minutes over the last hour by all users.)

For signature‐based inspection, identification can typically happen in the first couple of data packets in a stream. More often than not, those first few data packets don’t contain data that would typically be considered the content of a transmission, such as the text in an e‐mail or the voice in a VoIP call, etc. For example, for a SIP‐based VoIP call the first two data packets would be part of the “control flow”, which is used to establish call permissions and locations, etc., to initiate the call. Data from the actual conversation would only appear in subsequent packets.

The Ongoing Evolution of Traffic Classification Traffic classification continues to evolve with changes in network traffic. Early DPI solutions relied only on Layer 4 information to identify the TCP or UDP port that a packet was traversing. For example, a packet on port 80 is describing itself as http traffic. Application developers voluntarily include the port number in the packet header as a means of identifying the application. It is an honour system.

Popular applications, like Skype, were soon being developed that would intentionally obfuscate their identity to ensure passage when their proper port was blocked by an end user (e.g., a business that may be concerned about potential security vulnerabilities). Increasingly, Layer 4 DPI became unreliable as more and more obfuscation occurred. To illustrate, in a filing to the Canadian Radio‐television and Telecommunications Commission (CRTC) process on Internet Traffic Management Practices in 2009, Telus disclosed that only 3.08% of network bandwidth was being consumed by P2P file sharing, when a typical level for fixed line networks in North America was 20%3. The Telus result was from port‐based identification, while the industry average based on Layer 7 DPI. In describing the result, Telus stated:

“It is not possible for TELUS to provide an accurate breakdown of the composition of the traffic carried over its Internet networks because TELUS does not have that degree of visibility into Internet traffic. However, certain traffic analysis tools employed by TELUS at the core backbone level provide some insight into protocol use (by port number), though no historical (i.e., 2006‐ 2008) data is available. The chart below represents a rough attempt to identify the top seven types of applications in use, but should not be taken as complete or accurate for the reasons

3 Sandvine “2009 Global Broadband Phenomena” report

explained below. In particular, it is important to note that it is not possible to accurately estimate the percentage of traffic representing or peer‐to‐peer (P2P) filesharing because so much of such traffic today appears to the network as Hypertext Transfer Protocol (HTTP) traffic.

General application type %age Examples

Web 76.64% (HTTP, HTTPS) Streaming media 5.30% (Flash, MS, RTSP) Gaming 3.17% (Xbox, World of Warcraft) P2P 3.08% (gnutella, bittorrent) Undefined 2.79% (port 0 - fragmented or IPSec) Usenet news 1.81% (NNTP, NNTPS) Mail 0.12% (POP)

These data do not divide into the categories identified in the question (HTTP, P2P, UDP) for several reasons. TELUS notes that while HTTP (using port 80) was historically associated with general web content, many different services (including P2P filesharing applications) now use the same port. TELUS does not have the ability to differentiate between these different types of traffic.”

As a result of this traffic classification challenge, signature‐based DPI that incorporated Layer 7 data was needed.

The evolution in network traffic continues. For example, Sandvine has recently reported that encrypted traffic represents approximately 38% of traffic on fixed line networks in North America and approximately 65% of traffic on mobile networks in North America4, reflecting a growth trend that has been in place for a while. , the largest source of traffic on fixed line networks in North America, had only just begun to encrypt their streams when the data was published. As a result, Sandvine predicts that by the end of 2016, global Intenet traffic will be more than 70% encrypted, with some networks surpassing the 80% threshold5. This is a positive trend as it helps to protect the privacy of subscribers.

4 Sandvine “Encrypted Internet Traffic: A Global Internet Phenomena Spotlight”, https://www.sandvine.com/trends/encryption.html 5 Sandvine “Encrypted Internet Traffic: A Global Internet Phenomena Spotlight”, https://www.sandvine.com/trends/encryption.html

For the most part, the application can still be discerned with encrypted traffic. For example, Sandvine can still identify Facebook, YouTube and other encrypted applications, because key information like the Server Name Indication (SNI) is still “in the clear”. However, certain important information that may have implications for traffic management, etc. (like the video resolution) is not. As a result, in the future Sandvine believes that behavioural, flow‐based analysis (enhanced through machine‐learning techniques) will become more important to use alongside DPI to extract that kind of information.

But again, from a privacy perspective, does it matter what technological approach is used to gather the information? Clearly not. If traffic management, accurate charging, cyber security, etc. are all critical use cases to help BIAS providers deliver their core services, and therefore don’t require additional permission from subscribers, then certainly that’s the case no matter what technological tool was used to gather the requisite information to deploy them.

DPI is Everywhere!

Remember that DPI is, from a network engineering and architectural perspective, the act of any network equipment which is not an endpoint of a communication using any field other than the Layer 3 header information for any purpose.

To help the FCC understand the implications of restricting the use of DPI only to reasonable traffic management, a review of the ubiquity of DPI in networking equipment and solutions would be instructional. Here are some examples:

● NetFlow (Cisco) (and Jflow (Juniper), NetStream (Huawei), Cflowd (Alcatel‐Lucent), Rflow (Ericsson)). All these networking solutions are based on variants of the original Cisco NetFlow technology and use information beyond Layer 3. For example, NetFlow can see the port number, which is Layer 4 information. It can retrieve the URL, which is Layer 7 information. NetFlow can perform full packet capture, which is a Layer 7 capability. Data from NetFlow is arguably the industry standard for BIAS providers’ capacity planning activities and is used extensively in network security and other use cases. NetFlow and its variants are embedded by default into each interface of the access switches and routers that form the backbone of the Internet today. It inarguably uses DPI, by any credible definition. ● IPFIX is an IETF protocol created to standardize the export for Internet Protocol flow information from routers, probes and other devices that are used by mediation systems, accounting/billing systems and network management systems to facilitate services such as measurement, accounting and billing. IPFIX was based on NetFlow version 9 and accordingly uses information beyond Layer 3 to identify information such as port number, destination URL, etc. This standard requires DPI. ● IPDR (IP Detail Record) is originally a billing standard and widely used today for quality, capacity, and billing purposes in the Cable industry. It introduces the concept of service flows which map to applications, and is used to measure volume and delay on e.g. voice versus Internet traffic.

● Packet gateways incorporate DPI for many of the same use cases as Sandvine. ● Routers/firewalls look at the Layer 7 SIP exchange, for example, to extract flow information to let the voice data through. If they don't, the voice component is blocked. ● NAT. DPI is also a key part of the innovation in allowing a migration from IPv4 to IPv6, allowing a network operator to convert from one to the other using a carrier‐grade network‐address‐ translation (NAT), and keeping protocols such as VoIP operational.

In other words, DPI is a critical, ubiquitous and time‐tested technology. Quite simply, and without hyperbole, any rule that limits the use of DPI solely to reasonable network management threatens the very functioning of the Internet itself.

Many Critical Use Cases for DPI

So how is DPI used?

Sandvine is the acknowledged leader in DPI, according to IHS Infonetics’ “Service Provider Deep Packet Inspection Products, Biannual Worldwide and Regional Market Share, Size and Forecasts: 2nd Edition,” dated October 2015. According to IHS Infonetics, when it comes to DPI we’re bigger than Cisco, Huawei, and any other major network equipment vendor, all of which include DPI in their offerings.

Given Sandvine’s leadership position in DPI, the FCC may be surprised to learn that the company gets no revenue whatsoever from advertising use cases (the use case that Nebuad and Phorm deployed that confused the public about DPI). Further, only 17%6 of the company’s software order value (Sandvine’s use cases are represented as software loads) in fiscal 2015 relates to reasonable network management.

By contrast, 100% of Sandvine’s deployments include its base Business Intelligence software, called Network Demographics, which is bundled with all sales of Sandvine’s Policy Traffic Switch so that BIAS providers can understand network traffic before and after network policies (such as for traffic management, cyber security, and subscriber service creation, etc.) are put in place. In addition, 8% of software order value relates to a value‐added Business Intelligence product called Network Analytics.

A full 62%6 of Sandvine’s software order value in 2015 related to BIAS providers implementing innovative subscriber service tiers. In other words, today, from Sandvine’s leadership perspective, when it comes to BIAS provider use cases for DPI, it’s not at all about advertising and it’s predominantly about giving subscribers choice in services, rather than about managing network traffic. At the highest level, you can start to see the impact that restricting DPI to “reasonable network management” would have to subscribers, BIAS providers and networking equipment providers, like Sandvine. Any such rule would greatly harm the entire Internet ecosystem and be wholly discriminatory against vendors like Sandvine.

6 See slide 7 in Sandvine’s latest investor presentation at https://www.sandvine.com/downloads/investors/general/latest‐investor‐presentation.pdf

In this section, we’ll review some use cases that would not be possible without DPI.

Business Intelligence While certain network traffic data can be gleaned without DPI (total traffic volume, off‐peak and at peak, number of active subscribers, etc.), such data often does not provide sufficient information for informed decisions by BIAS providers. Application‐level data is critical, and that’s only available with DPI.

Applications place widely varying demands on the network. VoIP and online gaming consume little bandwidth but have very low tolerance for latency and packet loss. Certain types of video are bandwidth‐intensive but can be tolerant of loss, latency and jitter due to buffering, while other video types have entirely different sensitivities. Broad averages of throughput, latency, loss or jitter are insufficient to describe the subscriber’s experience with individual applications. There are a number of critical use cases where DPI adds significant value:

● Subscriber service planning. What applications are trending in the network? Which applications may create the basis for compelling application‐based service plans (both from a subscriber “popularity” and bandwidth cost perspective), potentially to address low‐income earners like students or seniors, or others that simply give price certainty for usage of a particular application, like streaming music, without the risk of overages? ● QoE measurement: Broad averages of latency, jitter and loss for all traffic may indicate that network quality is fine, while certain applications are actually suffering impairment due to their specific sensitivities. To get a true picture of the subscriber experience (and therefore be able to manage it) requires application‐level quality scores. Additionally, only DPI can detect packet drops – a key quality metric – as Layer 3 appliances only store and forward packets through the network. ● Capacity planning: Links that are running at or near capacity may or may not be impacting subscriber QoE. Only application‐level information provides the answer. For example, expanding throughput in a “near‐capacity” network location when all adaptive video traffic (like Netflix) on the resource is already being transmitted at HD rates would not improve the quality of that application (it’s already at maximum quality), so capital would be better deployed to network locations where video is being limited to SD rates due to capacity constraints. Further, DPI (combined with behavioral analysis, in some cases) can detect SD versus HD flows and the video type (live streaming, P2P streaming, video on demand, etc), which due to their unique characteristics react differently to network conditions, like congestion, and should be managed differently. ● Formulating and measuring the impact of reasonable traffic management policies: When traffic management is necessary at a congested network location at a moment in time, the most targeted (and therefore most reasonable) approach would consider the needs of individual applications. Visibility into applications would let BIAS providers exclude from the shaping any traffic that is not contributing meaningfully to the congestion and which would be significantly adversely impacted by shaping, like VoIP, online gaming and other low‐bandwidth, real‐time

applications. Measurements of the results, by application could instantly provide feedback on the quality of each application after the shaping policy was deployed. ● Fraud detection: Subscribers have tried to make all their data look like DNS traffic, because it travels free in some networks. DPI can validate the “DNS” traffic to confirm its true identity and circumvent fraud. Similarly, DPI can be used to report on subscribers circumvention of geographical restrictions on content (getting the U.S. version of Netflix in Canada). In VoLTE, the voice network bearer is essentially a tunnel that gives voice traffic higher priority over other data traffic when a call traverses the network. Other applications can fraudulently obfuscate themselves under the VoLTE bearer, which only DPI could detect. ● Device‐aware subscriber communications: to communicate with subscribers effectively, (whether to avoid bill shock when usage thresholds are about to be eclipsed, for security alerts, or for relevant service options like roaming plans for travelers), a message needs to be presented in a format appropriate to the device that the subscriber is using at the moment. DPI can discern the device type by looking at information across all OSI layers. ● And many others…

Sandvine not only makes all of this data available in its own Business Intelligence solutions, increasingly BIAS providers are deploying Big Data solutions to support use cases like Customer Experience Management, into which Sandvine feeds its raw data (in accordance with the BIAS provider’s subscriber data protection techniques). In the Big Data solution, Sandvine’s network data can be correlated with data from other systems, like Customer Care, to get a more fulsome view of the customer experience and resolve problems more quickly.

Accurate charging for innovative service plans As mentioned, at Sandvine DPI is primarily used for the deployment of innovative service plans. The use case represents a full 62% of Sandvine’s software order value, much of which relates to consumer‐ friendly service plans that zero‐rate (or bundle in) usage of certain applications.

In this use case, DPI technology identifies whenever subscribers to the zero‐rated plan use the zero‐ rated application (e.g., video streaming, as with T‐Mobile’s Binge On). The solution would then communicate such usage to the charging system, and other necessary systems, in real‐time to ensure that the data is not counted towards any data cap for the subscriber. For such a use case, DPI involving signature inspection at Layer 7 would be required to generate an accurate bill for the subscriber.

Similarly, for sponsored data plans (like Verizon’s FreeBee Data), where for marketing or benevolent purposes a third party volunteers to pay for subscribers’ usage of its application, or visits to its website, etc., DPI would be used to identify the sponsored applications or URLs. The solution would communicate such usage to the charging system, and other necessary systems, so that the charge for the data is “reversed” and applied to the application or content provider instead of the subscriber, like an Internet toll free call.

Also, mobile carriers often zero‐rate traffic to its self‐care portal or apps to allow the user to change preferences, buy credits, etc without the need to pay for the bytes. Similarly, airport WiFi providers zero‐rate traffic to let customers without any credit to access a portal to log in or pay for the service.

By proposing to limit the use of DPI to reasonable network management, the FCC is simultaneously putting T‐Mobile’s Binge On, Verizon’s FreeBee Data and other common zero‐rating use cases offside of its rules. These consumer‐friendly, competition‐enhancing services would be denied to subscribers. After an FCC meeting on November 19, 2015, Chairman Wheeler was asked to comment on T‐Mobile’s Binge On plan, as it related to the FCC’s Open Internet Order. Mr. Wheeler had this to say:

“It’s clear in the Open Internet Order that we said we are pro‐competition and pro‐innovation. Clearly this meets both of those criteria. It’s highly innovative and highly competitive.”

With this NPRM, is the FCC truly meaning to reverse its stance on such plans? Is it no longer interested in supporting “highly innovative and highly competitive” service plans? We suspect that’s not the case. Instead we believe that the FCC was unaware of the central role of DPI in such innovation.

Additionally, certain mobile service plans are transparent in their requirement that tethering of other devices is not allowed. DPI is capable of supporting such plans by inspecting header information beyond Layer 3 that can reveal the related device type. A message could instantly be displayed to the user reminding them of the service terms.

Sandvine submits that the charging use case for DPI is explicitly covered by paragraph 115 of the NPRM, as the technology is explicitly required to “… (1) initiate, render, bill, and collect for broadband services.” Accordingly, under the NPRM BIAS providers should be able to use, disclose, or permit access to customer PI gathered through DPI in connection with this use case, without customer notice or approval.

Cyber security Sandvine uses DPI to enable a number of cyber security use cases.

Outbound spam mitigation: count mail activity to and from email accounts to determine anomalous activity that indicates spam. To achieve this goal Sandvine accesses information from SMTP (Simple Mail Transfer Protocol ) headers in Layer 7.

Phishing attacks: reference best‐of‐breed, third party libraries of known phishing websites against the URL (found in Layer 7) of each inspected data packet. If there is no match, the solution forgets the inspected URL.

Regulatory compliance: reference libraries of websites that are required to be blocked by regulatory authorities in a jurisdiction (for example the Internet Watch Foundation list of individual web pages with child sexual abuse content) against the URL (found in Layer 7) of each inspected data packet. If there is no match, the security solution does not record the inspected URL.

Distributed Denial of Service (DDoS) attacks: use machine learning techniques that combine Layer 3 to Layer 7 data to look for correlations that suggest an attack. For example, if packets in a suspected flow “look” homogenous (similar characteristics such as inter‐packet delay, packet‐length, etc.) then there is an increased chance that the flow is part of a DDoS attack as packets in a normal flow are rarely uniform. DPI is required for this approach.

Parental Controls: inspect packets for matches with certain web sites or categories of web sites (e.g., pornography, gambling) to block content as required by the subscriber, all of which requires inspection of Layer 7 data.

Sandvine submits that all of these use cases are covered under paragraph 117 of the NPRM, which allows the BIAS provider to use or disclose CPNI (and possibly all customer PI) whenever reasonably necessary to protect themselves or others from cyber security threats or vulnerabilities.

Subscriber engagement Increasingly BIAS providers are realizing that ongoing engagement with subscribers, through important alerts impacting the service and contextual offers and promotions, etc., is one important aspect to building loyalty. From a subscriber’s perspective, communications from the BIAS provider can be very useful to avoid bill shock, or to receive relevant offers that could provide better or less expensive service, or when the subscribers’ service is being compromised by a malicious attack or quality of service issues.

To be useful rather than irritating, such moments of engagement need to take into account as much as possible about the subscriber’s current context, including the application, device and location of the subscriber at the moment of engagement– some or all of which is information gathered by DPI.

For example, the decision about how to present a message to a subscriber will be impacted by the device the subscriber is using and the activity that the subscriber is engaged in at the moment. You may not want to present a message via a browser overlay if the subscriber is currently on a Skype video conference as that could interrupt the event. Similarly, if a mobile user is watching YouTube videos on his phone and has just exceeded his data cap, it’s necessary to get that information to him right away. Video consumes data quickly and could see the subscriber incurring significant overage charges in a short time. In this case, choose a browser pop up over an email or text, which may not be looked at for some time. Application and device awareness are key here.

Obviously any notice relating to specific application usage (“Congratulations, this movie trailer is being sponsored by Columbia Pictures!”) or malicious activity (“You have been infected by a spam botnet. Please click here to clean your device”) requires DPI for identification of the underlying activity.

Reasonable network management The NPRM singles out as acceptable the use of DPI for reasonable network management. Sandvine agrees that reasonable network management is a critical use case for the technology and should require no further permissions from subscribers.

Not all traffic management use cases require DPI, but most traffic management policies could become more targeted to the underlying problem through the application of DPI. For example, a traffic management policy that shapes traffic only at moments in time and at network locations that are experiencing congestion seems very targeted. It can be even better. The policy can be made more targeted (and therefore more reasonable) and the subscriber experience improved by excluding from the shaping any traffic that is not contributing meaningfully to the congestion and which would be significantly adversely impacted by shaping, such as VoIP, online gaming and other low‐bandwidth, real‐ time applications. Similarly, network resources that are running at or near a target capacity (i.e., congested) may or may not experience quality of experience issues for the subscribers at that location, depending on traffic mix and other factors. Ideally, the traffic management decision is based on subscriber QoE scores for sensitive applications, enabled through DPI. Such a refined policy would avoid unnecessary management of traffic, compared to approaches that automatically start shaping when a resource hits an arbitrary threshold, such as 85% of capacity, for example.

Again, as the DPI market leader, we would point out that reasonable network management is no longer the most significant use case for the technology today, representing only 17% of our software order value in fiscal 2015. BIAS providers have realized the power of DPI to enable other equally critical use cases.

DPI use cases are necessary to the provision of BIAS services In recognizing the value of DPI to reasonable network management (as the NPRM does in paragraph 256), the FCC is implicitly subscribing to one of the most important themes of this submission – that it is the use case that should matter most when determining privacy issues, not the technology. Why then does the paragraph also attack the technology?

Given the black eye that DPI received throughout the prominent Nebuad and Phorm controversies surrounding behavioural targeted advertising, we suspect that the FCC was unaware or distracted from the technology’s other common use cases in BIAS providers’ networks. Hopefully the FCC now has a better understanding of the breadth of use cases for DPI:

 Capacity planning  Subscriber service planning  Subscriber QoE measurement and enforcement  Creation of innovative, competition‐enhancing subscriber service plans  Accurate charging and billing  Fraud detection

 Preventing and mitigating spam, DDoS attacks, phishing attacks and other malicious activity  Regulatory compliance, such as to block child pornography  Subscriber engagement to avoid bill shock and alert subscribers to malicious activity  Network address translation to migrate to ipv6  Session border control for VoIP  Firewalls, intrusion prevention and detection

As described earlier, Sandvine believes that the use of DPI for some of these use cases is already covered by specific exemptions that the FCC is proposing through paragraphs 115 and 117 of the NPRM. Additionally, Sandvine submits that the remainder of these use cases for DPI (amongst others) are covered by the broader exemption described in paragraph 112 and 113 of the NPRM, which together state a BIAS provider has implied consent from subscribers to:

“use, disclose, or permit access to individually identifiable CPNI (ed: or potentially customer PI) in its provision of (A) the telecommunications service from which such information is derived, or (B) services necessary to, or used in, the provision of such telecommunications service.”

Could anyone reasonably argue that any of the described DPI use cases above aren’t essential to providing a BIAS service?

DPI‐supported Policies use IETF and Other Industry‐approved Techniques

Many IETF standards implicitly require the use of DPI, such as:

● RFC 3489, "Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"7, and RFC 2766, "Network Address Translation ‐ Protocol Translation (NAT‐ PT)"8. ● The IETF’s 1998 RFC 24759 discusses an “Architecture for Differentiated Services,” or “DiffServ” as it has come to be known, which explicitly describes methods to provide differentiated service levels to various applications, based on their heterogeneous network requirements. The overview of this RFC describes its purpose as follows: “This document defines an architecture for implementing scalable service differentiation in the Internet. A "Service" defines some significant characteristics of packet transmission in one direction across a set of one or more paths within a network. These characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may

7 See http://www.faqs.org/rfcs/rfc3489.html

8 http://www.faqs.org/rfcs/rfc2766.html

9 IETF RFC 2475. See http://www.ietf.org/rfc/rfc2475.txt

otherwise be specified in terms of some relative priority of access to network resources. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service.”

● IPFIX (as discussed elsewhere in this document) standards requirements were outlined in the original IETF RFC 391710. Cisco NetFlow Version 9 was the basis for IPFIX. The basic specifications for IPFIX are documented in RFC 701111 through RFC 701512, and RFC 510313.

Also, the 3rd Generation Partnership Project (3GPP) of the GSM Association (GSMA) develops and maintains standards for a wide variety of mobile networks, including GSM, UMTS and LTE. Starting with Release 1114, the 3GPP standards called for a Traffic Detection Function TDF, which enables BIAS providers to leverage “service awareness,” or what we have been referring to as application awareness herein. Release 11 notes that the “traffic detection functionality and corresponding notification can be implemented by a standalone entity as well as be collocated with PCEF.” Sandvine’s Policy Traffic Switch (PTS) product is a PCEF (Policy Charging and Enforcement Function).

DPI Use Cases that Require Special Consideration

Certain use cases that can be supported at least in part through DPI, such as lawful intercept, copyright enforcement, and targeted advertising, can raise privacy considerations. While there are beneficial aspects to each use case, rules about what data to collect, user consent and when such use cases can be deployed are clearly required. Significantly, such use cases are achieved through a wide variety of technologies, not just ─ or even significantly ─ DPI.

While DPI technology can comprise a component of targeted advertising solutions, it has been very rarely used this way. Instead, other technologies have dominated. Google is one of the leaders in targeted advertising, but to Sandvine's knowledge Google’s targeted advertising solutions do not use DPI. According to Google’s Privacy and Terms for Advertising15, they primarily use cookies, technology similar to cookies and other means. Plus, users are automatically opted in and may not be able to fully opt out. Despite not using DPI, the cookies and other technologies gather the websites you’ve visited, your search history, location information, app activity, and information you’ve provide to other online services and advertisers.

According to Google:

“What determines the ads by Google that I see?

10 https://datatracker.ietf.org/doc/rfc3917/ 11 https://tools.ietf.org/html/rfc7011 12 https://tools.ietf.org/html/rfc7015 13 https://tools.ietf.org/html/rfc5103 14 Overview of 3GPP Release 11 is available at http://www.3gpp.org/specifications/releases/69‐release‐11 15 https://www.google.com/policies/technologies/ads/

Many decisions are made to determine which ad you see.

Sometimes the ad you see is based on your current or past location. Your IP address is usually a good indication of your approximate location. So you might see an ad on the homepage of YouTube.com that promotes a forthcoming movie in your country, or a search for ‘pizza’ might return results for pizza places in your town.

Sometimes the ad you see is based on the context of a page. If you’re looking at a page of gardening tips, you might see ads for gardening equipment.

Sometimes you might also see an ad on the web that’s based on your app activity, or an in‐app ad that’s based on your web activity, or based on your activity on another device, if you've previously signed in to your Google account on another device.

Sometimes the ad you see on a page is served by Google but selected by another company. For example, you might have registered with a newspaper website. From information you’ve given the newspaper, it can make decisions about which ads to show you, and it can use Google’s ad serving products to deliver those ads.

You may also see ads on Google products and services, including Search, Gmail, and YouTube, based on information, such as your email address that you provided to advertisers and the advertisers then shared with Google.”

According to the same Privacy notice, even if you opt‐out of interest‐based ads, you can’t do so fully. You only opt out of the use of the cookie, not the cookie tracking itself:

“How you can control advertising cookies

You can use Ads Settings to manage the Google ads you see and opt out of interest‐based ads. Even if you opt out of interest‐based ads, you may still see ads based on factors such as your general location derived from your IP address, your browser type and recent, previous searches related to your current search.”

Similarly, according to Google’s description16 of how Gmail ads work they result from scans of your emails and you can’t totally opt out of that activity either:

“You can opt‐out of the use of your email and other personal information for the personalization of Gmail ads from the Ads Settings page, by turning off Ads based on your interests. If you do opt‐out, you may still see ads, but they will not be based on your email or other personal data Google has associated with your Google Account. Even if you opt‐out, Google will still scan and filter your email with our automated processing. .”

16 https://support.google.com/mail/answer/6603?hl=en

Again, to Sandvine's knowledge, none of these approaches use DPI.

Again, applications of technologies may raise privacy concerns, not technologies themselves. Sandvine urges the FCC to adopt a technology‐neutral view when considering privacy on the Internet.

Aggregate Customer PI and Non‐identifiable, Non‐aggregate Customer PI Should Both be Covered We agree with the NPRM that aggregated, non‐identifiable customer PI should be able to be used by the BIAS provider without seeking further customer approval. However, we believe that this coverage should also extend to non‐aggregated, non‐identifiable customer PI. Ultimately, when it comes to privacy issues, the key point is not whether the information is aggregated or not, it’s whether it’s personally identifiable, with aggregation being one aspect of de‐identification.

First, it should be an obvious statement that to create aggregated data a BIAS provider needs access to individual user’s data. There are a number of important use cases where a BIAS provider may need to look at individual non‐identifiable data.

For example, it is not uncommon that Network Address Translation devices, like home routers, are misused for commercial purposes. An owner of a multi‐dwelling unit may improperly provide all tenants in its building with through connections from a single cable modem in the unit. To detect such fraud, a BIAS provider may need to run a report on all accounts where there are 50‐plus devices (for example) in the home and then do further analysis on each individual account record to determine which may have that number of devices legitimately and which may be candidates for fraudulent activity.

Often, when reviewing account information for fraudulent activity, it won’t be immediately obvious what factors to look at. Experimentation may be required, which then requires further reports and extraction of further individual records. You don’t know what you’re looking for until you correlate factors from individual records. The same may be true when troubleshooting network quality issues. Original investigations may locate the problems to a local area, which may then reduce to a specific network resource. Then only by looking at individual account activity on that resource could it be determined that one user is causing the issues, perhaps due to extreme file‐sharing activity, or a large number of concurrent devices online due to tethering, etc.

In other use cases it may be valuable for a BIAS provider to look at median or “typical” user activity. For example, in the case above it may be important to know the median number of devices in the home. The median subscriber’s data consumption at peak hours may be an important factor in capacity planning. The median user is, by nature, an individual account. To arrive at the median data the BIAS provider must have access to all individual account data for ranking purposes.

To safeguard the identity of non‐aggregated, non‐identifiable customer PI, a BIAS provider could use available algorithms such as a one‐way hash from the private account identifier (such as phone number or SIN number) to a non‐identifiable numerical reference for reporting purposes. Common encryption techniques like SHA (Secure Hash Algorithm, used in SSL) would suffice. The bar need only be set as high as necessary to prevent an unusually snoopy employee of a BIAS provider (or third party to which the information has been provided) from digging around in private information, rather than preventing the world’s most talented cryptographer from cracking the code.

Data Retention The NPRM requests comment on potential reasonable retention limits for customer PI. As covered in other section of this submission, Sandvine’s data is used to support long term planning decisions related to network capacity, effective network routing and the types of services subscribers may be interested in, among many others. The nature of these use cases demand that data be kept for some time in order to discern trends that could be acted on. We concur with the FTC Staff Report on Privacy, which cautions that data retention limits could limit innovation in the future regarding development of new beneficial products.

Sandvine recommends that operators keep data for three years, with older data being less granularized than recent data. For example, all usage data should be kept within the last month, usage at four‐hour intervals for the past year, and perhaps daily intervals beyond that. At a bare minimum data for the last 13 months should be retained so month over month usage comparisons can be made, though such a severe limitation would limit the identification of long term trends and therefore limit the number of use cases that such data could support.

In Sandvine’s solutions, data that is kept, whether for one minute or one year, is aggregated in some regard. Statistics such as data volume by application over time are kept. All reports are anonymized and not based on an individual destination, flow, URL, etc.

IP Address and MAC address are not CPNI Sandvine does not believe that the IP address or MAC address constitutes CPNI.

In some domains a device is fairly synonymous with a person (e.g. mobile phone). In others (e.g. cable) it can be a collection of people including (via WiFi for example) ones that have no affiliation with the account holder. As a consequence we do not believe that device information is a type of CPNI.

The MAC address is even more remote from CPNI. It is normally private to the link it is on (as part of Layer 2) and is not available elsewhere in the network. The MAC address is not a destination nor is it used to route information to an end user. First, it only is a Layer 2 address of the account, not the end user, nor end user device (the customer premise equipment is separate), and it doesn’t represent a single user. In addition, Layer 3 (IP) is used in routing, not Layer 2 (MAC). The MAC is not what is

considered 'destination' nor 'technical configuration', as these would be IP.

With respect to PII, the link to MAC is even more tenuous. There is no circumstance where it is personal, it is simply a link‐local addressing. It is associated with multiple users in fixed networks (since it is of the gateway). There is no mechanism by which it can be used to personally identify an individual.