Evidently I seem to hold a contrarian position on whether Broadband access bandwidth consumption should be capped or not. My position is that ISPs are in the business of offering service at the Network Layer and they should be free to charge based on the consumption. My rationale is simple: with the freedom to charge at the Network Layer, ISPs will not be in a position to dictate usage policy or to play favoritism to one provider over another. Please note that I also contend that freedom to charge at the Network Layer includes offering differentiated service (at the Network Layer) as long as differentiation is requested by the users and are charged to them. Today I read something from an unexpected source that reinforces my position.
Sonic.net, a competitive access provider based in California is strongly and unequivally opposed to capping bandwidth usage. So I had understood. Indeed, they supplied usage data to widely reported study that refutes effectiveness of bandwidth caps in relieving congestion. But an article in Gigaom that quotes Dane Jasper, CEO of Sonic.net seems to suggest their position is conditional after all. First let me quote some passages (referring to why the company is offering fiber access only to consumers and not to businesses) from the article:
“... when it comes to delivering broadband to businesses, he recognizes that a superfast gigabit connection to a business will have a very different usage pattern than one delivered to a consumer. ... “With our stance on no capping, I [Jasper] have a little bit of concern delivering 1 gig to a business at $89.95 and them using half of it, because that could really happen.”
… For example, the lack of applications for gigabit networks probably helps Jasper here, as does the fact that most consumers typically use downlink services to consume content. And currently there’s a limit to how much they can consume, even with three or four TVs downloading or streaming HD content.
“Consumption is still constrained by the number of TVs and hard drives and even though everyone eventually has more stuff, practically speaking it really does end up normalizing down to a reasonable level,” Jasper says. … But a business might hook a data center or several servers up on a gigabit connection and use that to send a lot of traffic out. And that could get expensive.”
This is my take away from this article: Currently consumers use the connection mostly to download content and there is a natural limit on how much they can use it for. In other words, Sonic.net is relying on the empirical cap. what happens if the usage pattern changes and the empirical cap is not acceptable anymore? What happens if consumers place low-cost servers to serve their content by themselves? What if some OTT player distributes Nano Data Centers to Sonic.net’s customers? After all rate arbitragers would love this, won’t they?
There is a more damning indictment with regards to businesses. Sonic.net has decided to not offer gigabit access to businesses, just so they can cling to “no cap” policy. What would be our reaction if AT&T Worldnet decided not to offer DSL, but stick to just dial-up modems for some policy reasons. Isn’t it better for businesses to pay for consumed bandwidth, but still get gigabit access? After all the major benfit of high-speed access is reduced latency.
So I say to Sonic.net and other proponents of “no cap” policy: fanatical adherence may be robbing the very same customers you think you are protecting.
A couple of days back, my Twitter stream saw a few mentions about a story that suggested potential privacy issue due to a flaw in Skype. A quick tracing of the origin of the story pointed to a research paper published by a few associated with NYU-Poly, which is about six weeks old. It is not clear why it surfaced this late. Nonetheless it is instructive to study the paper and understand the root cause of the flaw.
The paper is clearly written and is based on a well designed experiment. Apparently, the authors have alerted Skype of the problem and the authors lament that Skype has not taken any steps to address the issues. But it looks, on the surface at least, it is simple to thwart the attack.
What the study found out is that it is able to
I don’t think that many will find it very alarming that one can so easily find out the Skype ID aof a person. After all it is widely known that Skype provides a directory service. After all, with White Pages, we could reasonably get a person’s address. Also, determining Bit Torrent activity is outside the scope of Skype. So our focus really is how are they able to determine the IP address at which a Skype user is connected.
It turns out that Skype clients and the supernodes generate a signature pattern of datagrams during a session setup, thereby identifying the IP address of the target Skype client. In the following A is the Skype client originating the session and B is the target Skype client. When A initiates a session with B, A is given the IP addresses of a bunch of supernodes AND that of B (if B is not currently connected then the last connected address). Even though A does not know which is B’s, the researchers have identified a weakness in Skype’s protocol design that can be exploited to identify B’s address.
As part of session initiation, Skype protocol initiates TCP connection to all of them. If the TCP connection attempt to B fails, then A and B exchange bunch of UDP datagrams of predetermined length. Interestingly, this does not happen with other nodes. Additionally, if the TCP connection between A and B fails, then B does not indicate the presence of an incoming call on the UI. In other words, the user of B does not know of a malicious call attempt. The researchers suggest that one can exploit these two flaws to determine and track the IP address at which B is connected to the Internet. Specifically, the researchers prevented the establishment of any new TCP connection by dropping all outgoing and incoming SYN packets to all IP addresses. Then monitor UDP traffic to identify B’s IP address.
It is not clear why Skype has not addressed this issue thus far. A simple solution is clear: Skype needs to hide B in plain sight. They just have to make all the nodes to behave the same way when TCP connection fails. In other words all the nodes have to exchange UDP packets. Since the content is encrypted and obfuscated, the infrastructure nodes can be saying “let us pretend to talk”. As an added mesaure the length of UDP packets should be varying from instance to instance. It is simple to add a random length of padded bytes. The fact that they have not fixed the flaw suggests that there must be operational reasons why this apparently simple solution will not work.
In any event, Skype must add these malicious call attempts to the call logs, even if they do not want to inform the user via UI. The call logs can give the information of the Skype ID, their IP address (isn’t that poetic justice?) who made these surreptitious call attempts. This way at least users will be aware of they being tracked.
It is likely that this is a known flaw. I recall that one of the suspects in the murder of a British student in Italy was tracked in Germany after he attempted to use Skype. It is possible that the authorities used this mechanism.