Subject: Re: [ipcdn] docsIfUpChannelTxTimingOffset in RFC2670

From: Rich Woundy <[email-masked]>
Date: Fri, 23 Feb 2001 08:41:56 -0500

James,

This is a good question, which I am now looking at, as part of the RFC2670 
update.

The timing adjustment is defined in the RFI to be "the time by which to 
offset frame transmissions so that frames arrive at the expected mini-slot 
time at the CMTS." I believe that this value is always non-positive, 
because it takes a non-negative amount of time for a frame to be 
transmitted from a CM to a CMTS. (Note: I may misunderstand the polarity of 
this value -- it may be always non-negative. I definitely don't understand 
how this value can be both positive and negative.)

The timing offset is defined in the MIB to be "A measure of the current 
round trip time at the CM, or the maximum round trip time seen by the 
CMTS." I believe that this value is always non-negative. The MIB timing 
offset appears to be (approximately, but not necessarily) double the 
absolute value of the RFI timing adjustment, because it measures round-trip 
rather than one-way time. Perhaps the MIB object is misnamed.

Is this correct?

And is this how folks have implemented the MIB object value?

-- Rich

At 02:57 PM 8/4/2000 -0700, James Yee wrote:
>This was brought up on the side during the last IPCDN meeting in
>Pittsburgh....
>
>In RFC2670 it is defined:
>
>         docsIfUpChannelTxTimingOffset         Unsigned32
>
>whereas in the DOCSIS RFI specs the description for the
>timing adjust TLV has consistently been:
>
>         TX timing offset adjustment (signed 32-bit, units of (6.25 
> microsec/64))
>
>See Table 6-21 of DOCSIS 1.1 RFI.
>
>Is this signed/unsigned inconsistency intentional or
>should the MIB object SYNTAX be changed to be consistent
>with the RFI spec?
>
>Thanks,
>
>James
>
>_______________________________________________
>IPCDN mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Victor Hou <[email-masked]>
Date: Fri, 23 Feb 2001 11:27:09 -0800

A few points of clarification:

1.  The ranging offset is a timing correction employed by the CM in
transmitting a burst.  The ranging offset maintained by the CM should be a
positive number signifying the amount of time that the CM should transmit
earlier relative to its local clock that is a time-delayed replicate of the
CMTS master timebase communicated via the timestamp messages.

2.  The timing adjustment in a RNG-RSP, in contradistinction to the ranging
offset, can be positive or negative and is an adjustment to the ranging
offset used by the CM.  As stated in the RFI, the convention is that a
negative adjustment decreases the amount of time of the overall ranging
offset used by the CM, thus, resulting in a later time of transmission.

3.  The RFI specification does say that the CM, even from the very first
time it sends a RNG-REQ, must apply an "initial ranging offset."  The spec
says that this is to include downstream PHY interleaving delay (depending on
the interleaver mode) and "internal fixed delay."  The purpose of applying
this initial offset is to allow the subsequent ranging procedure to
compensate mainly for the variable and unknown propagation delay.  This
"initial ranging offset" in effect is always incorporated as part of the
ranging offset of the CM.

4.  The ranging offset, defined as the sum of the "initial ranging offset"
and subsequent ranging adjustments from the CMTS, reflects a round-trip
delay between CMTS and CM, not just one direction.  The ranging offset minus
the "initial ranging offset" is roughly the round-trip propagation delay,
not just one direction.

Now, with all that said, the MIB object in question for the CM should be the
ranging offset ("initial ranging offset" plus subsequent adjustments).

The MIB object for the CMTS is trickier.  It currently says "maximum round
trip as seen by the CMTS."  As discussed earlier, the ranging adjustments
made by the CMTS do not include what the CM already adjusted for--the
"initial ranging offset."  Thus, my suggestion is that the wording be
changed to "maximum propagation round trip as seen by the CMTS."  Now, there
is the question of whether the CMTS is expected to sum all ongoing
adjustments of ranging offset for all CMs in order to properly determine and
report this "maximum propagation round trip."   Alternatively, it may be
sufficient for the CMTS to just use the cumulative timing adjustments when
it sends the first RNG-RSP to a CM with the "success" indicator.  That, to
me, should be left as an item of vendor-implementation choice.

Final note:  it is possible that the CM's "initial ranging offset" is not
very accurate.  Thus, it must be understood that the CMTS's perception of
propagation round trip may not be highly accurate--it depends on "how" the
CM calculated its "inital ranging offset."  If the CM overestimates its
"initial ranging offset" and happens to be very close to the CMTS, it is
possible that there will be no adjustment or an initial negative adjustment
by the CMTS, provided that the burst did not arrive so early that it
collided with the previous burst.  So it is possible for the CMTS to
perceive that a CM needs a negative ranging offset (again, from CMTS
perspective, this does not include the "initial ranging offst").  That a
negative ranging offset would be the maximum seen by the CMTS is not
probable.  Thus, it may not be necessary to have a signed value for this MIB
object.

Victor Hou
Pacific Broadband Communications

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Friday, February 23, 2001 5:42 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ipcdn] docsIfUpChannelTxTimingOffset in RFC2670

James,

Is this correct?

-- Rich

---

From: Victor Hou <[email-masked]>
Date: Mon, 26 Feb 2001 19:52:15 -0800

Rich,

Suggest addition of "At the CM" in the DESCRIPTION:

                "A measure of the current round trip time at the CM, or the
                 maximum propagation round trip time seen by the CMTS.  **At
the CM**, used
                 for timing of CM upstream transmissions to ensure
synchronized
                 arrivals at the CMTS. Units are in terms of
                 (6.25 microseconds/64)."

Regards,
Victor

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Monday, February 26, 2001 1:48 PM
To: Victor Hou; [email-masked]
Cc: [email-masked]
Subject: RE: [ipcdn] docsIfUpChannelTxTimingOffset in RFC2670

Victor,

Thanks for the clarifications and corrections. Looks like I erred on the 
following:
(a) the polarity of the timing offsets (always non-negative),
(b) the accumulation of the timing adjustments in multiple Ranging Response 
messages (hence, individual adjustments could be negative or positive), and
(c) the round-trip property of the timing offset (not one-way).

Based on your analysis I'll assume that the MIB object description in RFC 
2670 should have the following minor correction:

    docsIfUpChannelTxTimingOffset OBJECT-TYPE
            SYNTAX      Unsigned32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
                "A measure of the current round trip time at the CM, or the
                 maximum propagation round trip time seen by the CMTS.  Used
                 for timing of CM upstream transmissions to ensure
synchronized
                 arrivals at the CMTS. Units are in terms of
                 (6.25 microseconds/64)."
            REFERENCE
                "DOCSIS Radio Frequency Interface Specification,
                 Section 6.5."
            ::= { docsIfUpstreamChannelEntry 6 }

Comments?

-- Rich