If you have a lot of spliced fibre runs then an Optical-TDR is golden, but not cheap. If you are using copper, then most modern switches have TDR functionality built in. On a Cisco switch the command 'test cable-diagnostics tdr interface ' will do the business.

I have found a tone probe (you attached a box to the line which sends a 'tone' down the cable. then use a wand to trace the cable by induction). They are great for tracing cables run without having to resort to the old 'tug-and-trace' method, and usually include a Cat5 cable tester. Fluke make one for about £100.

They can't sell them, they don't own them. the RIR (RIPE NCC) has very strict rules over the transfer of IPv4 addresses. If the currently end user no longer requires them they should are to be returned to RIPE for zero compensation, RIPE can then re-assign based on applications requirements and justification. The rules were brought in to prevent people setting up shell companies to land grab all the remaining address space once it became obvious it would be exhausted.

Indeed, I suspect some parts are missing.

As mentioned interrupt processing / context switches can add latency and jitter. As a 10G LAN has a very small round-trip delay (RTD), TCP can calculate the re-transmit timeout (RTO) to be a very small number. which makes it very sensitive to small amounts jitter, and can result in packets incorrectly being flagged as lost, this causes re-transmission and for the TCP window size to be zeroed (killing throughput) (some congestion control tuning can help here). The problem can become severe with 10G networks to a VM over a software bridge, but to the jitter introduced by the bridge. (SR-IOV can help here). There is a lot you can do to TCP to improve its performance in such circumstances, increased window buffers, use a modern congestion control algorithm, interrupt coalescing, SR-IOV. For very low latency applications (like HFT) people generally don't use interrupts, they configure their NIC to kernel bypass (user space library with direct access to the NIC hardware, to avoid context switching), map to the optimum NUMA space for the core handing network events, keep their application in CPU cache, align data-structures to cache lines, turn off all hyper-threading and power saving and assign a core to busy spin checking for network events, not very green.

The powers that be have been pushing for a ubiquitous telecoms surveillance pork fest for at least the last 20 years. There is a fresh push with every new government / home secretary. I have no doubt whatsoever that we have not seen the last of this, need to stay vigilant.

When put to our expert panel of vendors^H^H^H^H^H^H^H advisors they said.. "Oink Oink.. scoffle scofffle..snort.. TERRORISTS!.. psst! got a lovely non-exec possition put aside for after the next election.."

This will just be a talking shop to waste money producing another pile of fully buzzword compliant rubbish, like the Digital Britain Report. As for the killer app, given our government's tendencies I would not be at all surprised of they thought it was a good idea to extend hi-res CCTV into everyoneâ(TM)s houses, you know cos of the terrorists and all.

Under UK law failure to provide all decryption keys on demand is a serious criminal offence. Unless you can *prove* that you can't decrypt the data you are presumed guilty. Given the difficulty in proving a universal negative, plausible denial mechanism such as those in TrueCrypt could land you in serious hot water.