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.