Thank you so much, Bill! I will spend the next couple of months reflecting on
your answers! They are extremely useful!
All the best!
Nathalie
Sent from my iPhone
On Dec 21, 2015, at 1:20 AM, Bill Woodcock <woody(_at_)pch(_dot_)net> wrote:
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 we!
re 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 t!
o 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