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
On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:
Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee?
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.
To: ktokash@hotmail.com Subject: Re: Industry standard bandwidth guarantee? From: Valdis.Kletnieks@vt.edu Date: Wed, 29 Oct 2014 19:02:53 -0400 CC: nanog@nanog.org
On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:
Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee?
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.....
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. On Wed, Oct 29, 2014 at 6:57 PM, keith tokash <ktokash@hotmail.com> 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.
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.
To: ktokash@hotmail.com Subject: Re: Industry standard bandwidth guarantee? From: Valdis.Kletnieks@vt.edu Date: Wed, 29 Oct 2014 19:02:53 -0400 CC: nanog@nanog.org
On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:
Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee?
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.....
On 30 October 2014 08:04, Ben Sjoberg <bensjoberg@gmail.com> wrote:
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've always found it useful to refer to this: https://www.gronkulator.com/overhead.html M
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
On Oct 30, 2014, at 8: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.
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.. 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
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
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.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..
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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
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. On Thu, Oct 30, 2014 at 2:53 PM, Joe Greco <jgreco@ns.sol.net> wrote:
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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
-----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces@nanog.org] Namens Joe Greco Verzonden: Friday, October 31, 2014 12:02 PM Aan: Rafael Possamai CC: keith tokash; nanog@nanog.org Onderwerp: Re: Industry standard bandwidth guarantee? ...
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.
And bits/s is exactly what you get. With your example: You don't get kilometers at the gas stations, you get quantities of gas (e.g. a liter). And depending on a lot of factors, you get a distance from that quantity. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP)
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.
So if you tell a customer you are giving them 10 g of space for their email, you shouldn't charge them for the storage taken up by each individual email's headers. Is that how it works though? Not so much I think. As long as the pricing policy is consistent across the industry, and it is, then you are not being ripped off. Creating, implementing and maintaining a deep dive billing systems to figure out how much of your traffic is packet header and protocol and how much is your data would just add to operating expense which would eventually be passed on to the customer. If you want a pipe that will let you transmit 10G of raw data, I can have than implemented. Just tell me where to connect the two ends. If you want to connect one end to our router or switch, we'll do that too, but it won't get you much. If you want to participate on the internet with a 10Gig link, you are going to have to use protocols, and the data will have to be in layer 3 packets, and they can be any kind you choose. But you are originating the request packets and receiving the reply packets and those will include overhead. We just transport them to and from the internet. In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download limitation in bits per second. You will not exceed that unless you run multiple sessions, and even then it will always be less than link speed, which is your physical limit, how many bits you can receive in a second, protocol or otherwise.
We get this with wireless carriers -- they ask for quote for a 100 Mbps Ethernet circuit, and then tell us afterwards that it's 100 Mbps of goodput, so we have to size it to 125 Mbps to cover all their one MPLS and two 802.1Q tags and to past the RFC 2544 test at 64-byte frames. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Bacon, Ricky (RJ) Sent: Friday, October 31, 2014 11:50 AM To: David Hofstee; nanog@nanog.org Subject: RE: Industry standard bandwidth guarantee?
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.
So if you tell a customer you are giving them 10 g of space for their email, you shouldn't charge them for the storage taken up by each individual email's headers. Is that how it works though? Not so much I think. As long as the pricing policy is consistent across the industry, and it is, then you are not being ripped off. Creating, implementing and maintaining a deep dive billing systems to figure out how much of your traffic is packet header and protocol and how much is your data would just add to operating expense which would eventually be passed on to the customer. If you want a pipe that will let you transmit 10G of raw data, I can have than implemented. Just tell me where to connect the two ends. If you want to connect one end to our router or switch, we'll do that too, but it won't get you much. If you want to participate on the internet with a 10Gig link, you are going to have to use protocols, and the data will have to be in layer 3 packets, and they can be any kind you choose. But you are originating the request packets and receiving the reply packets and those will include overhead. We just transport them to and from the internet. In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download limitation in bits per second. You will not exceed that unless you run multiple sessions, and even then it will always be less than link speed, which is your physical limit, how many bits you can receive in a second, protocol or otherwise.
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 On 10/31/2014 6:02 AM, Joe Greco wrote:
That's fine as long as they're giving you a resource that can potentially transfer the 20Mbps.
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.
Finding new ways to give the customer less while making it look like more has a long, proud history, yes.
... JG
-- Jeff Sorrels Network Administrator KanREN, Inc jlsorrels@kanren.net 785-856-9820, #2
If you're selling to end users, under promise and over deliver. Tell them 20Mbit but provision for 25. That way when they run their speedtest, they're delighted that they're getting more, instead of being disappointed and feeling screwed. In practice they will leave it idle most of the time anyway. This isn't a technical problem, it's just a matter of setting expectations and satisfying them. Some of the customers might be completely clueless, but if your goal is to make them happy, then explaining protocol overhead is probably not the right way. -Laszlo -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jeff Sorrels Sent: Friday, October 31, 2014 16:14 To: nanog@nanog.org Subject: Re: Industry standard bandwidth guarantee? 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 On 10/31/2014 6:02 AM, Joe Greco wrote:
That's fine as long as they're giving you a resource that can potentially transfer the 20Mbps.
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.
Finding new ways to give the customer less while making it look like more has a long, proud history, yes.
... JG
-- Jeff Sorrels Network Administrator KanREN, Inc jlsorrels@kanren.net 785-856-9820, #2
I have a feeling this issue only occurs with residential customers, and perhaps small businesses. It is most likely cheaper to over deliver in this case then to maintain a larger call center and support team to attempt to explain end users how TCP has limitations. No two large communication businesses (ISP in this case) with properly educated technical people (i.e. network engineers or similar) on both ends should start an argument on who gets to cover transmission overhead (or for simplicity, the packaging on the cake). On Fri, Oct 31, 2014 at 11:56 AM, Laszlo Hanyecz <laszlo@heliacal.net> wrote:
If you're selling to end users, under promise and over deliver. Tell them 20Mbit but provision for 25. That way when they run their speedtest, they're delighted that they're getting more, instead of being disappointed and feeling screwed. In practice they will leave it idle most of the time anyway. This isn't a technical problem, it's just a matter of setting expectations and satisfying them. Some of the customers might be completely clueless, but if your goal is to make them happy, then explaining protocol overhead is probably not the right way.
-Laszlo
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jeff Sorrels Sent: Friday, October 31, 2014 16:14 To: nanog@nanog.org Subject: Re: Industry standard bandwidth guarantee?
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
On 10/31/2014 6:02 AM, Joe Greco wrote:
That's fine as long as they're giving you a resource that can potentially transfer the 20Mbps.
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.
Finding new ways to give the customer less while making it look like more has a long, proud history, yes.
... JG
-- Jeff Sorrels Network Administrator KanREN, Inc jlsorrels@kanren.net 785-856-9820, #2
+1 on this exactly what we do, keeps the calls down. 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 On 10/31/14, 9:56 AM, "Laszlo Hanyecz" <laszlo@heliacal.net> wrote:
If you're selling to end users, under promise and over deliver. Tell them 20Mbit but provision for 25. That way when they run their speedtest, they're delighted that they're getting more, instead of being disappointed and feeling screwed. In practice they will leave it idle most of the time anyway. This isn't a technical problem, it's just a matter of setting expectations and satisfying them. Some of the customers might be completely clueless, but if your goal is to make them happy, then explaining protocol overhead is probably not the right way.
-Laszlo
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".
From the provider side (bearing in mind I've been in that business for a few decades), usually what the customer wants is to understand what they're purchasing, and if you as a provider tell them that
Perhaps that's because in the case of shipping, it is usual and customary to expect an item to be packaged carefully and that the packaging is counted as part of the shipped package. they're buying a 100Mbps circuit, they kinda expect that they can shovel 100Mbps down that circuit. No amount of "but you should expect that there's packaging and you should just /knoooooow/ (whine added for emphasis) that means only 80Mbps usable" is really going to change that. That's why I designed an analogy that is much more representative of reality than yours. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
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'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? On Wed, Oct 29, 2014 at 6:57 PM, keith tokash <ktokash@hotmail.com> 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.
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.
To: ktokash@hotmail.com Subject: Re: Industry standard bandwidth guarantee? From: Valdis.Kletnieks@vt.edu Date: Wed, 29 Oct 2014 19:02:53 -0400 CC: nanog@nanog.org
On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:
Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee?
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.....
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. http://fasterdata.es.net/ Bruce.
On Wed, 29 Oct 2014, Valdis.Kletnieks@vt.edu wrote:
On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:
Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee?
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.....
...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
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/> On 10/29/14, 3:24 PM, "keith tokash" <ktokash@hotmail.com> wrote:
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
participants (18)
-
Bacon, Ricky (RJ) -
Ben Sjoberg -
Bruce A. Mah -
Carlos Alcantar -
David Hofstee -
Dorian Kim -
Frank Bulk -
Jeff Sorrels -
Jimmy Hess -
Joe Greco -
Justin M. Streiner -
keith tokash -
Laszlo Hanyecz -
Mark Andrews -
Matthew Walster -
Rafael Possamai -
Sander Steffann -
Valdis.Kletnieks＠vt.edu