Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.
View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 | 3 
2445 posts

Uber Geek
+1 received by user: 146


  Reply # 2107120 13-Oct-2018 08:20
Send private message quote this post

If you use syncthing in NZ, the local public (based in auckland, peered at akl-ix and others) syncthing relay no longer allows spark IPs due to the lack of peering. (They're dropped at the firewall). This is because the relay was starting to push a lot of traffic via non-IX peering. (That is, via paid transit) (Mostly to spark customers).

If this affects you, complain to spark about their lack of open/settlement free peering. :)

2016 posts

Uber Geek
+1 received by user: 772

Trusted

  Reply # 2107121 13-Oct-2018 08:27
2 people support this post
Send private message quote this post

kyhwana2: If you use syncthing in NZ, the local public (based in auckland, peered at akl-ix and others) syncthing relay no longer allows spark IPs due to the lack of peering. (They're dropped at the firewall). This is because the relay was starting to push a lot of traffic via non-IX peering. (That is, via paid transit) (Mostly to spark customers).

If this affects you, complain to spark about their lack of open/settlement free peering. :)

 

I love Syncthing, but this must affect what, 6 people? :)


2443 posts

Uber Geek
+1 received by user: 838

Trusted
Lifetime subscriber

  Reply # 2107123 13-Oct-2018 08:35
One person supports this post
Send private message quote this post

muppet:

 

freitasm:

 

Time to access/download resources - there's a bit of difference between AKL and Narita in terms of the distance bits have to travel...

 

 

Right, but it doesn't present an actual problem, aside from longer RTT's and slightly longer page load time.  Which for a HTTP2 page is unlikely to be noticed by most users, it's not exactly taking seconds to load (is it?)

 

Don't get me wrong, I agree the lack of local in-country traffic routing seems silly.  Back when I worked at one of the large telco's (not Spark) and we (network engineering) were told this de-peering had to take place and that we had to turn off the APE peers, we argued vehemently against it.  The senior people asked us "But what will actually break?" and we had to, begrudgingly, admit that nothing would break, some traffic might route a slightly longer way etc.  (We were also told if we didn't do it and kept moaning about, we'd be shown the door, so we turned it down as instructed)

 

Anyway, I don't think it's a problem.  Slightly slower RTT, sure.

 

Finally, there's always two sides to the peering story.  I'm not saying Spark aren't the "bad guys" here, but you also don't know for sure that Spark are holding out signing some contract because it exposes them in some way that the other ISPs have just rolled over and signed.  [That is meant only as an example, not based in any factual information at all!!]

 

 

I agree with much of what was said above, knowing how some of the inner working worked back when I was at Spark there were all sorts of issues with smaller ISPs taking the p..s that has lead to the situation today.

 

The main issue I see is more links with smaller players means more BGP import and export filters to manage and operational cost overhead with managing additional capacity links and ensuring that no one fat-fingers a routes.

 

The Spark core is incredibly simple and designed to be that way as shifting 8+PB a day and having a peak of over 500GBit/s back when I was there. More complexity = more cost = more operational management = harder to get changes deployed into production as everything had to be tested.

 

This when costs are continuing to go down in regards to monthly plan charges vs the cost of delivering a network where capacity doubles every year.

 

raytaylor: I am pretty sure that you can buy spark peering in different cities, and buy a backhaul product to those cities.
Spark basically know they have a high number of customers and if you want your mutual customers to have a better experience with your online service, you need to pay spark to deliver the traffic from a closer source.

Spark don't understand who their customer is.
However rugby world cup may change the dynamics of how spark peers... I still have hope.

Jessie from @fullflavor has some experience with getting to spark customers via Australia

 

The RWC content will all be delivered from Akamai CDN nodes installed within the ISPs network so it will never leave the network so have no material impact on peering. I think the control serves are hosted in AWS but that is just for authorising the streams and is a tiny amount of traffic vs the actual stream. What I can suspect will happen is smaller ISPs who don't have Akamai peering will struggle, and other ISPs who have under invested in their own Akamai CDN nodes will also struggle. That to me should be a far larger concern for Spark as they have no control over Vodafone or 2D etc on how much investment they put into installing more Akamai CDNs to cover the anticipated load. That being said I would bet coming closer to the date there will be plenty of ad's from Spark "Sparks network is scaled to handle the load for RWC but your current ISP isn't, come join us and get all these free things.." 

 

While I personally don't agree with not peering, I know it will add a whole lot of extra complexity onto engineers that are already busy enough keeping up with current changes.








BDFL - Memuneh
61479 posts

Uber Geek
+1 received by user: 12205

Administrator
Trusted
Geekzone
Lifetime subscriber

  Reply # 2112811 23-Oct-2018 15:32
Send private message quote this post

Unrelated but related... Cloudflare peering portal: option 3 would work for Spark if they don't want to peer directly:

 

 

Scenario 3:  Hosting a Node

 

There are scenarios where neither PNI nor IxP peering is feasible, such as when Cloudflare and our potential partners are not present in the same physical location. In these cases, our partner can request to host Cloudflare equipment in their own data center racks. Once commissioned, the equipment effectively operates as if it were a Cloudflare data center (PoP). The cache will populate and all of our performance and reliability services will execute right there, close to our peering partner's customer.

 





Meow
8004 posts

Uber Geek
+1 received by user: 4003

Moderator
Trusted
Lifetime subscriber

  Reply # 2112818 23-Oct-2018 16:13
One person supports this post
Send private message quote this post

freitasm:

 

Unrelated but related... Cloudflare peering portal: option 3 would work for Spark if they don't want to peer directly:

 

 

Scenario 3:  Hosting a Node

 

There are scenarios where neither PNI nor IxP peering is feasible, such as when Cloudflare and our potential partners are not present in the same physical location. In these cases, our partner can request to host Cloudflare equipment in their own data center racks. Once commissioned, the equipment effectively operates as if it were a Cloudflare data center (PoP). The cache will populate and all of our performance and reliability services will execute right there, close to our peering partner's customer.

 

 

 

This is the problems - the reason is politics, not that they are not present. They could peer if they wanted to but instead they simply don't.

 

Which is why my traffic to Cloudflare currently is going via "Tokyo, Japan (NRT)" on a corporate connection via Spark where my home connection is taking a more direct route just 5 hops away served by the APE.

 

Not to mention it actually "feels" slow to browse Geekzone on a Spark connection no, that's no placebo, it is fact looking at the waterfall.

 

Just excellent. It is nice that traffic takes a scenic route over to Japan and back to NZ where Geekzone is hosted.





I fix stuff!
1701 posts

Uber Geek
+1 received by user: 374

Trusted
Vocus
Subscriber

  Reply # 2112882 23-Oct-2018 20:06
6 people support this post
Send private message quote this post

BarTender:

 

I agree with much of what was said above, knowing how some of the inner working worked back when I was at Spark there were all sorts of issues with smaller ISPs taking the p..s that has lead to the situation today.

 

The main issue I see is more links with smaller players means more BGP import and export filters to manage and operational cost overhead with managing additional capacity links and ensuring that no one fat-fingers a routes.

 

The Spark core is incredibly simple and designed to be that way as shifting 8+PB a day and having a peak of over 500GBit/s back when I was there. More complexity = more cost = more operational management = harder to get changes deployed into production as everything had to be tested.

 

This when costs are continuing to go down in regards to monthly plan charges vs the cost of delivering a network where capacity doubles every year.

 

 

As a large network operator (who has worked for pretty much everyone ISP in NZ now), I find that quite hard to believe. Most Large operators use BGP communities these days to manage their export rules and input rules consist of "stop anything stupid from happening". They are very low touch.

 

The main reason comes down to commercials. Spark don't want to give up the hundred of thousands dollars or so they get from ISP's and business who have to pay for domestic traffic to reach spark with low latency. This is why spark always say "No business case to peer" and this is why. They risk losing a lot of revenue.

 

Its the same thing over in Australia with Telstra and Optus and several Tier1 providers around the world. (Level3 etc).

 

I don't agree with it, but I understand why.

 

 


27123 posts

Uber Geek
+1 received by user: 6565

Moderator
Trusted
Biddle Corp
Lifetime subscriber

  Reply # 2113028 24-Oct-2018 07:20
2 people support this post
Send private message quote this post

Spark's lack of peering will ultimately be one of the downfalls of their RWC coverage and push into the TV space. I see a change of policy before the RWC - not because Spark want to, but because they simply have no other option.

 

I'm pretty confident Spark can built a streaming platform to handle what is required, and that their own users will have a great experience. That doesn't mean every other RSP will, especially those having to interconnect in Australia.

 

The average end user doesn't care about politics and $$ - they just want their Internet to work, and when it doesn't work during the RWC there will be riots in the street with pitchforks.

 

 

 

 


3738 posts

Uber Geek
+1 received by user: 2268

Trusted
Spark NZ

  Reply # 2113055 24-Oct-2018 08:47
4 people support this post
Send private message quote this post

I strongly suspect that investment in CDNs will be a much bigger predictor of Rugby World Cup success than significant changes to our peering policies.

I've seen the rwc argument a couple of times on here now being put forward by people without any knowledge of how the event will be provisioned to spark and other customers and thought it was time to correct this misunderstanding.

Cheers N

I fix stuff!
1701 posts

Uber Geek
+1 received by user: 374

Trusted
Vocus
Subscriber

  Reply # 2113125 24-Oct-2018 09:49
Send private message quote this post

Slightly offtopic

 

but AU are going though the same thing and the ACCC have deemed the Gang of 3 of not being anti-competitive with their peering stance aslong as they make public the criteria required for peering.

 

(Worth noting that Telstra is now peering with Vocus).

 

https://www.computerworld.com.au/article/648621/no-need-regulate-isp-peering-arrangements-accc-says/

 

 


Meow
8004 posts

Uber Geek
+1 received by user: 4003

Moderator
Trusted
Lifetime subscriber

  Reply # 2116417 29-Oct-2018 17:18
One person supports this post
Send private message quote this post

Hmm - I've been annoyed for quite some time on the status of Spark peering but this is another reason where it can negatively affect the customer and an good example:

 

I personally run Apache Guacamole inside a Docker container however as a layer of security this is run via Cloudflare. This is also hosted in NZ (on my home server). On most ISP's it is totally fine - 14ms latency, SSH / RDP / VNC works totally fine however on Spark this goes via Tokyo at a 500ms round trip which makes SSH quite slow and RDP / VNC unusable. It was actually quicker to use this via my mobile, tethering (2degrees - 40ms RTT) than via the Spark Fibre connection.

 

Cloudflare isn't just for websites - actual services can be hosted behind it also. I think it is somewhat important for ISP's to peer to such things given more and more websites, app servers and also API's are sitting behind Cloudflare these days.

 

So, in response to the following:

 

muppet:

 

freitasm: Time to access/download resources - there's a bit of difference between AKL and Narita in terms of the distance bits have to travel...

 

Right, but it doesn't present an actual problem, aside from longer RTT's and slightly longer page load time.  Which for a HTTP2 page is unlikely to be noticed by most users, it's not exactly taking seconds to load (is it?)

 

Don't get me wrong, I agree the lack of local in-country traffic routing seems silly.  Back when I worked at one of the large telco's (not Spark) and we (network engineering) were told this de-peering had to take place and that we had to turn off the APE peers, we argued vehemently against it.  The senior people asked us "But what will actually break?" and we had to, begrudgingly, admit that nothing would break, some traffic might route a slightly longer way etc.  (We were also told if we didn't do it and kept moaning about, we'd be shown the door, so we turned it down as instructed)

 

Anyway, I don't think it's a problem.  Slightly slower RTT, sure.

 

Finally, there's always two sides to the peering story.  I'm not saying Spark aren't the "bad guys" here, but you also don't know for sure that Spark are holding out signing some contract because it exposes them in some way that the other ISPs have just rolled over and signed.  [That is meant only as an example, not based in any factual information at all!!]

 

I give you the following:

 

Yes, it does affect more than just websites. It can affect apps that work behind Cloudflare (API's, Websockets (in my case) and other things). Cloudflare isn't just for websites and moreso since they're expanding into other areas now. But, peering will also assist services that go via Spark (eg - a particular large bank or 2 where some traffic has to go via Australia now to reach their apps).





1267 posts

Uber Geek
+1 received by user: 291


  Reply # 2116427 29-Oct-2018 17:29
Send private message quote this post

The connection on I'm currently is on an ISP which supposedly peer at the Auckland exchanges and I'm also being sent to Tokyo for most of Cloudflare for the past... nearly a month?

 

 

Have to agree can definitely notice the delays.

1 | 2 | 3 
View this topic in a long page with up to 500 replies per page Create new topic

Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.