Author Archives: Russ
Author Archives: Russ
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):
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
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.
My friends from ECI join the Network Collective to discuss 5G—well worth listening to for an understanding of 5G from a wired network perspective.
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
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.
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
Dave Farber, the Grandfather of the Internet, joins Donald and I on the History of Networking at the Network Collective.
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
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, 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
The consolidation trend also has the potential to affect who participates in the IETF and how those in the industry view the value of standardization. Larger, more prosperous companies tend to have a greater ability to support standardization work, which is often paid for out of R&D or innovation budgets. Continue reading
On this episode of the Network Collective, we are talking about the value of certifications.
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
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
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
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