What does "clock sequence" mean?

Question

RFC 4122 (A Universally Unique IDentifier (UUID) URN Namespace) uses the term "clock sequence":

4.1.5. Clock Sequence

For UUID version 1, the clock sequence is used to help avoid duplicates that could arise when the clock is set backwards in time or if the node ID changes.

If the clock is set backwards, or might have been set backwards (e.g., while the system was powered off), and the UUID generator can not be sure that no UUIDs were generated with timestamps larger than the value to which the clock was set, then the clock sequence has to be changed. If the previous value of the clock sequence is known, it can just be incremented; otherwise it should be set to a random or high-quality pseudo-random value.

Similarly, if the node ID changes (e.g., because a network card has been moved between machines), setting the clock sequence to a random number minimizes the probability of a duplicate due to slight differences in the clock settings of the machines. If the value of clock sequence associated with the changed node ID were known, then the clock sequence could just be incremented, but that is unlikely.

The clock sequence MUST be originally (i.e., once in the lifetime of a system) initialized to a random number to minimize the correlation across systems. This provides maximum protection against node identifiers that may move or switch from system to system rapidly. The initial value MUST NOT be correlated to the node identifier.

For UUID version 3 or 5, the clock sequence is a 14-bit value constructed from a name as described in Section 4.3.

For UUID version 4, clock sequence is a randomly or pseudo-randomly generated 14-bit value as described in Section 4.4.

What does this term mean?

Answer 1

"Clock Sequence" seems like a really misleading name. Based on its definition, a better name might be "Random Component of uuid".

One of uuid's big claims to fame is that if we both generate a UUID value we can be pretty confident that we won't generate the same 128 bit values. This says something about the likely hood of a collision.

If we had a common coordinator or a pre-agreed scheme we could also be confident that we wouldn't experience a collision.

Potential Schemes:

1. Partition Int Space: I get numbers 1-999, you get 1000-1999.
2. Request Reservation: Request 10 numbers and increment a centrally stored max reserved numbers.  You get numbers 1-10.  The next reservation gets 11-20.

The big UUID observation is that if you have quite a few bits (16 in this case), it's pretty unlikely for the next requester to get the same random value.

Lotteries are based on this concept.

Answer 2

The term "clock sequence" is a misnomer. It's just a random number, not a sequence.

The clock sequence exists for one purpose only: to help to avoid duplicates.

The RFC-4122 says that the clock sequence must be changed when:

• the clock is backwards;
• the clock might have been set backwards;
• the generator is not sure if the clock is backwards or not;
• the node identifier has changed;
• node identifiers are getting mixed up.

The clock sequence "can just be incremented" (like a sequence). But it is a MAY, not a SHOULD. I've found some implementations that always randomize the clock sequence here and here.

I think the word "sequence" causes confusion. Although the clock sequence behaves like a sequence when it is incremented, it is in fact a random number.

UUID v1 has 3 parts, namely:

• time (number of 100-nanos since 15 October 1582);
• place (IEEE address);
• some entropy (clock sequence).

In this Github issue you can find a discussion about clock sequence: https://github.com/uuid6/uuid6-ietf-draft/issues/41