[175744] in North American Network Operators' Group
RE: Industry standard bandwidth guarantee?
daemon@ATHENA.MIT.EDU (Bacon, Ricky (RJ))
Fri Oct 31 12:50:03 2014
X-Original-To: nanog@nanog.org
From: "Bacon, Ricky (RJ)" <rj.bacon@verizon.com>
To: David Hofstee <david@mailplus.nl>, "nanog@nanog.org" <nanog@nanog.org>
Date: Fri, 31 Oct 2014 12:49:43 -0400
In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75CAC0683D@SBS1.blinker.local>
Errors-To: nanog-bounces@nanog.org
>That *is* a silly example.
>
>A more proper analogy would be that you buy 12 gallons of gas, but the=20
>station only deposits 11 gallons in your tank because the pumps are operat=
ed by gasoline engines and they feel it is fine to count the number of gall=
ons 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 ema=
il'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 di=
ve 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.=20
If you want a pipe that will let you transmit 10G of raw data, I can have t=
han 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 lin=
k, 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 originat=
ing the request packets and receiving the reply packets and those will incl=
ude overhead. We just transport them to and from the internet. =20
In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download limit=
ation 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 y=
our physical limit, how many bits you can receive in a second, protocol or =
otherwise.
