The Network Protocol Battle:
A tale of hubris and zealotry
Dear KV, I’ve been working on a personal project that involves creating a new network protocol. Out of curiosity, I tried to find out what would be involved in getting an official protocol number assigned for my project and discovered that it could take a year and could mean a lot of back and forth with the powers that be at the IETF. I knew this wouldn’t be as simple as clicking something on a Web page, but a year seems excessive, and really it’s not a major part of the work, so it seems like this would mainly be a distraction. For now, I just took a random protocol number that I know doesn’t conflict with anything on my network and things seem to work fine. I guess my real question is why would anyone bother to go to the IETF to ask for this unless they were a company that could waste someone’s time on an e-mail campaign to get a properly assigned number?
SAGE: Whitebox Fuzzing for Security Testing:
SAGE has had a remarkable impact at Microsoft.
Most ACM Queue readers might think of "program verification research" as mostly theoretical with little impact on the world at large. Think again. If you are reading these lines on a PC running some form of Windows (like 93-plus percent of PC users--that is, more than a billion people), then you have been affected by this line of work--without knowing it, which is precisely the way we want it to be.
Revisiting Network I/O APIs: The netmap Framework:
It is possible to achieve huge performance improvements in the way packet processing is done on modern operating systems.
Today 10-gigabit interfaces are used more and more in datacenters and servers. On these links, packets flow as fast as one every 67.2 nanoseconds, yet modern operating systems can take 10-20 times longer just to move one packet between the wire and the application. We can do much better, not with more powerful hardware but by revising architectural decisions made long ago regarding the design of device drivers and network stacks.
The Hyperdimensional Tar Pit:
Make a guess, double the number, and then move to the next larger unit of time.
When I started in computing more than a quarter of a century ago, a kind elder colleague gave me a rule of thumb for estimating when I would have finished a task properly: make a guess, double the number, and then move to the next larger unit of time. This rule scales tasks in a very interesting way: a one-minute task explodes by a factor of 120 to take two hours. A one-hour job explodes by "only" a factor 48 to take two days, while a one-day job grows by a factor of 14 to take two weeks.