I guess low bandwidth is no problem. You only need to send a stream of price changes of the most common instruments (currencies, stocks). And only if there are meaningful movements. I guess a few kbit/s can already provide a lot of value.
How fast would such a connection be? Is there an easy way to calculate the distance the signal takes compared to great circle line?
You can send samples. E.g. the USD/EUR rate (or the price of an equities future) if it changes by more than x within the last 50ms. The difference of that rate to the "local" rate in London is enough to generate the trade. Same with equity indices. You'll know that if there's no movement, there's no opportunity. So it's enough to send a signal if there has been a significant move that's "young" enough so that the other side can't know it yet.
Your trades only make money on the difference of the public information in London and what you get faster from Chicago. Therefore sending trade instructions isn't helpful as Chicago doesn't know London prices. But just giving the London algorithm that bit of inside can help a lot.
I assume trade strategies are mostly very simple as well. Basically just anticipating a change in price and quickly buying/selling to make some money off it.
N.B.: I only talk about Chicago->London here but given that Chicago hosts one of the largest Futures markets, I'd assume a lot is actually done in reverse. Using local prices from London of an underlying instrument (e.g. London stock market) to "predict" the value of the future traded in Chicago. You can make a lot of money if you know the price of the underlying instrument of a future before others do.
Generally speaking, folks use the CME futures as a leading indicator, so you may have several different trading strategies that trade against the European markets and just use the CME pricing as one of their inputs. In that case, the most bandwidth-efficient play is to send your market data over once from Chicago, replicate it / make it available to all your trading strategies, and let them do their work locally.
Sure, you're certainly not sending a full feed -- presumably you've got some algo sitting in Chicago that's looking for interesting / potentially profitable price / vol changes and sending them via the fast path, while the remainder of the feed is going via higher-bandwidth but slower paths.
You might as well have your decision logic before the communication path, then you can send like buy/sell orders in code using an agreed decryption pad/dictionary. (Akin to Morse's original conception).
I'm not an algo trader, but you need the data from both ends of the link to determine if there is a trade you want to make, right? One side or the other is going to need prices from both ends in order to make a trading decision, and preferably both, since each side can only make decisions that are relevant to their side of the link, because needing a round trip negates all of the speed advantage you incurred by developing a top secret HF trading link.
Edit: I meant the HF here to refer to the "high frequency" wavelengths in use in the link (in Ham parlance, HF and shortwave are roughly synonymous), but just realized it also could be "high frequency" as in the frequency of trades.
How fast would such a connection be? Is there an easy way to calculate the distance the signal takes compared to great circle line?