Russ

Author Archives: Russ

Is it Balance, or Workism?

While we tend to focus on work/life balance, perhaps the better question is: how effective are we at using the time we use for work? From a recent study (which you may have already seen):

  • Workers average just 2 hours and 48 minutes of productive device time a day
  • 21% of working hours are spent on entertainment, news, and social media
  • 28% of workers start their day before 8:30 AM (and 5% start before 7 AM)
  • 40% of people use their computers after 10 PM
  • 26% of work is done outside of normal working hours
  • Workers average at least 1 hour of work outside of working hours on 89 days/year (and on ~50% of all weekend days)
  • We check email and IM, on average, every 6 minutes

This is odd—we are starting work earlier, finishing later, and working over weekends, but we still only “work” less than three hours a day.

The first question must be: is this right? How are they measuring productive versus unproductive device time? What is “work time,” really? I know I don’t keep any sort of recognizable “office hours,’ so it seems like it would be hard to measure how much time I spend Continue reading

Webinar: How the Internet Really Works

I’m doing a live webinar at Safari Books Online on March 15thabout the operation of the ‘net—

This live training will provide an overview of the systems, providers, and standards bodies important to the operation of the global Internet, including the Domain Name System (DNS), the routing and transport systems, standards bodies, and registrars.

You can register here.

Troubleshooting Webinar at Safari Books Online

I’m doing a live webinar on troubleshooting on Safari Books on the 19th of April—

Troubleshooting is a fundamental skill for all network engineers, from the least to most experienced. However, there is little material on correct and efficient troubleshooting techniques in a network engineering context, and no (apparent) live training in this area. Some chapters in books exist (such as the Computer Networking Problems and Solutions, published in December 2017), and some presentations in Cisco Live, but the level of coverage for this critical skill is far below what engineers working in the field to develop solid troubleshooting skills.

This course is grounded in the formal half split method of troubleshooting I learned back in electronic engineering applied to networks. It’s probably the most efficient and effective method of troubleshooting available.

You can register here.

Why not OSPF for the Internet Core?

Every now and again (not often enough, if I’m to be honest), someone will write me with what might seem like an odd question that actually turns out to be really interesting. This one is from Surya Ahuja, a student at NC State, where I occasionally drop by to do a guest lecture.

We were recently working on an example design problem in one of our courses, and like a dedicated student I was preparing the State, optimisation, surface sheet ? One of the design decisions was to explain the selection of the routing protocol. This got me thinking. When BGP was being created, were there modifications to OSPF itself considered? … it could have been made possible to just use OSPF across enterprise and the internet. Then why not use it?

A quick answer might go somethign like this: OSPF did not exist when BGP was invented. The IETF working group for OSPF was, in fact, started in 1988, while the original version of BGP, called EGP, was originally specified by Eric Rosen in 1982, some 6 years earlier. The short answer might be, then, that OSPF was not considered because OSPF had not been invented yet. ?

But this quick Continue reading

Research: Service Fabric

Microservices architectures probably will not “take over the world,” in terms of solving every application you can throw at them, but they are becoming more widespread. Microservices and related “staged” design patterns are ideal for edge facing applications, where the edge facing services, in particular, need to scale quickly across broad geographical regions. Supporting microservices using a standard overlay model can be challenging; somehow the network control plane, container placement/spinup/cleanup, and service discovery must be coordinated. While most networks would treat each of these as a separate problem, service fabrics are designed to either interact with, or even replace, each of the systems involved with a single, unified overlay construct.

Kakivaya, Gopal, Lu Xun, Richard Hasha, Shegufta Bakht Ahsan, Todd Pfleiger, Rishi Sinha, Anurag Gupta, et al. “Service Fabric: A Distributed Platform for Building Microservices in the Cloud.” In Proceedings of the Thirteenth EuroSys Conference, 33:1–33:15. EuroSys ’18. New York, NY, USA: ACM, 2018. https://doi.org/10.1145/3190508.3190546.

Kakivaya, et al., begin by considering the five major design principles of a service fabric: modular and layered design; self-* properties; decentralized operation; strong consistency; and support for stateful services. They then introduce Microsoft’s Service Fabric (SF) service, which they Continue reading

Learn to Code?

A long, long time ago, in a galaxy far away, I went to school to learn art and illustration. In those long ago days, folks in my art and illustration classes would sometimes get into a discussion about what, precisely, to do with an art degree. My answer was, ultimately, to turn it into a career building slides and illustrations in the field of network engineering. ? And I’m only half joking.

The discussion around the illustration board in those days was whether it was better to become an art teacher, or to focus just on the art and illustration itself. The two sides went at it hammer and tongs over weeks at a time. My only contribution to the discussion was this: even if you want to be the ultimate in the art world, a fine artist, you must still have a subject. While much of modern art might seem to be about nothing much at all, it has always seemed, to me, that art must be about something.

This week I was poking around one of the various places I tend to poke on the ‘net and ran across this collage. Click to see the full image.

Get the Continue reading

Research: User Fairness as a Quality of Service Problem

In networks, we tend to think of Quality of Service (QoS) relating primarily to classes of traffic. These classes of traffic, in turn, are grounded in application behavior driven by user expectations. For instance, users expect voice communications to be near real time so conversation can take place “normally,” which means delay must be held to a minimum. In order to provide support for the CODECs that make voice communication possible, jitter must be tightly controlled, as well; it is often better to drop a packet outside some jitter bounds than to deliver it. ‘Net neutrality, on the other hand, tends to see the key factor as access to a particular service.

In this diagram, assume Y and Z are two different video streaming services; A is streaming video from Y, while B is streaming from Z. The argument of ‘net neutrality is that the provider who runs the E to F link (or the network represented by that single link) should not be allowed to prefer the service at Y over Z (or the other way around). One of the basic problems with ‘net neutrality is the problem of not preferring one content provider over another is not as Continue reading

1 36 37 38 39 40 162