A 100/100 enterprise connection can easily support hundreds of desktop users if
not more. It’s a lot of bandwidth even today.
-Ben
> On Apr 2, 2019, at 10:35 PM, Mikael Abrahamsson wrote:
>
>> On Tue, 2 Apr 2019, Paul Nash wrote:
>>
>> FWIW, I have a 250 subscribers sitting on a 100M fiber
On Tue, 2 Apr 2019, Paul Nash wrote:
FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I
have had no complains about speed in 4 1/2 years. I have been planning
to bump them to 1G for the last 4 years, but there is currently no
economic justification.
I know FTTH footprints
On Tue, Apr 2, 2019 at 2:20 PM Josh Luthman
wrote:
> We have GB/mo figures for our customers for every month for the last ~10
> years. Is there some simple figure you're looking for? I can tell you off
> hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500
> GB/mo at simi
Mixed residential (ages 25 - 75, 1 - 6 people per unit), group who worked
together to keep costs down. Works well for them. Friday nights we get to
about 85% utilization (Netflix), other than that, usually sits between 25 - 45%
paul
> On Apr 2, 2019, at 5:44 PM, Jared Mauch wrote:
>
I would say this is perhaps atypical but may depend on the customer type(s).
If they’re residential and use OTT data then sure. If it’s SMB you’re likely
in better shape.
- Jared
> On Apr 2, 2019, at 5:21 PM, Paul Nash wrote:
>
> FWIW, I have a 250 subscribers sitting on a 100M fiber into T
FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I have had
no complains about speed in 4 1/2 years. I have been planning to bump them to
1G for the last 4 years, but there is currently no economic justification.
paul
> On Apr 2, 2019, at 3:21 PM, Louie Lee via NANO
Certainly.
Projecting demand is one thing. Figuring out what to buy for your backbone,
edge (uplink & peer), and colo (for CDN caches too!), for which
scale+growth is quite another.
And yeah, Jim, overall, things have stayed the same. There are just the
nuances added with caches, gaming, OTT stre
+1 Also on this.
>From my viewpoint, the game is roughly the same for the last 20+ years. You
might want to validate that your per-customer bandwidth use across your
markets is roughly the same for the same service/speeds/product. If you
have that data over time, then you can extrapolate what each
> On Apr 2, 2019, at 2:35 PM, jim deleskie wrote:
>
> +1 on this. its been more than 10 years since I've been responsible for a
> broadband network but have friends that still play in that world and do some
> very good work on making sure their models are very well managed, with more
> math
Louie,
Its almost like us old guys knew something, and did know everything back
then, the more things have changed the more that they have stayed the same
:)
-jim
On Tue, Apr 2, 2019 at 3:52 PM Louie Lee wrote:
> +1 Also on this.
>
> From my viewpoint, the game is roughly the same for the l
Hello all,
If there’s someone on the Google (AS15169) network, preferably in San Jose or
Denver area, could you please send me a trace route to the following IP:
2600:1010:b062:616f:f0da:421c:c752:2780
Off-list would be great, we are trying to identify the return path for traffic
being sourced
An article was published recently that discusses the possible impact of
Cloud-based gaming on last-mile capacity requirements, as well as external
connections. The author suggests that decentralized video services won't be the
only big user of last-mile capacity.
https://medium.com/@rudolfvande
+1 on this. its been more than 10 years since I've been responsible for a
broadband network but have friends that still play in that world and do
some very good work on making sure their models are very well managed, with
more math than I ever bothered with, That being said, If had used the
methods
On Tue, 2 Apr 2019, Tom Ammon wrote:
Netflow for historical data is great, but I guess what I am really
asking is - how do you anticipate the load that your eyeballs are going
to bring to your network, especially in the face of transport tweaks
such as QUIC and TCP BBR?
I don't see how QUIC
We have GB/mo figures for our customers for every month for the last ~10
years. Is there some simple figure you're looking for? I can tell you off
hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500
GB/mo at similar rates per month.
Josh Luthman
Office: 937-552-2340
Direc
“…especially in the face of transport tweaks such as QUIC and TCP BBR? “
Do these “quic and tcp bbr” change bandwidth utilization as we’ve know it for
years ?
-Aaron
We use trendline/95% trendline that’s built into a lot of graphing tools…
solarwinds, I think even cdn cache portals have trendlines… forecasts, etc.
My boss might use other growth percentages gleaned from previous years… but
yeah, like another person mentioned, the more history you have the b
:: How do people model and try to project residential
:: subscriber bandwidth demands into the future? Do
:: you base it primarily on historical data?
--
Yes, if you have a lot of quality data that goes far
back in the past you can make
Residential whatnow?
Sorry, to be honest, there really isn’t any.
I suppose if one is buying lit services, this is important to model.
But an *incredibly* huge residential network can be served by a single basic
10/40g backbone connection or two. And if you own the glass it’s trivial to
s
Ack for NTT
On Mon, Apr 1, 2019 at 21:36 Christopher Morrow
wrote:
> (from offline chat and pokery)
>
> It looks like 701/1239/3356 are permitting 4837 to announce this prefix
> because:
> $ whois -h whois.radb.net 192.139.135.0
> route: 192.139.135.0/24
> descr: managedway company
> o
How do people model and try to project residential subscriber bandwidth
demands into the future? Do you base it primarily on historical data? Are
there more sophisticated approaches that you use to figure out how much
backbone bandwidth you need to build to keep your eyeballs happy?
Netflow for hi
Any luck reaching AS4837?
route-views>show ip bgp 192.139.135.0/24 longer-prefixes
BGP table version is 103101215, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f
22 matches
Mail list logo
