Re: [uknof] Consumer broadband packet scheduling
On 8 Apr 2011, at 21:30, Mo McRoberts wrote: > On Fri, Apr 8, 2011 at 12:13, Adrian Kennard wrote: > >> Biggest issue is the likes of bit-torrents. They are lots of separate >> tcp sessions so normal "full link" behaviour tends to balance between >> tcp sessions not between customers. > > Pardon the dense question, but: Why? > > Customer A is sending a bunch of packets, customer B is sending a > bunch of packets; why bother to introspect at the tcp/ip layer at all? > >> Something more aware of per-customer >> traffic levels and management is likely to be fairer, or something >> specific to the types of traffic like this that are "unfair" somehow. > > Right, so if you do the traffic management in the core network (and > I'm guessing it is), you're not going to have a clue what your > customers are doing (at least not without an awful lot of nasty remote > interrogation going on); what if you do it at the edge? Don't the > DSLAMs know what their own port throughput is? And the switches > they're connected to? and so forth? > > [W]FQ isn't exactly new-tech, and sticking stuff in the core to > mitigate issues at the edge seems an awful lot like 'medicine' from > the middle ages. > > M. Is the main purpose of traffic shaping not to relieve congestion in the core/backhaul. To do this in the dslam would require it to know about packet drop some way upstream from it. If the dslam is overcontended then it would make sense to control traffic there but which is the greater problem? Identify the congested links and identify the traffic type then either apply queuing downstream of it (in the case of p2p) or utilise cdn to move popular content closer to the eyeballs. Or is the major slowdown in uk infrastructure happening at the edge with the core running underutilised? mike
Re: [uknof] Consumer broadband packet scheduling
On 8 Apr 2011, at 22:28, Mo McRoberts wrote: >> Is the main purpose of traffic shaping not to relieve congestion in the >> core/backhaul. To do this in the dslam would require it to know about packet >> drop some way upstream from it. If the dslam is overcontended then it would >> make sense to control traffic there but which is the greater problem? > > fair point — but by the same token it doesn't follow necessarily to > move all of the traffic management into the core if backhaul is a > problem, to my uneducated eyes… depends where exactly the congestion's > occurring, as you say, especially if that means you're then reliant on > slightly “interesting” mechanisms in order to achieve it. > >> Identify the congested links and identify the traffic type then either apply >> queuing downstream of it (in the case of p2p) or utilise cdn to move popular >> content closer to the eyeballs. > > why “in the case of p2p”? what if a bunch of people are doing whacking > great HTTP or RTSP transfers that's causing overcontention? CDN only > helps in some scenarios, and has some “interesting” economic angles. > > consider... > > customer A has a P2P session (e.g., Spotify, or a multiplayer game) > consuming a modest amount of bandwidth. > > customer B has an RTSP stream pulling a couple of megabits a second. > > in times of contention, which one would get penalised? > > > M. I suppose one of the problems that p2p (be it bittorrent or VOIP) causes is that it tends to fill the upstream as well as the downstream pipe as opposed to the customer with a large http stream where only acks are being sent back. I suspect that when the BB infrastructure was being provisioned then it was assumed that almost all data would be flowing towards eyeballs and little would be coming back. This probably explains the vast majority of "home" offerings having much smaller upstream speeds even when it isn't dictated by the technology eg FTTP I also suspect that the methods of determining customer flows are so significant in terms of hardware requirements that it is easier to do it on a well specified core router/switch and therefore also easier to manage than placing the necessary intelligence to gather the information at the edge and transmitting it to the noc then sending back the necessary changes to the edge in real time. mike
Re: [uknof] London Proof Tier 1 - Manchester TCW
A few years ago I had to do major incident planning for the emergency services so we were running through "likely" scenarios. The one that sticks in my mind as being described as "worryingly feasible" was the caesium based "dirty bomb" which would remove access to an area the size of docklands++ for longer than the diesel supplies would last. Seems reasonable to avoid a geophysical SPOF > On 30 Oct 2013, at 18:00, Ben King wrote: > > Hi Stephen, > > Coming back to you on your original point, you make a valid point that if you > lose London you lose most of the UK, from my perspective though UK is far > from the whole game, we only supply businesses in a pretty region specific > area, the vast majority customers are directly connected to our network (as > opposed to via another providers active network) and all customers have a > route to Manchester that avoids London, so in the event of a London fail I am > sure they would be delighted to be able to continue to send traffic outside > of the UK and carry on their international business relations (I concede > there may be other hurdles that get in the way in that scenario). > > I think you actually highlight is that ideally more providers should be > attempting to be present in both London and Manchester to give greater UK > diversity. > > Regards... Ben > > > > > > >> On 30 October 2013 17:41, Stephen Wilcox wrote: >> Well, take a list of Tier1s: >> AT&T >> Qwest >> Savvis >> DT >> XO >> GTT >> Verizon >> Sprint >> Telia >> NTT >> Level3 >> Tata >> Zayo >> Cogent >> FT >> Seabone >> >> >> Remove any that only have BGP PoPs in docklands or no UK POP, this leaves: >> >> GTT >> Level3 >> Zayo >> Cogent >> >> Remove any that dont interconnect outside docklands with BT, Virgin, >> Talktalk, Sky: >> >> Level3.. maybe? >> Cogent.. maybe? >> Zayo.. maybe? >> >> >> Why not pick someone not in the tier1 list with better UK connectivity and >> network (that was my prior point) this gives you a wide choice. >> >> Steve >> >> >> >> >> >> >> >>> On 30 October 2013 17:28, James Bensley wrote: >>> Continuing this thread; >>> >>> Can anyone recommend a good Tier 1 provider that is at least docklands >>> proof (by which I mean Global Switch 1 / 2 & Smelehouse East / North >>> / West)? Everyone and their mum is in that little cluster, can anyone >>> recommend a Tier 1 that is proven to not depend on those sites rather >>> than all of London? >>> >>> Whilst I don't think this is quite such a big ask as the original >>> question I'd like to find a provider who can provide me routes from >>> else where, be it Manchester or else where in London etc, *that don't >>> go via docklands already*. A couple of providers I have had >>> conversation with have said that traffic would go via docklands but >>> then if docklands explosededed, it would then go via Manchester or via >>> else where instead, but then they would then be running a fail over >>> scenario; links could be congested, latency increases etc etc. >>> >>> Any providers who will be not be routing via docklands as default is >>> more specifically what I'm after. >>> >>> Cheers, >>> James. > > > > -- > Ben King > WarwickNet - The Business & Science Park ISP > Tel: 024 7699 7222 > Mob: 07973 848007 > http://www.warwicknet.com > >
Re: [uknof] BTW FTTC VDSL Modem
> On 30 Oct 2013, at 18:16, "Neil J. McRae" wrote: > > > >> On 30/10/2013 16:07, "Haroldo F. Jardim" wrote: >> >> Hi Steve, >> >> I actually have an 887VA-W myself and have been using the built in VDSL >> controller for a couple of years now without any problems. > > Haroldo, > > > Do you see any noticeable difference in sync performance? > > One of the concerns raised by some of my colleagues about doing a wires > free service is the requirements in compatibility between chipset vendors, > and personally speaking in the past (with Cisco 8xx specifically) on > ADSL2/2+ was pretty challenging with different chipsets in different > CPE/DSLAMS. > Also need to ensure future chipset compliance with a potential vectoring > roll out. > > > Regards, > Neil. > > The issue was in the 870s with a wierd interaction between the Alcatel modem chipset "STMI" and the Huawei MSAN "IFTN" Cisco moved to Broadcom chipsets for their newer kit which have proven to be *much* better both in the 800 series and in the HWIC Mike
Re: [uknof] London Proof Tier 1 - Manchester TCW
Answers inline > On 30 Oct 2013, at 22:58, "Neil J. McRae" wrote: > > Michael, > Absolute rubbish! Joy > > How do tesco get food onto shelves? > p sure they have a contingency plan > How does the NHS exchange information on patients? > Bless. I am so glad that it appears that the NHS exchanges useful info in a meaningful manner, makes me very proud to be a part of it. > How does the country manage its infrastructure in the widest sense. > It tends to route around bad things and shut down or ignore that which it can't > Answer-> The Internet’s that we build and operate today. > > Our networks in docklands are Critical national infrastructure. The army > won’t be holding us back, they will be assisting us to build the plan to > recover. > Yes except it won't be about roping in some people. Your infrastructure will be u/s I thought we learned this from the WTC. > I don’t agree with your assumption that this wouldn’t be allowed, look at > Japan for a reference of it being allowed. Is it desirable, no it isn’t, but > sometimes you just have to roll your sleeves up and put on the radiation > suits. > Japan was a very different type of event and those weren't volunteers getting your networks to stay up so that packets could flow, they were trying to stop cores from going critical. Answer to this is: If you haven't already been part of the planning "in case" so already know ~exactly~ what would happen then you aren't considered to be critical. Sorry... I am sure there are assets there that are deemed to be v important but I also am 100% sure that they aren't critical failure points. which was the point of this > Neil. > Best wishes Mike > From: Michael Simpson > Date: Wednesday, 30 October 2013 22:00 > To: "Neil J. McRae" > Cc: "uknof@lists.uknof.org.uk" > Subject: Re: [uknof] London Proof Tier 1 - Manchester TCW > > > >> On 30 October 2013 21:16, Neil J. McRae wrote: >> It would’t remove the access to the site. It would just mean you needed a >> lot of volunteer to spend a short amount of time in the location. A dirty >> bomb like this would most likely do little damage to the infrastructure in >> the location. >> >> Regards, >> Neil. > > That sounds good but it really isn't going to happen. You won't be allowed to > expose civilian volunteers to Caesium dust until the area has been > decontaminated and getting the POPs back up is not going to be the first > priority. > I agree that there will be very little physical damage (compared to something > like Grangemouth going up) but the buckets of diesel toting volunteers won't > get through the army cordons. > > >a lot of volunteer > > heh > that's you bankrupted from the class action brought by the first people to > get cancer post event whether it is linked or not. > Inhaled caesium can be horrendous and removal of access is part of the reason > for these bombs (maximises both terror and disruption) > > http://www.aristatek.com/drjbomb.aspx > > that was based on one ounce of Ce137 > > Also, just for fun, try doing some stuff in an NBC suit and do some costings > on decontamination units that are suitable for this threat (eg not just > asbestos grade) bearing in mind that the demand for them locally might be > *quite* high. > > If I was part of the team controlling the MI and you came to me asking for > entry to fill your genny I would be disinclined to allow it and unless the > facility is filtered to clean room standards the whole lot is junk anyway. > > I might even be cheeky and ask you why you weren't regionally diverse in your > connections but i would be under a fair bit of stress at the time. > :) > > mike >
