Re: [nznog] UFB 1 gig plans for retail and impact they have

4 Nov 2014

      That captures the key points. I'm not about restricting freedoms, just
protecting from derp.

Macca

On Tue, Nov 4, 2014 at 12:16 PM, Dean Pemberton 
wrote:
...
Barry,  have I summed up your points correctly below"
1)  You can't do nothing because as access link speeds increase at a
greater rate than aggregation of core link speeds there is an
unacceptable risk that single digit numbers of users will cause
significant link saturation.
2)  You can't filter at the edge because in most cases you don't own
the edge.  You don't own the CPE in any meaningful way, nor do you own
the access network.  By the time the traffic arrives at your handover
it's already causing you problems.
3)  There needs to be some way to remotely disconnect customers at L2,
in the access network, who are causing issues.
Macca, your points are:
1)  The environment is fundamentally different than it was in the
past.  Single digit numbers of home users have not historically had
the ability to cause substantial issues in table resource, CPU and
memory across the access, aggregation and core networks.
2)  The only way to mitigate this is to limit what the end users are
able to do from a service point of view  "unfiltered and unfettered
provision of default residential services is coming to an end"
Have I missed anything?
On Tue, Nov 4, 2014 at 7:13 PM, Barry Murphy
 wrote:
...
I don¹t believe this to be true, you can¹t just police the users data at
the access port, the data is already consuming the full capacity of the
connection before you can police it, your policing will do nothing.
You¹d need chorus to do the policing before it reached you which is not
likely as it¹s a layer 2 service, so you¹d have to police at the egress
of
each CPE, if you were in control of it.
I understand (and we do it) that you can scan your own network, detect
where open relays or open DNS servers are and firewall on your ingress
from transit and peering upstreams to ensure the downstream clients
aren¹t
the source of the attack, but it simply takes one nasty worm someone
wasn¹t expecting and you haven¹t blocked and bam your 10gig is full, the
only fix is to disconnect the affected users you cannot police them.
While there is cheap tin these days such as mikrotiks, second hand ciscos
or junipers etc for the small entrants of sub 500 users. To get scale you
need big devices that can scale in size to support 100,000+ subscribers
like what we use, Alcatel Lucent 7750. Your cost per 10G port is around
$15k USD per port, this considering you¹ve already spent around $100k on
the chassis. While these prices may seem like nothing to the likes of
Telecom or Vodafone, majority of those on the list that operate an ISP,
adding an extra 10G handover for a UFB location at $10-15k plus backhaul
is not really cheap I don¹t believe, not when you¹re competing with mass
market products where people are price conscious. While we don¹t compete
for such services, some of our wholesalers do, at the end of the day we
have to point out the quantity vs quality points for them to understand.
The problem still lies, if you have a 10gig handover and you have 10
infected downstream customers that have 1Gbps access circuits pumping out
1gbps of data, they can easily consume the size of the handover and
affect
everyone else on that handover until you disconnect their session. With
the theoretical maximum capacity being 80Gbps per region (say telecom can
have a maximum of 80Gbps to service the whole of auckland), it would only
take 80 of their 100¹s of thousands of customers to consume all their
Auckland region UFB handover. With the amount of data Telecom would be
passing through their routers consuming 80gbps of data, it would take
some
time for some one to pick those 80 infected customers our of 100,000
customers and then disconnect each, all while the 100,000 other customers
have packet loss and bad connectivity.
I guess the fix is to have 100gbps handovers, but even then these would
likely go into aggregation switches then back to the BNG/BRAS, you¹d have
to have multiple 100gbps handovers directly into your BNG/BRAS.
Kind regards,
Barry Murphy / Chief Operating Officer
From:  Kris Price 
Date:  Tuesday, 4 November 2014 5:17 pm
Cc:  nznog 
Subject:  Re: [nznog] UFB 1 gig plans for retail and impact they have
There are networks out there that cope with these issues. Develop means
to
monitor and detect DDoS and police users in near real time at the access
port. Think about what happens when someone tries to launch a DDoS from a
cloud provider.
The related aspect to this is we can, if we choose provide very high
amounts of bandwidth with very low over sub ratios. Network equipment is
now a commodity. Provided you have the fiber you can light vast amounts
of
bandwidth for surprisingly low cost,
 not just in the access but also the long haul.
Sent from my mobile
On Nov 3, 2014, at 6:23 PM, McDonald Richards
 wrote:
Sure - we had the conversation then, when 1.5Mbit of saturation didn't
also exhaust firewall state tables, CPU and memory resources of
everything
in the service path.
What we do have now, that we didn't have then, are bot-nets for hire and
parties who intentionally exploit, infect, test and document these hosts
for hire as weapons while the end users in a lot of cases have no idea
that it's happening outside of a slower
 Internet connection.
On Mon, Nov 3, 2014 at 5:53 PM, Jeremy Visser
 wrote:
On 03/11/14 22:26, McDonald Richards wrote:
...
The days of the "any to any, open Internet" are slowly coming to an
end. One small flaw in one mass produced and mass distributed piece
of software (including software that runs on CPE) can easily snowball
into hundreds of gigabits of traffic at the "core" of the Internet (I
hate that term but I'm too tired to come up with anything else right
now).
We had this same conversation when people started moving from dial-up to
DSL.
"OMG a single user on 1.5 Mbit/s can saturate our entire server farm
bandwidth"
The world didn't end.  The same rules apply today that applied back then.
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog

NZNOG mailing list
NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog