Subject: draft-ietf-intserv-charac-01.txt

From: [email-masked] (Fred Baker)
Date: Wed, 15 Nov 1995 13:22:13 -0800

>This document describes some generic parameters that are carried along
>with reservations.  This is new (you've never seen this before) and has
>some controversial features (such as IP hops, which some of the WG
>chairs think should be carried by RSVP and isn't INT SERV at all).

Controversy is needed at this point? Does introducing controversy at the
eleventh hour help us deliver product at the twelfth?

One man's opinion, but this sounds unwise.

>Number of IP Hops
>
>   The local parameter is the number of IP hops between the last (i.e.,
>   upstream) IS network element and this one.  Observe that since the
>   network element may not be aware of its neighbor on the the upstream
>   path, *the local parameter must be provided to the network element by
>   the setup protocol* (possibly by tracking the TTL value).

I think I know how to calculate IS hops, as those map pretty directly to
RSVP hops. Since I don't know the original value of the IP TTL that the
previous hop used, don't know whether each hop en route (a) decremented TTL
at all or (b) if they did by what decrement, and since (c) even if the
sending TTL were written in he RSVP common header, receiving socket
interfaces normally don't tell us what the received TTL was -

Does some kind soul have an algorithm for me?

>Latency
>
>   This delay
>   may result from "speed-of-light" propagation delay, or from packet
>   processing limitations, or both.

I guess I can see packet porcessing limitations - what is the smallest
amount of time the packet remains in the box without being mailed away?

Question though: how about cut-through implementations, where the packet
starts egress before ingress completes? Do we report a negative latency?

>   The delays are measured in units of one microsecond.
>
>   Note that while the granularity of measurement is microseconds, a
>   conforming element is free to measure delays more loosely.  The
>   minimum requirement is that the element estimate its delay accurately
>   to the nearest 100 microsecond granularity.  Elements that can
>   measure more accurately are, of course, encouraged to do so.
>
>      NOTE: Measuring in milliseconds is not acceptable, because if the
>      minimum delay value is a millisecond, a path with several hops
>      will lead to a composed delay of at least several milliseconds,
>      which is likely to be misleading.

I think you just told me that most commercially available hardware is
unacceptable. I can certainly estimate the amount of time a typical
forwarding event takes, but I'll bet that this comes in the form of a
constant somewhere in the implementation. If the software runs on two
different chassis that have differing clock rates, I'm not sure I can
guarantee that I will know which of them I'm on at the moment.

Also, it's relatively unusual for commercial routers to have microsecond
granularity clocks. Millisecond and small multiples of milliseconds are
reasonably common, and a lot of the equipment that I have worked on with
various employers has used 50 or 100 ms granularities.

What are you trying to say here?

My principal comment on these items is that they are all probably
interesting things to know, but you have provided no motivation for knowing
them or algorithms for using the information when it is known. In some
cases, noted above, their practical knowability is in doubt.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Some ideas are so crazy that only an intellectual could believe them...
        George Orwell