[tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]

grarpamp grarpamp at gmail.com
Mon Nov 18 18:33:05 UTC 2013


>> People, can we please mind using the proper units.
>
> How is 'bytes' improper when that is the basic transfer unit of TCP/IP,
> and half of the underlying protocols? The only ones who really don't
> care about bytes are the layer 1 guys.

No, routing the global internet occurs at layer 3.
Bandwidth is a commodity, bought and sold on the open
market in units of 'bits per second', from the Tier-1's all
the way down to your ISP/hoster. All of them use routing
and switching hardware from Juniper, Huawei, etc that is
configured in 'bits per second'. When you go to provision
a continuous big bandwidth service such as Tor, bittorrent,
streaming, etc, you ultimately do that in 'bits per second'.
Especially for large bitrates, multiple megabits and up.
Any 'Bytes' shown to you by the provider are simply an
abstraction from the real 'bits' they use internally (and of
particular importance at their billing points with peers [1]).
Bytes are a translated kludge meant to match the 'Bytes'
seen in end user incidental application logs, which
traditionally moved data you owned and managed off disk.

People who sell bandwidth in quantity will look at you like
you're speaking some foreign language when you come
to them wanting to push '30TiB/mo' instead of 100Mbps.
They want to know (how much CAR on) what port you're
going to fill up 24x7x365 so they can buy and bill appropriately.
That's done in DS-x, T-x, OC-x, 10/100/1000/10000...
all bits, not Bytes.

Your dialup, cable, dsl, and fiber lines are all in bits/sec
too [2]. Why in the world should you have to sit there with
a calculator to figure out how you want to fit Tor within that.

[1] You know, the series of tubes.
[2] Excepting any silly transfer caps, that you then have
to decide to eat up all at once at a high (or maximum)
line rate or slowly over time. Which, with constant applications
you don't care about, becomes... guess what... a simple
bps number all over again! You should have used bps from the
start in that case.

>> I know Tor doesn't make it easy because Tor itself incorrectly
>> uses Bytes. But Tor is a network application, and real network
>> apps are measured in 'bits per second',
>
> So, neither scp nor wget are real network applications? Nor ftp, nor firefox?

Correct, in the sense, unless aggregated across many users,
they are non-constant incidental end user applications,
not a part of the real network itself.

> Tor is an overlay application just like bittorrent

Yes. Tor, I2P, torrent/sharing, vpn, overlay nets, software routers,
etc are all network bandwidth services, usually provisioned in the
sense/mindset that they will fill their entire provisioned/intended
bitrate and that one best make plans/headroom/commitment/tolerance
for just that case.

When you go to drop relays on the net, or even get a job on
the net, in reality you're going to be speaking in 'bits per second'.
Everything else 'Bytes' is just a hack made for the
traditional web/ftp people and their logs. Bandwidth providers
and what amount to transit services are not really in a
position to optimize and thus don't care about that sort of logs,
they just tack up a bitrate, pay the same bill every month and
forget about it.

> Is there anything nowadays that does move data on networks
> in finer grain than bytes?

It's not about 'fineness', it's about interop at levels at which
counting and optimizing Bytes is irrelevant. Yes, thankfully
some things like Vuze, Tor head, some OS packet filters,
software routers, and such can be configured in bits/sec.

And as the internet continues growing to support constant
HD video streams down to every curb and datacenter port,
those old style Bytes/caps become doubly irrelevant.
It's bits per second now, just like hardware routers do it.


More information about the tor-relays mailing list