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

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 21 Oct 2002 16:57:55 -0600

David,
 
Here are four comments based mostly on MIB compiling this version of the
MIB:
 
1. You need to import IANAifType FROM IANAifType-MIB at the top of the MIB.
 
2. You need to change your date strings to be in extended UTC format, aka
Y2K friendly syntax. You should also reduce the number of REVISION clauses
down to two: one for the original RFC, and one for your RFC version. For
example:
 
docsIfMib MODULE-IDENTITY
        LAST-UPDATED    "200210180000Z" -- October 18, 2002
        ORGANIZATION    "IETF IPCDN Working Group"
        CONTACT-INFO
            "        David Raftus
             Postal: Imedia Semiconductor       
                     340 Terry Fox Drive, Suite 202
                     Ottawa Ontario
                     Canada
             Phone:  +1 613 592 1052 ext.222
             E-mail: [email-masked]
<mailto:[email-masked]>            
 
             IETF IPCDN Working Group
             General Discussion: [email-masked] <mailto:[email-masked]> 
             Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
<http://www.ietf.org/mailman/listinfo/ipcdn> 
             Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
<ftp://ftp.ietf.org/ietf-mail-archive/ipcdn> 
             Co-chairs: Richard Woundy, [email-masked]
<mailto:[email-masked]> 
                        Jean-Francois Mule, [email-masked]
<mailto:[email-masked]> "
        DESCRIPTION
            "This is the MIB Module for DOCSIS 2.0 compliant Radio
             Frequency (RF) interfaces in Cable Modems (CM) and
             Cable Modem Termination Systems (CMTS)."
        REVISION "200210180000Z"
        DESCRIPTION
            "Modified by David Raftus to ..."
        REVISION "199908190000Z"
        DESCRIPTION
            "Initial Version, published as RFC 2670.
             Modified by Mike StJohns to fix problems identified by
             the first pass of the MIB doctor.  Of special note,
             docsIfRangingResp and docsIfCmtsInsertionInterval were
             obsoleted and replaced by other objects with the same
             functionality, but more appropriate SYNTAX."
        ::= { transmission 127 }
 
3. The object docsIfCmtsChannelUtId needs a range, because it serves as an
index for the docIfCmtsChannelUtilizationTable. Should this object have the
same value range of ifIndex, i.e. (1..2147483647)? Or can it be constrained
to a much smaller value, e.g. a maximum of 1024 or 65536?
 
4. Here are the objects that are missing from the compliance statements:
 
W: f(DOCS-IF-MIB.mi2), (698,1) Item "docsIfUpChannelPreEqEnable" is not
contained in any group defined in the current module
W: f(DOCS-IF-MIB.mi2), (1030,1) Item "docsIfSigQExtUnerroreds" is not
contained in any group defined in the current module
W: f(DOCS-IF-MIB.mi2), (1043,1) Item "docsIfSigQExtCorrecteds" is not
contained in any group defined in the current module
W: f(DOCS-IF-MIB.mi2), (1056,1) Item "docsIfSigQExtUncorrectables" is not
contained in any group defined in the current module
W: f(DOCS-IF-MIB.mi2), (1424,1) Item "docsIfCmStatusEqualizationData" is not
contained in any group defined in the current module
W: f(DOCS-IF-MIB.mi2), (2746,1) Item "docsIfCmtsChannelUtilizationInterval"
is not contained in any group defined in the current module
W: f(DOCS-IF-MIB.mi2), (2810,1) Item "docsIfCmtsChannelUtUtilization" is not
contained in any group defined in the current module

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

Hi everyone,
 
Please find attached a draft of the Docsis RF Interface mib v5. The TOC and
compliance statements have not been updated, but suggestions received since
v4 regarding new mib objects have been incorporated after appropriate
massaging.
 
Comments are welcome on this draft until 5pm EST Friday October 25. At that
time an official version of the draft will be prepared for submission to the
IETF last call process, leading to RFC designation.
 
Thanks very much,
Dave
 
************************************
David Raftus
Imedia Semiconductor
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
[email-masked]           
613.592.1052  ext 222
************************************

---

From: "Raftus, David" <[email-masked]>
Date: Tue, 22 Oct 2002 05:15:50 -0700

Hi Bob,
 
Thanks for your comments. Here are replies:
 
1) There is no intention to deprecate the 32 bit docsIfSigQ counters. The
situation is the same as the 32 and 64 bit counters in the
docsIfCmServiceTable introduced last year.
 
2) The new 64 bit counters already have a note saying they are a 64 bit
version of the 32 bit counters. A note could be added to the 32 bit version
to complete the loop, but there is no precedent in other 32-64 bit tandem
counter implementations for this. The 'special' behavior you cite is a
vendor specific implementation detail that would not seem to be supported by
the mib guidelines.
 
3) I haven't yet completed the compliance statements and other supporting
documentation. I wanted to get the mib in the community for comment asap, so
sent it out when the 'meat' was done. Compliance, etc will be done before
the mib goes to the IETF and before it becomes the subject of a Docsis ecr.
 
Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Bob Himlin [mailto:[email-masked]]
Sent: Monday, October 21, 2002 6:14 PM
To: 'Raftus, David'; 'Docsis 20 Reflector (E-mail)'; 'Docsis Oss Reflector
(E-mail)'; 'Ipcdn List (E-mail)'
Subject: RE: [ipcdn] rf mib draft v5 - comment period end Friday Oct 25
 
Regarding the 64-bit docsIfSigQ codeword counters, is it the intent of the
authors to deprecate the 32-bit counters, or to have both 32-bit and 64-bit
counters, similar to ifTable & ifXTable octet counters?  If the intent is to
deprecate the 32-bit counters, the 32-bit objects should be listed as
deprecated, not as current.  If not, perhaps a note in the description of
the 32-bit counters should state that the 32-bit counters are intended to
reflect the 32 LSBs of the 64-bit counters.  This would prevent any unwanted
'special' behavior of the 32-bit counters on rollover, an example of which
might be to reset all the 32-bit counts to 0 when the highest one rolls (a
behavior I have observed in the past).
 
Also, the 64-bit counters are not referenced in any compliance statement.
Given they are not required by compliance statements, do you expect them to
be implemented?
 
Bob
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Raftus,
David
Sent: Friday, October 18, 2002 12:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David
Subject: [ipcdn] rf mib draft v5 - comment period end Friday Oct 25
 
Hi everyone,

 
Thanks very much,
Dave

[email-masked]           
613.592.1052  ext 222

---

From: "Raftus, David" <[email-masked]>
Date: Tue, 22 Oct 2002 05:24:02 -0700

Hi Rich,
 
Thanks - will incorporate.
 
Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Monday, October 21, 2002 6:58 PM
To: 'Raftus, David'
Cc: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
 
David,

 

             IETF IPCDN Working Group

 
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Friday, October 18, 2002 3:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David

 
Thanks very much,
Dave

[email-masked]           
613.592.1052  ext 222

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 25 Oct 2002 12:33:21 -0600

David,

Here are some non-MIB-compiler comments on your draft.

1. In many subsections of section 3.2.5, you refer to "MAC packets as well
as data packets" (e.g. section 3.2.5.1.1, ifOutOctets), or refer to "data
packets as well as MAC layer packets". Would it be correct and more precise
to change "MAC packets" and "MAC layer packets" to "MAC management
messages"?

2. Please remove the extraneous 'n' from the DESCRIPTION of:

docsIfCmtsCmStatusIpAddress OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-only
        STATUS      deprecated
        DESCRIPTION
            "IP address of this Cable Modem. If the Cable Modem has no
             IP address assigned, or the IP address is unknown, this
             object returns a value of 0.0.0.0. If the Cable Modem has
             multiple IP addresses, this object returns the IP address
             associated with the Cable interface.n 
             This object has been deprecated and replaced by
             docsIfCmtsCmStatusInetAddressType and
             docsIfCmtsCmStatusInetAddress, to enable IPv6 addressing
             in the future."
        ::= { docsIfCmtsCmStatusEntry 3 }

3. Please update references [23], [25], and [26] with the most current
versions of these specifications. Note that [16] is not used anywhere, and
refers to an old version of RFI 1.0.

I am still working on some Security Considerations comments for your draft,
that I will send out tonight.

-- Rich

-----Original Message-----
From: Woundy, Richard 
Sent: Monday, October 21, 2002 6:58 PM
To: 'Raftus, David'
Cc: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)

David,

             IETF IPCDN Working Group
             General Discussion: [email-masked]
                        Jean-Francois Mule, [email-masked]"

-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Friday, October 18, 2002 3:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David

Hi everyone,

 
Thanks very much,
Dave

[email-masked]           
613.592.1052  ext 222

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

---

From: "Raftus, David" <[email-masked]>
Date: Fri, 25 Oct 2002 14:17:42 -0700

Hi Greg,
 
Appreciate your point, but this utilization model was actually suggested by
the MSOs.  The statistics are given per physical channel, whereas other
maintained counts accessible through SNMP are per logical channel.
Parameters used in the utilization calculations such as raw bandwidth,
filler bits, etc are not readily available through snmp. 
 
Not to sound like a salesman, but this method also provides a convenient one
line per physical channel summary of utilization stats.
 
Thanks,
Dave

[email-masked]           
613.592.1052  ext 222

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

Hi Dave, 

We have a comment regarding the percentage utilization calculation: 
docsIfCmtsChannelUtUtilization OBJECT-TYPE
       SYNTAX       Integer32 (0..100)
       UNITS        "percent"

We couldn't find a precedent for computing a running percentage 
in any of the existing standard MIBs required by DOCSIS. 
Usually an SNMP agent just reports a set of counter values when 
polled by an SNMP manager. The manager then polls the MIB counters 
at an interval that it sets (ala MRTG) and then computes the delta 
utilization and percentage from these samples.  This would also allow 
multiple managers to poll at independent rates. 

Regards, 
Greg 

"Raftus, David" <[email-masked]> 
Sent by: [email-masked] 
10/18/02 02:55 PM 
        
        To:        "Docsis 20 Reflector (E-mail)" <[email-masked]>,
"Docsis Oss Reflector (E-mail)" <[email-masked]>, "Ipcdn List
(E-mail)" <[email-masked]> 
        cc:        "Raftus, David" <[email-masked]> 
        Subject:        rf mib draft v5 - comment period end Friday Oct 25

Hi everyone, 

  
Thanks very much, 
Dave 

[email-masked]           
613.592.1052  ext 222

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 25 Oct 2002 18:58:44 -0600

David,

One concrete comment on the Security Considerations: please replace the
(non-existent) object 'docsIfCmtsServerQosProfile' with
'docsIfCmtsServiceQosProfile' in the text. This is an error carried over
from RFC 2670.

I am trying to evaluate whether any of the MIB objects are "sensitive",
according to the Security Considerations text in
<http://www.ops.ietf.org/security.html>. In particular, I am wondering
whether the MAC addresses and IP addresses (and how they are related) in the
docsIfCmtsCmStatusTable and docsIfCmtsMacToCmTable are "sensitive". If they
are, we would need to add text similar to the following:

   There are a number of managed objects in this MIB that may contain
   sensitive information. These are:

       < list the objects and state why they are sensitive >

   It is thus important to control even GET access to these objects and
   possibly to even encrypt the values of these object when sending them
   over the network via SNMP.  Not all versions of SNMP provide features
   for such a secure environment.

If we don't get a timely answer for the "sensitive objects" question above,
I would go ahead and publish a draft for WG last-call, incorporating the
rest of the comments from myself and others on the mailing list.

-- Rich

-----Original Message-----
From: Woundy, Richard 
Sent: Friday, October 25, 2002 2:33 PM
To: 'Raftus, David'
Cc: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn
List (E-mail)

David,

-- Rich

-----Original Message-----
From: Woundy, Richard 
Sent: Monday, October 21, 2002 6:58 PM
To: 'Raftus, David'
Cc: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)

David,

             IETF IPCDN Working Group

-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Friday, October 18, 2002 3:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David

Hi everyone,

 
Thanks very much,
Dave

[email-masked]           
613.592.1052  ext 222

---

From: [email-masked]
Date: Fri, 25 Oct 2002 14:35:18 -0500

Hi Dave,

Regards,
Greg

        To:     "Docsis 20 Reflector (E-mail)" <[email-masked]>, "Docsis Oss 
Reflector (E-mail)" <[email-masked]>, "Ipcdn List (E-mail)" 
<[email-masked]>
        cc:     "Raftus, David" <[email-masked]>
        Subject:        rf mib draft v5 - comment period end Friday Oct 25

Hi everyone,
 
Please find attached a draft of the Docsis RF Interface mib v5. The TOC 
and compliance statements have not been updated, but suggestions received 
since v4 regarding new mib objects have been incorporated after 
appropriate massaging.
 
Comments are welcome on this draft until 5pm EST Friday October 25. At 
that time an official version of the draft will be prepared for submission 
to the IETF last call process, leading to RFC designation.
 
Thanks very much,
Dave

[email-masked] 
613.592.1052  ext 222

---

From: [email-masked]
Date: Fri, 25 Oct 2002 18:04:19 -0500

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.

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.

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.

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

10/25/2002 04:17 PM

        To:     "[email-masked]'" <[email-masked]>, "Raftus, David" 
<[email-masked]>, "Docsis 20 Reflector (E-mail)" 
<[email-masked]>, "Docsis Oss Reflector (E-mail)" 
<[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]>
        cc: 
        Subject:        RE: rf mib draft v5 - comment period end Friday Oct 25

Hi Greg,
 
Appreciate your point, but this utilization model was actually suggested 
by the MSOs.  The statistics are given per physical channel, whereas other 
maintained counts accessible through SNMP are per logical channel. 
Parameters used in the utilization calculations such as raw bandwidth, 
filler bits, etc are not readily available through snmp. 
 
Not to sound like a salesman, but this method also provides a convenient 
one line per physical channel summary of utilization stats.
 
Thanks,
Dave

[email-masked] 
613.592.1052  ext 222

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 25, 2002 3:35 PM
To: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector 

Hi Dave, 

Regards, 
Greg 

 
        To:        "Docsis 20 Reflector (E-mail)" 
<[email-masked]>, "Docsis Oss Reflector (E-mail)" 
<[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]> 
        cc:        "Raftus, David" <[email-masked]> 
        Subject:        rf mib draft v5 - comment period end Friday Oct 25

Hi everyone, 

  
Thanks very much, 
Dave 

[email-masked] 
613.592.1052  ext 222

---

From: "Raftus, David" <[email-masked]>
Date: Mon, 28 Oct 2002 06:36:34 -0800

Hi Minnie,

Thanks for your suggestion. I don't have an issue with increasing the upper
range of this object from 1522 to 65535. The limit of 1522 was chosen when
the object was created since it seemed to be an accurate value that would
not require change. This has proven to be short-sighted.

Thanks,
Raftus (:))

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]]
Sent: Friday, October 25, 2002 3:04 PM
To: Raftus, David
Cc: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail); [email-masked]

Hi, Raftus,

    There is conflict between RFI spec. and the following MIB object range

  docsIfQosProfMaxTransmitBurst OBJECT-TYPE
         SYNTAX      Integer32 (0..1522)  <===========
         MAX-ACCESS  read-create
         STATUS      current
         DESCRIPTION
             "The maximum number of bytes that may be requested for a
              single upstream transmission. A value of zero means there
              is no limit. Note: This value does not include any
              physical layer overhead.
              MUST NOT be changed while this row is active."
         REFERENCE
             "Document [25] from References, Appendix C.1.1.4."
         DEFVAL { 0 }
         ::= { docsIfQosProfileEntry 9 }

In RFIv1.1 (C1.1.4.6) and RFIv2.0 (C1.1.4.6), it defined 2 bytes and does
not have upper limit to 1522.    This conflict exists in v4 version which
is in use by OSSI spec. (1.1, and 2.0).

  Any reason for MIB to have such upper limit ? If not, would you please
correct this error in the MIB file ?

Thanks a lot !
Minnie

At 12:55 PM 10/18/2002 -0700, Raftus, David wrote:

>Ottawa Canada
>[email-masked]************************************
>58147a.jpg581498.jpg
>
>
>
>

---

From: "Raftus, David" <[email-masked]>
Date: Mon, 28 Oct 2002 10:54:45 -0800

Hi Minnie,

Please see oss-n-02106/oss2-n-02107.

Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]]
Sent: Monday, October 28, 2002 1:52 PM
To: Raftus, David
Cc: 'Minnie Lu'; Docsis 20 Reflector (E-mail); Docsis Oss Reflector
(E-mail); Ipcdn List (E-mail); Rich Woundy (Work) (E-mail)
Subject: RE: rf mib draft v5 - comment period end Friday Oct 25

Hi, Raftus,

Thanks a lot for fixing the conflicts.
By the way, before v5 is accepted by CableLabs, I think that we need an ECR
for v4 for OSSI spec..

Thanks!
Minnie

---

From: "Greg White" <[email-masked]>
Date: Tue, 29 Oct 2002 13:31:23 -0700

I agree with Margo's clarification.

-Greg

-----Original Message-----
From: Margo Dolas [mailto:[email-masked]]
Sent: Monday, October 28, 2002 1:49 PM
To: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector

Dave,

I think that you misunderstood what I meant by granted slots.  Granted slots
are unicast slots granted to a real CM on the plant; grants assigned to the
null SID and contention regions are not considered granted slots.

I would also argue that UGS grants from the CMTS increase the utilization
figure
whether or not the channel is idle.  This is because whether the CM uses it
or not,
it is still bandwidth that the CMTS cannot grant to another CM.

However, in order to measure the utilization of contention regions, the
actual
upstream burst needs to be measured.

I think that the text needs to be updated to adequately cover both of these
cases.
I suggest the following clarification -

              Upstream Channel Utilization Index:
              The upstream channel utilization index is expressed as a
              percentage of minislots utilized on the physical 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 physical channel.  For all other
              regions, utilized minislots are those in which the CMTS
              granted bandwidth to any unicast SID on the physical channel.

If the vendor community chooses to go along with Greg's suggestion, I
believe
that this distinction needs to be maintained.

Regards,
Margo

-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, 28 October, 2002 9:32 AM
To: 'Margo Dolas'; Raftus, David; Docsis 20 Reflector (E-mail); Docsis
Oss Reflector (E-mail); Ipcdn List (E-mail)
Subject: RE: rf mib draft v5 - comment period end Friday Oct 25

Hi Margo,

Thanks for your comments. However, I don't think your suggestion would
provide an actual real-world view of utilization as required by the MSOs.
Since the scheduler cannot have any gaps in the upstream, your model would
always provide close to 100% utilization, which is deceptive.  Also, UGS
grants from the CMTS when the channel is idle may increase the utilization
figure.

I do think that the actual upstream bursts received from the CM provide a
truer picture of utilization.

Thanks,
Dave

[email-masked]
613.592.1052  ext 222

-----Original Message-----
From: Margo Dolas [mailto:[email-masked]]
Sent: Friday, October 25, 2002 2:46 PM
To: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector

Dave,

I have one minor comment on the docsIfCmtsChannelUtilization object.

For granted slots, once the CMTS has made the grant, that bandwidth is
"utilized" regardless of whether the CM actually puts a burst in that slot
or not.  I think that the wording in the mib spec needs to be modified so
that any grant counts as "utilized".

How about the following text change?
Replace -
              Upstream Channel Utilization Index:
              The upstream channel utilization index is expressed as a
              percentage of minislots for which the CMTS received an
              upstream burst from any CM on the physical channel, regardless
              of burst type.

With -
              Upstream Channel Utilization Index:
              The upstream channel utilization index is expressed as a
              percentage of minislots for which the CMTS granted bandwidth
to
              any CM on the physical channel, regardless of burst type.

Regards,
Margo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Raftus, David
Sent: Friday, 18 October, 2002 3:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David
Subject: rf mib draft v5 - comment period end Friday Oct 25

Hi everyone,

Thanks very much,
Dave

[email-masked]
613.592.1052  ext 222