In ICMP echo, what are the Identifier and Sequence Number fields for, and how does the echoed data let a sender measure round-trip time?
answer
- ICMP has no ports
- responder copies three things back
- port-like session tag
- timestamp inside the data field
basics
~20 sThe Identifier tags a probing session (ICMP has no ports) and the Sequence Number tags each probe; the reply copies both plus the data, so the sender matches replies and times the round trip from a send time it embedded.
solid answer
~40 sAn echo request carries a 16-bit `Identifier`, a 16-bit `Sequence Number` and arbitrary `Data`; RFC 792 and RFC 1122 require the responder to return all three unchanged. Because ICMP has no ports, the identifier works like one: it lets a host running several probes recognise its own replies. The sequence number increments per request, so the sender can pair each reply with its request and detect loss, duplicates and reordering. For round-trip time the sender either keeps a table of send times keyed by sequence number or writes the send time into the data, which comes back verbatim. Only the sender's clock is used, so no clock sync with the responder is needed.
go deeper
Remember that echo carries an Identifier, a Sequence Number and data, and that the reply copies all three back so the sender can pair them up.
Explain the identifier as a port substitute, the sequence number as the loss, duplicate and reordering detector, and RTT computed from a send time echoed in the data.
Show where the numbers mislead: NAT rewriting identifiers, sequence wrap on long runs, and router control-plane delay inflating echo RTT relative to forwarding delay.
Judge when echo RTT is an adequate latency signal for an estate's monitoring and when application-level timing is required, given what an echo exchange does not exercise.
## The echo message layout Both ICMP echo messages share one layout (RFC 792 for IPv4; RFC 4443 gives ICMPv6 the same layout with types `128` and `129`): | Bits | Field | Echo Request | Echo Reply | |---|---|---|---| | 0-7 | `Type` | `8` | `0` | | 8-15 | `Code` | `0` | `0` | | 16-31 | `Checksum` | computed by sender | recomputed by responder | | 32-47 | `Identifier` | chosen by sender | copied from request | | 48-63 | `Sequence Number` | chosen by sender | copied from request | | 64+ | `Data` | any bytes | copied from request | RFC 792 describes the responder's job almost mechanically: swap the source and destination addresses, change the type to `0`, recompute the checksum. The **Identifier**, **Sequence Number** and **Data** go back untouched. RFC 1122 makes the data rule a MUST ("entirely included"), and RFC 4443 says the ICMPv6 data MUST be returned "entirely and unmodified". ## Identifier: which session is this? ICMP has no ports, so a host with several ping sessions running at once needs another way to tell their replies apart. RFC 792 suggests exactly that: the identifier "might be used like a port in TCP or UDP to identify a session". In practice: - A classic implementation puts something per-process in it, conventionally derived from the process ID, so that each running prober can recognise its own replies. - Where the operating system offers an unprivileged ICMP echo socket, the kernel assigns the identifier much as it assigns an ephemeral port, and demultiplexes replies itself. - A NAT treats the identifier as the port-equivalent of an ICMP query session (RFC 5508 calls it the **Query Identifier**) and may rewrite it on the way out and back, so the identifier you sent is the one you get back only after the translator has restored it. ## Sequence number: which probe is this? The sequence number is the per-probe counter. RFC 792 gives the example of incrementing it on each request. With it the sender can: 1. **Match** each reply to the one request it answers, even when replies arrive late. 2. **Count loss**: a sequence number that never comes back is a lost request or a lost reply. 3. **Spot duplicates**: the same sequence number arriving twice means one probe drew two replies — a copy made on the path, or a second device answering for the address. 4. **Spot reordering**: sequence numbers arriving out of order. The field is 16 bits, so it wraps after 65,536 probes; a long-running prober has to tolerate that. ## Measuring round-trip time **Round-trip time (RTT)** is the time from sending a request to receiving its reply. Two designs work: - **Keep state**: store the send time in a local table keyed by sequence number; on a reply, look up the entry and subtract. - **Carry the state in the packet**: write the send time into the `Data` field. Because the responder must return the data unmodified, the reply hands the timestamp back, and the sender subtracts it from the current time without keeping any table. Either way, **only the sender's clock is used**. The responder never interprets the data, so no clock synchronisation between the two machines is needed. That is the key difference from the ICMP **Timestamp** message (type `13`, reply `14`), whose reply carries the responder's own Receive and Transmit timestamps. ```pseudocode send_probe(seq): data = encode(now()) send Echo Request(type=8, id=my_id, seq=seq, data=data) on_echo_reply(pkt): if pkt.type != 0 or pkt.id != my_id: ignore if pkt.seq already seen: count duplicate; return rtt = now() - decode(pkt.data) record(pkt.seq, rtt) ``` ## What the RTT includes The measured RTT is the forward path, the responder's handling time and the return path, for one small ICMP datagram. Routers typically answer echo addressed to themselves in a slower control path than the one that forwards traffic, as an implementation choice, so an echo RTT to a router can look worse than the forwarding delay through it. Treat an echo RTT as a property of that exchange, not as the latency an application's traffic will see.
- Why does a NAT need to touch the echo Identifier at all?A NAT that maps many inside hosts onto one outside address must tell their echo replies apart, and the reply has no port to key on. RFC 5508 therefore treats the Identifier as the Query Identifier of an ICMP query session, the port-equivalent, and a NAT may rewrite it outbound and restore it inbound. Two inside hosts that both chose identifier 1 would otherwise collide on the outside.
- How is echo-based RTT different from what the ICMP Timestamp message measures?Echo RTT uses only the sender's clock: the send time travels inside the data and the responder never reads it. The Timestamp message (type 13, reply 14) asks the responder to write its own Receive and Transmit timestamps, so it can separate the two one-way legs and the responder's handling time, but only if the clocks agree. Echo trades that detail for needing no clock agreement.
It is like posting a numbered letter that contains a note of when you posted it, to a friend who promises to send the same letter straight back unopened. When it returns you read your own note and compare it with your own watch; your friend's clock never matters.
saying these in an interview costs you the question
- The responder increments the sequence number before sending the reply.
- Replies are matched using the IP header's Identification field.
- Echo RTT needs the two hosts' clocks to be synchronised.
- The responder may trim or rewrite the echo data as it likes.
- The Identifier must be zero in every echo request.