Revision History - Shared Internet Resources Policy
Show other documents from
Version Comments
The "When will the SIR Policy be in effect?" date has been pushed to "early 2017".
The section "4. When will the SIR Policy be in effect?" has been updated.
The following section has been updated: "7. I'm not really feeling the traffic management piece of your SIR Policy. Can I opt out?"
The answer to the question "Is there any other traffic management that TekSavvy end-users should know about?" has been updated concerning blocked ports and SkyFi.
The implementation of the SIR Policy on the Rogers and Videotron platforms has been delayed yet again to "later in October or November 2016" (previously June or July).
The year mentioned under section 8, "I thought TekSavvy was all about net neutrality" has been changed.
The SIR Policy will now be implemented on the Rogers and Videotron platforms later in June or July (previously March or April).
The SIR Policy is to be implemented on the Rogers and Videotron platforms later in March or April (previously February).
The section "When will the SIR Policy be in effect?" has been updated.
This document has been renamed to "Shared Internet Resources Policy" and completely revamped.
Yet again, a new major version has been published.
Another major version has been published.
A new major version has been published.
This is the initial version that ParanoidPaul captured. It is not necessarily the first version of the document.
Internet Traffic Management Practices   

	TekSavvy is a strong advocate for network neutrality and end-user privacy, the yardsticks against which we measure all of our policies. We invest aggressively in our network in order to reduce the possibility of congestion. Nonetheless, network congestion does occur. Congestion may arise as a function of how certain Internet applications and protocols are designed. Congestion may arise if, after when we place orders to provision additional bandwidth, trading partners like wholesale network access providers do not meet the timelines we expect them to. 

	We therefore maintain a limited set of "Internet Traffic Management Practices", or "ITMPs", either to minimize and, where that is not possible, deal fairly with network congestion; or to reduce the potential for exploits like spam and botnets. 

	There are three kinds of ITMPs. Economic ITMPs link rates for Internet services to end-user consumption, matching consumer usage with willingness to pay. Technical ITMPs manage traffic on a network-wide basis, in order to prevent or respond to network congestion or harm. And hybrid ITMPs combine these.  

	TekSavvy employs an economic ITMP (capped plans), a hybrid ITMP (uncapped plans in exchange for voluntary peak-time throttling), and a technical ITMP (temporary deprioritization, under situations of network congestion, of the highest-volume download sources). In addition, users provisioned over cable-based network access are subject to limited upload management flowed through by third-party wholesalers. All of these ITMPs are described below. 


	Our economic practice is to offer both unlimited and capped plans. Capped plans allow users to pay a lower price in exchange for a bit cap. The bit cap is restricted to network congestion scenarios, so it applies to downloads, but not uploads; and not to downloads between 2:00 am and 8:00 am.  

	Capped plans are available at the 75, 150, or 300 GB levels. Overages cost either 25 (DSL) or 50 (cable) cents per gigabyte. Users receive email warnings when their usage hits 50%, 75%, 90%, 100%, and 110% of their cap. However, overage charges are limited to $25 (DSL) or $50 (cable), so they apply only to the first 100 GB of download overages in a month. 


	Our hybrid practice, called "Zap the Cap", is a demand-shifting tool. It allows users on the largest-capped plans (300 GB) to convert theirs to unlimited plans, in exchange for halving their download speeds between 8:00 pm and midnight. That four-hour window is the portion of the 8:00 am to 2:00 am download day that is most likely to experience congestion. Users can enable or rescind "Zap the Cap" from one month to the next. 


	We employ two technical practices. The first is to deprioritize download-day outliers in the event of congestion on that download day. The second is to block usage of two ports, 25 and 53, that is typically associated with network attacks. 

	So, first, if there is network congestion that we have not yet been able to resolve through bandwidth provisioning, we use de-prioritization to address events that allow some users to command a disproportionate share of network resources. We do so in respect of accounts whose aggregate downloads during a single "download day" (a continuous 8:00 am to 2:00 am period) are extreme outliers based on two criteria. Their downloads for that day exceed average downloads by at least one-and-a-half standard deviations, recalculated monthly (currently: 25.8 GB in a day). And they account for no more than 2 percent of active accounts.  

	De-prioritization is only applied to outliers, in respect of the download day in which the outlying behaviour took place. This means that, if you download more than the specified amount during a download day (8:00 am to 2:00 am), your account will be de-prioritized only in the event that congestion occurs during that same download day. It will not carry forward to the next download day. 

	Accounts that are de-prioritized during a download day are affected, only for that download day, as follows. The account is assigned a lower priority in download traffic contention. If the network is uncongested, this has no effect. But, where other accounts contend for the same download capacity, the de-prioritized account could be slowed down to a floor of 1.5 Mbps. 

	Second, we block Internet traffic tagged with either of two port numbers: outbound traffic from a TekSavvy user, on port 25 (outgoing mail); and inbound traffic to a TekSavvy user, on port 53 (domain name service).  

	Blocking outbound, unencrypted Simple Mail Transfer Protocol ("SMTP") mail on port 25 is a best practice for reducing spam, particularly from infected machines. Users are encouraged to migrate to secure standards for sending mail (over port 587: RFCs 2554 and 2476).  

	Blocking inbound DNS traffic on port 53 curtails vulnerability to DNS amplification attacks, a form of distributed denial of service attack, which is also most frequently achieved through compromised or infected machines.  

	However, where users have a requirement for outbound port 25 or inbound port 53 traffic, we review it with them on a case-by-case basis. 


	TekSavvy's payments to Wholesale Network Access providers are based in part on the bandwidth we purchase from them to connect our access users to our network. This limits WNA providers' incentive to reduce congestion through traffic management, rather than additional network provisioning. However, cable-based WNA providers, whose technology requires clusters of users to share portions of the network with one another, do impose limited upload ITMPs on both their users and on ours. The uploads of TekSavvy users connecting over certain cable-based wholesalers will, therefore, be subject to the following technical management practices. 

	Cogeco network access is subject to deep packet inspection that traffic-manages upload bandwidth. Cogeco's deep packet inspection analysis has what Cogeco has described as the "single purpose" of traffic-managing file-sharing Peer-to-Peer applications: "Content analysis is restricted to traffic classification only for traffic management purposes on upstream traffic. No content records are maintained. No Internet traffic management measures are applied in the downstream direction." 

	Rogers network access is subject to what Rogers describes as "a variety of network management techniques. These techniques have evolved as the Internet has changed". A CRTC letter to Rogers dated 29 February 2012 described these as "a technical ITMP [applied] to unidentified TCP upload traffic, regardless of the port used, when traffic from certain popular P2P applications is or was recently present." 

	Shaw network access is subject to ITMPs that reduce, to 80 Kbps per end-user, upstream bandwidth allotted to "P2P applications completing non-real-time file transfer activity" within serving area nodes experiencing "upstream congestion". These ITMPs are "not applied to downstream data transfer, real-time interactive or time-sensitive Internet applications." 

	Videotron network access is, at speeds of 120 Mbps speeds or higher, subject to upload measures that Videotron has explained are to prevent users from congesting shared "upload channels" serving a few dozen modems. Every 15 minutes, a system checks the usage rate for each upload channel. If the usage rate has reached a threshold beyond which congestion is imminent, the system identifies the 120 Mbps and 200 Mbps modems on that channel that have uploaded a statistically significant amount of data. Uploading from these modems is then momentarily given lower priority. Depending on the severity and duration of the congestion, uploading speed may be slowed for these modems. When the amount of data uploaded by the modem is diminished or the transmission of data goes back to a rate that does not cause congestion, uploading will return to its usual priority.

If you'd like to be notified when makes updates to documents like this, choose which ones you'd like to subscribe to today (it's free!).