Last month I got access to Jio 5G like everyone else around in Haryana. They are running a beta program with uncapped data for now. Overall it works fine for usual stuff (web surfing on popular sites, YouTube videos, music streaming etc) but 464XLAT seems to be a little buggy in IPv4 hardcoded destinations. Initially it was giving quite a few issues but many of them seem to be fixed in last few days.
Last year had many interesting developments and one of that has been object storage. For those unaware, object storage is de-facto cloud storage which stores data as objects instead of file system architecture. This gives the option of simple plug-and-play horizontal scalability. It became popular when Amazon Web Services (AWS) launched S3. The idea was straightforward - pay-as-go storage with a few cents/GB/month charge to store data and a few cents/GB to egress data. No need to plan storage, no need to plan hard disk, storage servers, or rack capacity but a simple pay-as-you-go opex cost. Plus top tier cloud players do offer redundancy of data. The API replies with “success” on uploads only when data is replicated to multiple datacenters.
I was recently discussing with a friend Jio’s Fifa streaming issues. Considering PNI capacity challenges with other telcos, I wonder if they were serving FIFA streams out of their network or if it would be on some CDN like Akamai. As I was testing, I noticed a couple of megs of flow data with my provider’s local IP. Turns out that was a local Google GGC node in Rohtak and as I try to connect to it, it replies on HTTP port 80 and 443. The port 443 response is rather more interesting because while connecting to IP throws an error, it does give me the SSL certificate out of handshake and now I know it’s indeed Google! :)
Yesterday there was an article in the Indian paper Financial Express with the title “OTTs may have to pay access charge to telcos”.
Quoting a few points from the article:
- Social media intermediaries like WhatsApp, Facebook and Twitter, and over-the-top (OTT) players like Netflix, Prime Video and Disney+Hotstar may have to pay a carriage charge to telecom service providers
- Data, particularly video, comprises 70% of the overall traffic flow on telecom networks, and this would grow further with the rollout of 5G services
- Upon reference from the DoT, Trai is currently studying various possible models under which OTTs can be brought within the purview of some form of regulation
- According to sources, an interconnect regime is a must between OTTs and telcos because as 5G services grow, there would be immense data/ video load on networks, which may lead to them getting clogged or even crashing at times.
This concept of “OTTs must pay” is not new. This has been argued a few times in past. Exactly ten years ago in 2012 I wrote a blog post about Bharti Airtel expecting Google/YouTube to pay. At that time they could not convince OTTs to pay. Why is this renewed interest now? Well, that has to do with the first SK Telecom (South Kore telecom) Vs Netflix court case in South Korea where SK Telecom claimed that a large part of bandwidth utilization was because of Netflix and hence they should pay a “fair share” of their traffic which they lost. Soon around this multiple of large telecom monopolies in Europe started this discussion in their respective geography. Four of the top EU players - Deutsche Telekom, Orange, Vodafone and Telefonica are of opinion that OTTs should share the burden (news here). And hence Indian telcos possibly looking to renew this debate.
I was having this discussion with someone recently on possible software to manage an IXP. Lately, IXP Manager has become the de-facto choice for managing IX. It’s a good tool. Nick and INEX team has built a fantastic open-source tool. But I still feel it’s a bit overloaded for a small 1-2 DC IX operation.
If I have to set up a small to mid-size IX, I would rather do that with arouteserver instead of IXP Manager as I did in case of BharatIX in Mumbai (until it shutdown!). One of the problems with arouteserver is that it can be script intensive and one may need something around it to manage it for things like build config on clients.yml update, regularly update filters etc.