Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5

From: "Greg White" <[email-masked]>
Date: Fri, 13 Dec 2002 17:31:56 -0700

All,

To try to wrap this up so that Dave can submit v5 before the ietf
deadline, I'd like to suggest the following utilization-counter
proposal.  This proposal is based on a number of suggestions that have
been given both on the reflector, and to me offline.  Since the deadline
is rapidly approaching, we really need to converge on the objects to
include in v5.

This obviously needs to be written up in MIB notation (and I'll leave
that to Dave....:)), but in brief, here is the proposal.

For the downstream utilization counters:

docsIfDownChannelTotalBytes
docsIfDownChannelUsedBytes

I would like to revert to something closer to my original wording for
TotalBytes:
		"The total number of bytes in the DOCSIS Payload portion
of 
		DOCSIS-PID MPEG Packets (i.e. including MAC Frames and 
            stuff_bytes, but not including MPEG Header or 
		pointer_field, nor including any non-DOCSIS-PID MPEG
packets) 
		transported by this downstream channel since CMTS 
		initialization. For the CM this object is reported as
0."

Reference can be made to the RFI spec where the terms "DOCSIS Payload",
"stuff_bytes", "MPEG Header", and "pointer_field" are defined.  This
definition only includes the bytes that are available for transporting
data on the downstream.  By design it does not include other PIDs, nor
does it include the J.83 overhead (RS-FEC, TCM).  Based on this
definition, it is possible for the counters to properly indicate 100%
utilization when all bytes available are used for carrying downstream
traffic.  Also, the concept of counting bytes in the J.83 realm is a
problem since everything is done in terms of R-S symbols (7bits) or
modulation symbols rather than octets.  

For the upstream utilization counters, beyond basic utilization, a
number of additional, detailed counters have been suggested to allow an
operator to debug/manage upstream contention regions.  In order to allow
vendor differentiation, it has been suggested that the additional
counters be made optional.  Also, since the number of counters has
increased, it has been suggested that a separate table be created to
contain them.

MANDATORY CMTS OBJECTS
...UpChannelTotalMinislots - count ALL minislots on the logical channel
(all IUCs, all SIDs, even the NULL SID)
...UpChannelUnicastGrantedMinislots - count all minislots assigned to a
unicast SID
...UpChannelTotalContentionMinislots - count all minislots assigned to a
broadcast or multicast SID
...UpChannelUsedContentionMinislots - count all contention minislots
where a burst is received correctly

OPTIONAL CMTS OBJECTS
...UpChannelCollisionContentionMinislots -  count all contention
minislots where a burst is detected but not received correctly

...UpChannelTotalContentionReqMinislots - count all minislots for IUC1
assigned to a broadcast or multicast SID
...UpChannelUsedContentionReqMinislots - count all contention minislots
for IUC1 where a burst is received correctly
...UpChannelCollisionContentionReqMinislots - count all contention
minislots for IUC1 where a burst is detected but not received correctly

...UpChannelTotalContentionReqDataMinislots - count all minislots for
IUC2 assigned to a broadcast or multicast SID
...UpChannelUsedContentionReqDataMinislots - count all contention
minislots for IUC2 where a burst is received correctly
...UpChannelCollisionContentionReqDataMinislots - count all contention
minislots for IUC2 where a burst is detected but not received correctly
 
...UpChannelTotalContentionInitMaintMinislots - count all minislots for
IUC3 assigned to a broadcast or multicast SID
...UpChannelUsedContentionInitMaintMinislots - count all contention
minislots for IUC3 where a burst is received correctly
...UpChannelCollisionContentionInitMaintMinislots - count all contention
minislots for IUC3 where a burst is detected but not received correctly

-----Original Message-----
From: Victor Hou [mailto:[email-masked]] 
Sent: Thursday, October 31, 2002 4:15 PM
To: Greg White; Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS
Majordomo List; Ipcdn List (E-mail)
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

Just to tighten things a little further, two minor items need to be
addressed with previously suggested wording:

1.  Initial Maintenance regions typically encompass a large number of
mini-slots while the the number of mini-slots actually required to send
the RNG-REQ is small.

Margo's suggested wording was as follows:

"For contention regions, utilized
minislots are those in which the CMTS received an upstream
burst from any CM on the physical channel."

First, it should be stated that the term "regions" as used in the RFI
spec refers to a number of contiguous mini-slots defined by an
Information Element in the MAP.  So, it is understood that a contention
"region" can have multiple transmission opportunities.  However, it is
possible that an informational note would be helpful in the MIB object
description.  But back to the main topic...

For Initial Maintenance regions, the wording above would suggest to
count only the minislots used for the RNG-REQ.  It is not clear what the
original intent was, but since minislots that are allocated for Initial
Maintenance cannot be used for anything else, it appears that the
duration of the complete region, translated into minislots, should be
counted as "utilized slots."  If that is the case, a specific sentence
like the following should be added: "For an Initial Maintenance region,
the minislots for the complete region are considered utilized if the
CMTS received an upstream burst within the region from any CM on the
physical channel."  There is, of course, another alternative--which is
to count all mini-slots allocated to Initial Maintenance as utilized,
whether used or not.  In most normal scenarios, the difference between
the two approaches will be negligible with respect to the reported
utilization, but not necessarily for all.

As for contention REQ and REQ/DATA regions, there may be multiple
opportunities within the region.  And in that case, we should alter the
above to: "For contention REQ and REQ/DATA regions, the minislots for a
transmission opportunity within the region are considered utilized if
the CMTS received an upstream burst within the opportunity from any CM
on the physical channel."

2.  What does it mean to "receive a burst"?

Does this mean a burst of some sort was detected or the burst was
received correctly?  In low Packet Error Rate scenarios, the difference
is completely negligible, but in other cases, that would not be true.  I
believe the intent is to count only correctly received bursts after
forward error correction is performed.

Victor

-----Original Message-----
From: Greg White [mailto:[email-masked]]
Sent: Thursday, October 31, 2002 11:32 AM
To: [email-masked]
Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List;
Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); [email-masked]
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

Does anyone else have an opinion on this?

I will try to flesh out the proposal:

Leave the utilization table as is (with the clarification that Margo
proposed IMO), and add the following objects:

docsIfUpChannelTotalMinislots OBJECT-TYPE
        SYNTAX      Counter64
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "Current count, from CMTS initialization, of minislots 
		defined for this upstream (logical) channel.  This count

		includes all minislots, even those allocated to the NULL

		SID for a 2.0 logical channel which is inactive.  For
the
		CM this object is reported as 0."
        ::= { docsIfUpstreamChannelEntry 20 }

docsIfUpChannelUsedMinislots OBJECT-TYPE
        SYNTAX      Counter64
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "Current count, from CMTS initialization, of minislots 
		utilized on the upstream (logical) channel, regardless 
		of burst type.  For contention regions, utilized 
		minislots are those in which the CMTS received an 
		upstream burst from any CM on the upstream (logical) 
		channel.  For all other regions, utilized minislots are 
		those in which the CMTS granted bandwidth to any unicast

		SID on the logical channel. For the CM this object is 
		reported as 0."
        ::= { docsIfUpstreamChannelEntry 21 }

docsIfDownChannelTotalBytes OBJECT-TYPE
        SYNTAX      Counter64
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
		"The total number of bytes in the DOCSIS Payload portion
of 
		DOCSIS MPEG Packets (i.e. not including MPEG Header or 
		pointer_field, nor including any non-DOCSIS MPEG
packets) 
		transported by this downstream channel since CMTS 
		initialization. For the CM this object is reported as
0."
        ::= { docsIfDownstreamChannelEntry 8 }

docsIfDownChannelUsedBytes OBJECT-TYPE
        SYNTAX      Counter64
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
		"The total number of DOCSIS data bytes transported by
this downstream 
		channel since CMTS initialization. The number of data
bytes is 
		defined as the total number of bytes transported in
DOCSIS Payloads
		minus the number of stuff_bytes transported in DOCSIS
Payloads. For 
		the CM this object is reported as 0."
        ::= { docsIfDownstreamChannelEntry 9 }

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 30, 2002 10:30 AM
To: Greg White
Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List;
Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); [email-masked]
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

We are agreeable with your suggestion. 
And we can compromise for the utilization table if still desired by the
MSOs. 

Regards, 
Greg & Tom C. 

"Greg White" <[email-masked]> 
10/28/02 01:05 PM 
        
        To:        "Raftus, David" <[email-masked]>,
<[email-masked]> 
        cc:        "DOCSIS 2.0 Majordomo List"
<[email-masked]>, "DOCSIS OSS Majordomo List"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]>, "Rich
Woundy (Work) (E-mail)" <[email-masked]> 
        Subject:        RE: [ipcdn] RE: rf mib draft v5 - comment period
end Friday Oct 2 5

All,

Since I originally presented to this group the desire of MSOs to have
channel utilization information, I thought I'd chime in with some
comments.

Dave's comments notwithstanding, I think Tom did raise some interesting
points about the side-effects of making a very simple snapshot view of
channel utilization available via the MIB.  If we can come up with an
alternative that still meets the operators' needs and does not have
these side-effects, then I think it would not be a difficult sell.

Just thinking out-loud here....

If running counters were used, I think the following would be all that
is absolutely necessary for calculating upstream utilization.

1) 64bit counter for raw minislots, per logical channel
2) 64bit counter for minislots used, per logical channel

I don't think that either of these counters, or anything close, is
available now.

In the case of a single logical channel, the calculation is clear: query
both objects at the start of the interval, then at the end, take the
ratio of the two deltas and you get the utilization, in percent, over
the interval.

In the case of two (or more) logical channels, the calculation is not as
straightforward.  Assuming that counter 1 includes minislots allocated
to the null SID (while the logical channel is idle), then the operator
could calculate % utilization for each logical channel, and sum them to
get the total utilization for the physical channel. There is some
ambiguity in the case where initial maintenance slots are shared between
the logical channels, but that exists regardless of how utilization is
reported, and even if not resolved would probably have a negligible
impact on the end result.

The operator would have to use the ifStackTable to associate the logical
channels, since I don't see a simple way of reporting these counters in
aggregate for the physical channel.

So rather than a single MIB object to query to get a snapshot of the
utilization, the operator would (in general) have to identify the
ifIndex of the physical channel in question, query the ifStackTable to
identify all logical channels associated with that physical channel,
then query the two counters on each logical channel at the start and end
of the interval and do the math above.  It certainly isn't as
straightforward as a single MIB object for utilization percentage, but
also doesn't have the side-effects that Tom brought up.

A possible compromise would be to leave the utilization table as is, and
add the two counters above to the docsIfUpstreamChannelTable.  Since the
CMTS probably has to maintain these counters anyway in order to report
utilization, maybe this would not add much overhead.  Something similar
would have to be added to the docsIfDownChannelTable as well.

Thoughts?

-Greg

-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, October 28, 2002 8:21 AM
To: [email-masked]'; Raftus, David
Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector
(E-mail); [email-masked]'; Ipcdn List (E-mail);
[email-masked]; Rich Woundy (Work) (E-mail)
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

Hi Tom,

Thanks for your well-considered comments. I need to state initially
though
that the MSOs have already told us what they want - the channel
utilization
mib design originated with them, not with me. I simply structured their
needs into the mib design. I fear that your proposed changes may be seen
as
an attempt to 'tell the customer what they want', when they already have
expressed their desires.

Please see individual responses inline.

Regards,
Dave

Dave, 

Thanks for the quick response on Greg's email. 

Greg and I were discussing this topic earlier, and we agreed that the
basic
premise behind your proposal (allowing MSOs to view statistics on a
physical
interface) is very sound and quite desirable. We were even discussing
how
many MSOs already acquired and displayed a lot of these statistical
measurements via MRTG calculations of SNMP-acquired counts, so we
acknowledge the value of the statistical measurements. 

We also like the idea of "displaying one line per physical channel
summary
of utilization stats in displays", but the manner in which the data is
displayed seems not to be related to how the data is stored in the MIB.
We
think that the goal of displaying one line per physical channel can be
accomplished in many ways without affecting the manner in which the data
is
stored or sampled. 

There are a few fundamental areas of concern within the draft, so we
wanted
to discuss alternatives to the specific approach that was described in
the
draft. 

Our biggest concern with the existing proposal was the requirement that
there be a fixed sampling interval. We believe several problems can
occur as
a result of that approach. 

1) Consider the case where multiple SNMP managers are accessing the
CMTS.
The biggest problem with the proposal in the draft seems to be the fact
that
it precludes multiple SNMP managers from simultaneously accessing the
statistical data if they have different desired sampling intervals. In
that
case, the last SNMP manager to set the sampling interval wins and
destroys
the resolution of the accesses for all of the other SNMP managers that
were
already accessing the CMTS data. In addition, the other SNMP managers
are
not even aware that their data collection was corrupted without
checking. 

<dave>
If this situation occurs, I believe it would be an MSO management
problem.
Multiple snmp managers with write access to the CMTS would seem to be an
undesirable dangerous situation. Writable parameters in any table could
conceivably be changed by one manager without being known by the others.
I could see the merit in adding an object to record when either when the
most recent interval started, or when it would end.  
<end dave>

2) The problem also shows up if you have a single SNMP manager that is
trying to collect data with high-resolution (short sampling intervals)
and
with low-resolution (long sampling intervals) for the same window of
time.
Unless I am missing something, the proposed approach seems not to
support
this requirement, which we have seen to be desired by MSOs that display
their statistics with MRTG. This is desirable, because the
low-resolution
sampling is useful for displaying long-term average measurements whereas
the
high-resolution sampling is useful for displaying short-term (burst) 
measurements.

<dave>
I do not see that the new utilization table precludes an MSO from doing
this. They are certainly free to use existing counters to setup sampling
intervals, etc as they wish for more complicated statistical scenarios.
The
new utilization table is there for their convenience and at their
suggestion. It provides an easy method of measuring simple physical
channel
utilization.
<end dave>

3) If stored in the fashion that you described and if the sampling
interval
is set up to collect high resolution statistics (with a short sampling
interval), then collecting an approximate low resolution statistic (with
a
long sampling interval) will require the SNMP manager to store ALL of
the
samples that the agent creates with the short sampling intervals and
"averaging the averages". However, to do this averaging of averages, the
SNMP manager's collection process must be synchronized to the sampling
window on the CMTS to sample ALL of the sampling intervals. Otherwise,
it
may miss some of the samples or over-sample a window more than once.
Since
it is not likely that the SNMP manager will be synchronized with the
CMTS
sampling interval, this approximation (using an average of averages) is
unlikely to be correct in a real-world implementation. 

<dave>
Similar reply as to 2). Please view the utilization table as a quick
fairly
accurate summary of activity. This doesn't stop the MSO from gathering
statistics and garnering the more detailed information they want through
other methods available to them.
<end dave>

Because of these deficiencies within the proposed draft, we believe that
MSOs may find the resulting MIB objects to be less useful than you had
originally intended. 

We believe that you can accomplish your goal (of providing MSOs with the
data they need to create the statistics) and circumvent the three
problems
listed above if you slightly modify your approach. We think the modified
approach should be based on counters. 

All of the data required for the statistical measurements (raw
bandwidth,
data passed, etc.) can be passed up as counters. The counters can be
sampled
from each SNMP manager with sampling rates that correspond to their
desired
resolutions. Thus, an SNMP manager can take a first counter sample at
the
beginning of the desired window and a second counter sample at the end
of
the window, and it can then subtract the two counter values and divide
by
the window size to create the average. As a result of this approach,
multiple SNMP managers can access the counters and not interfere with
one
another. In addition, a single SNMP manager can maintain both long-term
and
short-term statistics by taking samples with both short and long windows
that are overlapping one another. We believe that this approach provides
more flexibility in displaying the statistical data that MSOs want.
Using
this counter approach may permit more flexibility and may accommod! ate
the
needs of more MSOs. 

Thanks,
Tom 

Tom Cloonan
CTO- Broadband Division
ARRIS

Phone:  630-281-3050
Fax:       630-955-9870
e-mail:    [email-masked]

************************************
David Raftus
Imedia Semiconductor
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

[email-masked]           
613.592.1052  ext 222
************************************               

-----Original Message-----
From:                  [email-masked]
[mailto:[email-masked]] 
Sent:                 Friday, October 25, 2002 7:04 PM
To:                 Raftus, David
Cc:                 Raftus, David; Docsis 20 Reflector (E-mail); Docsis
Oss Reflector
(E-mail); [email-masked]'; Ipcdn List (E-mail);
[email-masked]
Subject:                 [ipcdn] RE: rf mib draft v5 - comment period
end Friday Oct
25

<< Message:  >>  << File: image001.png >>  << File: image002.jpg >> 

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

---

From: "Margo Dolas" <[email-masked]>
Date: Tue, 17 Dec 2002 13:50:21 -0500

Greg,

I have some concerns with your proposal to edit the rfmib.  I don't believe
the proposed "TotalBytes" counter accurately represents the total available
downstream capacity.  This is because the CMTS will send MPEG null frames,
which do not have the DOCSIS PID, whenever it doesn't have DOCSIS traffic
to send.  (See RFI2, section 7.5, paragraph 5.)  These MPEG null frames
may still represent part of the total downstream bandwidth available to
the CMTS, but using the wording below they would not be included.

Of course, this also results in a misleading view of channel utilization
when "UsedBytes" is compared to "TotalBytes."

A rough example may help to clarify my comment:  Suppose the CMTS is
initialized with on a single 40Mbps downstream.  It has full use of this
channel, i.e. it is not multiplexing DOCSIS frames with video frames.
Immediately after initialization, it transmits one 183-byte DOCSIS frame.
It puts this frame plus one stuff byte into a single MPEG frame which is
transmitted with the DOCSIS PID.  During the next second, the CMTS has no
DOCSIS data so it sends approximately 26,000 null frames with the null PID.
After one second, the TotalBytes and UsedBytes MIBs are read.  Using the
wording below, the value of TotalBytes would be 184 and it would appear
as though the channel utilization were above 99%.  The reality is that
TotalBytes should be about 4.7 million and channel utilization is very
close to 0%.

Extending this example, if the CMTS is now reset, but this time it is
swamped with 4.7 million bytes of DOCSIS data, it could conceivably send all
4.7 million bytes within the first second, in which case it would be
genuinely utilizing nearly 100% of the channel.  The point here is that the
"DOCSIS PID" MPEG stream can expand as needed, subject to limitations of
physical layer bandwidth and CMTS provisioning.

A more detailed understanding of the original intent may be helpful in
developing a more workable approach.

Regards,
Margo

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg White
Sent: Friday, 13 December, 2002 7:32 PM
To: Victor Hou; Greg White; Raftus, David; DOCSIS 2.0 Majordomo List;
DOCSIS OSS Majordomo List; Ipcdn List (E-mail)
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

All,

MANDATORY CMTS OBJECTS

OPTIONAL CMTS OBJECTS

-----Original Message-----
From: Victor Hou [mailto:[email-masked]]
Sent: Thursday, October 31, 2002 4:15 PM
To: Greg White; Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS

Victor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 30, 2002 10:30 AM
To: Greg White
Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List;

Regards,
Greg & Tom C.

All,

Thoughts?

-Greg

-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, October 28, 2002 8:21 AM
To: [email-masked]'; Raftus, David
Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector

Hi Tom,

Regards,
Dave

Dave,

<dave>

<dave>

<dave>

Thanks,
Tom

Tom Cloonan
CTO- Broadband Division
ARRIS

Phone:  630-281-3050
Fax:       630-955-9870

[email-masked]
613.592.1052  ext 222