RFC 778

RFC 778 ✨

DCNET Internet Clock Service 🎀

Okay bestie, this one is a Category: Unknown kind of doc (the original doesn't say, so I'm not guessing 💀), written by D.L. Mills of COMSAT Laboratories and dated 18 April 1981 📅. It doesn't obsolete or update anything 🫶. Let's get into it! 🦋

1. Introduction 🌸

Okay so this doc describes the Internet Clock Service (ICS) that every DCNET host provides 💖. It's mainly for clock synchronization and one-way delay measurements with cooperating internet hosts ⏰. It uses the Timestamp and Timestamp Reply messages of the proposed Internet Control Message Protocol (ICMP) ✨. Then, to keep things working with older systems, it also uses the Echo and Echo Reply messages of the Gateway-Gateway Protocol (GGP), but only for a limited time 🥺.

Here's the lowkey important bit: ICMP and GGP datagrams are usually considered tightly bound to the Internet Protocol (IP) itself, so a user on something like a TOPS-20 system can't really get at them directly 🙈. They get treated differently from regular user datagrams in gateways and DCNET hosts, because certain internal queueing mechanisms get bypassed 🔥. That makes them a super useful tool for the most accurate and stable time reference 👑. The main goal of this note is to get other internet hosts and gateways building this service too, so everyone can figure out whether it's feasible to use across the whole community 🌈.

2. ICS Datagrams and Timestamps 🎀

2.1. Datagram Basics 💅

Right now the ICS runs over either ICMP or GGP datagrams 💖. The only real difference is the protocol number: ICMP uses protocol number 1 and GGP uses protocol number 3 🧚. This doc treats them as the same thing and calls them ICS datagrams 🫶. An ICS datagram is an internet header followed by an ICS header, laid out like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |     Code      |            Sequence           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Originate Timestamp                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Receive Timestamp                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Transmit Timestamp                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       ICS Datagram Format

2.2. Sending Side 🍓

The originator fills in all three timestamp fields just before the datagram is forwarded to the net ⏰. Each of these fields holds the local time at origination 💜. The last two are technically redundant, but they're the reason roundtrip delay measurements can be done using remote hosts that don't have timestamping facilities 🙌. The "Type" field can be either 8 (GGP Echo) or 13 (ICMP Timestamp) ✨. The "Code" field SHOULD be zero 💀. The "Sequence" field can hold either zero or an optional sequence number from the user 🦋. The datagram is 36 octets long, counting the 20-octet internet header but not the local-network leader 🎀.

Heads up: the "Code" field SHOULD be zero, so keep that in mind when you're building these 💅

2.3. Receiving Side 💖

The host or gateway that gets an ICS datagram fills in the "Receive Timestamp" field just as it comes in from the net, and the "Transmit Timestamp" just as it's forwarded back to the sender 🫶. It also changes the "Type" field to 0 (GGP Echo Reply) if it was 8, or to 14 (ICMP Timestamp Reply) if it was 13 🔥. Everything else stays the same 🌸.

2.4. Timestamp Format 🌈

Timestamps are in milliseconds from midnight UT, stored right-justified in those 32-bit fields 🕛. Normally all time calculations are done modulo 24 hours in milliseconds 🧚. That's a neat match for operating systems that keep their system clock as ticks past midnight 👑. The millisecond unit lines up with how accurate existing radio clocks are, and with the errors you'd expect from the timestamping process itself 💜.

3. Delay Measurements 🦋

Delay measurements work with any DCNET host, and it's honestly so easy: just send an ICS datagram in the format above and process the reply 💅. Let t1, t2 and t3 be the three timestamp fields of the reply, in order, and let t4 be the time it arrives back at the original sender ⏰. Then the delays, not counting internal processing inside the DCNET host, are:

• (t2 - t1) to the DCNET host
• (t4 - t3) for the return
• (t2 - t1) + (t4 - t3) for the roundtrip

And here's the best part: for the roundtrip, the clock offsets between the sending host and the DCNET host cancel out 😭🫶.

ICS datagrams come back from all DCNET hosts no matter what other connections that host is using at the moment 🙌. The most useful host will probably be the COMSAT-WWV virtual host at internet address [29,0,9,2], which is also the internet echo virtual host formerly called COMSAT-ECH 👑. This virtual host lives in the COMSAT-GAT physical host at internet address [29,0,1,2] 🌈. That one connects to the ARPANET through the COMSAT Gateway, the Clarksburg SIMP, and a 4800-bps line to IMP 71 at BBN 🔥. The roundtrip delay on this path, between the COMSAT-GAT host and the BBN Gateway, is typically 550 milliseconds as the ICS datagram flies 🧚.

As with all DCNET hosts, if the COMSAT-WWV virtual host is down (only possible here if the Spectracom radio clock is down or misbehaving), a "host not reachable" GGP datagram comes back 🥺. In unusual situations, a "net not reachable" or "source quench" GGP datagram could come back instead 🙈. And yep, the references to "GGP" in here will be read as "ICMP" at some appropriate future time 💖.

4. Local Offset Corrections 🎀

All DCNET timestamps are referenced to a designated virtual host called COMSAT-WWV (what else?) with internet address [29,0,9,2] 💅. This host has a Spectracom radio clock that normally gives WWVB time and date to within a millisecond ⏰. The clock synchronization mechanism supplies offset and drift corrections for other hosts relative to this host 🌸. Offsets up to an appreciable fraction of a second still happen regularly, though, because power-line clocks in some machines are hard to track 😭. Here's how to grab a table of the current offsets 🫶.

1. Connect to the COMSAT-GAT host at internet address [29,0,1,2] using TELNET and local echo 📞.
2. Send the command SET HOST HOST. A table with one line per DCNET host should come back. Find the entry under the "Offset" column for the WWV host. That's the offset in milliseconds that should be added to all timestamps generated by either the COMSAT-GAT or COMSAT-WWV hosts to get the correct time as broadcast by WWVB 🔥.
3. Send the command SET WWV SHOW. You'll get a summary of datagram traffic, plus an entry labelled "NBS time." The string after that is the last reply received from the Spectracom unit, in this format:

              <code>  DDD HH:MM:SS  TZ=00

Here <code> is normally <SP> if the WWVB signal is being received correctly, or ? if it isn't 🧚. DDD is the day of the year, and HH:MM:SS is the time past UT midnight 💜. The two digits after TZ= are the time zone, and here 00 means UT 🌈.

4. Close the connection (please!) 🙏💀.

References 📚

[1] ICMP

Postel, J., "Internet Control Message Protocol", RFC 777, USC/Information Sciences Institute, April 1981. 🦋

[2] GGP

Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979. 🌸

Appendix A. PDP11 Header Specification 👑

Okay so here's the ICS header written out in PDP11 code 💻:

;
; GGP/ICMP Header
;
 .       =       0
GH.TYP:  .BLKB   1               ;Message type
GC.RPY   =       0               ;Echo reply
GC.UPD   =       1               ;Routing update
GC.ACK   =       2               ;Positive acknowledgment
GC.DNR   =       3               ;Destination unreachable
GC.SQN   =       4               ;Source quench
GC.RDR   =       5               ;Redirect
GC.ECH   =       10              ;Echo
GC.STA   =       11              ;Net interface status
GC.NAK   =       12              ;Negative acknowledgment
GC.TIM   =       15              ;Timestamp
GC.TRP   =       16              ;Timestamp Reply
GH.COD:  .BLKB   1               ;Message code
GH.SEQ:  .BLKW   1               ;Sequence number
GH.HDR   =       .               ;Beginning of original
                                 ;internet header
GH.ORG:  .BLKW   2               ;Originating timestamp
GH.REC:  .BLKW   2               ;Received timestamp
GH.XMT:  .BLKW   2               ;Transmitted timestamp
GH.LEN   =       .               ;End of timestamp header

Note that all PDP11 word fields (.BLKW above) are "byte-swapped," meaning the order of byte transmission is the high-order byte followed by the low-order byte of the PDP11 word 🫶✨