nanog mailing list archives
RE: Industry standard bandwidth guarantee?
From: keith tokash <ktokash () hotmail com>
Date: Thu, 30 Oct 2014 12:44:43 -0700
I'm willing to recommend to sales people that they advertise the size of the *usable* tube as well as the tube overall, but I'm fairly sure they won't care. Ben rightly stated the order of operations: BS quote > disappointment > mea culpa/level setting. If that fails I'll at least make sure no one quotes circuit sizes in terms of "movies transferred," or whatever metric is popular at the moment.
From that nice gronkulator page I see a couple of MPLS and a dot1q tag bringing a theoretical limit down to around 94% (non-jumbos), which to my conservatively estimating mind means customers should expect ~90 on a normal day. This isn't factoring latency, intermittent loss, or congestion elsewhere on the tubes, so I'm not sure where this has gotten me. A number has been specified to be sure, but one that blows away with a gentle sneeze.
From: rafael () gav ufsc br Date: Thu, 30 Oct 2014 13:21:41 -0500 Subject: Re: Industry standard bandwidth guarantee? To: mysidia () gmail com CC: bensjoberg () gmail com; ktokash () hotmail com; nanog () nanog org You can't just ignore protocol overhead (or any system's overhead). If an application requires X bits per second of actual payload, then your system should be designed properly and take into account overhead, as well as failure rates, peak utilization hours, etc. This is valid for networking, automobile production, etc etc.. On Thu, Oct 30, 2014 at 7:23 AM, Jimmy Hess <mysidia () gmail com> wrote: On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg <bensjoberg () gmail com> wrote:
That 3Mb difference is probably just packet overhead + congestion
Yes... however, that's actually an industry standard of implying higher performance than reality, because end users don't care about the datagram overhead which their applications do not see they just want X megabits of real-world performance, and this industry would perhaps be better off if we called a link that can deliver at best 17 Megabits of Goodput reliably a "15 Megabit goodput +5 service" instead of calling it a "20 Megabit service" Or at least appended a disclaimer *"Real-world best case download performance: approximately 1.8 Megabytes per second" Subtracting overhead and quoting that instead of raw link speeds. But that's not the industry standard. I believe the industry standard is to provide the numerically highest performance number as is possible through best-case theoretical testing; let the end user experience disappointment and explain the misunderstanding later. End users also more concerned about their individual download rate on actual file transfers and not the total averaged aggregate throughput of the network of 10 users or 10 streams downloading data simultaneously, or characteristics transport protocols are concerned about such as fairness.
control. Goodput on a single TCP flow is always less than link
bandwidth, regardless of the link.
--- -JH
Current thread:
- Industry standard bandwidth guarantee? keith tokash (Oct 29)
- Re: Industry standard bandwidth guarantee? Valdis . Kletnieks (Oct 29)
- RE: Industry standard bandwidth guarantee? keith tokash (Oct 29)
- Re: Industry standard bandwidth guarantee? Rafael Possamai (Oct 29)
- Re: Industry standard bandwidth guarantee? Ben Sjoberg (Oct 29)
- Re: Industry standard bandwidth guarantee? Matthew Walster (Oct 29)
- Re: Industry standard bandwidth guarantee? Jimmy Hess (Oct 30)
- Re: Industry standard bandwidth guarantee? Dorian Kim (Oct 30)
- Re: Industry standard bandwidth guarantee? Rafael Possamai (Oct 30)
- RE: Industry standard bandwidth guarantee? keith tokash (Oct 30)
- Re: Industry standard bandwidth guarantee? Mark Andrews (Oct 30)
- Re: Industry standard bandwidth guarantee? Joe Greco (Oct 30)
- Re: Industry standard bandwidth guarantee? Rafael Possamai (Oct 30)
- Re: Industry standard bandwidth guarantee? Joe Greco (Oct 31)
- RE: Industry standard bandwidth guarantee? David Hofstee (Oct 31)
- RE: Industry standard bandwidth guarantee? Bacon, Ricky (RJ) (Oct 31)
- RE: Industry standard bandwidth guarantee? Frank Bulk (Oct 31)
- RE: Industry standard bandwidth guarantee? keith tokash (Oct 29)
- Re: Industry standard bandwidth guarantee? Valdis . Kletnieks (Oct 29)
- Re: Industry standard bandwidth guarantee? Jeff Sorrels (Oct 31)
- RE: Industry standard bandwidth guarantee? Laszlo Hanyecz (Oct 31)
- Re: Industry standard bandwidth guarantee? Rafael Possamai (Oct 31)