Re:Re:Re: FddiTime (Time and Time again)

[dsiinc![e-mail]]

After seeing this discussion going in circles, I'm sorry I brought 
the whole thing issue!  :-)

I'd like get past this, but I don't think I've seen consensus for 
ANY proposal yet.  I don't think this is that important of an issue,
and am surprised it's taking this long to resolve.

SMT currently uses three types for representing time:

    A.  FddiTimeStamp - 64-bit integer : semantics of 80 ns units.

    B.  FddiTime - 32 bit integer : semantics of 80 ns units.

    C.  FddiTimerTwosComplement - 32 bit integer: semantics of unsigned 
	    twos complement 80 ns units.

To simplify things in rfc-1285, we omitted all FddiTimeStamp variables
and converted FddiTimerTwosComplement types to FddiTime.  
For the new mapping, the idea is to restor the FddiTimeStamp variables
and nail down a good representation for the other two types.
As I understand the discussion, the new mappings fall
into the following categories:

    1.  FddiTimeStamp:  There seems to be only one proposed encoding:

	A.  OCTET STRING (SIZE (8)), with semantics indicating that
	    it is really a 64-bit INTEGER, encoded in network order.
	    The real concern is that everyone encodes (and decodes) 
	    the same way.  No one seems to care that these are not
	    in microsecond resolution.


    2.  FddiTime:  There are two proposed encoding rules:

	A.  INTEGER, with semantics of 80 ns units.
	    Advantage:  Most closely matches SMT.
	    Disadvantage:  Values with high bit set may show up on "dumb" 
	        manager stations a negative.  This is not a problem, since 
		there are only a few variables that use this encoding and 
		they typically won't need anything in that range.
		
	B.  INTEGER, with semantics of 1 microsecond units. 
	    Advantage:  Easier to read on management stations.  No
	        problem representing large values.
	    Disadvantage:  Loss of resolution.  It would be impossible
		to specify exact timer values as the minimum resolution
		of the 1 microsecond timer would be (12.5) 80 ns units.


    3.  FddiTimerTwosComplement:  There are at least three proposed encodings:

	A.  INTEGER, with semantics of unsigned twos complement 80 ns units.
	    Advantage:  Most closely matches SMT.
	    Disadvantage:  Almost every value will have its high bit
	        set.  "Dumb" managers will always display negative numbers.  
		"Hard" to convert to format non-FDDI people understand.

	B.  INTEGER, with semantics of 1 microsecond units. 
	    Advantage:  Easier to read on management stations.  No
	        problem representing large values.
	    Disadvantage:  Loss of resolution.  It would be impossible
		to specify exact timer values as the minimum resolution
		of the 1 microsecond timer would be (12.5) 80 ns units.
		Potential confusion for people who understand FDDI 
		networks and who are using management station to
		diagnose problems.

	C.  OCTET STRING (SIZE (4)), as with FddiTimeStamp
	    with semantics of either 80 ns units or unsigned
	    twos-complement units.  
	    Advantage:  Gets around the "negative" number issue.
	    Disadvantage:  Hexs strings may be harder to convert.
	
I agree with James Reeves (Synoptics) that, if possible, the encodings
should match SMT as closely as possible.  There is no point in trying
to second guess ANSI and try to determine a "new, improved" encoding when
the ones we have are sufficient.  I don't understand why people (or
SNMP managers) who don't understand FDDI will care what form the numbers 
are in, as they would have no meaning to them in any form.  The people 
(or SNMP managers) that do understand FDDI will have to understand
whatever format we decide on, so it doesn't really matter to them.
All the conversions we are talking about are simple 1-line conversions.  
This is not rocket science.

    80 ns -> microsecond		: (number / 12.5)
    uns. two comp. 80 ns -> microsecond	: ((~number + 1) / 12.5)

The other reason why I'm opposed to this is that we haven't yet
addressed the other issues, and I'd hate to specify something
(with the intent of making it more friendly) that actually makes
FDDI harder to manage.  Are we sure the loss of resolution going
from 80 ns units to microseconds is acceptable in all cases?  
I'm not trying to make a major issue, but people designing real-time,
large, or high utilization networks will not have the ability to
set hardware timers with as much accuracy as they can with SMT.

If we switch to microseconds, there is no way to exactly represent the 
values commonly used by the hardware.  Unless someone wants to tell me 
why that a resolution of 12.5-byte clocks is never important in 
synchronous or priory transmission, I don't see how we can justify 
the conversion.

In summary, my opinion is that since we can't seem to decide, the best 
thing we could do is represent everything as closely as possible to the
SMT format as possible and move on to the next issue.  

Thus, for the vote counters, I vote for:

    FddiTimeStamp encoded as OCTET STRING (size (8)) representing 80 ns units.

    FddiTime encoded as INTEGER that represents 80 ns units.

    FddiTimerTwosComplement encoded as INTEGER that represents
	unsigned twos complement 80 ns units, regardless of the fact 
	that with "dumb" managers it will appear as a negative number.

Ron Mackey			Distributed Systems International, Inc.
[e-mail]			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057