Office 365 Expert - I am not. I have a customer that...

Mailman List Mirror (Read Only)
1

I have a customer that heavily uses Microsoft Office 365. It's hosted. All
the data I see about usage per user appears theoretical. In that the
formulas assume people are taking turns using the bandwidth as if there is
a patient line of packets at the Internet gas pump. Nobody is clicking at
the same time. We all know that is not the real world.

Does anyone have any experience with Office 365 hosted that can tell me
the practical bandwidth allocation (NOT in KB per month, but in
megabits/sec) for 100 users (during normal work hours) needs to be
available ?

Thank You in advance,
Bob Evans
CTO Fiber Internet Center

2

I know there is no such thing as a patient line of packets.
There was recently some research done on feedback from big early adopters (hosts) that I will try to dig out if you need it.
I remember that (1) user-to-data center bandwidth is much less than the resulting in-data-center bandwidth or dc-dc bandwidth (2) there are some useful metrics (ratios) for estimating bandwidth if you know the workload server GHz, installations need balance (3) Many (most?) estimates underestimate fiber bandwidth actual requirements.
Roy

**Roy Hirst* 425-556-5773
XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA

3

I found both these useful, all credit to the authors:

Application-Driven Bandwidth Guarantees in Data Centers www.hpl.hp.com/people/jklee/Sigcomm14-CloudMirror.pdf <http://www.hpl.hp.com/people/jklee/Sigcomm14-CloudMirror.pdf>

Surviving failures in Bandwidth-Constrained Datacenters http://research.microsoft.com/pubs/167565/fp285-bodikPS.pdf

Roy

**Roy Hirst* 425-556-5773
XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA

4

Thanks to those of you that answered...It is hypothetical....However, I
found another customer that uses Office 365 heavily ... said they
discovered 1 meg/sec per Microsoft Office 365 user works well in most
scenarios. This customer has 80 users and a 100 meg/sec connection with
us.

Thank You
Bob Evans
CTO

5

[snip]

Does anyone have any experience with Office 365 hosted that can tell me
the practical bandwidth allocation (NOT in KB per month, but in

Most likely in the real world where packets don't line up neatly... O365
is most probably not the largest bandwidth user, when there is
Pandora and Youtube.
It depends on factors that may be specific to the organization which
are truly unpredictable
for each individual user, but you could gather data for your specific
population of users.

I believe I would just ignore O365, since the bandwidth usage is not
much, and pick
a standard rule of thumb for the amount of bandwidth your typical
Office user actually needs
to get work done, that includes more than sufficient 'slack' for O365.

My suggested rule of thumb if you can't actually measure the traffic
in advance for your
population: count the number of workstation devices that will be your
network, figure
at least 0.5 Megabit of WAN for each typical business user
workstation or laptop.

Assuming equal numbers of active users and workstations all operating
8 hours a day (
if there are many more devices than users, or many more users than
devices, then adjust in proportion).

    *Each internal workgroup server or Office manager's workstation
counts as 300% of a workstation.
      (In other words: better figure 1.5 Megabits for each of those,
instead of 0.5.)

     *Each Wireless tablet or phone connected by WiFi = 33% of a workstation.
       so add 0.17 Megabits for each staff person that may connect
a smartphone.

     *Designer, Engineer workstations are 500% (So figure 2.5 Mbit
for each of those).

Add an extra safety margin of either 2 Megabits, or 30%,
whichever is greater.

So for 100 standard workstations, 100 Tablets, 2 Internal servers, 1
Office manager desktop, and 2 Designers.
I would say get a 100 Megabit WAN.

6

Thanks Frank... I do have a customer with 500 meg/sec service running 350
meg/sec average all day.... just 800 employees - no company driven focused
use of MS office 365.

Applications used and time of day, etc. So, I don't think one can compare
a college's overall app bandwidth usage to a business primarily using
office 365.

I'm really looking for a "minimum bandwidth recommended requirement for
100 employees all using Office 365 hosted docs that are all outside the
LAN. " MS has no such number. MS just leaving it to the individual
case-by-case discovery process.

I bet Microsoft can't answer that simple question or they wouldn't have
these GB per user equations that use X for average document size. Best, I
have to go on so far is what one of our customers "thinks" is needed.

Thank You
Bob Evans
CTO

7

Thanks Jimmy - I agree - It's pretty much what we do today...it's just
this one customer wanted Office 365 specific details. I don't think anyone
knows. Including Microsoft, app creator.

Wonder when Cloud providers get a clue, step up and help recommend a
circuit size based on users and the services their customer buy from them.
All that investment in co-lo infrastructure and it's left the middle man.
VCs in the cloud sector should be realizing that customer experience in
their cloud investment can be hindered as they leave this up to the
middle. But, they (and MS) should publish something other than the monthly
GB transfer/seats they charge by. Enterprise circuits are not sold by GB
transfer. After all we just want to get it right and help make the cloud
service provider's apps run well.

Thank You
Bob Evans
CTO

8

Wonder when Cloud providers get a clue, step up and help recommend a
circuit size based on users and the services their customer buy from them.

When they think that poor customer word of mouth will cost them more sales
then they are currently gaining from customers who would *not* move away
from on-prem if they understood all the costs including increased
bandwidth?

9

Wonder when Cloud providers get a clue, step up and help recommend a
circuit size based on users and the services their customer buy from
them.

When they think that poor customer word of mouth will cost them more sales
then they are currently gaining from customers who would *not* move away
from on-prem if they understood all the costs including increased
bandwidth?

Agreed - it will be the smart ones that don't wait for that end user
experience to go bad.
In the meantime, I can tell you sitting here in silicon valley that all
these sharp VCs don't see the hole in many of these basic business plans
called "Cloud, Rack of servers in multiple locations".

Bob Evans
CTO

10

then they are currently gaining from customers who would *not* move away
from on-prem if they understood all the costs including increased
bandwidth?

The extra bandwidth needed to utilize most SaaS-based applications is
not significant. I would say the larger problems in some cases would
be the increase in end-to-end latency.

SaaS apps seem most sensible where rapid deployment is desired, where
the number of users and amount of data are low.

In other cases, there are concerns about the additional vendor
lock-in, loss of strong control of the data. Cannot assure that it
is encrypted and secure against access by social engineering attacks
against SaaS provider. Vendors can increase monthly rates later,
after it becomes much harder to switch to an on-prem option. The
list of security hazards expands. Cannot mitigate application
downtime caused by problems with vendor infrastructure or failure of
vendor to backup data like they promised.

In the meantime, I can tell you sitting here in silicon valley that all
these sharp VCs don't see the hole in many of these basic business plans
called "Cloud, Rack of servers in multiple locations".

Well, I cannot fault those folks for trying, or VCs from dabbling in
Buzzword-Driven financing and risky ventures. Even if there actually
are gaping holes in respective plans that they are accepting: they
are playing a high-rewards game, and likely have their odds all
calculated.

2 or 3% of those 'cloud,rack of servers' people may very well manage
to pull off some tricky in-flight maneuvers to escape whichever
perceived hole, or come to realize the "fix" after starting with
otherwise inherently flawwed plans.. just having a flawwed enough plan
was still good enough in theory to show a starting point.

Any plan will essentially have holes of varying sizes, with varying
amounts of camouflage.

But the results of following a plan with holes are not necessarily
disastrous... so long as what is actually done is adapted later in
place of the original plan as required, in order to accommodate
realities.

11

The one that bit us on the tookas for a recent 'outsource to SaaS' project was
trying to negotiate support for our ITAR users (which summarizes to "servers on
US soil, and no 'non US persons' for support staff"). We ended up with several
racks of gear iin a separate room onsite instead....

(To be fair - several vendors were able to provide ITAR-compliant SaaS, just not
at a price point that worked for us...)

12

Current developing fads include messaging a server POST messages over http,
receiving JSON data. Both the request and answer are smallish small. A
interface update refresh may depend on this data arriving. So the less
latency, the more agile and snappy will feel the application.

This is less trafic than webpages. A typical webpage page update may need
400KB / 700KB +. HTML can be wasteful in big pages with a lot of data.
The same data coming from in JSON can weight much less, maybe x10 less.

I have not tried O365, so I don't know if it follow the typical modern web
app.

13

I don't belong to the O365 product group, but did you look at this?

https://technet.microsoft.com/en-us/library/hh852542.aspx

and a blog article to go along with that:

http://blogs.technet.com/b/educloud/archive/2013/08/20/do-you-have-any-bandwidth-calculators-for-office-365.aspx

There's a bunch more than comes up under "office 365 bandwidth calculator" in your friendly neighborhood search engine.

The Exchange client model, for example, looks like it can give you basics for a model based projection if you can characterize your base.

Thanks,
Christian

14

biggest issue to deal with is migration traffic analysis,
you need to identify biggest pst users, biggest non techie users who dont delete emails so hence have large email sets.
you need to identify work times so that migration efforts can start overnight ideally.

Colin