[175732] in North American Network Operators' Group
RE: Industry standard bandwidth guarantee?
daemon@ATHENA.MIT.EDU (keith tokash)
Thu Oct 30 15:47:18 2014
X-Original-To: nanog@nanog.org
From: keith tokash <ktokash@hotmail.com>
To: Rafael Possamai <rafael@gav.ufsc.br>, Jimmy Hess <mysidia@gmail.com>
Date: Thu, 30 Oct 2014 12:44:43 -0700
In-Reply-To: <CAJB2g-Gt0txCCcbavNOiP=EtFYeDtmDv9EScNZWERmNtKZoLvA@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
I'm willing to recommend to sales people that they advertise the size of th=
e *usable* tube as well as the tube overall=2C but I'm fairly sure they won=
't care. Ben rightly stated the order of operations: BS quote > disappoint=
ment > mea culpa/level setting.
If that fails I'll at least make sure no one quotes circuit sizes in terms =
of "movies transferred=2C" or whatever metric is popular at the moment.
From that nice gronkulator page I see a couple of MPLS and a dot1q tag brin=
ging a theoretical limit down to around 94% (non-jumbos)=2C which to my con=
servatively estimating mind means customers should expect ~90 on a normal d=
ay. This isn't factoring latency=2C intermittent loss=2C or congestion els=
ewhere on the tubes=2C so I'm not sure where this has gotten me. A number =
has been specified to be sure=2C but one that blows away with a gentle snee=
ze.
From: rafael@gav.ufsc.br
Date: Thu=2C 30 Oct 2014 13:21:41 -0500
Subject: Re: Industry standard bandwidth guarantee?
To: mysidia@gmail.com
CC: bensjoberg@gmail.com=3B ktokash@hotmail.com=3B nanog@nanog.org
You can't just ignore protocol overhead (or any system's overhead). If an a=
pplication requires X bits per second of actual payload=2C then your system=
should be designed properly and take into account overhead=2C as well as f=
ailure rates=2C peak utilization hours=2C etc. This is valid for networking=
=2C automobile production=2C etc etc..
On Thu=2C Oct 30=2C 2014 at 7:23 AM=2C Jimmy Hess <mysidia@gmail.com> wrote=
:
On Wed=2C Oct 29=2C 2014 at 7:04 PM=2C Ben Sjoberg <bensjoberg@gmail.com> w=
rote:
=0A=
=0A=
> That 3Mb difference is probably just packet overhead + congestion
=0A=
=0A=
Yes... however=2C that's actually an industry standard of implying
=0A=
higher performance than reality=2C because end users don't care about
=0A=
the datagram overhead which their applications do not see they just
=0A=
want X megabits of real-world performance=2C and this industry would
=0A=
perhaps be better off if we called a link that can deliver at best 17
=0A=
Megabits of Goodput reliably a "15 Megabit goodput +5 service"
=0A=
instead of calling it a "20 Megabit service"
=0A=
=0A=
Or at least appended a disclaimer *"Real-world best case download
=0A=
performance: approximately 1.8 Megabytes per second"
=0A=
=0A=
=0A=
Subtracting overhead and quoting that instead of raw link speeds.
=0A=
But that's not the industry standard. I believe the industry standard
=0A=
is to provide the numerically highest performance number as is
=0A=
possible through best-case theoretical testing=3B let the end user
=0A=
experience disappointment and explain the misunderstanding later.
=0A=
=0A=
End users also more concerned about their individual download rate on
=0A=
actual file transfers and not the total averaged aggregate
=0A=
throughput of the network of 10 users or 10 streams downloading data
=0A=
simultaneously=2C or characteristics transport protocols are
=0A=
concerned about such as fairness.
=0A=
=0A=
=0A=
> control. Goodput on a single TCP flow is always less than link
=0A=
> bandwidth=2C regardless of the link.
=0A=
=0A=
---
=0A=
-JH
=0A=
=
