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 * On 1/6/2015 12:49 PM, Roy Hirst wrote:

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

* On 1/6/2015 12:37 PM, Bob Evans wrote:

...

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

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? -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com

Dave Pooser <dave-nanog@pooserville.com> wrote:

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. On Mon, Jan 12, 2015 at 9:07 AM, Bob Evans <bob@fiberinternetcenter.com> wrote:

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.

Bob Evans CTO -- -JH

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. -- -- ℱin del ℳensaje.

On 20 Jan 2015, at 23:19, Christian Kuhtz <chkuhtz@microsoft.com> wrote:

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-bandw...

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.

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