[discuss] Questions

Mon Dec 21 06:20:56 UTC 2015

> On Dec 20, 2015, at 6:58 PM, Nathalie Coupet <nathaliecoupet at yahoo.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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20151220/0536fcbd/signature.asc>