Hi *, sorry if this has been answered, I did look.
Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? Specifically I'm thinking of a sub-interface on a shared physical interface. I've not thought much about it but if there's a more generally-accepted guideline than, "when the customers start leaving / when you leave," I'm at least 5% ears.
Thanks,
Keith
How are you going to come up with a standard that covers both the uplink from
Billy-Bob's Bait, Fish, Tackle, and Wifi, where a fractional gigabit may be
plenty, and the size pipes that got clogged in the recent Netflix network
neutrality kerfluffle?
And where your PoPs are (and how many) matters as well - if you have a peering
agreement with another carrier, and you exchange 35Gbits/sec of traffic, the
bandwidth at each peer point will depend on whether you peer at one location,
or 5, or 7, or 15.....
I'm sorry I should have been more specific. I'm referring to the *percentage* of a circuit's bandwidth. For example if you order a 20Mb site to site circuit and iperf shows 17Mb. Well ... that's 15% off, which sounds hefty, but I'm not sure what's realistic to expect.
And beyond expectations, I'm wondering if there's a threshold that industry movers/shakers generally yell at their vendor for going below, and try to get a refund or move the link to a new port/box.
That 3Mb difference is probably just packet overhead + congestion
control. Goodput on a single TCP flow is always less than link
bandwidth, regardless of the link.
I'd say if there's a strong financial reasoning (or greed some times)
behind a complaint, it will be brought up, otherwise shouldn't it be all
based on civil talks and agreements anyway?
For access side (home users) we have slightly over provisioned there
circuits, to minimize the "I¹m paying for 20 why am I getting 19" type of
calls. Provision them out to 25 they get 23-24 on there speedtest
everyone is happy.
Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos@race.com / http://www.race.com
<http://www.race.com/>
...and many different carriers have different definitions of "congestion". Some carriers might have several definitions of the word, depending on the service you have and which group you happen to be speaking to that day.
It's pretty much impossible to guarantee bandwidth on an inter-carrier packet-switched link.
jms
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.
If memory serves me right, keith tokash wrote:
I'm sorry I should have been more specific. I'm referring to the
*percentage* of a circuit's bandwidth. For example if you order a
20Mb site to site circuit and iperf shows 17Mb. Well ... that's 15%
off, which sounds hefty, but I'm not sure what's realistic to expect.
This doesn't exactly answer your original question, but...
iperf (as well as its follow-on, iperf3) runs between two end hosts, so
an iperf test will be measuring other effects, such as congestion (as
others have pointed out), but also end-host tuning, the LANs to which
the end hosts are attached, etc.
${WORK} maintains a good reference to tuning networks for
high-performance R&E networks...some of these techniques are applicable
to other environments as well.
Bruce.
Not it’s not. All the link speeds are products of standards, be it SDH/SONET,
PDH, or various flavors of ethernet. They are objective numbers. What you are
advocating, given that much of the overhead is per packet/frame overhead
and will vary based on the application and packet size distribution, will create
more confusion than what we have today.
-dorian
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..
Hi,
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"
But you don't know what the user is going to do over the link. If the average packet size is very small the overhead will be much larger. And the path-MTU depends on many factors besides the customer link. The only real number to give to the customer is the raw link speed. Everything else depends on how the link is used. Giving customer numbers like "IF you do X then expect a maximum speed of Y" will only cause more confusion. Especially because you can only give theoretical maximums because real speeds depend on many other factors (pMTU, RTT, congestion somewhere etc) as well.
Cheers,
Sander
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.
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..
Are you saying that the service provider should take into account overhead?
And report the amount of bandwidth available for payload? Even there we
have some wiggle room, but at least it is something the customer will be
able to work out (IP header overhead, etc).
If not, I'm at a bit of a loss. As a customer, how do I identify that my
traffic is actually going over an ATM-over-MPLS-over-VPN-over-whatever-
other-bitrobbing-tech circuit and that I should only expect to see 60% of
the speed advertised?
... JG
Useable data over a link depends on packet size.
56 byte IP packets at X Mbps
1500 byte IP packets at Y Mbps
This is then comparable across link technologies and framings used
on those technologies.
You can then compare a DSL vs GPON vs Cable as provided by the ISP
using Apples to Apples comparisons.
Yes, and no.
If you are a given a limited resource (in this case, a physical port that
can process no more than 1gbps for example) and your efficiency in
transferring data over that port is not 100%, the provider itself is not to
blame. Each and every protocol has limitations, and in this case we are
talking about payload I guess. What the provider should say is: if you need
"true" 20mbps, then instead you should contract 20mbps X
1+your-payload-process-loss.
A silly example would be this: you fill your gas tank with 12 gallons...
After driving until it's empty, your engine only used an average of 6
gallons to actually move you from point A to point B. The other 6 were just
wasted in form of heat. Do you ask for your money back at the gas station?
Or maybe you invest in a hybrid car?
Like I mentioned before, this is not unique to networking, it's a broader
concern in the design of any system or process.
Yes, and no.
If you are a given a limited resource (in this case, a physical port that
can process no more than 1gbps for example) and your efficiency in
transferring data over that port is not 100%, the provider itself is not to
blame. Each and every protocol has limitations, and in this case we are
talking about payload I guess. What the provider should say is: if you need
"true" 20mbps, then instead you should contract 20mbps X
1+your-payload-process-loss.
That's fine as long as they're giving you a resource that can potentially
transfer the 20Mbps.
A silly example would be this: you fill your gas tank with 12 gallons...
After driving until it's empty, your engine only used an average of 6
gallons to actually move you from point A to point B. The other 6 were just
wasted in form of heat. Do you ask for your money back at the gas station?
Or maybe you invest in a hybrid car?
That *is* a silly example.
A more proper analogy would be that you buy 12 gallons of gas, but the
station only deposits 11 gallons in your tank because the pumps are
operated by gasoline engines and they feel it is fine to count the
number of gallons pulled out of their tank instead of the amount given
to the customer.
Like I mentioned before, this is not unique to networking, it's a broader
concern in the design of any system or process.
Finding new ways to give the customer less while making it look like more
has a long, proud history, yes.
... JG
-----Oorspronkelijk bericht-----
And if you look at it from the provider's prospective, they have lots of customers who want 12 gallons of gas worth of driving time, but only want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it showed their purchased gas only gave them 10 gallons worth of driving time).
Consider a better analogy from the provider side: A customer bakes a nice beautiful fruit cake for their Aunt Eddie in wilds of Saskatchewan. The cake is 10 kg - but they want to make sure it gets to Eddie properly, so they wrap it in foil, then bubble wrap, then put it in a box. They have this 10kg cake and 1kg of packaging to get it to up north. They then go to the ISP store to get it delivered - and are surprised, that to get it there, they have to pay to ship 11kg. But the cake is only 10kg! If they pay to ship 11kg for a 10kg cake, obviously the ISP is trying to screw them. The ISP should deliver the 10kg cake at the 10kg rate and eat the cost of the rest - no matter how many kg the packaging is or how much space they actually have on the delivery truck.
And then the customer goes to the Internet to decry the nerve of the ISP for not explaining the concept of "packaging" up front and in big letters. "Why they should tell you - to ship 10kg, buy 11kg up front! Or better yet, they shouldn't calculate the box when weighing for shipping! I should pay for the contents and the wrapping, no matter how much it is, shouldn't even be considered! It's plain robbery. Harrumph".
Jeff