The number of hops is largely irrelevant. With high speed (10G) Ethernet links the serialisation delay is pretty much insignificant, instead distance is usually the significant factor.

I suspect the reason the trace via Sky shows less hops is due to them using layer 2 backhaul to a London BRAS or using MPLS/L2TP which will hide the intermediate layer 3 hops (can't tell as the 2nd hop in the trace didn't respond).

Zen peer with leaseweb at LINX exactly the same as Sky do (195.66.225.56 is a leaseweb router on the LINX LAN, as is 195.66.225.100).

I've included a traceroute from one of our servers located in our headquarters (Sandbrook Park, Rochdale) showing several hops with no noticeable latency increase. With a non-interleaved FTTC circuit you'd expect latency of around 5-6ms so add this to the 12ms shown below and the results are identical.

Tracing route to hosted-by.leaseweb.com [85.17.208.105]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 212.23...<removed>
2 <1 ms <1 ms <1 ms 88.98...<removed>
3 <1 ms <1 ms <1 ms 88.98...<removed>
4 1 ms <1 ms <1 ms ae1-0.dr2.sp-roch.zen.net.uk [62.3.80.94]
5 1 ms 1 ms 1 ms ae1-0.cr2.kp-leeds.zen.net.uk [62.3.80.98]
6 6 ms 6 ms 6 ms ge-3-0-0-0.cr1.th-lon.zen.net.uk [62.3.80.78]
7 6 ms 7 ms 7 ms ge-2-0-0-0.cr2.th-lon.zen.net.uk [62.3.80.42]
8 18 ms 16 ms 14 ms ten4-0.lon.leaseweb.net [195.66.225.56]
9 12 ms 12 ms 14 ms po100.sr1.evo.leaseweb.net [85.17.100.226]
10 12 ms 12 ms 12 ms hosted-by.leaseweb.com [85.17.208.105]

Trace complete.

cssuk - Do you know who specifically your query was referred to?

It's unfortunate that we weren't able to resolve the interleaving issue for you, being an ex-QW/Q3 player I fully understand the frustration of having poor latency. We do need work with BT Openreach further in order to establish a mechanism for us (and other ISPs) to have more control over FTTC line profiles.

Regards,

Carl

Design Team
Network & Infrastructure

Sounds interesting because the speed of my 80/20 service on Sky is exactly 80/20.

I smell a rat.

I've yet to see a single case where the line provisioned at anything over 40/10 or 80/20 if it was fast enough for those speeds regardless of provider.

In reply to a post by Acidic:

The number of hops is largely irrelevant. With high speed (10G) Ethernet links the serialisation delay is pretty much insignificant, instead distance is usually the significant factor.

Thank god someone said what I was thinking. The ping and hop obsessives haven't a clue. Sky could well not show all hops for all I know to make it look better, via various perfectly legitimate scenarios.

Hops are meaningless in this context.

I suspect the reason the trace via Sky shows less hops is due to them using layer 2 backhaul to a London BRAS or using MPLS/L2TP which will hide the intermediate layer 3 hops (can't tell as the 2nd hop in the trace didn't respond).

*nods* - which is what I wrote above basically before I'd read this bit of your post.

In reply to a post by Acidic:

The number of hops is largely irrelevant. With high speed (10G) Ethernet links the serialisation delay is pretty much insignificant, instead distance is usually the significant factor.

So you seem to be saying Zen has no control over the number of hops. I think the number of hops is important because each one increases the likelihood of latency occurring.

That isn't what's been stated. However, the issue here wasn't due to latency occurring within our network, so what could happen is irrelevant.

An ISP does control how it's network is designed and configured, but without a customer knowing the specific designs deployed by two ISPs being compared it's not possible to say with certainty that less hops displayed actually means less hand-over points in an ISPs network - i.e the point Carl's made regarding layer 2 back-haul - which would hide hops, essentially. Sky won't have built their connectivity from London directly to Rochdale without data passing through intermediate locations - which simply don't appear on a trace route; however, if you take the Sky traceroute as representing every handover point in Sky's network that would be the only conclusion you could come to.

As Carl's highlighted, the latency on Zen and Sky's networks match very closely for non-interleaved lines - which makes sense given the data is travelling about the same distance and our handover to Leaseweb is in LINX, as is Sky's.

regards,
Phil.

So you don't have any control over interleaving either?

On FTTC, no. No ISP does - and that was the point in this thread, if you've followed it all.

It's purely down to Openreach and DLM unfortunately. An engineer can attend to change it, but it would be re-applied when DLM determines it's needed again - and if the engineer wasn't fixing a fault condition it would be a chargeable visit too.

On ADSL/ADSL2+ we could opt out/in or set as auto. No such functionality exists for FTTC - and that's something we'll take up with Openreach (as, hopefully, other ISPs will too).

regards,
Phil.

Re: interleaving on FTTC

I have a suspicion that this is all to do with the application of vectoring in the future. This will require the DLM to be in TOTAL control of all the lines in a cable binder.
It is not helpful having someone outside the loop (the ISP) unilaterally decide that they want to switch interleaving off on one line. Under vectoring this would mean the DLM will now need to alter(or at least re-analyse) the parameters on all the other lines in the same binder.

So my best guess (I'm prepared to eat my hat) is the BTOR will not release control of interleaving.

That's a good point, I hadn't considered. Probably a discussion more suited to the FTTC forum here, but the vectoring solution would need to be re-analysing regularly in any case I would have thought - as the results of crosstalk isn't the only thing DLM is adjusting to handle?

In reply to a post by Acidic:

I suspect the reason the trace via Sky shows less hops is due to them using layer 2 backhaul to a London BRAS or using MPLS/L2TP which will hide the intermediate layer 3 hops (can't tell as the 2nd hop in the trace didn't respond).

Yes indeed. Straight into an all MPLS network so no intermediate hops visible from IP's point of view.

The individual exchanges go to edge routers, ERs, which function as MPLS PEs. On the Sky MPF network the MSAN doesn't respond to pings generally and is the CE so from there it's all blank until leaving the MPLS network. Looking at traceroutes seems Sky use PHP to reduce load on some core routers.

Been a very long time since I touched that network so can't assume a whole bunch of things haven't changed. It was originally conceived to only run native IP in the core for the IGPs.