India

This post analyses impact of cancellation of Bangladesh’s transit aggrement for India. It comparies latency via local Vs Bangladeshi paths.

This posts covers a quick analysis of Airtel’s recent interconnection at MSK-IX in Moscow, Russia

This post covers network connectivity check of Contabo in India.

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.

CERT-IN i.e Computer Emergency Response Team, India issued new guidelines on 28th April. Guidelines essentially ask those VPN providers to keep a log of customer details, their IP addresses, emails, phone numbers etc and maintain that log for at least 5 years. The detailed notification is here.

This not only extends to VPN players but also to datacenters, VPS, cloud service providers etc. I can understand the problem they are trying to solve as most criminal activities are hidden behind VPN players and investigating agencies just hit a dead end as they see the WAN IP of a VPN player.

In the early phase of Russia - Ukraine war, Ukraine made a strange request to ICANN. They asked ICANN to remove .ru (Russian ccTLD) from the root DNS servers, revoke SSL certs for .ru and shut down root DNS servers hosted in Russia.

Here are the three requests they made:

Complete letter is here (and original source is here). This is going to be one of few notable cases where critical internet infrastructure is being weaponised. ICANN declined the request for good. Due to my limited understanding of Russia, Ukraine, US, EU, NATO etc I am not going to comment on the conflict itself. But coming to the critical infrastructure part - this reminds me of my earlier blog post on Doomsday and DNS resolution.

I am in Bangalore for two days. While there are many things packed into these two days short schedule, one of the most exciting ones is Google Global Network India Innovation Summit. While Google has presented across various events in past talking about their AS15169 backbone, this is the first summit where they are covering it in detail and that too with the Indian context!

Must say that I find AS15169 quite fascinating on the BGP side of things. A massive network which follows “cold potato” routing i.e keeping the majority of traffic over IGP over larger locations, terminating BGP sessions on the virtual appliance with SDN backing, a pretty robust failover design with BGP + DNS taking care of server(s) and even entire PoP failing. I blogged about them back in 2020 here. So this should be fun!

Vultr has announced start of their Mumbai location on 12th of this month. It’s amazing to see them entering India. Always a good thing for growth of cloud computing on demand in India.
Besides Vultr, we have got Amazon AWS, Microsoft Azure, Google Cloud, Digital Ocean, Linode, Oracle Cloud etc in India. I heard OVH also planning for Indian location and so have to see how that goes.

In meanwhile, let’s have a quick check on Vultr’s network connectivity. I just created a Virtual machine in Mumbai to look at the routing and connectivity. I got following for my test VM:

Background

Lately, NIXI has been making a bit of news in the Indian peering ecosystem. NIXI for those who may not be aware is the National Internet Exchange of India. It was founded in 2003 with the idea to provide inter-connection layer 2 peering fabric for local Indian ISPs. They were supposed to ensure domestic Indian traffic is exchanged within India and not outside of India. In my previous post, I did cover how that is not true for now. They never picked up much interconnection due to a number of fundamental issues with their policies.