Service Latency. Service latency targets apply to Services provided to AT&T as described in Appendix D and will be reported as required in Section 6 above. Notwithstanding the foregoing, non-performance penalties will apply solely to the following portions of the Services as further described in Appendix D: ***
Service Latency. Private Access will process HTTP and HTTPS requests consisting of units of data made into single Internet protocol packages traveling along a network path (“Requests”) in no more than 100 milliseconds 95% of the time over any calendar month measured from the time Private Access receives the content to the time Private Access attempts to transmit the content. Communication times outside of Private Access are not included in this SLA • This service latency SLA only applies to “Qualified Content”, which means Requests that are: less than 1 MB HTTP GET request and response; not SSL-intercepted; not related to streaming applications; not subject to bandwidth management rules (e.g. QoS enforcement); and resulting from a reasonable level of consumption (not more than 2,000 Requests per User per day on average). • If in any one calendar month 5% or more of the Qualified Content is not processed in 100 milliseconds or less as determined by the monthly average Private Access processing time among samples taken by Forcepoint in a given calendar month (“Missed Latency SLA”), Customer may be eligible for a Service Credit equal to 1 week as a result of the Missed Latency SLA subject to a maximum aggregate Service Credit of 4 weeks during any 12-month term.
Service Latency. User requests for Services shall be fulfilled in accordance with Table 2 below for each calendar month. This includes delivery of all bytes of the response (content plus protocol overhead) that Infospace controls (i.e. service requests and subsequent requests for which the browser’s URL target is hosted by Infospace). InfoSpace will achieve the latency targets set forth in Table 2 below on the schedule set forth in Table 2. The parties agree to review such latency targets from time to time during the Term and to assess whether to adjust the latency. Unless otherwise mutually agreed, these are the targets for penalties as set forth in Section 8.3. *** Table 2, Latency Target Ramp *** This redacted material has been omitted pursuant to a request for confidential treatment, and the material has been filed separately with the Commission. EXHIBIT G – SERVICE LEVEL AGREEMENT These requirements are specific to the portion of end to end Latency incurred within the Infospace’s Span of Control and will be measured from the secure network nearest the Infospace border router. The design of latency monitoring infrastructure will ensure appropriate components of the request and response are adequately measured. The implementation of latency monitoring infrastructure will include the deployment of a separate and specific server(s) for the purpose of monitoring and fault management. The latency introduced by the GPRS network, the WAP Gateway and other elements of the Cingular Network are excluded from the latency measurements described above.
Service Latency. Service latency targets apply to Services provided to Cingular as described in Appendix D and will be reported as required in Section 6 above. Notwithstanding the foregoing, non-performance penalties will apply solely to the following portions of the Services as further described in Appendix D: *** *** *** *** This redacted material has been omitted pursuant to a request for confidential treatment, and the material has been filed separately with the Commission. EXHIBIT G – SERVICE LEVEL AGREEMENT *** Table 9, Latency Penalty Calculation *** Table 10, Latency Target Ramp Subject to Section 8.1, Infospace agrees to pay to Cingular excessive latency fees based on performance according to Table 10 above for each month of the SLA reporting period. In the event the monthly latency measurement for a particular Service Area listed in Table 9 above exceeds ***
Service Latency. User requests for Services shall be fulfilled in accordance with Table 2 below for each calendar month. This includes delivery of all bytes of the response (content plus protocol overhead) that Motricity controls (i.e. service requests and subsequent requests for which the browser’s URL target is hosted by Motricity). Motricity will achieve the latency targets set forth in Table 2 below on the schedule set forth in Table 2. The parties agree to review such latency targets from time to time during the Term and to assess whether to adjust the latency. Unless otherwise mutually agreed, these are the targets for penalties as set forth in Section 8.3. *** This redacted material has been omitted pursuant to a request for confidential treatment, and the material has been filed separately with the Commission. Period Percentile 1 Latency Target 1 Percentile 2 Latency Target 2 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Table 2, Latency Target Ramp These requirements are specific to the portion of end to end Latency incurred within the Motricity’s Span of Control and will be measured from the secure network nearest the Motricity border router. The design of latency monitoring infrastructure will ensure appropriate components of the request and response are adequately measured. The implementation of latency monitoring infrastructure will include the deployment of a separate and specific server(s) for the purpose of monitoring and fault management. The latency introduced by the GPRS network, the WAP Gateway and other elements of the AT&T Network are excluded from the latency measurements described above.
Service Latency. Service latency targets apply to Services provided to AT&T as described in Appendix D and will be reported as required in Section 6 above. Notwithstanding the foregoing, non-performance penalties will apply solely to the following portions of the Services as further described in Appendix D: *** Table 9, Latency Penalty Calculation Subject to Section 8.1, Motricity agrees to pay to AT&T excessive latency fees based on performance according to Table 9 above for each month of the SLA reporting period. In the event the monthly latency measurement for a particular Service Area listed in Table 2 above exceeds ***
Service Latency. User requests for Services shall be fulfilled in accordance with Table 2 below for each calendar month. This includes delivery of all bytes of the response (content plus protocol overhead) that Motricity controls (i.e. service requests and subsequent requests for which the browser’s URL target is hosted by Motricity). Motricity will achieve the latency targets set forth in Table 2 below on the schedule set forth in Table 2. The parties agree to review such latency targets from time to time during the Term and to assess whether to adjust the latency. Unless otherwise mutually agreed, these are the targets for penalties as set forth in Section 8.3.
Service Latency. User requests for Services shall be fulfilled in accordance with Table 2 below for each calendar month. This includes delivery of all bytes of the response (content plus protocol overhead) that Motricity controls (i.e. service requests and subsequent requests for which the browser’s URL target is hosted by Motricity). Motricity will achieve the latency targets set forth in Table 2 below/. The parties agree to review actual performance results compared to latency targets on or before September 30, 2009 to determine whether or not new targets are required. Prior to the end of the first period, parties will agree to either amend the existing latency targets, or agree to keep them as is. *** This redacted material has been omitted pursuant to a request for confidential treatment, and the material has been filed separately with the Commission. In addition to the monthly SLA reports, Motricity will provide an analysis of capacity and performance, system dimensioning (including maximum, sustainable, peak transactions per second, per hour, peak sessions per hour,) and actual traffic information (including average and peak latency, average http transaction payload, etc.) for the Services (by Service type) as input into any and all performance reviews. Thereafter, latency shall be reviewed from time-to-time during the Term and to assess whether the latency targets need to be adjusted due to increased volumes, or new functionality that elongates the transaction time. Unless otherwise mutually agreed, these are the targets for penalties as set forth in Section 8.3. *** Table 2, Latency Target Ramp These requirements are specific to the portion of end to end Latency incurred within Motricity’s Span of Control and will be measured from the network equipment at Motricity that first receives and processes a Service request from the AT&T network and transmits a response back. The design of latency monitoring infrastructure will ensure appropriate components of the request and response are adequately measured. The implementation of latency monitoring infrastructure will include the deployment of a separate and specific server(s) for the purpose of monitoring and fault management. The latency introduced by the GPRS network, the WAP Gateway and other elements of the AT&T Network are excluded from the latency measurements described above.
Service Latency. Cloud Web will process HTTP and HTTPS requests consisting of units of data made into single Internet protocol packages traveling along a network path (“Requests”) in no more than 100 milliseconds 95% of the time over any calendar month measured from the time Cloud Web receives the content to the time Cloud Web attempts to transmit the content. Communication times outside Forcepoint’s data center are not included in this SLA. • This service latency SLA only applies to “Qualified Content”, which means Requests that are: less than 1 MB HTTP GET request and response; not SSL-intercepted; not related to streaming applications; not subject to bandwidth management rules (e.g. QoS enforcement); and resulting from a reasonable level of consumption (not more than 2,000 Requests per User per day on average). • If in any 1 calendar month 5% or more of the Qualified Content is not processed in 100 milliseconds or less as determined by the monthly average Cloud Web processing time among samples taken by Forcepoint in a given calendar month (“Missed Latency SLA”), Customer may be eligible for a Service Credit equal to 1 week as a result of the Missed Latency SLA, subject to a maximum aggregate Service Credit of 4 weeks during any 12-month term.
Service Latency. Licensor shall use commercially reasonable efforts to fulfill User requests for services in accordance with Table below for each calendar month. This includes delivery of all bytes of the response (content plus protocol overhead) that Licensor controls. In recognition of the nature of the Information Service which encompasses GPS interaction and for purposes of maintaining best possible customer service the latency shall be defined to apply only to the interval pertaining to incoming requests and subsequent response time within the data center. For clarity, the Parties agree not to include end-to-end latency which is subject to too many variables. The parties agree to review such latency targets from time to time during the Term. Percentile 1 Latency Target 1 Percentile 2 Latency Target 2 95% 2000ms 99.9 % 3000ms These requirements are specific to the portion of end to end Latency incurred within the Licensor’s Span of Control within their data center and will be measured from the secure network nearest the Licensor border router. The design of latency monitoring infrastructure will ensure appropriate components of the request and response are adequately measured. The implementation of latency monitoring infrastructure will include the deployment of a separate and specific server(s) for the AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies except under written agreement purpose of monitoring and fault management. The latency introduced by the GPRS network, the WAP Gateway and other elements of the AT&T Network are excluded from the latency measurements described above. For clarity, the Parties agree not to include end-to-end latency which is subject to too many variables.
