With the World Cup just around the corner, you may be tempted to catch a match live while at work by watching streaming media over your computer. However, today our UK office received a letter from the TV Licensing Agency which may stop you in your tracks if your offices are located in that country.

The letter advises that “…if your staff or customers watch television programmes as they are being shown on TV, including live World Cup games, then your organization needs to be covered by a TV licence.  This is the case whether they use a laptop, computer, TV set, mobile (cell) or any other device owned by your business”.

The key phrase here is  “owned or provided by your business” as the letter goes on to advise of an exception. Apparently, if your staff watch television programmes as they’re being shown on  television USING THEIR OWN DEVICE, and they haven’t connected it to the mains or an aerial, then they’re covered by their own home TV Licence, if they have one.

A full explanation of the situation is available on the TV Licensing agency web site  http://www.tvlicensing.co.uk/check-if-you-need-one/business-and-organisations/

Of course, the quickest way to ensure your organization doesn’t fall foul of this regulation is to either buy a licence or impose a blanket ban on anyone watching TV while at work. However, for some fans it’s going to be really hard to resist just taking a quick look online using office equipment.  Alternatively, they may decide to bring in their own devices.

Either way, if you are an owner, director or manager you need to know what is being accessed over your company’s network in case, at worst, it is illegal or more innocently (but probably of greater significance) impacting the performance of other networked applications.  This is where you may find our AppQoS monitoring products useful as they can show you how the network is being used and who’s accessing what, including World Cup TV.

We really wish our team well and hope that this is the year when we bring home the World Cup, while at the same time ensuring we all stay on the right side of the regulations.

I had a debate with one of our customers the other day on how to measure latency in their network.

You may wonder why this even matters:  Well, as I outlined in a previous blog, for almost all TCP based applications (Mail, Web, ftp, custom sockets applications…) latency matters just as much, or more, than bandwidth.  If bandwidth is the “speed of our road”, then latency is the “journey time”, which is related to “the length of the road” as well as all the “holdups” (competing traffic, delay at routers, switches, repeaters etc) along the way.  If we want to test how an application will work in a real network using a network emulator then we need to understand the latency, bandwidth etc that it will experience.

The simple and traditional answer in measuring latency is to use ping, or a tool based on ping or its underlying protocol ICMP.  These send an ICMP  packet to the destination which it turns around and sends back and the round trip time (RTT) is calculated.  But this has problems in most modern networks! 

Why?  This is due to most modern networks, the Internet, corporate WANs, and MPLS included, implementing some form of traffic prioritisation (or QoS – Quality of Service- as it’s often known).  This has been done so that important applications, such as corporate VoIP, SAP etc receive preferential handling and others, such as access to iPlayer etc receive a low priority.  The problem with Ping (ICMP) is that it receives no particular priority at all, and so is not really representatitive of a particular application. 

I don’t mean to diss ping completely – sometimes it’s all we’ve got, but the way around this is to measure the latency of “real” application traffic which is subject to the appropriate network QoS.   To do this we can take advantage of the fact that when a TCP connection is made, and before any http, ftp etc. request is made, or data is sent, a handshake (known as the three way handshake) takes place between the client and the server.  

Using some maths on this we get to see the latency for presisely that application, as the handshake packets are subject to all the QoS parameters of the rest of the TCP session.

You could therefore take the approach of trying to create a TCP session to a target server using the correct IP addresses and ports and time the handshake, but this might cause problems for the server, and as we’re unlikely to complete the transaction it could be regarded as a potential intrusion or DoS (Denial of Service) attack.

Because of this, in our INE Companion and iTrinegy AppQoS products, we provide the ability to “watch” the normal, existing  transactions taking place and time their handshakes.