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

From: George Hart <[email-masked]>
Date: Fri, 1 Nov 2002 16:20:23 -0500

The upstream counters make sense to me, and will be useful in helping
operators determine the utilization of the upstream path. I think I
understand the concept for downstream, although the description for the
object docsIfDownChannelTotalBytes may be confusing. It seems to me this
should represent the downstream capacity available, not the number of bytes
transported which is enumerated by docsIfDownChannelUsedBytes.

One refinement to consider for the upstream is to count minislots available
vs used in the contention region separately from the MAP region. These two
regions are subject to very different access mechanisms and having separate
indications of utilization on these regions could prove helpful.

Thanks to all for the hard work in moving this along so aggressively. It
will be extremely useful to us.

George

-----Original Message-----
From: Greg White [mailto:[email-masked]]
Sent: Thursday, October 31, 2002 2:32 PM
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: "Kirk Friedman" <[email-masked]>
Date: Fri, 1 Nov 2002 16:57:04 -0800

I think George is right.  The description should be simpler for
docsIfDownChannelTotalBytes.  Otherwise it could get very confusing  For
example, the MPEG header/pointer fields are factored out, but not the
Reed-Soloman encoding on the downstream.  I'm also not sure how it applies
to NULL vs. DOCSIS PIDs.   Finally the OSS spec uses the raw downstream
rates for the ifTable (RFC 2233) ifSpeed MIB object. Simplify it to
docsIfDownChannelTotalBytes.  Suggest:

		"The total number of bytes

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
George Hart
Sent: Friday, November 01, 2002 1:20 PM
To: 'Greg White'; [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

George

-----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