Zen say no demand for ipv6 - do you agree?

Zen have recently said that they will not be introducing ipv6 as there is no demand.

Is there any interest in ipv6, if not for production, then at least for testing?

Comments welcome

Plus 1. Worked well for me in the past on a Fritz!Box 7390. Seamless on Apple products which for dual IP sites will normally select the faster loading site. Don't ask me how Apple do it?

Do want.

Had it on Entanet for at least 5 years. Many gigs a month of v6. Since moving to Zen I've had to use a tunnel for it. I'd love to have it natively again!

I also think it's a little shortsighted that they've not even got a roadmap for it when so many other ISP's have either got it implemented by default (AAISP, IDNet etc) or are well on the way to having it available to all (Plusnet, BT, Sky, Entanet and many others)

I have a friend who outright disregarded Zen due to lack of a roadmap. I'm sure he isn't the only one who has stayed away because of it either.

Edited by summat (Fri 30-May-14 18:21:27)

It's a shame to see an otherwise competent ISP burying their head in the sand like this.

I've consciously not purchased a non IPv6 enabled service since 2008, which has ruled Zen out every time.

Odd thing to say but perhaps read into it more. Is Zen just saying there is no demand meaning that the average customers doesn't know or care?

There is probably only 3-5% that actually know what IPv6 is and why it will be needed in the future. I doubt there are any IPv6 only sites/services so at the moment there is no need for residential ISP's to provide IPv6 as standard.

Have a IPv6 tunnel at work but I know of one web site I use that doesn't load if I have IPv6 enabled on my PC so I disabled it.

This is extremely disappointing. I was seriously considering Zen for my imminent migration to FTTC.

My current ISP it would appear also has no plans. When asked, I have had responses like:

"We are 100% compliant with IPv6 but have no plans to implement it just yet.'

and:

"We appreciate your concerns regarding IPv6 but would like to re-assure you that we as an ISP have plenty of IPv4 addresses remaining."

I registered to be on their trial list 15 months ago but have yet to hear anything. I can only assume that they're not even trialling it yet.

This attitude is extremely shortsighted. My ISP may have plenty of IPv4 addresses however the problems start when I need to connect to a server where they don't.

Thankfully I currently have a tunnel to he.net with a /48 (1.2 septillion addresses, slightly more than you could shake a stick at)!

I know IPV6 is coming, but the issue is it has been coming since the late 1990's, but still not here.
Are there any valuable sites which are IPV6 only. When some of these sites announce cut off dates for IPV4 , this is then the IPV6 roll out will escalate.

In reply to a post by AndrewW:

I know IPV6 is coming, but the issue is it has been coming since the late 1990's, but still not here.

Yes, but things are different than the 90s, for starters IANA have reached IPv4 exhaustion and AFAIK even Comcast - one of the largest, and most hated, ISPs in the US is rolling out IPv6 across its whole broadband network(may even have finished?). Why shouldn't customers have the option of IPv6? Soon we'll have the Internet of things and that'll add more impetus for addresses. If small ISPs, like Aquiss for example, can pull their finger out then how about Zen?

HI Spud2003 , Haven't we discussed this before, was it you looking for a trial of IPV6 ??? apologies if i have not remembered correctly.

I agree that IPV6 is coming, but its glacial movement (very slowly).
In my view there is nothing that is driving this.
let's look at the internet of things.

CCTV , Fridges (some of which spam email look it up is quite funny it it was not so serious), washing machines., bins, tablets, TVs, TV boxes sky for example. All of these (except CCTV) do not require inbound connections. If their are reporting its typically to a web site, which may contact the user by various means. There there is the wearable tech, most this interfaces via Bluetooth to mobile device, Again, no need for additional IP addresses. The limiting factor may be the default class C subnet common on most routers, i.e 192.168.0.1, but there are other options to enlarge this.

Until a number of large sites make it clear of their intention to disable IPV4 usage then there will be no need for IPV6.
When that time happens then the migration will be swift, and some ISPs who do not have a good plan in place will be in trouble. I suspect Zen would have done a lot of work in the back ground , and are purchasing IPV6 compliant devices, but have chosen to put on the the deployed project.

I speculate a very simple reason why - Zen have core pieces network/broadband aggregation equipment that does not support IPv6.

In reply to a post by Spud2003:

Yes, but things are different than the 90s, for starters IANA have reached IPv4 exhaustion and AFAIK even Comcast - one of the largest, and most hated, ISPs in the US is rolling out IPv6 across its whole broadband network(may even have finished?). Why shouldn't customers have the option of IPv6? Soon we'll have the Internet of things and that'll add more impetus for addresses. If small ISPs, like Aquiss for example, can pull their finger out then how about Zen?

Comcast didn't deploy IPv6 because customers wanted it, they deployed it because they ran out of RFC1918 space for the cable CPE on their network.

In reply to a post by AndrewW:

Until a number of large sites make it clear of their intention to disable IPV4 usage then there will be no need for IPV6.
When that time happens then the migration will be swift, and some ISPs who do not have a good plan in place will be in trouble. I suspect Zen would have done a lot of work in the back ground , and are purchasing IPV6 compliant devices, but have chosen to put on the the deployed project.

Why would they do that? They already have IPv4 address space so will continue to use it until IPv4 is phased out. They're not going to cut their noses off!

The problems start when new sites or users can only get IPv6 addresses.

Think you just answered your own question. There is no reason to go in ipv6.
Once the majority of new users only use ipv6, then the ipv4 services will be dropped. Just like Zen are doing with the usenet service. Not enough users, so they are killing it.

In reply to a post by AndrewW:

Think you just answered your own question. There is no reason to go in ipv6.
Once the majority of new users only use ipv6, then the ipv4 services will be dropped. Just like Zen are doing with the usenet service. Not enough users, so they are killing it.

On the contrary. There is an extremely good reason to go dual-stack, there is no reason to migrate solely to IPv6 at the moment. There will always be a long transition period.

It's called being prepared. You musn't consider just the users, you have to consider the sites and services as well. What happens when you need to access that IPv6-only site or service? You can't, just because your ISP isn't prepared.

Usenet is not a fundamental requirement for use of the Internet, IP addresses are - apples and pears.

In reply to a post by Ignitionnet:

Comcast didn't deploy IPv6 because customers wanted it, they deployed it because they ran out of RFC1918 space for the cable CPE on their network.

Are you referring to the "RIPE 54"(?) document? It does also say they were allocated a large IPv4 block(which I assume wasn't enough) and also -

High Speed Internet
� customer service remains IPv4 for now
� May add IPv6 service in later phase

So there were no hard plans to give Internet customers IPv6 back in 2007(?), despite using IPv6 elsewhere, it was a matter of choice - it appears they didn't have to do it if they didn't want to.

Zeb99 agreed, if you read my earlier posts that what i said. However running dual stacks costs and the amount of time this is done for is will need to be limited, hence my comment relating to the Usenet server.

No one has mentioned one large and popular site which is IPV6 ONLY or planning to run that way.

Also i have not heard of any ISP's only offering IPV6 only as they cant get IPV4 addresses.

NAT and proxies have been the technologies which helped to limit the growth of ipv6

NAT and proxies have been the technologies which helped to limit the growth of ipv6

Not entirely accurate. They are technologies, or rather "hacks", that have been developed to address the short-falls of IPv4, thus diluting the demand for IPv6.

I mostly agree with Zen's stance on the topic, as much as I detest it. The reality is IPv6 will not be used until it really needs to be used. So until the day arrives when a customer needs an 8 IP address netblock, but can't get that because they (Zen) have run out of IPv4 address space, there will be no drive at all to use IPv6. Should that day arrive and they don't have IPv6 ready to go, that will be their downfall; as zeb99 said, "it's called being prepared".

Also, the use of IPv4/6 tunnels is no big deal. It's yet another hack, just like NAT and proxies are. Provided the customer's end point has at least one uniquely routable IPv4 address, that's enough to quickly provision a /48 IPv6 network and hook it up to the rest of the IPv6 network with minimal fuss and technological barriers.

As zeb99 has also said, "there will always be a long transition period". The Internet is an organic network, from inception to present day. It will always evolve with its users encountering problems and inventing solutions to those problems over extended periods of time. NAT and proxies have served us well leading out of the 20th and into the 21st century, but these technologies will diminish as newer/better ones are preferred, ie. IPv6, and all that is possible without having NAT in the way.

Edited by deleted (Mon 02-Jun-14 14:12:14)

In reply to a post by mixt:

The reality is IPv6 will not be used until it really needs to be used. So until the day arrives when a customer needs an 8 IP address netblock, but can't get that because they (Zen) have run out of IPv4 address space, there will be no drive at all to use IPv6. Should that day arrive and they don't have IPv6 ready to go, that will be their downfall; as zeb99 said, "it's called being prepared".

As an IT Manager I'd like to have IPv6 on my Zen FTTC to play with and gain experience. I suspect that nothing will happen and then suddenly a new service people want will be IPv6 only and then things will change very quickly. What that might be and when it might happen I have no idea!

I'm not referring to that, however as Comcast were deploying IPv6 to the edge of the network anyway there was virtually no additional work required to deploy to customer devices too.

Nothing to do with a shortage of public addresses at all but given they were deploying dual-stack for the CPE it made sense to supply to customers too as part of the same project and be done with it.

In reply to a post by Ignitionnet:

Nothing to do with a shortage of public addresses at all but given they were deploying dual-stack for the CPE it made sense to supply to customers too as part of the same project and be done with it.

You are tying IPv6 rollout for devices to rollout for Internet customers, for which they had no definite plans at the start. According to the doc the devices were being dealt with in 2006/2007 - press reports suggest Comcast IPv6 rollout for Internet users was started around 2012. That suggests that the link between the two, while there, is not strong(five years difference). It would probably have been easier to be lazy and just leave Internet users with IPv4 connectivity alone especially since Comcast are considered one of the worst companies in America for customer satisfaction, which is my point.

In reply to a post by Spud2003:

In reply to a post by Ignitionnet:

Nothing to do with a shortage of public addresses at all but given they were deploying dual-stack for the CPE it made sense to supply to customers too as part of the same project and be done with it.

You are tying IPv6 rollout for devices to rollout for Internet customers, for which they had no definite plans at the start. According to the doc the devices were being dealt with in 2006/2007 - press reports suggest Comcast IPv6 rollout for Internet users was started around 2012. That suggests that the link between the two, while there, is not strong(five years difference). It would probably have been easier to be lazy and just leave Internet users with IPv4 connectivity alone especially since Comcast are considered one of the worst companies in America for customer satisfaction, which is my point.

Rolling out IPv6 to CPE in 2006/7, when Comcast had no support for IPv6 in its CMTS, as they were DOCSIS 1.1/2.0 and IPv6 over DOCSIS 2 was 5-6 years away, not to mention that none of their vendors supported it, would've been impressive indeed.

Comcast began IPv6 trials to both CPE and end users via 6RD then dual-stack in 2010. They were waiting on CMTS software, which was delivered by Arris and Cisco in 2010 and Motorola in 2011.

The deployments were if not precisely pretty much simultaneous.

terrible attitude for an isp, even BT are going to introduce it and they are a mass market isp.

If you dont like the policy I can only suggest walk with your money away from zen, if they are saying they will only introduce it when they see a financial reason to, then the only motivation for them is people to leave.

Edited by Chrysalis (Tue 03-Jun-14 16:49:47)

cat and mouse situation, no big site is going to go ipv6 only until broadband isps first mass rollout the protocol.

Although it wouldnt surprise me if google were to do it one day to "force" things along if they get frustrated, but even they arent immune to cutting of masses of users to make a point.

Totally agree, and I think it will go along the lines of 24 months notice.

I Agree that there is no drive that would force the use of IPV6.
I work for a large hosting provider and we have no more then a very basic plan and no time scales for IPV6.

I am in two minds about Zen doing this though, we are with them and are happy to pay more for the quality of service we get. We expect more from them then lesser ISP's.
I would not want them to rush the deployment of IPV6 or prioritise it over more pressing updates I would be though disappointed if they did not at least have it on there roadmap and have some sensible time scale.

More and more if there core networking kit will be IPV6 compatible as the old stuff goes EOL assuming they are replacing EOL kit (some times its cheaper to do so some times you are happy to risk it!). so they should have less and less excuses for not implementing it.

The argument that we must have IPV6 as we are running out of IPV4 does not hold a lot of water though as we would all want an IPV4 address too else we would end up behind a proxy or nat/pat pool for connections to IPV4 address.


Maybe an intermediary steep would be for Zen to provide an IPV6 endpoint / broker service for those that want it.

dual stacking is the intermediate step.

for what its worth I think website owners should be dual stacking also, a few I work for arent interested. But we wont be seeing any large scale ipv6 only sites with current state of affairs.

If you've got Flash you can see what percentage of Google visitors (ie people doing web searches) came to them over IPv6 here

http://www.google.com/intl/en/ipv6/statistics.html

and there's also a tab showing the deployment rate in different countries, the UK is very low compared to the US, because we have no major ISPs (sorry A&A, your service is great and I'd glad of it, but you're no TalkTalk) offering IPv6 in this country. So most IPv6 users in the UK will be on university networks I'd guess since JANET - unlike the home ISPs and most businesses - rolled out IPv6 years ago on its core networks.

So, with 3.5% global penetration, and nearly every last one of that 3.5% being dual stack, there is no reason for anyone to have an IPv6-only site today. For a large company like Google or Facebook it makes sense to have a IPv6 version of your site (and they do) because you have dozens of servers, so even 1% of users are worth separating out. But if you run a web site about your local gardening society, why would you lift a finger to enable IPv6? And in some cases it is just a matter of lifting a finger, if you've hosted sites with Dreamhost for example IPv6 is free, but you've got to click one button per web site to enable it.

No UK ISP will ever face the problem Comcast ran into, we're too small a country. So the impetus for ISPs to enable dual stack will most likely have to come from Ofcom, or else we'll just have to wait until things completely fall apart and they've no choice. In the latter case expect to see CGNAT rolled out in a big way first because it's "what customers demand" (aka the cheapest somewhat working option).

Edited by deleted (Wed 04-Jun-14 17:26:48)

Where exactly did they say this?

Try here

In reply to a post by techguy:

Where exactly did they say this?

Nowhere.

In context; I said in the near-term we wouldn't be introducing IPv6 on our Broadband services. I also said the demand isn't there not that there was no demand. They are very different statements; the statement I made was about a lack of sufficient demand. Perhaps I could have been clearer, but in the context I expected readers to understand I was talking volume, not an absolute. The question itself implied demand, so to say there was none would be blatantly false. It's also not the only time the question has been asked, so clearly there is some demand. Demand, in the context I answered, i.e.near-term would be a big factor in any decision, as the situation otherwise doesn't justify a high priority right now.

That picture will change (with need/adoption becoming more important than pure customer demand in the future), and we regularly revisit the subject and priority based on the current and predicted situation to ensure we're ready in time. When we have concrete news we'll let you know - but that isn't now.

We also continue to make decisions on our network and systems development based on the future need for IPv6 (we also peer with other providers via IPv6), so it's not a case of doing nothing about it.

kind regards,
Phil

SkyFire, had you considered that maybe "the demand isn't there" simply because potential customers that *need* v6 now are just skipping over Zen and using an ISP who can already provide it?

Extremely good point.

I have to say, it is my opinion that Zen are being very blas� and unforthcoming regarding the issue. near-term is also clearly a non-committal get-out clause, and I have to personally interpret this is as a simple "no, we have no plans for IPv6, and it's not a top priority for us".

Basically, on every forum post I've seen regarding Zen and IPv6, spanning the last decade, Zen are unable to give a concrete straight answer on the subject. It is always of a non-committal / side-stepping tone, much as like what Phil has given.

They way I see it is, as an ISP, you either:

1) Already support it and can provision it to customers (Andrews and Arnold are already there with this).

2) You freely disclose that you are in the process of provisioning it across your network, and have some ETA on when that's going to be complete, and are able to tentatively introduce that to interested customers for testing (PlusNet are at this point).

3) You haven't bothered and have no immediate interest in providing it as part of your service.

Phil's response clearly fits in with 3 above. If they were in the process of doing anything, 2 would be more suited and there would be some kind of ETA (even if that's a 2-3 year ETA).

I suggest Zen begin to try and do some market research here for every customer they see migrating away, in an attempt to identify why that customer left, making "lack of IPv6" an option. That's going to tell them if there is indeed a demand for IPv6. For as sthen has said, not being able to provide the service provides no way of testing if there is a demand for it, as potential new customers simply won't bother with Zen and choose alternative providers who can provision IPv6 off the bat (and Zen will be none the wiser of this decision by that potential customer).

I suppose, ultimately, this is about "confidence". Personally, I have no confidence what so ever that Zen are going to introduce IPv6 or indeed have any intention to do so, in the "near-term" (what ever that means). But that's fine, I accept it, and deal with it appropriately (via a tunnel). But they should be aware that the market is always changing, and customer requirements doubly so, so if they don't keep an eye on things, they'll be playing catch-up in a competitive market before they even realise they've slipped behind everyone else.

Edited by deleted (Tue 10-Jun-14 12:10:43)

Hi,

We do capture information on why people leave. IPv6 doesn't figure prominently in that. Overall market adoption is a factor in demand (and also need) - not just demand from existing customers. These discussions also play their part too, of course.

Near-term (or short-term) I'd describe as three to six months. That doesn't mean in six months we'll definitely release something for Broadband users, by the way, but that it isn't currently something we're actively working to implement on Broadband in that timescale. To re-iterate, we review the situation regularly, to make sure we'll have something at an appropriate time based on the circumstances. We are in technology - the nature of the business is change! We know what needs to be done, it's just a case of choosing the right time - in the context of everything else we're doing (e.g. our biggest infrastructure investments in Zen's lifetime were made in the past year) - to do it. As has been mentioned in previous threads on this topic (I think - could be they were on our own forums), we are already peering via IPv6; it's not a case of having done nothing. It's just what has been done isn't yet visible to Broadband users.

regards,
Phil.

To be honest, consumer CPE still lag some way, both in support for working ipv6 and the firewall configuration side of things that becomes more important.

Thank you Phil for providing a "straight down the line" answer as to what is really going on within Zen in terms of IPv6 deployment. I feel I had to push you in that regard to get some kind of discrete answer, and I'm glad I did. I also feel you may have slightly slipped from category 3 in my previous post to 2 (although not fully), which is only a good thing.

As you have said, this is of no direct benefit to end users (yet), but at least it brings some enlightenment to others who are wondering of Zen's IPv6 plans longer term, and how your current advancements fit into making IPv6 available to customers. As a current (and previous) customer, it would be nice to see native IPv6 available from Zen in the next 1-2 years, but I appreciate as a business you may have more pressing immediate priorities to address to make this possible.

Edited by deleted (Tue 10-Jun-14 14:16:58)

demand is always going to register low if you relying on questionaires sent out to leaving customers or perhaps what potentional new customers ask sales for, one such reason will be that the majority of people wont even know what ipv6 is.

you seem to have a lot of confidence tho that when this "demand" appears you will be able to deploy ipv6 quick enough to not be behind.

Me personally given the size of zen as an isp, I would give the bad rep you getting from this thread and others as justification alone to get on with some testing, I do wonder if plusnet staff read this section and jumped in to get some good free brownie points as its amusing they started their trial whilst this discussion was ongoing. The cost of testing ipv6 I would have thought would be very small so something with little to no cost shouldnt need demand for a business decision but maybe your network equipment is very old and expensive to replace who knows.

Edited by Chrysalis (Tue 10-Jun-14 14:45:36)

In reply to a post by Chrysalis:

demand is always going to register low if you relying on questionaires sent out to leaving customers or perhaps what potentional new customers ask sales for, one such reason will be that the majority of people wont even know what ipv6 is.

Analysing data like that on a pure numbers scale would be foolish, I agree. Proportion (where volume exists so the data is statistically significant) and trends (in our data/the wider market) are far more relevant than the simple number of responses or queries.

In the case of those who don't know what IPv6 is - yes, that wouldn't register as demand; they just want their service to work and to be able to access the Internet. That's where need overtakes demand and where asking customers what they want isn't appropriate - we're best-placed to know what will continue to deliver the core of what those customers who don't care how the underlying service works need.

In reply to a post by Chrysalis:

you seem to have a lot of confidence tho that when this "demand" appears you will be able to deploy ipv6 quick enough to not be behind.

As I've said, demand is a near/short-term consideration. Growth and need are the bigger factor over time; i.e. being prepared before it's a problem. I don't believe there are any worries in that regard.

In reply to a post by Chrysalis:

Me personally given the size of zen as an isp, I would give the bad rep you getting from this thread and others as justification alone to get on with some testing, I do wonder if plusnet staff read this section and jumped in to get some good free brownie points as its amusing they started their trial whilst this discussion was ongoing. The cost of testing ipv6 I would have thought would be very small so something with little to no cost shouldnt need demand for a business decision but maybe your network equipment is very old and expensive to replace who knows.

I'm not convinced this thread represents us getting a "bad rep". The subject is a little misleading, of course, but I think the overall discussion has been frank and useful and hopefully in the eyes of some readers it's clear we're not ignoring the issue; but nor are we rushing in.

As far as cost; it's all relative. IPv6 does not exist in isolation. If the time and effort are going to have greater impact, sooner, elsewhere (without impacting long-term needs) then that "elsewhere" will and does get priority. e.g. if we ran a trial it wouldn't be simply deploy to customers and job done; it then takes an ongoing resource costs to ensure it keeps working and we get the most out of that testing (if a fault occurs on a trial people tend to revert to none-trial services or workarounds, so minimising the useful data a trial delivers).

regards,
Phil.

In reply to a post by mixt:

Thank you Phil for providing a "straight down the line" answer as to what is really going on within Zen in terms of IPv6 deployment. I feel I had to push you in that regard to get some kind of discrete answer, and I'm glad I did. I also feel you may have slightly slipped from category 3 in my previous post to 2 (although not fully), which is only a good thing.

As you have said, this is of no direct benefit to end users (yet), but at least it brings some enlightenment to others who are wondering of Zen's IPv6 plans longer term, and how your current advancements fit into making IPv6 available to customers. As a current (and previous) customer, it would be nice to see native IPv6 available from Zen in the next 1-2 years, but I appreciate as a business you may have more pressing immediate priorities to address to make this possible.

You're welcome. It's a difficult one to talk about in isolation of what else we're working on, and the lack of an absolute ETA does complicate discussions, but I'm glad that hopefully the situation and reasons are clearer now.

ta,
Phil.

I'm with Zen happy with them and uses HE net for ipv6 tunnel some time some websites that uses IPv6 thinks I'm from US. and block the account if I try to log in on their ipv6 website. which is annoying.

statistic can be wrong even google will think we are from US (I could be wrong though)

I give time till October 2014 if nothing happens on Zen front I have to look else where, I really like AAISP but very expensive and complicated unit pricing for home use. aquiss probably my next bet.

I really like AAISP but very expensive and complicated unit pricing for home use. aquiss probably my next bet.

I went with A&A late last year and have been very happy with them - there isn't actually any unit pricing for the Home::1 tariff, just 100 Gb anytime chunks.

My office line was with Be, so I'm actually in the market for a new ISP there (the MAC arrived yesterday in fact, and we were enabled for FTTC two weeks ago). A&A are too expensive (no Home::1 for business), so Zen looked very appealing; I'd talked to someone there about switching from Be, and it sounded promising until I asked about IPv6 - and didn't even get a reply!

I'll probably go with IDNet for the FTTC+PSTN: IPv6 and 100 Gb should do. I'd prefer "unlimited" for easier budgeting, but not at the expense of losing IPv6.

I need around 200gb data usage per month, with A&A it will come to double what I pay for zen FTTC. I wouldnt mind paying £10 extra for ipv6 not £25

In reply to a post by din100:

I need around 200gb data usage per month, with A&A it will come to double what I pay for zen FTTC. I wouldnt mind paying £10 extra for ipv6 not £25

I make it £45 for A&A (Home::1 40/10 FTTC, 200 Gb/month option) versus £32.40 for Zen (Unlimited Fibre 1, broadband only). Breaking the 200Gb barrier would be a pain though.

My A&A contract runs until November, so I might well jump if anyone has a decent offering by that point. Maybe port my landline number to VoIP (which would cease the BT line, then I'd reinstate it on a fresh number as data-only).

This is what I have (unfortunately) had to do. I would have stayed with A&A, but they just couldn't deliver on price.

I was on their unit based tariff, averaging 3 units a month, but slipping beyond this. 3 units a month, with their line rental, came in at £45.90 per month for a 40/10 FTTC service. Averaging between 100-200Gb per month, their Home::1 package would not have helped me either - £47.00 per month for 100Gb/month, again on a 40/10 service including line rental, rising to £57.00 per month for 200Gb/month.

With Zen, it's £45.44 per month (including line rental) for an unlimited 80/20 service (I get 60/20). Only downside is no native IPv6, but I can live with that. So far, speeds seem consistent and I can't complain.

Have to hand it to A&A though. I slipped past 6 units into the red just before migrating to Zen, and was expecting to be charged for this, along with the short line rental period that the line remained with them past my 30 day notice period, before being moved to Zen. Due to "my good custom", they wrote this off after the migration to Zen completed and issued no further invoices. So I am glad to have left on good terms with A&A; I would return to them if they could match Zen on product and price.

let us know your experience with the Zen service after a few months. I am with SKY and for now its about the same service & costs but no static IP. For me it ok for now and not worth the bother to change..

It's yet to be a few months, but I can already see subtle differences in service between A&A and Zen.

Just before I left A&A (on a 40/10 service), speed tests were no longer maxing out on my connection. A&A BQM graphs (one second monitoring) showed, pretty much, no packet loss, even with the drop on speed tests. I suspect this was due to an influx of new customers joining A&A, and capacity issues their side, as Adrian posted a blog comment discussing the current issues they were having with BT in ordering another gateway (more bandwidth).

Now on Zen (60/20 service), the BQM graphs (see my signature) are showing subtle specs of red at the top indicating extremely minor packet loss from time to time. I did not see this at all with A&A.

This packet loss is not sufficient to be bothersome, but I guess it demonstrates the difference between how both ISPs manage their links. In order to offer an unlimited service, Zen simple contend the connection down to a minimum speed (in my case, around 40Mbps on a 60Mbps sync) during peak times. That's how they can offer an unlimited service. However, with A&A, they aim to never be the bottle neck, thus probably the reason I very rarely saw packet loss (Adrian Kennard is highly against any kind of packet loss, per his blog post). Of course, that is why A&A offer a metered service (which may not suit everyone) and charge accordingly. Use more, pay more. They can guarantee you a packet loss-less service because of this. But it seems Zen can't (not 100% completely anyway).

So that's my take on it. I'm still happy with Zen, and I had my reasons for moving here. But it still comes down to a clear case of you get what you pay for. I'm not prepared to pay anything more than what Zen charge for my broadband+line, so that's why I joined them - this packet loss doesn't bother me, others may not feel the same way. I'm pretty sure on Zen's Fibre Office product (double the price of Fibre 2, with a minimum speed of 60Mbps), packet loss would be pretty much non-existent.

Hope this helps with your decision on your next ISP.

I'm in need of a new ISP and now that Zen have reasonably priced fibre offerings i'm planning to rejoin the fold. But i've got to say that i am disappointed there's still been no progress on providing native IPv6 (exactly) 8 years after i originally asked.

I'll probably still be joining Zen because i need decent basic connectivity, and i know Zen's good for that. I'll continue using my HE tunnel and re-assess the situation in a year.

In reply to a post by mixt:

In order to offer an unlimited service, Zen simple contend the connection down to a minimum speed (in my case, around 40Mbps on a 60Mbps sync) during peak times. That's how they can offer an unlimited service.

Is this correct?

Is this correct?

Source: http://support.zen.co.uk/kb/KnowledgebaseArticle.asp...

EDIT: I'm presuming they use contention, as they do not traffic shape. If you can suggest yet another alternative method they may use, I'm all ears.

Edited by deleted (Tue 08-Jul-14 15:45:04)

In reply to a post by mixt:

Is this correct?

Source: http://support.zen.co.uk/kb/KnowledgebaseArticle.asp...

EDIT: I'm presuming they use contention, as they do not traffic shape. If you can suggest yet another alternative method they may use, I'm all ears.

That is actually what BT wholesale (their supplier) gaurantee. Any isp who uses them for backhaul will be the same. I'm unsure if BT Openreach have something similar for GEA.

As for contention, everything is contended on the Internet. What you care about is congestion. See here for the difference. http://aa.net.uk/kb-broadband-contention.html

As far as I'm aware Zen don't congest any of their links on purpose. That would definitely be noticeable to everyone.

Thanks for clearing that up then.

It would appear then that Zen have some congested links because since joining them, I have seen minor packet loss on my connection (see my BQM graph). When they have bounced the connection (and I connect to a different gateway), it seems to alleviate the problem but the issue does return after a while.

I never saw this issue with A&A.

In reply to a post by mixt:

It would appear then that Zen have some congested links because since joining them, I have seen minor packet loss on my connection (see my BQM graph).

This is jumping to a conclusion about where your fault is here. To explain a little about all that makes up your Internet connection.

[Your Router]<->[Your BT Modem]<->[Micro filter]<->[Copper Telephone Line]<->[DSLAM In green cab]<->[Fibre back to exchange]<->[BT Equipment in exchange]<->[Optional - Link to another exchange]<->[Optional - BT Equipment in exchange]<->[Connection to BT Wholesale Network]<->[BT Wholesale Network]<->[Connection to Zen Network]

All in, there are at least 9 (or maybe 11 if you are on a child exchange) components which could cause you packet loss. While I'm not saying the fault isn't down to Zen's network, you can't really be sure without getting them to investigate.

While you may not have experienced this 'problem' with A&A, how much is actually the same? You may have a different router, a different BT Modem. The route around BT's network to your ISP's interconnect is also likely different. Additionally, there is the path between thinkbroadbands BQM servers and your ISP's network. Again, these could be totally different.

Also, just because you are seeing increased latency and packet loss, it doesn't actually mean there is a problem. You could just be using your connection. Take a look at mine. http://www.thinkbroadband.com/ping/share/eac81d2a0f1...

You can see bad stuff happening between 6 and 8pm. That is my wife watching Netflix. You can then see some more bad stuff happening between 10pm and around midnight. Again that is Netflix. You then see some massive bad stuff going on at 3.30pm. That was a large file being downloaded. And finally between 7 and 8am there is more Netflix viewing (My wife watches a ridiculous amount of TV)

All throughout the day when there are things that I can't specifically identify the cause there is minor spikes in latency, and the occasional dropped packet. That kind of thing is to be expected, and not actually a problem.

Looking at your graph, it does seem a bit excessive, and if you are actually noticing throughput issues you should get Zen to investigate.

Edited by Geordish (Wed 09-Jul-14 10:08:45)

Nothing has changed. Same hardware, same modem. What has changed is a switch from 40/10 to 80/20, and the ISP (A&A -> Zen).

The connection is mostly idle during the day. The yellow peaks are when the connection is being used. At other times, it is mostly dormant. Yet the packet loss continues through all these periods (as you can see).

This doesn't appear to affect throughput or usability of the connection. A wget speed test maxes out the connection at exactly 6.89 MB/s, even though the overall speed for 100Mb is 6.64 MB/s.

$ wget -O /dev/null http://ipv4.download.thinkbroadband.com/100MB.zip
--2014-07-09 10:25:32--  http://ipv4.download.thinkbroadband.com/100MB.zip
Resolving ipv4.download.thinkbroadband.com... 80.249.99.148
Connecting to ipv4.download.thinkbroadband.com|80.249.99.148|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/zip]
Saving to: �/dev/null�

100%[================>] 104,857,600 6.89M/s   in 15s

2014-07-09 10:25:47 (6.64 MB/s) - �/dev/null� saved [104857600/104857600]

I never seem to see pauses or symptoms of packet loss. Also, there's no increase in latency. With regards to sync speed, the FTTC modem has not re-synced since I went live with Zen 3 months ago (its current sync is just above 60000). So it is unlikely to be a line issue, or related to any kind of line noise/interference. As far as I can tell, interleaving is off.

Who knows. Maybe they are prioritizing ICMP ping lower than other protocols.

Let me do some tcpdump analysis and get back to you - currently have a packet capture running over the next hour.

Well, 3600 pings received, 3600 replies sent. That's from about 10:55am to 11:55am this morning.

Yet, the BQM TTB graph shows packet loss over this hour.

That leaves only one explanation - not all reply pings made it back to the TTB BQM monitoring IP.

The mystery deepens.

Were your 3600 pings to the TTB ping monitor host?

If not maybe try a lengthy pathping to the TBB ping server host.

It'll ping all hops along the way all in one go, if any hops along the way have loss you'll maybe uncover where stuff may be getting lost.

If you *were* pinging the TTB ping monitor host and you had no loss, yet the ping monitor says things were missed.. that would indeed increase the depth of mystery.

I'm on Zen too and I also get little flecks of red on my graph when the line is totally idle. I didn't have it on my previous provider (Entanet) - that said it isn't necessarily the ISP itself at fault, might simply be something along the route if things take a different path through peering/transit. I haven't really bothered looking too much into it as it's not really got any noticeable effect aside for the tiiiiiny bits of red on a TTB graph.

In reply to a post by summat:

If not maybe try a lengthy pathping to the TBB ping server host.

Rule #330348- Never ask people who run Linux to run Windows commands - you're just asking for a sarcastic/snotty response

Fair comment,

It's been so long since I mtr'd anything on a linux machine - really only ever used to look at problems like this when I gamed and back then was *veery* concerned whenever any packet loss entered my life.

I only ever gamed on windows so pathping took over my mind..

In reply to a post by summat:

Were your 3600 pings to the TTB ping monitor host?

Yes, IP 80.249.99.164

Regarding pathping, I think (for Linux) you mean tracepath. Here's the output of that, which is indeed showing some asymmetric routing happening, so I reckon there is a dodgy hop on the way back from me to the TBB BQM IP. Certainly, as far as my connection goes, I don't see any issues with it what so ever, and as I have confirmed, I did receive and reply to 3600 ping requests from the TTB BQM monitor (tcpdump confirms this 100%) even though the TBB monitor seems to reckon there was packet loss.

# tracepath -n 80.249.99.164
 1:  ??.??.??.??       0.265ms pmtu 1492 (my IP)
 1:  62.3.84.17        8.778ms
 1:  62.3.84.17        7.931ms
 2:  62.3.84.237       8.938ms asymm  3
 3:  195.66.224.240    8.944ms
 4:  80.249.97.17      8.946ms asymm  3
 5:  80.249.97.85     10.943ms asymm  4
 6:  80.249.99.164     8.954ms reached
     Resume: pmtu 1492 hops 6 back 60

(Un)fortunately, I don't have convenient access to a Windows machine anymore - Linux (CentOS) or Mac OS X only here.

I also monitor a VPS server using the TBB BQM - that is also showing packet loss, but not as much.

Same asymmetric routing for at least 2 hops within the realms of TTB BQM network.

# tracepath -n 80.249.99.164
 1:  ??.??.?.??        0.105ms pmtu 1500
 1:  77.73.?.???       0.108ms
 1:  77.73.?.???       0.078ms
 2:  31.25.190.85      0.202ms
 3:  37.128.135.194    0.556ms
 4:  89.151.97.225     0.900ms
 5:  89.151.95.129     3.074ms asymm  8
 6:  89.151.95.177     2.230ms
 7:  195.66.224.240    2.510ms
 8:  80.249.97.17      2.559ms asymm  6
 9:  80.249.97.85      4.234ms asymm  7
10:  80.249.99.164     2.637ms reached
     Resume: pmtu 1500 hops 10 back 57

your packetloss is all day, I am going to guess the most likely cause is your line with crc errors.

going from 40/10 to 80/20 will put more pressure on the line if it had excess snrm on 40/10.

unlock your modem, or ask zen to temporarily put you on 40/10 and see what happens.

In reply to a post by Chrysalis:

your packetloss is all day, I am going to guess the most likely cause is your line with crc errors.

No Chris, it is not. You either haven't read or understood my previous post that proves it is not. So let me re-iterate again.

I symultaneously launched 2 independent tcpdump packet captures to terminate after capturing exactly 3600 packets, one looking at ICMP type 8 (echo request) coming from the BQM IP and the other looking at type 0 (echo reply) being sent back to it.

Both were launched at exactly 10:55 and 10 seconds. Both terminated on the 3600th matched packet (11:55 and 09 seconds).

I received all 3600 ping requests the BQM monitoring IP sent me. I know this by looking at the sequence ID of the packets which varied from 12800 to 13055 (the sequence IDs appear to cycle around with a period of 256). Analysis shows I received every single ping packet sent by BQM, as there are no sequence ID gaps present.

The router also sent replies to every single one of these ping requests.

Thus I have no reason to suspect there is packet loss on my connection, and that it has anything to do with CRC errors. I received all the packets I was supposed to receive, and replied to them.

Yet the BQM graph is showing packet loss across the exact same packet set I just recorded using tcpdump. That does not make sense I'm afraid.

going from 40/10 to 80/20 will put more pressure on the line if it had excess snrm on 40/10.

unlock your modem, or ask zen to temporarily put you on 40/10 and see what happens.

I doubt Zen will do that as that would require a product change with BT Openreach contracting them into a further 12 months.

EDIT: Unless the packet loss is only happening on the upstream frequencies; an unlocked modem is going to be the only thing that shows that. Or, it's a dodgy hop on the way back to the BQM IP.

Edited by deleted (Thu 10-Jul-14 08:21:08)

until you unlock your modem you cant prove otherwise in my view.

what have zen said? as I assume you have contacted them.

The *nix equivalent that comes to mind is mtr, I'm not sure that tracepath will give you packet loss statistics?

The thing to be looking out for is a point at which all further hops after it have loss. A single router showing loss half-way along the route but no loss after it or on the actual target address means that hop along the way simply isn't putting much effort into responding to pings as it's got more important stuff to do.

Having looked at your BQM, you're getting a great deal more red at the top than I do (Example). Therefore I'd be less inclined to blame the Zen -> TTB route, and more inclined to blame what's responding your end, or the BT network between you and Zen.

Is the device responding to pings your end your router? If so why not try redirecting ICMP to a device inside the network that will always respond reliably (like a linux PC or server) and seeing if that changes anything in your graphs.

Edit: I see your other post earlier states you've already checked every single request sent a response back to TTB, so never mind that last bit!

Edited by summat (Thu 10-Jul-14 17:50:28)

Purely out of interest, is your connection 40/10 or 80/20 ? Interleaving on/off ? And finally, what is the IP address of the Zen gateway you are connected to? (first hop).

80/20 on Zen, was previously 40/10 on Entanet. Never had any flecks of red on the TTB graph when I was on my Enta connection, do get a few on this Zen connection, but so little I don't notice it as I said previously. No interleave.

Max: Upstream rate = 36495 Kbps, Downstream rate = 98064 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps

                Down      Up
SNR (dB): 11.3       17.7

I'm on 62.3.83.10 (losubs.subs.dsl5.wh-man.zen.net.uk) right now but I've been on various over the last several months due to various issues like powercuts/firmware upgrades on modem, etc. Doesn't seem to have much if any impact on my TTB graphs.

Edited by summat (Thu 10-Jul-14 20:12:42)

The problem could be on the graphing side of course, "they" are now doing stats on a lot of connections they may even be getting the responses but just not processing them quickly enough.