RE: GGF-NMWG: "Hop" definition?

["McKee, Shawn" <smckee@umich.edu>]

Thanks for the comments Martin.

I agree about the VPN "reduction" you mention below...most applications
would only see a "direct" connection to the other host at the end of the
tunnel.  However, I was trying to address what I thought I heard Thilo
mention, which was other ways of subdividing the path AT LAYER 3
depending upon the hardware and the application.  So, I would like a
better example of a set of devices at layer 3 which subdivide a path
where some of the devices are not routers (don't decrement the TTL).
Any suggestions?

The important concept for hop, in my mind, is that it represents the
indivisible unit of a path.  A path depends upon what type of operation.
At layer 3, the TTL is decremented at each router and a path is composed
of the host to router to router, etc. hops.  At layer 2 for ethernet,
the frame MAC address for src and dst are updated at each switch/router
and the path is the set of layer 2 devices between the end points.

What we then do with the hop or path is also context dependent.  If we
can find ways to measure link (or "hop") capacity along the path that is
useful.  If we can access "error" rates for a "hop" that is also useful.


I also agree that "hop" is the "link" plus the "host".  The RFC2230
definition defines the hop_i as the pair <l_i, h_i> where h_i is the ith
host and l_i is the link between h_i-1 and h_i.  This means the
bottleneck "hop" i results from the interaction of host_i-1 and hop_i.


Shawn

-----Original Message-----
From: Martin Stoufer [mailto:MCStoufer@lbl.gov] 
Sent: Wednesday, May 28, 2003 8:32 PM
To: McKee, Shawn
Subject: Re: GGF-NMWG: "Hop" definition?


The work with netest and nscd I have done so far has agreed with the RFC

mentioned. A Router alone is useless unless you are getting  SNMP from 
it. Which I have assumed so far is a pipe dream. Also, prior knowledge 
of a link capacity is nice as a high-water limit, but it does little 
when measuring dynamic throughput.

When we talk about bottleneck hop, it is the current interaction of a 
router (host) and its upstream link that gives us the observation. 
Therefore, static knowledge of each independently is of not much use. 
Measuring current link capacity is still  black magic to me, some input 
for making this observation  would be welcomed.

I heard that more than one of us where havin a tough go of it trying to 
reason with the circular inheritance path/hop/link we were inevitable 
creating. I think this approach, while not atomic as Les and Thilo 
wanted, addresses the abstract and not the concrete concepts of network 
connectivity.


---
I'm not sure a proper layer 3 app would be aware of VPN devices at all. 
 From my experiences with them, they are designed to mask themselves all

interim devices from layer 3. In the case of a traceoute, your example 
reduces to
<HOST>---<HOST>

As an example of my DSL connectivity to LBNL:

<HOST>---<VPN>---<SWITCH>---<ROUTER>---???---<ROUTER>---<VPN>---<ROUTER>
---<SWITCH>---<HOST>

So, a hop in this case would actually be made up of multiple links and 
hosts.

>If we have some layer 3 application, senstive to the VPN devices we 
>have 5 hops:
> 
>--------------------------------"path3"--------------------------------
>-
>--
><HOST>----<SWITCH>----<VPN>-----<ROUTER>-----<ROUTER>----<VNP>---<SWITC
H
>  
>
>>----<HOST>
>>    
>>
>     -------"hop1"------ --"hop2"--  ---"hop3"--- --"hop4"--
>-------"hop5"------
>
>Thus, "hop", and therefore "path", is well defined ONLY for a given 
>context.  We have avoided the layer-1 possibilities for "hops", like 
>repeaters and media converters, but those could utilize the same 
>definition.
>
>Please comment!
>
>Shawn
>
>
>  
>