Internet Peering in Mexico - What happens in Mexico should stay in Mexico!

Well after having written the previous post a year ago about Internet peering in Mexico, even more bad news has come to light.

After having tried to use Telecable in Puerto Vallarta, and Telecable in Zapopan for a specific use that would connect two locations together, we see the following

ping -t 201.130.248.XXX

Pinging 201.130.248.XXX with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 201.130.248.XX: bytes=32 time=344ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=338ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=343ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=413ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=303ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=299ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=309ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=337ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=353ms TTL=49

First Packet Loss! Second We see that there is EXCESSIVE latency caused by Protel who chose to ignore the issue because I was not their client directly! Not to mention this example all data goes from Mexico to USA TWICE! First to Level3 then to McAllen Texas via Protel. There is also 200ms of Latency between Laredo and Monterrey!

1 8 ms 7 ms 7 ms 200-56-193-1-cable.cybercable.net.mx [200.56.193.1]
2 43 ms 69 ms 79 ms 148.243.116.10
3 71 ms 84 ms 98 ms dial-200-57-215-25.zone-3.dial.net.mx [200.57.215.25]
4 101 ms 89 ms 63 ms 148.245.252.217
5 84 ms 68 ms 69 ms dial-200-39-230-53.zone-1.dial.net.mx [200.39.230.53]
6 118 ms * 68 ms 200.33.208.129
7 116 ms 108 ms 107 ms pos6/0.rr1.torixt.avantel.net.mx [200.33.208.201]
8 117 ms 93 ms 102 ms 200.33.208.150
9 100 ms 119 ms 99 ms na-224-21.na.avantel.net.mx [148.245.224.21]
10 128 ms 133 ms * so-8-1.car2.Houston1.Level3.net [4.79.90.97]
11 116 ms 118 ms 131 ms ae-2-5.bar2.Houston1.Level3.net [4.69.132.238]
12 130 ms 102 ms 96 ms ae-0-11.bar1.Houston1.Level3.net [4.69.137.133]
13 72 ms 50 ms 76 ms ae-13-13.ebr1.Dallas1.Level3.net [4.69.137.138]
14 117 ms 141 ms 113 ms ae-71-71.csw2.Dallas1.Level3.net [4.69.136.126]
15 123 ms 104 ms 137 ms ae-2-79.edge2.Dallas3.Level3.net [4.68.19.76]
16 128 ms 134 ms 137 ms Tiscali-Level3.Dallas3.Level3.net [4.68.110.158]
17 109 ms * 91 ms protel-inext-gw.ip.tiscali.net [77.67.68.146]
18 91 ms 106 ms 121 ms ge-0-0-0.core01-lar.redip.inext.net.mx [200.52.143.45]
19 293 ms 309 ms 300 ms as-1.core01-mty.redip.inext.net.mx [200.52.143.109]
20 354 ms * 343 ms po-5-0.inext01-slp.redip.inext.net.mx [200.52.143.230]
21 346 ms 328 ms * po-4-0.core01-ira.redip.inext.net.mx [200.52.143.237]
22 334 ms 327 ms 352 ms po-1-0.core01-mcallen.redip.inext.net.mx [200.52.143.225]
23 * 341 ms 365 ms po-2-1.core01-gdl.redip.inext.net.mx [200.52.143.90]
24 348 ms 313 ms 287 ms 134.142.52.200.static.redip.inext.net.mx [200.52.142.134]
25 * * * Request timed out.
26 * * * Request timed out.
27 * 319 ms * 201-130-248-XX-cable.cybercable.net.mx [201.130.248.XX]
28 310 ms 311 ms 296 ms 201-130-248-XX-cable.cybercable.net.mx [201.130.248.XX]

Trace complete.

What an embarrassment!

___________________________________________
UPDATE JAN 17, 2009

Here is the biggest lie that LACNIC could make
http://www.lacnic.net/documentos/lacnicxi/presentaciones/peeringmexico.ppt

GO ahead check it out. Then see the traceroute above and know that Inext refers to Protel that supposedly does peering with Telmex IN MEXICO according to that document. Furthermore here is more proof, and know that this traceroute is from Guadalajara TO Guadalajara.

traceroute to 187.140.21.XXX (187.140.21.XXX), 30 hops max, 40 byte packets
1 10.206.0.1 (10.206.0.1) 10.468 ms 10.491 ms 10.483 ms
2 10.255.255.1 (10.255.255.1) 183.849 ms 184.379 ms 184.971 ms
3 router.cybercable.net.mx (200.53.250.10) 184.142 ms 184.734 ms 184.402 ms
4 45.142.52.200.static.redip.inext.net.mx (200.52.142.45) 185.121 ms 186.734 ms 186.383 ms
5 * * *
6 ge-0-0.core02-lar.redip.inext.net.mx (200.52.143.46) 221.606 ms 260.877 ms 276.338 ms
7 xe-3-1-0-102.dal11.ip.tiscali.net (77.67.68.145) 284.812 ms 284.631 ms 28 5.410 ms
8 xe-2-0-0.sjc10.ip.tiscali.net (89.149.187.189) 310.528 ms 310.724 ms 311. 439 ms
9 xe-0.equinix.snjsca04.us.bb.gin.ntt.net (206.223.116.12) 311.433 ms 311.43 5 ms 311.118 ms
10 as-0.r20.lsanca03.us.bb.gin.ntt.net (129.250.4.97) 321.067 ms 321.714 ms 321.788 ms
11 * * *
12 xe-7-1.r01.lsanca03.us.ce.gin.ntt.net (204.1.253.70) 267.349 ms 267.482 ms 268.159 ms
13 dsl-187-140-21-XXX.prod-infinitum.com.mx (187.140.21.167) 314.538 ms 323.7 40 ms 311.758 ms

Why does LACNIC think we are so stupid? This problem is getting WORSE, NOT BETTER, and it has only been one year since my last post on this topic.

Here is one last bit of proof that there is really no peering IN MEXICO regardless of what the lie of the day is at LACNIC
1 9 ms 7 ms 8 ms 200-56-193-1-cable.cybercable.net.mx [200.56.193.1]
2 9 ms 8 ms 8 ms 148.243.116.10
3 79 ms 72 ms 62 ms dial-200-57-215-25.zone-3.dial.net.mx [200.57.215.25]
4 13 ms 13 ms 16 ms 148.245.252.217
5 26 ms 23 ms 38 ms dial-200-39-230-53.zone-1.dial.net.mx [200.39.230.53]
6 55 ms 60 ms 101 ms 200.33.208.129
7 46 ms 46 ms 46 ms SAT1.ALTER.NET [63.65.121.165]
8 44 ms 45 ms 46 ms 0.so-4-1-0.XL4.SAT1.ALTER.NET [152.63.97.194]
9 104 ms 112 ms * 0.so-7-0-0.XT2.LAX7.ALTER.NET [152.63.115.237]
10 82 ms 82 ms 80 ms GigabitEthernet7-0-0.GW7.LAX7.ALTER.NET [152.63.118.53]
11 75 ms 73 ms 76 ms telmex-gw.customer.alter.net [157.130.246.70]
12 76 ms 77 ms 74 ms iadsl-jal-bandera-16-ge7-0-0.uninet.net.mx [201.125.11.240]
13 126 ms 135 ms 109 ms dsl-187-140-21-XXX.prod-infinitum.com.mx [187.140.21.XXX]

The peering here again also seems to be in USA.'

I welcome a reply from LACNIC on this subject.


_________________________________________________

UPDATE January 29, 1009

LACNIC replied and the complete response is in the comments section, as well as my follow up. The short version is that apparently the powerpoint document referenced is not an official LACNIC document. I must then ask, why then is it posted on the LACNIC web site?

Secondly, The document refers to "ISP Peering in Mexico", not "Mexican ISP Peering in the USA" The difference again is the latency and at least one of the traceroutes shows that data is apparently being handed off in the USA between Mexican ISPs. It does therefore NOT qualify as "ISP Peering in Mexico", although may involve Mexican ISPs peering in the USA.

Thirdly, the peering diagram on page 6 also does not involve PURELY ISP peering. A closer look at those companies indicates that most, if not all are involved in telephone traffic. Now that more providers are using VoIP those "private connections" are more suitable for telephone traffic as they are more direct than sending the traffic to the internet. ^The latency involved , and unknown variables of the internet (via other connections) are less desirable, so naturally those ISPS (really meaning telcos) are filling those private connections to full capacity with telephone calls, and leaving little or no capacity for real dedicated internet peering.

I think a good possible solution is that some neutral organization needs to be created and ANY Licensed internet provider should be REQUIRED to interconnect through this independent third party in a major city such as Guadalajara or Mexico DF. Monterrey is too far to the north for most users in Mexico in my opinion. These mandatory internet connections should NOT BE USED FOR INTRA-CARRIER TELEPHONE TRAFFIC! Instead, they should be pure internet peering, and may be used for intra-carrier telephone traffic, only when saturated less than 50% to BOTH carriers involved. For example, if the bestel connection was at 80% average and the Avantel was at 40% Avantel should not send traffic to Bestel through this new peering route. If BOTH however were at 30% , then they may saturate it with internet and telephone traffic up to 70% however giving priority to INTERNET traffic, and use their own direct interconnections for telephone peering.

The example of these "peering" connections, is a perfect example of the types of conflicts of interests that hold Mexico back , and are ridden with the anti-competitive attitudes. This backward thinking should not hold back the evolution of the internet in Mexico and we should take steps to ensure that internet growth and performance in Mexico is more controlled. To do this the assistance of COFETEL and/or SCT will be necessary to make new requirements to ensure proper growth of the internet IN MEXICO as internet demand increases IN MEXICO. AT the same time, this new independent organization should also begin to interconnect internationally where necessary, specifically making more direct international connections that do not rely on sending traffic destined to Argentina via the USA. With this new philosophy we can give Mexico its own internet backbone, and Mexico can begin to lead the way in offering internet solutions such as hosting FROM MEXICO for all of Latin America, as well as serve as a robust gateway for traffic destined for the USA. Mexico makes an appropriate "internet gateway" to the USA from the rest of Latin America for it's physical proximity to the USA.

This all goes along with another one of my beliefs : WE AS MEXICANS, should not look to go where life is better, but to make MEXICO a better place to live!

________________________________________________________________________________
UPDATE February 1, 2009

After making this post and ranting about these problems with Protel, LACNIC, Telecable, and many others this page as received visits from many of those organizations, and I am happy to report that the situation has improved. By my most recent tests on the Telecable Puerto Vallarta / Telecable Guadalajara connection show an average of about 150ms. Previously it was twice that! I can say however I have not performed a single traceroute that showed domestic peering to date. I have seen Mexican providers peering, but those connections appear to be in the USA, which is not "Mexico Peering" .

I also want to point out that a part of this Telecable issue stems from the fact that they use one provider in Guadalajara and another in Puerto Vallarta and have none of their own infrastructure between those two cities, to keep data from Telecable to Telecable on their own network. Instead they route it to the respective providers in each city, who route it to the USA and back to Mexico again. EVERY licensed provider that operates in multiple cities should be required to have their own infrastructure for data from their network to their network, or they are only contributing to the problem.

VoLAN and WiFi Can create some exciting possibilities

Recently I had the opportunity to devise a sysyem for VoLAN (Voice over LAN) to offer a very unique solution.

The details of the project can be found at:
http://www.teknogeekz.com/RemoteDoorWifiSIP.htm , however I have posted a basic diagram below.


The project employed a unique device from Cyberdata which is a doorbell intercom. The wireless router shown is an over-simplification of the extensive Wireless Network that was already on site. Clearly the applications for SIP are growing when we begin to see devices available that have such limited, although useful applications such as the CyberData Intercom. What impressed me more however was the QuickPhones WiFI Handset , specifically it's Peer to Peer mode.

Part of the reason why this was such a good solution was the existing WiFi infrastructure that gave us better coverage than any long range cordless phone would have.

Since these devices were not relying on a server, we used P2P mode. The QuickPhones offers a P2P mode that allows IP address dialing via it's Phone book feature. This allowed us to set up multiple destinations instead of a "hotline" from the WiFi phone. This gave us the unexpected but much appreciated possibility of having more than one destination accessible from the WiFi handset. With a system like this one can easily establish intercom and possible PBX like functionality with no server, even with the functionality of PSTN lines via a device like an SPA 3102.

In the coming months I hope to have more time to explore such possibilities, and if any readers have any comments on the P2P functionality of the Quickphones , I would like to hear comments.