Broadband latency management

Abstract

Managing latency in a broadband connection to a local network. A client within the local network determines an address of a router and a server external to the local network. Sets of data packets of differing sizes are transmitted from the client to the router. The client receives, a response from the router to each packet. The client measures, a response time for each of the packets transmitted to the router. Data packets are transmitted from the client to the external server via the router. A response is received from the server to each packet. The client measures a respond time for each packet transmitted to the server. A distribution of response times is determined for the packets transmitted from the client to the router. A distribution of response times for packets transmitted from client to server is determined. Response times for packets transmitted by the client to the router and server are compared. An output indicates a contribution of latency of the local network latency and latency external to the local network based on the comparison.

Description

Field of the Invention The present invention relates to a system and method for monitoring and managing latency in a broadband connection, and in particular, a broadband router connected to an internet service provider providing data and internet services to one or more local clients. Background of the Invention A broadband router provides internet or data services to one or more clients (e.g., mobile devices, computers or other devices) within a local network, such as a home or office. The broadband router may provide such services over a wired connection (e.g., Ethernet) or more usually using Wi-Fi (RTM). The client may demand services from an external server or data service (e.g., a web page, application, streaming service, etc.) by forming a wired or wireless connection to the broadband router, which is connected to a broadband service (e.g., an internet service provider - ISP). Typically, a domain name system (DNS) within the ISP handles requests from the clients based on URLs and passes on responses from the server or service provider. Typical service requests and responses will have some level of latency depending on the performance of different parts of the network and the distance between nodes. For example, the Wi-Fi connection can introduce a portion of the latency, the broadband connection between the broadband router and the DNS can introduce further latency and the end service provider or content application provider (and wider internet) can introduce yet more latency. As experienced at the client, it may not be apparent where the latency has been incurred. For some services (e.g., email), latency can have little or no effect on the quality of service. For other services, e.g., gaming or virtual reality applications, latency can have a serious impact on the quality of service. It can therefore be important to identify different sources of latency so that the overall quality of service can be measured and optimised. Internet speed tests are common ways to test a broadband connection. Whilst some internet speed tests include a latency measurement (e.g., 10ms) as part of the test results, such internet speed tests usually involve transferring several MB of data, which can cause a degradation in latency during the test. Furthermore, different contributors of latency in the system are not apparent from such tests. Therefore, a way to manage and test the latency of broadband connections to local networks is required that, unlike speed tests, does not cause latency spikes as a result of the test itself and also facilitates demarcation of where latency is most accrued in the end-to-end broadband connection. Therefore, there is required a method and system that overcomes these problems. Summary of the Invention A client, such as a mobile application on a mobile device or a computer running a software application, can have access to or otherwise determine an address (e.g., IP address) of a broadband router within the same local or home network (e.g., Ethernet or Wi-Fi (RTM)) as the client. Ethernet cabling can be used for devices such as laptop or desktop computers. The client then sends data packets of different sizes to the broadband router. The broadband router responds to these data packets through the local network and the client measures the response time for each data packet. This may be achieved as part of a network utility (e.g., ping command). An external server or data service (e.g., a video streaming service) is selected, chosen, or a default or random server or data service is used. Data packets of the same or similar sizes to those transmitted between the client and the broadband router are used again but this time they are sent from the client to the broadband router and onto the external server. This may be achieved through a domain name service (DNS) of an internet provider of the home or local network. A DNS is only needed if the target Internet server is identified by its URL. A server on the Internet (or in the Network operator’s network) could also be identified directly by its IP address, if known. Responses from these data packets are received at the client. Again, a ping command may be used. The time between transmission from the client and receiving the response from the external server is measured. This should generally be greater than the response time for similar data packets sent only to the broadband router. This is because the route of the data traffic to the external server includes the internal network as well as the time spent traversing the internet to the server. Both tests may be repeated with the same or similar sets of data packets and the times recorded. The tests may also be interleaved, alternating a measurement (ping) to the home router) and a measurement to the network server. This approach reduces the time between a measurement to the broadband router and a measurement to the server, during which time traffic load may form queues in the broadband router and / or network equipment. A distribution of these times is formed because there will a variation in timings for different data packets (e.g., of the same or different sizes) having different response times due to instantaneous changes to network conditions within the local network and within the internet. The distributions may be recorded in the form of a cumulative distribution function (CDF), for example. Corresponding portions of the distribution of the local network data packets timings and portions of the distribution of the data packet timings to the external server or data service are compared. For example, the same percentile, quartile, or other fraction of the distribution may be compared (e.g., as part of a function or algorithm). This comparison provides an indication of the relative contribution to latency to these portions of the data packet journey. For example, the 50th percentile of each distribution may be compared. An output is provided based on this comparison. This output provides an indication of the latency, delay or transit time for data packets generated by the local network and by the internet (i.e., between the broadband router and the server or data provider). In a more complex embodiment, more than one corresponding fraction of the distributions may be compared (e.g., the 50th, the 90th, and / or the 99th percentile of both distributions can be compared) and an output may be produced or summarised based on these different comparisons. Selection of which CDF percentiles used in any subsequent calculation / comparison may depend on the analysis objective. The comparison may include simple ratios, percentages or fractions or more complex calculations. If a there is a spike in intra-home (local) traffic (e.g., over Wi-Fi or Ethernet) then this can cause a short-lived queue in buffers or "micro congestion", this could affect the measurement packet sent to the home router, but not to the one sent to the Internet / web server. Therefore, selection of which CDF percentiles are used in any subsequent calculation / comparison may depend on whether the objective (for the output) is to compare "structural" latency differences (due to transmission / propagation time - distance etc, in which case 1st to 50th percentiles may be appropriate), or to assess the impact of traffic load variation / spikes, in which case 90th, 99th and 99.9th may be of more interest. The CDF approach facilitates such flexibility for any subsequent analysis. A simple output may consist of a ratio or percentage indication of the contribution of latency to each stage of the packet response. For example, if the response time of the 50th percentile for each step was 2ms between the client and broadband router and the response time for the 50th percentile from the client to the server was 10ms (including the 2ms within the local network) then the ratio of latency contributions (local: external) is 2:8 (1:4) or 25% of the latency is caused by the local (e.g., Wi-Fi) network. This can provide a user or service provider with a better understanding of performance of the data services provided to a user within the local network. If the latency contribution of the local network exceeds a predetermined value, ratio, or percentage then an action may be triggered manually or automatically (e.g., change the Wi-Fi channel or reboot the broadband router). Whilst only comparing two portions of the broadband connection provides important information, the method may be enhanced to transmit data packets through different portions of the broadband connection, determine similar distributions and compare similar corresponding portions of these distributions to arrive at an enhanced output. A further advantage of the method and system is that they do not require any new software client to be integrated into the home broadband router. Against this background and in accordance with a first aspect there is provided a method for managing latency in a broadband connection to a local network, the method comprising the steps of: a client within the local network determining an address of a broadband router; the client determining an address of a server external to the local network; transmitting one or more sets of a plurality of data packets from the client to the broadband router, wherein the plurality of data packets have different packet sizes; receiving, at the client, a response from the broadband router to each data packet of the plurality of data packets; measuring, at the client, a respond time for each of the data packets of the plurality of data packets transmitted to the router; transmitting one or more sets of the plurality of data packets from the client to the external server via the broadband router; receiving, at the client, a response from the server to each data packet of the plurality of data packets transmitted to the server; measuring, at the client, a respond time for each of the data packets of the plurality of data packets transmitted to the server; determining a distribution of response times for the plurality of data packets transmitted from the client to the broadband router; determining a distribution of response times for the data packets transmitted from the client to the server; comparing corresponding portions of the distributions of response times for the data packets transmitted by the client; and providing an output indicating a contribution of latency of the local network and a contribution of latency external to the local network based on the comparison. Therefore, latency in a broadband connection can be monitored and managed more effectively because the contribution of latency caused by the local network to the overall latency experienced by client devices when obtaining data services across the internet, can be determined. Furthermore, this information can be determined more accurately because smaller data packets are also used, which have a lower latency component that is due to packet serialisation delay. When comparing the corresponding portions of distributions of response times for data packets transmitted by the client, this compares the data of the router response times with the external server response times. Rather than directly comparing individual data packet response times, corresponding portions of the distributions are compared, which improves the overall comparison. Furthermore, choosing different parts of the distributions to compare provides different information (e.g., structural latency and latency caused by instantaneous events on the network) and enables the selection of the most appropriate comparison to facilitate different analysis objectives. Optionally, the step of providing the output may further comprise transmitting the output to an external entity and / or the method may further comprise: repeating the method at different times of day and / or for a plurality of local networks. The method can be repeated for the same local network and different predetermined times of the day (and / or week and / or month), such as at low traffic times (e.g., 4am) and / or high traffic times (e.g., 7pm). This can be done for multiple local networks or internet service provider users or customers. Therefore, information regarding a network’s performance or the performance of particular routers, types of routers, or types of users can be obtained. The times may vary and / or be dependent on expected or historic traffic patterns and trends. The data may be stored so that a history of results can be generated and analysed. This can provide information regarding longer-term changes, for example. The external entity may be a server, an internet service provider, a telecommunications network, or another entity. Optionally, the method may further comprise the step of identifying one or more local networks of the plurality of local networks with an output indicating a contribution of latency of the local network and / or latency external to the local network greater than predetermined value or values. Therefore, individual customers, groups of customers, types of customers or local network can be identified that encounter latency problems for either or both their local network (e.g., router or Wi-Fi performance) and external internet provision. The latency threshold within the local network (e.g., Wi-Fi latency) may be different to the latency threshold for measurements of latency outside of the local network, for example. The thresholds may be varied. Optionally, the method may further comprise the step of changing a configuration of the local network and / or an internet service provider of the local network for the identified one or more local networks, routers or users. Therefore, resources to improve customer or user experience can be focused on where it will have the greatest impact or effect. These configuration changes may be permanent or temporary (e.g., only during measured or expected times of high latency). This further improves network efficiency and performance. Optionally, the change of configuration of the local network may be enabling Wi-Fi MultiMedia (WMM) on the router of the local network and / or the change of configuration of the internet service provider may be enabling Low Latency DOCSIS. Other configuration changes can be made. Furthermore, the service provider may be able to determine where network upgrades or maintenance resources can be focused, improving the efficiency of the network and overall quality of service for user. Further Quality of Service (QoS) techniques may be used. For example, Wi-Fi 7 brings new QoS options. For the ISP network, hierarchical scheduling, L4S and the use of Ethernet QoS (IEEE 802.1p) and multiprotocol label switching (MPLS) QoS may also be applied based on the test results (e.g., to determine if they will make a significant difference to latency and customer experience). Optionally, the address of the server external to the local network may be determined from a user input, a random selection of alternative addresses, or by a predetermined default address. Therefore, the external server can be selected based on services most commonly used by clients within the local network. However, if accuracy is not necessary then a default address can be used to simplify operation. Optionally, the client may be in communication with the broadband router over a WiFi or Ethernet network. Alternatively, a wired connection may be used (e.g., for a laptop of desktop computer), in which case an Ethernet cable connection or similar may be used. Optionally, the different packet sizes are any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B. Any other packet sizes may be used. However, this selection provides a good range for simulating typical types of traffic on the network. Furthermore, different size packets may experience different latencies. It is noted that these packet sizes are six examples, but other combinations may be used. Other ranges of packet sizes may be used. For example, at least five different packet sizes may be used and preferably with the ratio of largest to smallest packet size being >10. Many different packet size combinations may be used. Optionally, the set of the plurality of data packets may comprise at least five data packets and / or at least five sets of data packets are transmitted from the client to the broadband router and from the client to the server. At least first sets of data packets (e.g., for each data packet size) provide a good spread of results to produce a useful distribution of data. Increasing the number of sets will improve accuracy but increase the time to obtain results. The number of times a packet of each size is used in the measurement run is a trade-off between run-time of the measurement and volume of measurement data gathered. Advantageously, between five and 20 measurements at each packet size for each router / server target may be used. Optionally, a plurality of sets of data packets may be transmitted from the client to the broadband router and from the client to the server and wherein individual sets of data packets are alternately transmitted from the client to the broadband router and from the client to the server. Interleaving the measurements (data sets) in this way reduces further the effect of any variation of network traffic load during the time between measurements of local network and Internet latency being measured. This further improves accuracy and reliability. Optionally, individual data packets may be alternately transmitted from the client to the broadband router and from the client to the server. Therefore, the data packets may be interleaved as well as or instead of the data sets. Optionally, distributions of response times may be calculated as cumulative distribution functions, CDF, complimentary CDF, CCDF, or a probability density function, PDF. Other distribution types may be used. Optionally, the portions of the distributions for each section of the plurality of sections of the broadband connection may be any one or more of a 1st percentile; a 10th percentile; a 50th percentile; a 75th percentile; a 90th percentile; a 99th percentile; and / or a 99.9th percentile (P1, P10, P50, P75, P90, P99, and / or P99.9). Other percentiles, or divisions and portions (e.g., quartile, decile, etc.) may be used. The portions may be predetermined or selected for individual tests. Different combinations may be obtained. The values may be selected from a pre-defined menu of options, for example. Alternatively, a comprehensive or default set may be provided (for example, P1, P10, P50, P75, P90, P99 and P99.9). Advantageously, the method may further comprise the steps of: transmitting the one or more sets of the plurality of data packets from the client to a server within an internet service provider network (e.g., a domain name system (DNS); receiving, at the client, a response from the server within the internet service provider network to each data packet of the plurality of data packets; measuring, at the client, a respond time for each of the data packets of the plurality of data packets transmitted to the server within the internet service provider network; determining a distribution of response times for the data packets transmitted from the client to the server within the internet service provider network, wherein the step of comparing corresponding portions of the distributions of response times for the data packets transmitted by the client further includes comparing a portion of the distribution of response times for the data packets transmitted to the server within the internet service provider network with a corresponding portion of the distribution of response times for the data packets transmitted to the broadband router and a corresponding portion of the distribution of response times for the data packets transmitted to the server, and further wherein providing the output further indicates a contribution of latency of the server within the internet service provider network. A target server may be included within the network operator's network e.g., to obtain information about different portions of the broadband or internet connection (i.e., a three-domain demarcation in this example). Using a DNS is just one example of the type of server that may be pinged. However, any other server that the network operator hosts in their network may be used. A dedicated server may also be implemented by the network operator. Optionally, the data packets may be internet control message protocol packets, ICMP, including an echo request. Alternatively, two-way active measurement protocol (TWAMP) or STAMP may be used. Optionally, the client may be any of: a computer; a mobile device; a laptop computer; a tablet computer; a smartphone; or an application on a mobile device. Other client devices may be used. Optionally, the method may further comprise the step of: if the output indicates a contribution of latency of the local network above a predetermined threshold then triggering one or more actions within the local network or by a network operator. Being aware of service degradation caused by latency increases on a per-user basis allows any remedial action to be targeted more effectively. For example, the action may be an instruction to the user (e.g., to move the broadband router to a different location to reduce interference) or an automatic action. Optionally, the one or more actions may include any one or more of: changing the configuration of the broadband router; rebooting the broadband router; changing a Wi-Fi channel of the broadband router; changing a priority of clients or categories of clients within the local network; and issuing a notification. Other actions may be used or triggered. In accordance with a second aspect, there is provided system comprising means for carrying out the steps according to any method described above. The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium, including a non-transitory computer-readable medium. The computer system may include a processor or processors (e.g., local, virtual or cloud-based) such as a Central Processing Unit (CPU), and / or a single or a collection of Graphics Processing Units (GPUs). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and nonvolatile storage medium. A computer-readable medium (CRM) may be included to store the logic or program instructions. For example, embodiments may include a non-transitory computer-readable medium (CRM) storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform the disclosed methods. Non-transitory CRM may refer to a CRM that stores data for short periods or in the presence of power such as a memory device or Random Access Memory (RAM). For example, a non-transitory computer-readable medium may include storage components, such as, a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, and / or a magnetic tape. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example. It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which: FIG. 1 shows a schematic diagram of a broadband connection from a client device operating within a local network to an external server; FIG. 2 shows a flowchart of a method for monitoring and managing latency within the broadband connection of Figure 1; FIG. 3 shows a schematic diagram of a computer system used to implement the method of Figure 2; FIG. 4 shows a sequence diagram of the method of Figure 2; FIG. 5 shows a further schematic diagram of the broadband connection of Figure 1, illustrating example sources of latency; FIG. 6 shows graph of example latency spikes caused by periodic speed tests within the broadband connection of Figure 1; FIG. 7 shows a graphical illustration of latency requirements for a computer application utilising the broadband connection of Figure 1; FIG. 8 shows a further graphical illustration of latency requirements for a computer application utilising the broadband connection of Figure 1, illustrating an application at a limit of acceptable latency; FIG. 9 shows a further graphical illustration of latency requirements for a computer application utilising the broadband connection of Figure 1 and illustrating a limit of acceptable latency for an application; FIG. 10 shows a schematic diagram of a local network having a broadband connection and a graph showing a distribution of latency for different sections of the broadband connection; FIG. 11 shows a further schematic diagram of a local network having a broadband connection and a graph showing a distribution of latency for different sections of the broadband connection in more detail; FIG. 12 shows graphical results of latency measurements for different sections of the broadband connection of Figure 1, and how these results can be compared; FIG. 13 shows a graphical illustration of a time series of latency measurements; FIG. 14 shows a graphical illustration of a distribution of latency for different sections of the broadband connection; FIG. 15A shows a further graphical illustration of a time series of latency measurements; FIG. 15B shows a graphical illustration of data packet round trips per minute (RPM) measurements; FIG. 15C shows further graphical results of latency measurements for different sections of the broadband connection of Figure 1; FIG. 15D shows further graphical results of latency measurements for different sections of the broadband connection of Figure 1; FIG. 16 shows and graphical illustration of cumulative probability and response times for different data packets of the broadband connection of Figure 1; FIG. 17A shows a graphical illustration of a set of latency measurements; FIG. 17B shows a graphical illustration of the distribution of latency measurements of Figure 17A; FIG. 17C shows a graphical illustration of a set of latency measurements using a larger data set to the graph of Figure 17A; FIG. 17D shows a graphical illustration of the distribution of latency measurements of Figure 17C; FIG. 18 shows a schematic diagram illustrating different broadband connection types that can be monitored and managed by the method of Figure 2; FIG. 19 shows graphically an effect on latency of conducting a speed test within a broadband network; FIG. 20 shows a table of example latency measurements for different applications; and Fig. 21 shows a relationship between Round Trips per Minute of data packets and latency values. It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals. Detailed description of the preferred embodiments Figure 1 illustrates schematically a system 10 for providing broadband internet services to a local network 12, such as a home or office environment. One or more client devices 20 such as laptops, mobile devices, Internet of Things (loT) devices, etc., are served by a broadband router 30. This may be either using a wired connection (e.g., Ethernet) or Wi-Fi, for example. Each client device 20 may have one or more applications 15 that require an internet connection. Each application 15 may have its own broadband quality requirement such as latency, reliability, jitter, and bandwidth. The broadband router 30 has an external access connection and interface to an access node 40 using different types of connections. These may include copper wire, microwave link, cellular connection, or fibre optic cabling. These connections provide back haul services to an internet service provider (ISP) core 60 through an edge router, or broadband network gateway (BNG) 50, for example. The ISP core 60 may interface with the wider internet 80 through a transmit router 70 or by other means. One or more data service provides or application servers 90 may have their own connections to the internet 80. Therefore, an internet connection may be defined as from the client device 20 or broadband router 30 through each section of the broadband connection across the various nodes to the application server 90. When particular latency requirements for any of the applications 15 are not met then users of the client device 20 may experience adverse application performance, as illustrated in Figure 1 (see application 15). However, the user does not know the cause of the latency or how to improve latency to an acceptable level for their particular application. Figure 2 shows a flow chart of a method 100 for managing latency in a broadband connection to a local network 12. This method 100 is shown as a high level with further example details provided throughout this description. At step 105, a client device 20 (for example, an application executing within the client device 20) within the local network 12 served by the broadband router 30 determines the IP address of the broadband router 30. This may be achieved in different ways. For example, the client device 20 may be able to interrogate its own networking settings (e.g., Wi-Fi settings) to determine the IP address of the broadband router 30. The networking settings may be retrieved using commands such as IPconfig, for example. At step 110 the client device 20 (for example, an application executing within the client device 20) determines the IP address of an external server 90. The external server 90 may be an application or web server that provides data services to a plurality of client device 20 across the internet 80. This could be a well-known web site (e.g., a news site) or a video streaming service, for example. The IP address of the external server 90 may be determined by using a default IP address, selected randomly from a selection of external servers 90 (e.g., pre-tested for reliability of results) or user-selected, e.g., through an interface on the client device 20. At step 115 a plurality of data packets is transmitted from the client device 20 to the broadband router 30. This provides a test of the local network 12 serviced by the broadband router 30. The plurality of data packets may be of the same or different sizes. Preferably, multiple sets of data packets having different sizes will be transmitted. At step 120, responses from the plurality of data packets are received at the client device 20 (e.g., at the application executing on the client device 20). The process may be achieved using a ping command or other network utility. At step 125, the response times for each data packet are measured. This provides data used to determine the latency incurred by the local network 12. A similar procedure is followed for the external server 90. At step 130 a plurality of data packets is transmitted from the client device 20 (within local network 12) to the external server 90. Responses are received from the external server 90 at the client device 20 at step 135. At step 140 the response times for each data packet transmitted to the external server are measured. It should be noted that the data packets may be sent to the external server 90 before, after or at the same time as sending them to the broadband router 30. Preferably, the tests may also be interleaved, alternating a measurement (ping) to the broadband router 30 and a measurement to the external server 90. This approach reduces possible queuing at the broadband router and / or at the external server 90. If additional sections of the broadband connection are tested then this my use a round-robin approach, for example. The next series of steps analyses the latency measurement results. Step 145 determines a distribution of response times for the data packets transmitted to the broadband router 30 from the client device 20. Step 150 determines a distribution of response times for the data packets transmitted to the external server 90 from the client device 20. The distribution may be distributions of response times are calculated as cumulative distribution functions (CDF), complimentary CDF (CCDF), or a probability density function (PDF). Other distribution types may be used. The same distribution types are used for both distributions (broadband router 30 and external server 90). Corresponding portions of both distributions (e.g., the same percentile or percentiles) are compared at step 155. Step 160 provides an output (e.g., message or data to be stored) indicating a contribution of the latency caused by the local network 12 and external internet. In an example set of test results, 50% of responses for all data packets may be received within 3ms from the broadband router 30. 50% of responses for all data packets may be received within 9ms from the external server 90. Therefore, the comparison may provide a simple ratio (e.g., 3:9). Because the responses from the data packets transmitted to the external router 90 must also pass through the local network 12 (3ms) then the broadband connection outside of the local network 12 contributes twice as much latency (6ms) as that caused by the local network 12 (3ms) in this example. The method 100 described with reference to Figure 2 is implemented in a computer system that may form part of a network component (e.g., within the ISP core 60). As shown in Figure 3, the computer system 300 may include a number of components including communication interfaces 320, system circuitry 330, input / output (I / O) circuitry 340, display circuitry (not always necessary) and interfaces 350, and a datastore 370. The system circuitry 320 can include one or more processors or CPUs 380 and memory 390. The system circuitry 330 may include any combination of hardware, software, firmware, and / or other circuitry. The system circuitry 330 may be implemented, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), microprocessors, and / or analog and digital circuits. The display circuitry may provide one or more graphical user interfaces (GUIs) 360 and the I / O interface circuitry 340 may include touch sensitive or non-touch displays, sound, voice or other recognition inputs, buttons, switches, speakers, sounders, and other user interface elements. The I / O interface circuitry 340 may include microphones, cameras, headset and microphone input / output connectors, Universal Serial Bus (USB) connectors, and SD or other memory card sockets. The I / O interface circuitry 340 may further include data media interfaces (e.g., a CD-ROM or DVD drive) and other bus and display interfaces. The memory 390 may include volatile (RAM) or non-volatile memory (e.g., ROM or Flash memory). The memory may store the operating system 392 of the computer system 300, applications or software 394, dynamic data 396, and / or static data 398. The datastore or data source 370 may include one or more databases 372, 374 and / or a file store or file system, for example. The method and system may be implemented in hardware, software, or a combination of hardware and software. The method and system may be implemented either as a server comprising a single computer system or as a distributed network of servers connected across a network. Any kind of computer system or other electronic apparatus may be adapted to carry out the described methods. The method 100 may also be illustrated as a sequence diagram, as illustrated in Figure 4. The sequence diagram shows the interactions in the form of queries and response between the client device 20, the broadband router 30 and the external server 90. The first query and response (e.g., ping) between the client device 20 and the broadband router 30 identifies the IP address of the broadband router 30. The following interactions measure the latency of the broadband router 30 for client devices 20 using a range of packet sizes and measurements repeated several times. Preferably, each measurement alternates between measurement targets (broadband router 30 and external server 90). The distributions (e.g., CDF) are calculated for the results of each measurement target. Percentiles are extracted from the CDFs (e.g., 5O'h, 90th, 99th percentiles) and these are used them to calculate a percentage or fraction of the end-to-end broadband latency, which provides a measurement of responsiveness for the internet target (external server 90) due to the local network (e.g., Wi-Fi) or external network (internet). The results can be displayed, stored or otherwise processed. Figure 5 shows a further schematic diagram of the broadband connection providing internet services to the local network 12. Under this figure are a series of arrows (510-550) indicating different portions of the broadband connection. In this example, the first section of the broadband connection (arrow 510) starts at the client device 20 and ends at the access note 40. The second section (arrow 520) proceeds to the BNG 50. The third section proceeds through the ISP core 60 and ends at the transmit router 70. The fourth section (arrow 540) proceeds through the bulk of the internet 80. The fifth section (arrow 550) is the connection from the internet 80 to the external server 90. Different sections of the broadband connection may start and end at any of the components (20-90) forming the end-to-end broadband connection. Each portion of the broadband connection may contribute a different amount to the overall latency. Whilst the previous simplified description of the method 100 describes only measuring two sections of the broadband connection (client device to the broadband router 30 and client device 20 to the external server 90), in alternative implementations latency from any or all sections of the broadband connection may be measured and evaluated using the described method. The output may include any or all CDF (or other distribution types) percentiles or portions of the distribution for each of the sections described above and more. From this information, the client device 20 (or application executing on the client device 20) may be able to determine a proportion of the overall latency attributable to different sections of the broadband connection as well as the latency attributable to the local network 12. For example, if a portion of the latency is due to the section of broadband connection between the application server 90 and the internet then this may be under the control of the service provider. If latency is high (or has increased over time) from the core ISP 60 to the broadband router 30 then a further (e.g., temporary) request may be made (e.g., using an API call) from the application server 90 to the ISP for an improvement in quality for one or more users. This can be triggered by results reaching one or more predetermined thresholds, for example. Figure 5 illustrates different contributors to latency and the sum. A AQ technique breaks down network delay into three basic components of latency: G (Geography); S (Serialisation - the only one impacted by speed); and V (Variable - which is dependent on traffic loading). See https:^w,broadband-(retrieved 14 February 2024). Identifying the IP address of the broadband router 30 may be achieved by extracting the relevant data from an ‘Ipconfig’ command or a similar function. Latency may be measured using a round robin ping alternating between the target IP addresses of the broadband router 30, a component within the ISP core 60 (e.g., a domain name server -DNS) or speed test server, and a well-known web server on the public internet. Any number of sections of the broadband connection may be investigated in this way. Different user applications and data services will use data packets of different sizes. Therefore, the measurements may more accurately simulate such data communication by using different sized data packets. The latency measurements may use the same data packet size or a selection of data packets sizes. This can contribute to the difference in latency for particular sections of the broadband connection. For example, the different packets sizes may be any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B. In an example implementation, data packets of six different sizes may be used with five pings being sent for each data packet size. Queues and buffer bloat can arise (and disappear) very quickly, so alternating the target IP address between each individual ping across the different targes reduces the impact of time varying change in network load compared to multiple pings to one IP address target before moving to the next. Calculations of the difference between the CDFs of the latency for each network domain IP address target may be expressed as a percentage contribution to the overall latency. Responsiveness may be determined from these results. Simple numerical percentages may be generated in a basic mode and full graphical results, including CDF with key percentiles, may be enumerated in an advanced mode. Preferably, the results may be summarised and stored (e.g., locally or in a cloud storage service). Conventional speed tests do not measure responsiveness, as they can only measure capacity. Some speed tests use multiple TCP threads and others (e.g., BBF TR-471) use UDP, and so don’t “back-off” when packet drops or congestion occurs. Furthermore, speed tests use significant volumes of data as they usually involve transferring very large files upstream and downstream, which can impact other customers’ applications (QoE). The large file transfer approach can cause latency spikes and packet drops for other users of the shared media (e.g., Wi-Fi, DOCSIS, PON, etc.). Figure 6 illustrates graphically an example of speed test traffic polluting the network, resulting in latency spikes rather than from evolving traffic load from user data. The BBF TR-452.1 standard recommends that the following requirements are met: The AQA^B of the path (A,B) is characterised by the [G, S, V] tuple. Note that obtaining reliable estimates of G and S requires a sufficient spread of packet sizes, which leads to the following requirements on the packets being observed (whether these are normal data packets, injected test packets, or a mixture): [R-13] The stream of packets being observed at OPs along a path MUST have a spread of sizes. R-14] The ratio between the smallest and largest packets in the stream MUST be at least 10. [R-15] The number of different sizes in the packet stream MUST be at least 5. [R-16] The number of packets in the stream with each size MUST be approximately equal. The present method and system provide latency demarcation with fewer than 100 data packets, avoiding the use of large data transfers, whilst improving the granularity of the available results. Large data transfers can affect results and introduce latency spikes. Furthermore, the tests can be carried out faster and so avoid user runtime problems. The method and system may be formed as a client application or tool executing on the client device 20, with an output that provides a demarcation of latency and responsiveness in an end-to-end internet connection. For example, the client application may provide a percentage or fraction of latency degradation due to the local (e.g., home or office) network (e.g., Wi-Fi or Ethernet) compared with the overall broadband network. Further granularity may be provided by separately testing or pinging between different broadband network components within the internet, including the application or content servers and data centres, for example). This is achieved without the need for integration of any client software into the broadband router 30. A broadband user can initiate the tests using client software (e.g. running on a mobile phone or laptop) and see the results quickly. It is also possible for the client software to be running on the client device 20 in the background with tests initiated remotely by the broadband ISP / network operator and the results captured, stored in the cloud, and analysed, as required. The external (internet) server 90 may be any web server URL, game server etc. with a publicly addressable IP address. In a Windows (RTM) environment, this may be achieved using commands like IPconfig or Route PRINT, for example. There may be different ways to measure latency. However, the described methods are independent of the latency measurement protocol, e.g., Internet Control Message Protocol (ICMP), two-way active measurement protocol (TWAMP), STAMP, etc. Any or all of these protocols and others may be used. Every application that requires an internet connection has some level of latency and packet loss beyond which it will deliver poor a quality of experience for the end user. The CDF values provided by the system and method 100 provide an indication of this loss and delay. Figure 7 shows a simplified example graph illustrating this point. Line 710 illustrates the measured response time or latency. Line 720 illustrates a particular requirement for an individual application. In this example, the requirement line 720 shows that 50% of responses need to be made within 5ms and 95% of responses within 10ms for an adequate user experience. There may be an overall 0.1% failure rate (packet loss) that is acceptable. In the example shown in Figure 7, the requirements are met. Providing the CDF percentiles enables this to be determined by the requester of the data. In summary, any CDF whose curve is always to the left and above of the requirements line indicates an outcome that is “acceptable”. If the lines cross, then there may be performance hazard. Thresholds on the CDF can be used to express network capability (end-to-end and per link), application requirements and service level agreements (SLAs). However, the exact “threshold” (i.e. 99%, 99.5%, 99.9% ...) varies by application and for example, control plane vs user / data plane traffic. This is related to “ensuring fitness for purpose” in the data transport. Having such differentiation is useful and can avoid “quality creep”. This can be described as an operator unable to determine what network conditions are required to fulfil a stringent requirement. This can lead to wasted resources as all (or a large fraction) of the traffic needs to be handled with higher than necessary performance to guarantee that the requirements are met. This can lead to inefficiencies. Figure 8 illustrates a point at which degradation becomes apparent to users and Figure 9 illustrates when operation is not possible at all. Figure 10 shows a schematic diagram illustrating two sections of the broadband connection to a local network 11 that obtains internet services. The latency contribution to the overall broadband connection generated from the local network 12 is shown by the left line on the graph. The contribution of latency by the remaining portions of the broadband connection is shown as the right line. Figure 11 shows schematically a similar broadband connection but with greater granularity (i.e., three sections of the broadband connection in this example). Again, CDF distributions are shown for each section (local network), broadband router 30 to core ISP 60, and core ISP to application server 90. These CDF distributions are shown as the three lines (left to right respectively) in the graph of this figure. Figure 12 shows further example latency distributions for two sections of the broadband connection (within the local network 12 and external internet latency). This figure illustrates one possible way in which the latency data can be compared but there may be many others. In this example, a simple numerical percentage can be considered. A difference or ratio between P50, P90 and P99 CDFs may be compared for different sections of the broadband connection to the end-to-end latency of the full broadband connection (e.g., to the client device 20 from the application server 90). This may be a round-trip latency, for example. An advantage of this procedure is that it is easy to calculate and results may be stored efficiently. If the CDF percentiles for both sections of the broadband connection are labeled as Ph (home router or local network 12) and Pi (internet latency), then the home router latency portion as a fraction of the overall Internet latency could be estimated as: Home router latency as % of Internet latency = (Ph50 + Ph90 + Ph99) / (Pi50 + Pi90 + Pi99) x 100 It should be noted that the values for Pi may remove the contribution of latency from the home network. This uses the 50th, 90th and 99th percentiles for each distribution. The above equation provides a simple relative percentage comparison for the requester of the information to use or pass on to end users. When latency measurement granularity is increased then latency measurements to a server in the broadband operator’s network (core ISP 60) may also be included in the equation and subsequent calculations. These values may be labelled as Pn50, Pn90, Pn99). Therefore, these may also be included as a percentage or fraction of the overall end-to-end broadband latency as well. For example, Core ISP latency as % of Internet latency = (Pn50 + Pn90 + Pn99) / (Pi50 + Pi90 + Pi99) x 100 Any combinations may be used and presented as an output to be used to assess or compare the performance of any sections of the broadband connection. Figures 13 and 14 illustrate graphically an example of a network latency spike and the effect and implications of particular percentiles that are investigated. This provides data that may be used to select appropriate percentiles from the distributions under different conditions or to determine different types of performance and network behaviour. This also illustrates a need for flexibility in such selections. For example, the request may also include the percentiles (or other values) that need to be returned. Therefore, different requesters may request different data to be used according to their own requirements. A latency spike may become apparent when one (or more) of the latency measurements is obtained that exceeds the highest latencies measured on for the end-to-end broadband connection measurements (e.g., these may be taken at different times). This could be due to a transient traffic burst loading network equipment buffers. If traffic load and / or impact is of particular interest, then the P99.9 (99.9th) percentile may be requested or investigated. However, if the objective is to compare the (non-loaded) relative latency contributions of the various broadband sections or domains, then the P1 (1st) and P50 (50th) percentile CDF values may be of more interest. There may be different ways to measure latency. However, the described methods are independent of the latency measurement protocol, e.g., Internet Control Message Protocol (ICMP), two way active measurement protocol (TWAMP), STAMP, etc. Any or all of these protocols and others may be used. The network measurement technique, granularity (number of measurement data points used to construct the CDFs), accuracy, and / or number of network sub-domains offered can change over time, as implemented by the network operator (ISP) providing updated client applications to the client devices 20. Figure 15A illustrates a time-series of latency for the local network 12 and external internet. Figure 15B shows similar data scaled in round trips per minute (RPM). As illustrated schematically in Figure 15C and 15D, the data can indicate where performance bottlenecks are found (within or outside of the local network 12), and measures or actions may be taken to address them so that application performance can be maintained. Alternatives to CDF percentiles could also be provided as the output. Other statistical distributions may be used such as probability density function (PDF), complimentary CDF (CCDF), or CCDF with log scale. Better network performance on the CDF plot may be indicated by few or no dropping of packets of data (i.e., with a probability of return of a data packet to a request rising to one). A desirable latency characteristic may also be indicated by a rapid rise in the curve. This can indicate that a large percentage of the measured traffic has low and consistent latencies, hence low jitter (variation). Conversely, undesirable latency measurement result characteristics may be indicated by higher dropped packet percentages and highly variable (high jitter) latencies. Actions may be taken or triggered when performance in one or more sections of the broadband connection does not meet these determined or predetermined requirements. An action may be taken based on the data and output. This may be an optional step and the action may take different forms. Furthermore, the action may be taken by different entities including the application server 90, the client device 20 or application executing within the client device 20, a component within the local network 12, or another entity. The action may include steps needed to enhance any or all portions of the broadband connection. Different actions may be executed by different entities. In particular, these actions may enhance the provision of the broadband connection provided by the ISP core 60, such as allocating more resources to a particular broadband router 30, including prioritising data packets or individual data packets from different types of application servers 90. Alternatively, the actions may degrade latency if the latency requirements of a particular user or client device 20I are being met far in advance of their requirements. Deep packet inspection or other techniques may be used to determine which data packets require enhanced treatment, for example. Test data packets may also be used to measure latency. Other actions may include activating a multi-access edge computing (MEC) component located close to the broadband router 30 (e.g., at the access node 40). The action may also include steps used to enhance the broadband connection for multiple users or groups of users. For example, if a plurality of client devices 20 provide information to an application server 90 indicating a new group of users is forming in a particular location or country, it may be determined from results provided by the client devices 20 to implement a virtual machine (VM) within that country or region so that the application server 90 or an instantiation of that application server 90 is located closer to a group of end users. This further reduces latency in their collective broadband connections. The action may be a notice or message to the user of the client device 20 to take action within their local network 12. Using a fixed percentile of latency, such as the 99th or 99.9th percentile, has the benefit of capturing relatively rare events. These metrics can help offset the problems with using a simple mean by including information about the size of latencies in the tail of the distribution. One problem with using only the 99th percentile (or any other percentile) is that it can also hide information. As demonstrated in the graph of Figure 16, including the P50 and P90 percentiles may better distinguish between the CDFs on the right, which both have the same P99 percentile. This figure illustrates the risk of only using one percentile of the CDF (e.g., 99%), since the measurements could be vastly different at the lower percentiles. The particular selection of CDF percentiles in any subsequent calculation or comparison may depend on an objective of the analysis. The lower percentiles (e.g., 1st and 50th) provide insight into “structural” differences, e.g., due to network topology and technology. The 1st percentile could indicate the best achievable latency on that part of the broadband connection when traffic loading is lowest (i.e., an emptier network) and where IP packets are smallest. However, if the objective is to assess the impact of traffic load variation / spikes, then the 90th to 99.9th percentile range may be more appropriate. For example, if an application 15 at the client device 20 has to wait a significant time for the last packet of a “chunk” of data representing a video image before it can decode and render the picture, that may be responsible for any perceived lag. Outliers around the 99.9% point may determine the impact on the perception and quality of experience (QoE) of the application’s performance. Comparing the difference between the high percentiles vs the low percentiles provides an indication of how much network latency degrades when it is more loaded (e.g., in the evening busy hour) - and an indication of the network’s capacity headroom and congestion management. It is possible to work with latency distributions on their own, without including the packet loss percentage. This metric does provide some of the properties of quality attenuation, such as the ability to ‘add’ (which can include via convolution of statistical distributions) the contributions of different network segments when computing end-to-end delay or assigning budgets. However, if the ability to compute application outcomes is required then it is preferable to include packet loss because packet losses can contribute a lot to the user-perceived performance. Packet loss information can be included in the output results, for example. Figures 17A-D illustrate graphically how the volume of measurements can affect results (e.g., accuracy and run-time). Figure 17A shows example results with five network pings (a network timing utility) for each packet size under investigation (six), resulting in 30 measurements per target IP address and executing in 8 seconds. Figure 17C illustrates results from using 20 pings for each packet size, resulting in 120 measurements per target IP address and running in 33 seconds. These time series plots illustrate more granular results with four times the number of measurements. Figure 17B shows the CDF distribution of the results of Figure 17A. Figure 17D shows the CDF distribution of the results of Figure 17B. In can be noted that the CDF diagrams, which show the statistical distribution of the results, appear to be extremely similar. This demonstrates that using fewer data points (network pings) does not significantly adversely affect the statistical distribution (CDF) but will reduce the run time of the measurement. There will be a minimum value of required measurements, however. The measurement volume can be tuned or varied for each section or segment in the broadband connection. Despite the time series looking more coarse, the key statistics are effectively invariant over the time scale of these two measurement sets (which took place within 3 minutes of each other). Hence if we derive key performance metrics (e.g. 50 percentile latency, 99 percentile latency etc.) from the CDF, it is acceptable (no detriment to interpretation of the results) to use the reduced number of data measurements that will fit within a runtime design target of less than 10 seconds. Whilst the CDFs don’t necessarily change significantly with a longer test or measurement duration, this may be more apparent when analysing lower percentiles (<P50), which can reflect structural delay in the network. However, if a user of the output results wishes to explore the higher percentiles in more detail (e.g., >P99) to assess the occurrence of occasional latency spikes, then longer test periods with more data packets could be advantageous. Figure 18 illustrates different configurations providing internet connections to client devices 20 in different ways. This can include wired broadband connections (e.g., over the public telephone network) that require a broadband router 30, and mobile telephone tethering implementations. Other configurations can make use of the described method and system. Figure 19 illustrates that unlike speed tests, this broadband performance management technique does not cause latency spikes or noticeably adds to latency. This is illustrated in the graphical results of Figure 19. The top trace in this figure is latency measured over a broadband access line (500Mbps FTTH). The lower trace results include the Wi-Fi section as well. Different sources of latency can be individually measured and compared using the described method and system. In the home or office (local network 12), latency may be due to Wi-Fi, multiple uses using the system and other forms of congestion. The Data Over Cable Service Interface Specification (DOCSIS) gateway may also introduce latency due to request grant cycles, multiple users and other congestion. The core ISP 60 can introduce latency due to routing to peers and transit. The wider internet may have other causes of latency including routing to other networks and long distances (with speed of light constraints). Figure 20 shows a table illustrating the impact of latency on different types of applications that can operate on the client device 20. This table also illustrates different types of information that can be obtained by comparing different percentiles. When latency outside of the local network 12 is determined from the output, then traffic prioritisation can be used. The method can identify when such prioritisation is useful and can be more efficiently utilised and when it is not (e.g., because significant latency is due to the local network). These example results illustrate the impact on measured latency of traffic prioritisation when the Wi-Fi network is heavily congested. Figure 21 (top) illustrates different techniques for displaying the output in terms of Round Trips per Minute (RPM). Different latency boundaries are shown. The table of Figure 21 shows the correlation between RPM and latency time in milliseconds. Any latency measurement reflector (such as for the STAMP or TWAMP Lite protocol) may be deployed to broadband routers. This may provide an alternative to the ping command. The use of different packet sizes in the tests enables the method to be extended to provide Quality Attenuation measurement analysis. Alternating (“Round Robin” or interleaving) the measurements to the broadband router 30 and then the target externa (internet) server 90 provides an improved comparison since it mitigates the risk of short-lived traffic congestion queues building in the buffers of a router or network elements, which might result in only impacting one of the measurement targets (broadband router 30 or the external server 90). For a three-way demarcation of latency analysis, an additional target external server may be required in the ISP or network operator’s network (such as a DNS server or speed test server). This will enable the generation of additional distributions (e.g., CDF) for latency measurements to that additional server. Therefore, additional information may be provided. As well as providing a percentage, fraction or other measurement of the latency attributed to the local network 12 in the overall end-to-end connection to the external server 90, a result may also be provided indicating a percentage, fraction or other measurement of the latency attributed to the broadband network. Adding a target IP address on the CMTS, OLT or BNG can provide further granularity but requires a further distributions to generated for each. The choice of external server 90 (e.g., belonging to a third party data service provider) can depend on its response to the data packets or pings. Some servers can respond in unpredictable ways and so these can be avoided. Several servers can be tested to confirm their suitability. Testing in advance may be used to generate a selectable list of suitable servers for the client device 20. The following provides an example illustrating benefits for analysing distributions of latency samples. For example, if latency is sample 1000 times, and 10 of the samples show 500ms of latency and the other 990 samples measured at 30ms, then the average latency is only (990*30 + 10*500) / 1000 = 34.7 ms. Looking at this average alone, then the broadband connection appears to be good. However, the 10 cases of extreme latency spiking to at least 500ms will adversely affect user experience. A 500ms latency spike is very likely to annoy a player of an online game or talking to someone in a video conference, whilst the average latency indicates a good result. In this example, considering the tail of the distribution is important when assessing and taking actions to improve latency. The system, method or tool may include a feature that keeps a record of previous tests, enabling the user to assess how their broadband and home network connection performance has changed over time. Latency decomposition can provide additional information. The examples above describe round trip time (RTT) latency but the end-to-end latency is composed of several elements. In a further example implementation the RTT may be deconstructed into different sub-components. For example, this could separate out the latency in the downstream direction from upstream latency. Distributions for each may be generated and comparisons of percentiles or other portions may then be carried on each separate latency type. Another option is to break down the results into how much of the latency was due to physical distance to the target server (i.e., limited by the speed of light in an optical fibre) versus how much was due to the speed of the network links or IP packets queuing in network equipment. Such detailed breakdown approaches may require additional test capabilities to be located within the network. Jitter analysis may also be carried out. A further enhancement adds more analysis based on the variation in the current latency measurements (known as jitter). The latency of a broadband connection can vary as the traffic load varies (e.g., from other users on the network). Network load is not like a dimmer switch and from second to second it can behave more like an on / off switch. Generally, a network is either idle or being used. This causes a variation in latency, i.e., jitter. For some applications like voice calls, video conferencing and gaming, the jitter can be problematic if too high. Latency under load and scheduling tests may also be carried out. Latency under load testing can execute the described methods under conditions that provide close to a worst-case scenario for particular user applications, e.g., when the network is busy versus being lightly loaded or idle. Such a heavy network load can be simulated by measuring the latency at the same time as doing a downstream then upstream speed test (effectively a simultaneous large file transfer). An alternative to this artificial loading of the network via speed tests could be to adapt the method to schedule the latency test measurements during expected hours of highest internet use (typically early evening) and also during a quiet period (e.g., around 4am). The difference in latency from these two measurement sets can help quantify (realistically) the impact of other users’ internet traffic. In an example implementation, the system and method can be scheduled for execution at specific times. For example, an application executing on the client device 20 can schedule measurements to take place in the background. A benefit of this process is that measurements can be scheduled during expected busy times for the network (e.g., 7pm in the evening, when the network traffic is expected to be highest) as well as during quieter times (e.g., at 4am, when the network traffic is expected to be lowest). This provides realistic feedback on the user’s broadband line performance under their daily actual peak traffic load. Comparing the two results (or monitoring trends over time) provides additional information regarding capacity headroom and management on the broadband connection for individual users and across user groups. The measurements can be scheduled at the same time every day, two or more times a day, weekly, monthly or at other intervals or times. The relative latency of the "busy hour" versus "quiet hour" (or other time periods) results may also help identify which customers are most impacted by congestion at peak times and hence may benefit most from Quality of Service (QoS) techniques. The demarcation of network segments in the results can also help identify which QoS technique may be most applicable. The QoS technique may be selected based on the results. For example, if a particular customer had a large difference between these results for their home segment, they may benefit from WiFi QoS or Wi-Fi MultiMedia (WMM). However, if the larger difference was in their ISP network segment and it was a cable connection then they may benefit from Low Latency DOCSIS. Hence the tool facilitates "mass customisation" to find and target those customers with congestion issues and then tailor remedies for their individual customer broadband connection. The test results can be used to determine where QoS techniques may add most value. Current end-to-end latency tests test “latency under load” where they run downstream and upstream speed tests at the same time as the end-end latency measurements. As noted previously, current speed tests cause latency spikes due to huge amounts of synthetic traffic that they inject into the network. The scheduling procedure uses the described system and method to obtain measurements for different parts of the broadband connection (latency demarcation) and so avoids injecting large volumes of spurious synthetic traffic to load the network. Therefore, such scheduling measures the broadband connection’s actual loaded performance during busy times (as well as unloaded performance during quieter hours) to provide insight into capacity headroom. This also avoids disrupting other users when tests are executed. As described previously, current internet speed tests congest the capacity of the network causing latency spikes for other users and are therefore less desirable than the latency demarcation test described within this disclosure for assessing the difference in performance between the busy and quiet hours. The described methods and systems may be incorporated into a latency demarcation measurement tool. Quality of Service (QoS) techniques can prioritise certain traffic flows during periods of congestion. However, a key challenge for making a case to invest in deploying such technologies is assessing how many customers would benefit and where those customers are. Not all customers suffer or are impacted by congestion and those that do, don’t necessarily suffer from it all of the time. By scheduling the latency demarcation measurements to run in the busy and quiet hours, and collecting the results over several days, a natural load or natural congestion impact (i.e., not artificially forced by extraneous traffic volumes like latency under load tests) can be assessed for each customer’s broadband connection. By gathering the results for a plurality of customers on the network, those who suffer most from congestion can be identified. Therefore, such regular or repeated latency demarcation measurements (as described throughout this disclousre) can identify those customers who would benefit most from the use of Quality of Service (QoS) or other improvements. Given that the demarcation measurement tool can examine the latency spikes (e.g., P99 percentile value) to determine which network segment is impacted most by congestion and hence latency spikes, this information can be used to identify where the use of QoS or other tools could have the most benefit. For example, latency spikes in the home could suggest that the use of WMM could be useful (e.g., to prioritise certain network traffic in the home or office over other less critical data). If it is the ISP’s network causing high latency, then QoS techniques such as Low Latency DOCSIS or the use of the low latency low loss scalable (L4S) protocol may be of value. Speed tests alone cannot be used to predict the effectiveness of such improvements and cause their own latency spikes. Furthermore, the demarcation measurement tool can be used to determine and quantify improvements to latency after such configuration changes have been made. Therefore, scheduling latency measurements according to the described methods and systems extends benefits and utility beyond simply providing performance demarcation (which has its own advantages). The methods and systems can be used to turn the latency demarcation measurement tool into a “congestion hunter” to locate which customers, groups of users, or user types could benefit most from QoS and other enhanced services and in which network segment(s) it should be deployed. This is a difficult problem that many of those who are still testing QoS benefits in artificially congested lab networks have yet to consider but which benefits from the described methods and systems. The method and system may be implemented in hardware, software, or a combination of hardware and software. The method and system may be implemented either as a server comprising a single computer system or as a distributed network of servers connected across a network. Any kind of computer system or other electronic apparatus may be adapted to carry out the described methods. As used throughout, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as an ion multipole device) means "one or more" (for instance, one or more ion multipole device). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including but not limited to", and are not intended to (and do not) exclude other components. Also, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true, “B is true”, or both “A” and “B” are true. The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the disclosure and does not indicate a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure. The terms “first” and “second” may be reversed without changing the scope of the disclosure. That is, an element termed a “first” element may instead be termed a “second” element and an element termed a “second” element may instead be considered a “first” element. Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed. It is also to be understood that, for any given component or embodiment described throughout, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. It will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise. Unless otherwise described, all technical and scientific terms used throughout have a meaning as is commonly understood by one of ordinary skill in the art to which the various embodiments described herein belongs. As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims. For example, whilst only one client device (and local network) is shown, there may be many executing the same method and generating their own results. There may also be more than one client device within each local network executing the method. The client device may execute the method using an installed application (e.g., a mobile app) or this functionality may be part of another application or software (e.g., a broadband or router management application). The method may be executed manually by a user or may be triggered automatically by another entity (e.g., the ISP or external server). Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or 5 example may be used in any other embodiment by making the appropriate changes.

Claims

25CLAIMS:

1. A method for managing latency in a broadband connection to a local network, the method comprising the steps of:5 a client within the local network determining an address of a broadband router;the client determining an address of a server external to the local network;transmitting one or more sets of a plurality of data packets from the client to the broadband router, wherein the plurality of data packets have different packet sizes;receiving, at the client, a response from the broadband router to each data packet10 of the plurality of data packets;measuring, at the client, a respond time for each of the data packets of the plurality of data packets transmitted to the router;transmitting one or more sets of the plurality of data packets from the client to the external server via the broadband router;15 receiving, at the client, a response from the server to each data packet of theplurality of data packets transmitted to the server;measuring, at the client, a respond time for each of the data packets of the plurality of data packets transmitted to the server;determining a distribution of response times for the plurality of data packets20 transmitted from the client to the broadband router;determining a distribution of response times for the data packets transmitted from the client to the server;comparing corresponding portions of the distributions of response times for the data packets transmitted by the client; and25 providing an output indicating a contribution of latency of the local network and acontribution of latency external to the local network based on the comparison.

2. The method of claim 1, wherein the step of providing the output further comprises transmitting the output to an external entity, the method further comprising:30 repeating the method at different times of day and / or for a plurality of localnetworks.3 The method of claim 2 further comprising the step of identifying one or more local networks of the plurality of local networks with an output indicating a contribution of latency06 03 25of the local network and / or latency external to the local network greater than predetermined value or values.

4. The method of claim 3 further comprising the step of changing a configuration of the 5 local network and / or an internet service provider of the local network for the identified one or more local networks.

5. The method of claim 4, wherein the change of configuration of the local network is enabling Wi-Fi MultiMedia (WMM) on the router and / or wherein the change of configuration10 of the internet service provider is enabling Low Latency DOCSIS.

6. The method according to any previous claim, wherein the address of the server external to the local network is determined from a user input, a random selection of alternative addresses, or by a predetermined default address.

157. The method according to any previous claim, wherein the client is in communication with the broadband router over a Wi-Fi or Ethernet network.

8. The method according to any previous claim, wherein the different packet sizes are 20 any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B.

9. The method according to any previous claim, wherein the set of the plurality of data packets comprises at least five data packets and / or at least five sets of data packets are transmitted from the client to the broadband router and from the client to the server.2510. The method according to any previous claim, wherein a plurality of sets of data packets are transmitted from the client to the broadband router and from the client to the server and wherein individual sets of data packets are alternately transmitted from the client to the broadband router and from the client to the server.3011. The method according to any previous claim, wherein individual data packets are alternately transmitted from the client to the broadband router and from the client to the server.06 03 2512. The method according to any previous claim, wherein distributions of response times are calculated as cumulative distribution functions, CDF, complimentary CDF, CCDF, or a probability density function, PDF.5 13. The method according to any previous claim, wherein the compared portions of thedistribution of response times for the data packets are any one or more of the 50th percentile, the 90th percentile and / or the 99th percentile.

14. The method according to any previous claim, further comprising the steps of:10 transmitting the one or more sets of the plurality of data packets from the client to aserver within an internet service provider network;receiving, at the client, a response from the server within the internet service provider network to each data packet of the plurality of data packets;measuring, at the client, a respond time for each of the data packets of the plurality15 of data packets transmitted to the server within the internet service provider network;determining a distribution of response times for the data packets transmitted from the client to the server within the internet service provider network, whereinthe step of comparing corresponding portions of the distributions of response times for the data packets transmitted by the client further includes comparing a portion of the20 distribution of response times for the data packets transmitted to the server within the internet service provider network with a corresponding portion of the distribution of response times for the data packets transmitted to the broadband router and a corresponding portion of the distribution of response times for the data packets transmitted to the server, and further wherein25 providing the output further indicates a contribution of latency of the server withinthe internet service provider network.

15. The method according to any previous claim, wherein the data packets are internet control message protocol packets, ICMP, including an echo request.3016. The method according to any previous claim, wherein the client is any of: a computer; a mobile device; a laptop computer; a tablet computer; a smartphone; or an application on a mobile device.06 03 25if the output indicates a contribution of latency of the local network above a predetermined threshold then triggering one or more actions within the local network or by a network operator.5 18. The method of claim 17, wherein the one or more actions include any one or moreof: changing the configuration of the broadband router; rebooting the broadband router; changing a Wi-Fi channel of the broadband router; changing a priority of clients or categories of clients within the local network; and issuing a notification.10 19. A client device configured to operate within a local network, the client devicecomprising:one or more processors; andmemory storing computer-executable instructions that, when executed by the processor, cause the client device to:15 determine an address of a broadband router;determine an address of a server external to the local network;transmit one or more sets of a plurality of data packets from the client device to the broadband router, wherein the plurality of data packets have different packet sizes;receive a response from the broadband router to each data packet of the plurality of 20 data packets;measure a respond time for each of the data packets of the plurality of data packets transmitted to the router;transmit one or more sets of the plurality of data packets from the client device to the external server via the broadband router;25 receive a response from the server to each data packet of the plurality of datapackets transmitted to the server;measure a respond time for each of the data packets of the plurality of data packets transmitted to the server;determine a distribution of response times for the plurality of data packets30 transmitted from the client device to the broadband router;determine a distribution of response times for the data packets transmitted from the client device to the server;compare corresponding portions of the distributions of response times for the data packets transmitted by the client device; andprovide an output indicating a contribution of latency of the local network and a contribution of latency external to the local network based on the comparison..LDCM

Images