Hop count : Proper way to count hops : Router count vs Router count +1

Question

I am very puzzled and confused about the hop-count definition, especially related to RIP metric. Does hop-count have to reflect link count or router count ? Here are two possibilities :

Statement A :
. hop count=number of router crossed
. hop count to a host on the same subnet=0
. RIPv1 metric = hop count+1 ( assuming network cost=1 )

Statement B :
. hop count=number of router crossed+1
. hop count to a host on the same subnet=1
. RIPv1 metric = hop count ( assuming network cost=1 )

Which statement is true ?

Here is my network topology :

(192.168.2.0/24)--Router2--(192.168.1.0/24)--Router1--(192.168.0.0/24)--InternetGateway--z--

There seem to be an ambiguity about hop count : number of crossed routers vs number of links used.

wikipedia quote : “ In computer networking, a hop is one portion of the path between source and destination. Data packets pass through routers and gateways on the way. Each time packets are passed to the next device, a hop occurs. To see how many hops it takes to get from one host to another ping or traceroute/tracepath commands can be used. “

Is the final recipient considered a 'next device', thus implying a hop ?

Here is a local traceroute from host 192.168.2.30, through two routers :

test@ubuntu:~$ sudo traceroute -I 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 60 byte packets
1  192.168.2.1 (192.168.2.1)  0.868 ms  0.831 ms  2.565 ms
2  192.168.1.1 (192.168.1.1)  3.451 ms  3.450 ms  3.438 ms
3  Gateway (192.168.0.1)  5.213 ms  5.219 ms  5.945 ms
test@ubuntu:~$ 

1,2,3 .. is that 3 hops ? The traceroute format is puzzling me.

more, here is my subnet2 routing table ( including RIP entries ) :

test@ubuntu:~$ ip -4 route show
default via 192.168.2.1 dev eth0  proto zebra  metric 2 
192.168.0.0/24 via 192.168.2.1 dev eth0  proto zebra  metric 3 
192.168.0.1 via 192.168.2.1 dev eth0  proto zebra  metric 3 
192.168.1.0/24 via 192.168.2.1 dev eth0  proto zebra  metric 2 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.201  metric 1 
192.168.3.0/24 dev eth2  proto kernel  scope link  src 192.168.3.201  metric 1 
test@ubuntu:~$ 

We have a metric 3 to the subnet 0 ( ie crossing two routers ).

On this side, we crearly have a notion of hop count=link-count

On the other side, the wikipedia page displays a two routers in-line picture with this comment : "An illustration of hops in a network. The hop count between the computers in this case is 2."

More, it links to a page that clearly states that we must count hops over the routers, not hops over the links :

Here, we clearly have a notion of hop count=number of crossed routers.

What is the proper way to compute hop count ? How does it relate to the RIP metric ?
sources :
http://en.wikipedia.org/wiki/Hop(networking
http://www.infocellar.com/networks/ip/hop-count.htm

Notes : relevant quotes in RFC 1058 ( RIPv1 RFC ) :

In simple networks, it is common to use a metric that simply counts how many gateways a message must go through.
...

The main requirement is that it must be possible to represent the metric as a sum of "costs" for individual hops.

Formally, if it is possible to get from entity i to entity j directly (i.e., without passing through another gateway between), then a cost, d(i,j), is associated with the hop between i and j. In the normal case where all entities on a given network are considered to be the same, d(i,j) is the same for all destinations on a given network, and represents the cost of using that network.

To get the metric of a complete route, one just adds up the costs of the individual hops that make up the route. For the purposes of this memo, we assume that the costs are positive integers.

...

     A-----B
         \   / \
          \ /  |
           C  /    all networks have cost 1, except
           | /     for the direct link from C to D, which
           |/      has cost 10
           D
           |<=== target network

Each gateway will have a table showing a route to each network.

However, for purposes of this illustration, we show only the routes from each gateway to the network marked at the bottom of the diagram.

        D:  directly connected, metric 1
        B:  route via D, metric 2
        C:  route via B, metric 3
        A:  route via B, metric 3    

...

The metric of a network is an integer between 1 and 15 inclusive. It is set in some manner not specified in this protocol. Most existing implementations always use a metric of 1. ...

Each host that implements RIP is assumed to have a routing table. This table has one entry for every destination that is reachable through the system described by RIP. Each entry contains at least the following information:

  - The IP address of the destination.

  - A metric, which represents the total cost of getting a
    datagram from the host to that destination.  This metric is
    the sum of the costs associated with the networks that
    would be traversed in getting to the destination.    

...

The metric for a directly-connected network is set to the cost of that network. In existing RIP implementations, 1 is always used for the cost. In that case, the RIP metric reduces to a simple hop-count.

Answer 1

As you quote wikipedia, you should have noticed this clue :

To see how many hops it takes to get from one host to another ping or traceroute/tracepath commands can be used.

Traceroute works by usually sending either UDP, TCP or ICMP packets (what only matters is that the protocol in use is encapsulated into an IP datagram and that an answer on this same protocol can be delivered at the destination IP address) with a TTL field in the IP header equals 1 and then incremented by one after each try until the reply received is different from an ICMP type 11 code 0 packet (ICMP type 11 = Time Exceeded, code 0 = TTL expired in transit).

This use this part of the RFC 1812 :

The Time-to-Live (TTL) field of the IP header is defined to be a
timer limiting the lifetime of a datagram. It is an 8-bit field and
the units are seconds. Each router (or other module) that handles a
packet MUST decrement the TTL by at least one, even if the elapsed
time was much less than a second. Since this is very often the case,
the TTL is effectively a hop count limit on how far a datagram can
propagate through the Internet.

[...]

If the TTL is reduced to zero (or less), the packet MUST be
discarded, and if the destination is not a multicast address the
router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded
in Transit) message to the source

Almost all implementations interpret decrement the TTL by at leat one as decrement the TTL by one and hop measurement is globally considered as the amount of routers packets you sent will go through until they reach their destination.