On Dec 20, 2015, at 6:58 PM, Nathalie Coupet
<nathaliecoupet(_at_)yahoo(_dot_)com> wrote:
Could someone explain to me:
Sure. Open-ended questions often benefit from a little context which was
lacking from these, but:
1) what a network operator does on a daily basis?
I have been a network operator for the past thirty-some-odd years. Mostly my
days consist of replying to email. Sometimes I log in to a router and debug or
configure something. Often I sit on airplanes.
Speaking more generally, organizationally, the networks I’ve operated (referred
to as ASes, or Autonomous Systems, among operators) forward packets. They
“peer” with other networks across horizontal interconnections, buy “transit”
across upward vertical interconnections, and sell “transit” across downward
vertical interconnections. Economically, they transport packets from the IXPs
where they’re produced, to the sites of consumption. The packets lose quality
but gain expense and utility as they move from the site of production to the
site of consumption. Thus, Internet bandwidth is a perishable commodity, a lot
like a banana, for instance. By that analogy, network operators are like the
trucking companies that move crates of bananas from plantations (where they are
fresh and essentially free, but have no utility) to consumers (who may find
them expensive and somewhat bruised, but are able to derive some pleasure from
eating them).
So: network operators move packets on as direct a route as possible from IXPs
to consumers.
How do you manage a network?
Using SSH and a lot of scripts. It used to be more SSH and a lot of typing,
but that hasn’t scaled sufficiently well in a long time. Before that, it was
telnet and a lot of typing, but that was back before any significant numbers of
bad people had heard of the Internet. Oh, and serial ports. Those started out
as DB-25, then DB-9, then RJ-45, and now mini-USB, emulating serial ports.
People briefly tried bluetooth emulating serial ports, but there were too many
ways for that to go wrong.
But, fundamentally, the answer to your question is: “by typing."
An international link like fiber optic cables linking the US and let's
say…India?
That’s a link, not a network, and is managed very differently from a network.
That’s managed much more like an investment fund.
How can you throttle or speed up the connection?
Those are two very different questions, with very different answers. I’ll take
them one at a time.
Throttling a connection can be done in two ways: you can delay the transmission
of a packet, or you can throw it away.
Delaying a packet is immensely expensive, since you have to put it somewhere,
for the entire period of time that it’s delayed. At scale, the simplest and
most reliable way to delay a packet is to put it into one end of a spool of
fiber, and collect it again from the other end. You might be able to get
two-strand singlemode fiber for USD 0.40/meter. 206,856,796 meters would delay
a packet for one second, at a cost of USD 82,742,718. Of course, you’d also
need to regenerate the signal every few hundred thousand to million meters,
which requires amplifiers, adding another $10M-$20M to the cost, depending what
equipment you use, and how frequently you splice it in. And, of course,
there’s the power needed to run all that. So, in very round numbers, let’s say
you can delay a stream of packets for $100M per second of delay. Of course, if
you’re dealing with trivially small numbers of packets, you could buffer them
in RAM, using a FIFO buffer. Let’s say you were to do that on a single 10gb
circuit: you’d need ten gigabits of RAM, or 1.25 gigabytes of RAM. Seems
cheap, except that you’d also need to create a device to move packets between
the network interfaces and the RAM, and you’d need to make it reliable, and of
course, it would also use space and power and stuff. The up-side is that you
could also use a more complicated buffer management scheme, and retransmit some
packets in an order different than the order in which they were received.
There are, in fact, boxes that do this, but they’re not common. Delaying a
packet runs afoul of the Bandwidth Delay Product. That’s basically just saying
that speed times distance equals cost. If we want to transmit the same number
of packets a longer distance (hold them in our network a longer period of
time), we’ll have to pay more money. We don’t like paying more money. So,
instead, we try to move packets out of our networks as quickly as possible.
That’s referred to as “hot potato,” and is how the Internet (as opposed to
previous networks like the telephone network) optimizes for the most efficient
routing of packets. You don’t want to frustrate that.
The common way of throttling is to do what’s called “QoS” or “Quality of
Service,” which in fact means essentially the opposite: throwing away packets.
If you throw away a packet, the people who were trying to communicate will
either give up, or will try again. You can throw packets away randomly, or you
can choose specific packets to throw away (un)preferentially.
But these are both bad things to do. The first is counterproductive, the
second is evil (since it destroys value that’s already been paid for by a
customer).
So let’s turn to the happier side of your question. How do we speed up a
connection?
That’s easy: faster light. A simple matter of physics, I’m told.
Alternatively, we can make packets that enter our network leave sooner and at a
lower cost, reducing the delay portion of the bandwidth delay product by
drawing a straighter line (going through fewer kilometers of fiber and fewer
pieces of active equipment) between the IXP and the customer. Or we can make
more packets arrive in front of the customer in the same period of time, by
increasing the bandwidth portion of the bandwidth delay product, but then we
need to do something else more efficiently in order to keep the customer’s cost
from going up too much. Our best bet by far is to combine both of those
techniques, giving customers more bandwidth with lower latency, by building
more IXPs closer to customers.
So, that’s what I spend a lot of my time doing, when I’m not operating a
network: building more IXPs, closer to more people. Using our banana analogy,
I’m building lots of banana plantations very near population centers all over
the world, so more people can have more fresher bananas at a lower cost per
banana.
What tools are available to do so?
Delaying packets is straight-forward but expensive. Throwing packets away is
straight-forward but unethical. Both are easily accomplished using the same
tools that networks are already ordinarily built from. Moving more packets
over shorter distances at a lower cost is also straight-forward, and is also
done using the same tools than networks are already built from. None of this
requires anything special, it’s just in how you apply them.
2) What do the daily activities of a ccTLD Manager look like? How do they
differ from those of a gTLD Manager?
TLD managers are generally understood to be the managers of TLD _registries_ as
opposed to _registrars_. The smaller the TLD, the more likely the TLD manager
is to be acting in both roles, however, whether they’re a country-code or
generic TLD. There’s policy-driven separation of registry-registrar roles
that’s imposed on the ngTLDs, I guess, but there’s nobody with authority to
cram that down a cc’s throat. So, the bigger TLDs spend a lot of their time on
infrastructural stability and upgrades, and on their business and technical
interfaces with the registrars that are selling their domains. The smaller
TLDs spend much more of their time dealing with the actual registrants. Nearly
all of them, irrespective of size, spend some time trying to “promote the
brand” of their TLD to potential registrants who may be considering other TLDs.
So, like network operators, I suspect most TLD managers spend a lot of time
typing, and a bit on airplanes.
I hope this helps.
-Bill
signature.asc
Description: Message signed with OpenPGP using GPGMail