In reply to a post by Ignitionnet:

No - overall capacity remains the same...

I don't understand that. How can they shut down an external link yet retain the same capacity. What am I missing?

Same question here...

In reply to a post by MrSaffron:

Looking at BQM's it looks better, the pattern is much more like localised congestion with some VM areas actually looking pretty good now.

checked my live graph after seeing this thread, last 24 hours looks ok, now just looks like US channel congestion I got.

http://www.thinkbroadband.com/ping/share-thumb/b57b9...

In reply to a post by Ignitionnet:

In reply to a post by kwikbreaks:

I'm still surprised at how the sudden onset and cutoff could be caused by simple congestion on a peering link. Of course as we know VM do like to run their links hot so possibly just a little extra loading was enough.

Simply shutting the link down can't be a solution though as it will just cause their other peering links to run even hotter.

That's exactly what congestion on Ethernet looks like. The link that was shut down was logical and will not affect VM's overall capacity. Traffic from this ISP will go via Amsterdam and the peering there if it was just London shut down else it'll go via IP transit.

ignition you have any news on if VM are actually still planning to do a new traffic management system like comcast's? or has it been shelved.

Edited by Chrysalis (Wed 17-Oct-12 10:26:22)

They didn't shut a physical external link down, they shut down the logical link(s) to Atrato at LINX which allow the two to communicate directly over the LINX LAN(s).

Thanks for the explanation. I've no idea why such connections should be present but I can see how removing it makes no difference to overall capacity.

I was also surprised to read that ethermet congestion could have such a sudden onset - I would have expected some earlier spikes to have shown producing a more gradual build up but once again I have no practical experience in this sort of thing and just go on how I would expect it to work.

In reply to a post by kwikbreaks:

Thanks for the explanation. I've no idea why such connections should be present but I can see how removing it makes no difference to overall capacity.

It's a vital part of a public peering point, wanting to control who your network talks to directly and who has to use a transit provider to reach you. Every ISP connecting to the LINX LAN has to configure their own kit to talk to other ISPs and vice-versa.

http://en.wikipedia.org/wiki/Border_Gateway_Protocol

In reply to a post by Ignitionnet:

In reply to a post by MrSaffron:

Looking at BQM's it looks better, the pattern is much more like localised congestion with some VM areas actually looking pretty good now.

Something that is perhaps concerning more globally is that according to the LINX public lists BT have 24 x 10Gb and 1 x 100Gb interfaces to the London LINX LANs, VM have a total of 11 x 10Gb into them.

Speaking with a couple of different content providers they've more private peering to BT than VM, so it's debatable whether or not VM have lots of private peering taking the slack.

Maybe VM have tons of transit or loads of peering points elsewhere. Seems an anomaly that they've 50% less peering capacity than Talk Talk, 1/3rd the capacity of BT and just over 1/2 the capacity of Sky though.

They do to some extent - for example Virgin Media have their own trunk lines to Amsterdam and 80Gbps of interconnects into AMS-IX public peering, whereas BT only have 10Gbps. VM also peer at Edge-IX in Manchester through which they feed a great deal of their Youtube traffic, which BT do not have. BT on the other hand have quite a few minor interconnects in other places that VM don't have, but these are mostly single ~1Gbps ports that make little difference to the overall picture.

In reply to a post by kwikbreaks:

I was also surprised to read that ethermet congestion could have such a sudden onset - I would have expected some earlier spikes to have shown producing a more gradual build up but once again I have no practical experience in this sort of thing and just go on how I would expect it to work.

I'm not - was going to say this a few days ago on CF but these sudden onsets and cutoffs are pretty much exactly how ethernet congestion/saturation is expected to look like, with the exception of the level of increase being higher than I'd anticipate (which I've mentioned before). That's the only thing that surprises me - the amount of buffering that seems to be getting used on core LINX nodes.

In fact the most recent events seem to have a less sudden onset than previous incidents of core congestion on VM's network.

Here's some more examples of the effects of pure congestion on fast ethernet networks, i.e. what these events normally look like:

O2/Be core network congestion on an end user line:
http://qasdfdsaq.com/ping/14329a7aa728789fbc750857d4...
O2/Be core network congestion on an edge router:
http://qasdfdsaq.com/ping/3534523ca7831de4796c3d0a16...
http://qasdfdsaq.com/ping/3534523ca7831de4796c3d0a16...
http://qasdfdsaq.com/ping/3534523ca7831de4796c3d0a16...

Single port Ethernet congestion:
http://qasdfdsaq.com/ping/59b931aa912c3dbd571e0fc777...

Previous incident of VM core network congestion (11th-14th May):
http://qasdfdsaq.com/ping/b2e8d8ebe946be54635aa2eafd...
http://qasdfdsaq.com/ping/b2e8d8ebe946be54635aa2eafd...
http://qasdfdsaq.com/ping/b2e8d8ebe946be54635aa2eafd...
http://qasdfdsaq.com/ping/VM/0ec8f9b6b6d5ebc5ce12b7d...
http://qasdfdsaq.com/ping/b2e8d8ebe946be54635aa2eafd...
And the effect of the above on an end user line:
http://qasdfdsaq.com/ping/4f0bcff6483ed06b4ae2a1932f...
http://qasdfdsaq.com/ping/ea9c9dd3d4ac967344a4c54b2f...
Compared to the "current" incident a week ago:
http://qasdfdsaq.com/ping/b2e8d8ebe946be54635aa2eafd...
http://qasdfdsaq.com/ping/c3c367f023f83d3685408a227c...

And a fine example of what should *not* happen, i.e. when a network admin sets something up seriously wrong:
http://qasdfdsaq.com/ping/55c6f8599938ac6d0ecf98f881...

Edited by deleted (Wed 17-Oct-12 23:29:30)

Bump dead on 8pm tonight. Seems to only affect a handful of people this time though:

http://www.thinkbroadband.com/ping/share-thumb/38746...