Stuart Cheshire

Stuart Cheshire

Wizard without Portfolio, Apple Computer, Inc.

Research

I worked at Stanford with David Cheriton's Distributed Systems Group and then with Mary Baker's Mosquitonet research group on wireless networking and mobile computing, using Metricom spread-spectrum packet radios and Linux.

Books

Zero Configuration Networking: The Definitive Guide (November 2005): published by O'Reilly Media

Tricks of the Mac Game Programming Gurus (July 1995): Contributing author (networking chapter)

Research Publications

Ruckus WiFi Evaluation. (PDF, April 2006, 15 pages): Evaluation of the MF2900 (base station) and MF2501 (client) 802.11g wireless devices from Ruckus Wireless.

Nagle's Algorithm and Delayed ACK. (HTML, May 2005): TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK.

Consistent Overhead Byte Stuffing, ToN paper. (PDF, April 1999, 15 pages): Stuart Cheshire and Mary Baker, "Consistent Overhead Byte Stuffing." IEEE/ACM Transactions on Networking, April 1999; This is an improved version of the SIGCOMM paper; it is a little longer, but the descriptions are a little easier to understand, and it also includes HDLC in the experiments comparing COBS to other stuffing methods.; Also available in (crude) HTML form.; Also available: C reference implementation to perform COBS encoding and decoding.

Consistent Overhead Byte Stuffing, PhD Dissertation. (Postscript, March 1998): The full 152 pages of my PhD dissertation. Contains everything in the Transactions on Networking paper, and more. Only for the truly enthusiastic.

Consistent Overhead Byte Stuffing, SIGCOMM paper. (Postscript, September 1997, 12 pages): Stuart Cheshire and Mary Baker, "Consistent Overhead Byte Stuffing." SIGCOMM '97, September 1997.; Also available in (crude) HTML form.; Also available are the slides from the SIGCOMM talk (Postscript).

Latency and the Quest for Interactivity. (PDF, November 1996): Stuart Cheshire, "Latency and the Quest for Interactivity". White paper commissioned by Volpe Welty Asset Management, L.L.C., for the Synchronous Person-to-Person Interactive Computing Environments Meeting, San Francisco, November 1996.; Also available in (crude) HTML form.; See also It's the Latency, Stupid, the rant that was the precursor to this paper.

Internet Mobility 4x4. (Postscript, August 1996): Stuart Cheshire and Mary Baker, "Internet Mobility 4x4." SIGCOMM '96, August 1996.; Also available in (crude) HTML form.

Supporting Mobility in MosquitoNet. (Postscript, January 1996): Mary G. Baker, Xinhua Zhao, Stuart Cheshire and Jonathan Stone, "Supporting Mobility in MosquitoNet" Proceedings of the 1996 USENIX Technical Conference, January 1996.

Experiences with a Wireless Network in MosquitoNet. (Postscript, August 1995): Stuart Cheshire and Mary Baker, "Experiences with a Wireless Network in MosquitoNet." Proceedings of the IEEE Hot Interconnects Symposium '95, August 1995. Also republished in IEEE Micro, February 1996.

RFCs

RFC 6887 Port Control Protocol (PCP), April 2013: Category: Standards Track; Abstract: The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.

RFC 6886 NAT Port Mapping Protocol (NAT-PMP), April 2013: Category: Informational; Abstract: This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.

RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers, February 2013: Category: Standards Track; Abstract: This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

RFC 6763 DNS-Based Service Discovery, February 2013: Category: Standards Track; Abstract: This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

RFC 6762 Multicast DNS, February 2013: Category: Standards Track; Abstract: As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.

RFC 6761 Special-Use Domain Names, February 2013: Category: Standards Track; Abstract: This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

RFC 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP), February 2013: Category: Informational; Abstract: One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.

RFC 6709 Design Considerations for Protocol Extensions, September 2012: Category: Informational; Abstract: This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.

RFC 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry, August 2011: Category: Best Current Practice; Abstract: This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.
This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered.

RFC 6281 Understanding Apple's Back to My Mac (BTMM) Service, June 2011: Category: Informational; Abstract: This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices.

RFC 6055 IAB Thoughts on Encodings for Internationalized Domain Names, February 2011: Category: Informational; Abstract: This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.

RFC 5505 Principles of Internet Host Configuration, May 2009: Category: Informational; Abstract: This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.

RFC 5227 IPv4 Address Conflict Detection, July 2008: Category: Standards Track; Abstract: When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem.; This 2008 document is the foundation for the 2005 document RFC 3927, IPv4 Link-Local Addressing. IPv4LL can be viewed as a combination of two simple technologies: a random number generator to pick addresses, coupled with IPv4ACD to tell when it has picked a bad one. However, IETF politics was such that the idea of detecting address conflicts was very contentious, so the more complicated document (random number generator + ACD) was published first, and then the simpler document (ACD alone) was published three years later. If they'd been published in the other order, the IPv4LL document would have been much shorter, because it would have simply referenced RFC 5227 for how to detect address conflicts, instead of duplicating the text.

RFC 4436 Detecting Network Attachment in IPv4 (DNAv4), March 2006: Category: Standards Track; Abstract: The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment.

RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses, May 2005: Category: Standards Track; Abstract: To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.; IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.

RFC 3442 DHCPv4 Classless Static Route Option, November 2002: Category: Standards Track; Abstract: This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless — each routing table entry includes a subnet mask.

RFC 3397 DHCPv4 Domain Search Option, November 2002: Category: Standards Track; Abstract: This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames using DNS.

RFC 3396 Encoding Long Options in DHCPv4, December 2002: Category: Standards Track; Abstract: This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.

Presentations

Zero Configuration networking with Bonjour, Google engEDU talk, November 2005: Presentation given at internal Google engineering meeting, also recorded and made available publicly on Google Video.

Stuart Cheshire on IPv6 Adoption, IETF 72 Technical Plenary Session, Dublin, Ireland, Wednesday 30th July 2008: Panel discussion on "IPv6 Experiences from the Field"

Software Projects

Sleep Proxy Service: The Bonjour Sleep Proxy wakes your Mac automatically when you access it over the network.

iChatAutoLocationStatus: iChatAutoLocationStatus sets your iChat status automatically, according to your network connectivity, which it uses as an indicator of your physical location.

EtherPEG: EtherPEG shows you all the JPEGs (and GIFs) going by on your network.

Bolo: Networked multi-player tank battle game for the Apple Macintosh.

Stuart's Macintosh PPP Scripts for Metricom Ricochet Packet Radios: Two scripts to speed up and simplify use of Metricom's "Ricochet" Radios with Apple Remote Access or Open Transport PPP.

Natural Order: Macintosh System Extension that improves sorting order for items that have numbers in the name.

Witch: Macintosh printer driver for Epson, HP, Canon and Kodak printers

Macintosh Authenticator: User Authentication for Print Accounting

Software Librarian: Licence management for Macintosh applications

Macintosh Programming Notes: A collection of code snippets, bits of advice, and other miscellanea about programming the Mac.

StUU: A super-fast UU decoder (more than 1MB per second on PowerMac 6100/60)

SingleTalk: A local loop-back AppleTalk adev, so that you can keep AppleTalk active without draining the battery power on your PowerBook, and without tying up the serial port that you wanted to connect your modem to.

MetriTalk: A Macintosh AppleTalk driver for Metricom's 900MHz packet radios.

Starmode Radio IP: A Linux packet radio driver for Metricom's 900MHz packet radios.

Linux 2.0.x patches: Various Linux kernel enhancements

RadioScope: This is not my work, but it's listed here because it uses the STRIP protocol (and because it's really cool). RadioScope is a software-controlled digital oscilloscope designed by Elliot Poger. For its interface to the outside world the RadioScope uses a Metricom radio in its "Starmode" packet datagram mode. RadioScope implements the STRIP protocol, and a functional subset of UDP and IP, all in 1800 bytes of Motorola 68HC11 8-bit microcontroller code. A huge testament, I think, to the elegance of datagram protocols. If the RadioScope had used a connection-oriented device like a Hayes modem for its interface to the outside world it would have taken a lot more than 1800 bytes of code to make it work — having to do dial-up/hang-up, connect/disconnect/reconnect, modem initialization strings, etc., etc., etc. Using connectionless UDP datagram packets not only allows anyone anywhere on the Internet to communicate with the RadioScope without having to first "dial" its "modem"; it also allows any number of people to be communicating with the RadioScope at the same time, because you're not limited to only having one person at a time be "connected" to it. All in all, a great piece of work. Check it out!

PPCToolbox over TCP: It's not every day that Steve Jobs shows off your work in his keynote speech to thousands of people at a large conference...

Stuart's Rants

The ATM Paradox (July 1998): Reservations only really work well when you have enough bandwidth that you don't need them.

NBP/IP (Name Binding Protocol over IP) (July 1997): The world is crying out for easier-to-use IP, especially for small-office and home networks. NBP/IP would bring some of AppleTalk's legendary ease of use to IP, allowing IP to be used across the room as well as across the world.

AOL (January 1997): My nightmare trying to set up AOL for my family. I can't imagine how a computer novice copes with this.

Failures count more than Successes (August 1996): User-experience is defined by the times when a computer doesn't work, not by the times when it does.

Visioneer Paperport (August 1996): Great product, lousy company. Anyway, here's a useful tip for Paperport users.

It's the Latency, Stupid (May 1996): Forget bandwidth — latency is the tough problem.; Includes results of performance tests done with a variety of modems, ISDN connections, and "Cable Modems"; See also Latency and the Quest for Interactivity, a white paper covering similar issues.

Stuart's Law of Networkdynamics (May 1996): For every Network Service there's an equal and opposite Network Disservice.

The 'Monopoly' Effect (April 1995): Don't let the weaker players get bored in your multi-player game.

Stuart's Law of Quadratic Reliability (April 1995): Why writing networked games is so hard.

Apple needs better Advertising (September 1994): Maybe I can do better. Well, maybe I can't, but there's no harm trying, right?

Using Video Recorders for Backup (August 1994): A high-speed high-capacity backup system virtually for free. I wonder why no one ever did it.

Software Patents (January 1994): Why Software Patents threaten to cripple progress in the computer industry.

Initial comments on AppleScript (January 1994): What's good. What's bad.

Smarter Power Management for Laptop Computers (October 1993): Humans may be unpredictable, but application software often isn't. Why make the OS guess when the next disk access is going to happen, when a simple API could allow applications to tell it?

Billions and Trillions: What is this thing with American billions anyway?

Personal Data

"Magazine-style" biography: for magazines and academic publications that need a brief description of who I am and what I've done.

Curriculum Vitae (Resume): in Adobe Postscript form and; in Microsoft Rich Text Format (RTF) form.

Education and Other History

1998-Present: Wizard without Portfolio, Apple Computer, Inc.

2003: Named at position 19 on the Mac Daily Journal "Power 25" list of the 25 most influential people in the Macintosh industry.

March 1998: Ph.D., Computer Science, Stanford University Computer Science Department, Palo Alto, California, associated with:

David Cheriton's Distributed Systems Group

Stanford Residential Computing

Mary Baker's Operating Systems and Networking Group

June 1996: M.Sc., Computer Science, Stanford University.

June 1994 - September 1994: Summer Intern at Apple Computer working on QuickDraw 3D.

June 1992: M.A., Computer Science, Sidney Sussex College, Cambridge.

June 1988 - September 1990: Software engineer at Madge Networks.

September 1986 - June 1989: B.A. Computer Science, Sidney Sussex College, Cambridge.

September 1980 - June 1986: Bishop Vesey's Grammar School, in Sutton Coldfield, near Birmingham, England.

Bishop Vesey's Grammar School is 500 years old, and when I was there in the 1980s, it had no computer science program whatsoever, I think because they assumed that computers would be merely a passing fad. This may not have been a bad thing, because my enthusiasm for the field was not crushed in boring classes. (I expect Bishop Vesey's does teach computer science these days.) To track down old friends, take a look at the registry of old Veseyans.

In 1998, between finishing my PhD and starting work full-time at Apple, I built a deck. Several friends were interested to see my progress, so each day I took some photos with my QuickTake 200 digital camera so you can see my progress. On the subject of the QuickTake 200 camera, I found an absolutely excellent source of information at the QuickTake 200/Fuji DS-7 Users' Page.

2006, Swimming Pool by Swan Pools, San Jose. Unlike my deck, which I built myself, this time we're paying someone else to do the work.

Contact Information

E-mail: Used to be <something>@cs.stanford.edu; had to remove email address because of spam.; Sadly I do not have time to check my old cs.stanford.edu address very often, so that is no longer a good way to reach me. Guessing my new email address is left as an exercise for the reader :-)
Phone: Home +1 (408) 288-6685; Apple +1 (408) 974-3207
Mastodon: @stuartcheshire@mastodon.social

PGP Key