Subject: [ipcdn] RE: Docs QoS MIB Updates

From: Minnie Lu <[email-masked]>
Date: Wed, 27 Nov 2002 11:40:00 -0800

Hi,  William,

Please also correct the default values as I stated in OSS-O-02214 if you 
have not yet.

Thanks!
Minnie

At 10:04 AM 11/27/2002 -0700, Woundy, Richard wrote:
>Please support William in this request, as we want the QoS MIB to be an IETF
>approved RFC as soon as reasonably possible.
>
>-- Rich
>
>-----Original Message-----
>From: Murwin William-LWM008 [mailto:[email-masked]]
>Sent: Monday, November 25, 2002 9:41 AM
>To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
>Subject: Docs QoS MIB Updates
>
>
>Michael Patrick and Myself are in the process of updating the QoS MIB for
>version 7.
>At this point this version will include changes to the description of Row
>Status Objects,
>as well as the docsQosServiceFlowPkts object.
>If there are any other proposed changes please send them ASAP.
>
>Thanks,
>Will Murwin
>______________________________
>William Murwin
>Broadband Communications Sector
>Motorola Inc.
>Email: [email-masked]
>Tel: (508) 851-8385

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

---

From: Murwin William-LWM008 <[email-masked]>
Date: Thu, 12 Dec 2002 15:20:04 -0500

Currently Mike Patrick and Myself are planning to create 64bit counter for the QoS MIB.
We prefer to create them as new objects:
 
           docsQosPktClassHCPkts 
           docsQosServiceFlowHCPkts 
           docsQosServiceFlowHCOctets 
           docsQosServiceFlowLogHCPkts 
           docsQosServiceFlowLogHCOctets 

These are the only 64bit objects that we are proposing. We don't feel it necessary to create 64bit
counters for Dropped or Delayed Pkts. We plan to deprecate not obsolete the existing 32bit counters, since
we want to be backwards compatible with agents that support only the 32bit counter and that got Docsis 1.1 certified with
QoS MIB v4. The 32bit counters will work in conjunction with the 64bit counter i.e. the 32bit counters will
represent the lower 32bit of the 64bit counter just like the relationship between the ifTable and the ifXTable.
The only outstanding issue is whether to make these new objects optional or required. Since the QoS MIB will still require the 32bit counters, I have no problem with either option. Suggestions?
 
Will Murwin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:00 PM
To: Doug Jones
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail); [email-masked]; Murwin William-LWM008
Subject: RE: Docs QoS MIB Updates

Doug, 
        I like the idea of your proposal. For high-bandwidth, long-lived flows, 32-bit counters are just not large enough. However, it would be preferable to implement the 64-bit counters as new MIB objects and obsolete the existing 32-bit versions. OSS systems which depend upon current 32-bit counters will be very surprised or may even crash if they receive Counter64 objects for OIDs they thought would be only Counter32 objects. Following in the footsteps of the ifXTable, these new MIB objects could have an "HC" substring inserted into their names, giving them names such as: 

docsQosServiceFlowHCPkts 
docsQosServiceFlowHCOctets 
docsQosServiceFlowLogHCPkts 
docsQosServiceFlowLogHCOctets 

David 

	"Doug Jones" <[email-masked]> 
Sent by: [email-masked] 

12/12/02 01:49 PM 

        To:        "Murwin William-LWM008" <[email-masked]>, "Docsis-Oss (E-mail)" <[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]> 
        cc:         
        Subject:        RE: Docs QoS MIB Updates

I'd like to propose the following updates which change several counter32's to counter64.

1.  this change is proposed for the CMTS only (though i'm not opposed to making it for the CM too).

docsQosServiceFlowStatsTable  
    docsQosServiceFlowPkts
    docsQosServiceFlowOctets

2. these are CMTS-only objects, hence the change is only to the CMTS

docsQosServiceFlowLogTable    (-this table is only in the CMTS)
    docsQosServiceFlowLogPkts
    docsQosServiceFlowLogOctets

Changing these objects to counter64 will facilitate managing bandwidth usage on networks.

In RFC 2233, 64-bit counters are required if the interface runs at 20 Mbps or greater.  With DOCSIS 1.1, the downstream runs in excess of 20 Mbps.  With DOCSIS 2.0, both the upstream and downstream interfaces run in excess of 20 Mbps.

These QoS MIB counters are for logical channels (Service Flows) within the bigger DOCSIS channel.  Here are some rough numbers where a 32-bit octet counter would roll over (given the SF is filled with data):

128 kbps:  75 hours
512 kbps:  19 hours
 1 Mbps:   9.5 hours
1.5 Mbps:   6.3 hours
2.0 Mbps:   4.8 hours

With 32-bit counters, on a 1.5 Mbps Service Flow (very common) in order to catch an octet counter before it rolls over, the CMTS would have to be polled about every 5 hours.  With 64-bit counters, polling could occur daily, weekly, or once per billing period, greatly facilitating operations.

DOCSIS is being used more and more for business services, where near constant use of the SF(s) occurs.

The use of counter64 traffic counters at the CMTS is more desirable than having the large counters in the CM.  The CMTS is a trusted network element that allows centralized polling.  CMs are not trusted elements, and counter information stored in the CM can be lost for several reasons, e.g., rebooting the CM, powering off the CM, etc.

doug

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 25, 2002 7:41 AM
To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
Subject: Docs QoS MIB Updates

Michael Patrick and Myself are in the process of updating the QoS MIB for version 7.
At this point this version will include changes to the description of Row Status Objects,
as well as the docsQosServiceFlowPkts object.
If there are any other proposed changes please send them ASAP.

Thanks,
Will Murwin

---

From: "Doug Jones" <[email-masked]>
Date: Thu, 12 Dec 2002 14:49:02 -0500

128 kbps:  75 hours
512 kbps:  19 hours
  1 Mbps:   9.5 hours
1.5 Mbps:   6.3 hours
2.0 Mbps:   4.8 hours

doug

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 25, 2002 7:41 AM
To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
Subject: Docs QoS MIB Updates

Thanks,
Will Murwin

---

From: [email-masked]
Date: Thu, 12 Dec 2002 13:59:37 -0600

Doug,
        I like the idea of your proposal. For high-bandwidth, long-lived 
flows, 32-bit counters are just not large enough. However, it would be 
preferable to implement the 64-bit counters as new MIB objects and 
obsolete the existing 32-bit versions. OSS systems which depend upon 
current 32-bit counters will be very surprised or may even crash if they 
receive Counter64 objects for OIDs they thought would be only Counter32 
objects. Following in the footsteps of the ifXTable, these new MIB objects 
could have an "HC" substring inserted into their names, giving them names 
such as:

docsQosServiceFlowHCPkts

David

        To:     "Murwin William-LWM008" <[email-masked]>, "Docsis-Oss (E-mail)" 
<[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]>
        cc: 
        Subject:        RE: Docs QoS MIB Updates

I'd like to propose the following updates which change several counter32's 
to counter64.

1.  this change is proposed for the CMTS only (though i'm not opposed to 
making it for the CM too).

Changing these objects to counter64 will facilitate managing bandwidth 
usage on networks.

In RFC 2233, 64-bit counters are required if the interface runs at 20 Mbps 
or greater.  With DOCSIS 1.1, the downstream runs in excess of 20 Mbps. 
With DOCSIS 2.0, both the upstream and downstream interfaces run in excess 
of 20 Mbps.

These QoS MIB counters are for logical channels (Service Flows) within the 
bigger DOCSIS channel.  Here are some rough numbers where a 32-bit octet 
counter would roll over (given the SF is filled with data):

128 kbps:  75 hours
512 kbps:  19 hours
  1 Mbps:   9.5 hours
1.5 Mbps:   6.3 hours
2.0 Mbps:   4.8 hours

With 32-bit counters, on a 1.5 Mbps Service Flow (very common) in order to 
catch an octet counter before it rolls over, the CMTS would have to be 
polled about every 5 hours.  With 64-bit counters, polling could occur 
daily, weekly, or once per billing period, greatly facilitating 
operations.

DOCSIS is being used more and more for business services, where near 
constant use of the SF(s) occurs.

The use of counter64 traffic counters at the CMTS is more desirable than 
having the large counters in the CM.  The CMTS is a trusted network 
element that allows centralized polling.  CMs are not trusted elements, 
and counter information stored in the CM can be lost for several reasons, 
e.g., rebooting the CM, powering off the CM, etc.

doug

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 25, 2002 7:41 AM
To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
Subject: Docs QoS MIB Updates

Thanks,
Will Murwin

---

From: "Doug Jones" <[email-masked]>
Date: Thu, 12 Dec 2002 15:33:01 -0500

i would prefer the new counters be required on the CMTS.
 
dj

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 1:20 PM
To: [email-masked]'; Doug Jones
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail); [email-masked]
Subject: RE: Docs QoS MIB Updates

           docsQosPktClassHCPkts 
           docsQosServiceFlowHCPkts 

Will Murwin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:00 PM
To: Doug Jones
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail); [email-masked]; Murwin William-LWM008
Subject: RE: Docs QoS MIB Updates

Doug, 

docsQosServiceFlowHCPkts 

David 

12/12/02 01:49 PM 

128 kbps:  75 hours
512 kbps:  19 hours
 1 Mbps:   9.5 hours
1.5 Mbps:   6.3 hours
2.0 Mbps:   4.8 hours

doug

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 25, 2002 7:41 AM
To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
Subject: Docs QoS MIB Updates

Thanks,
Will Murwin

---

From: Mark Tillinghast <[email-masked]>
Date: Thu, 12 Dec 2002 17:32:38 -0800

Hello,
 
What I would like(if it were possible to carry chain two 32 bit counters
together so that the 32bit functionality would be preserved and if you used
the upper 32 bits you would get a 64 bit counter. This is not a Docsis
issue, but rather runs more core to an SMI issue, if someone is prepared to
take it up, I would do what I could to support it. They would be hero to a
lot of RFC 2233 implementers.
If not, then the HC namespace is an "easy" fix.
 
Thanks,
Mark Tillinghast
National Technical Systems

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:00 PM
To: Doug Jones
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail);
[email-masked]; Murwin William-LWM008
Subject: RE: Docs QoS MIB Updates

Doug, 
        I like the idea of your proposal. For high-bandwidth, long-lived
flows, 32-bit counters are just not large enough. However, it would be
preferable to implement the 64-bit counters as new MIB objects and obsolete
the existing 32-bit versions. OSS systems which depend upon current 32-bit
counters will be very surprised or may even crash if they receive Counter64
objects for OIDs they thought would be only Counter32 objects. Following in
the footsteps of the ifXTable, these new MIB objects could have an "HC"
substring inserted into their names, giving them names such as: 

docsQosServiceFlowHCPkts 

David 

12/12/02 01:49 PM 

        To:        "Murwin William-LWM008" <[email-masked]>,
"Docsis-Oss (E-mail)" <[email-masked]>, "Ipcdn List (E-mail)"
<[email-masked]> 
        cc:         
        Subject:        RE: Docs QoS MIB Updates

Changing these objects to counter64 will facilitate managing bandwidth usage
on networks.

128 kbps:  75 hours
512 kbps:  19 hours
 1 Mbps:   9.5 hours
1.5 Mbps:   6.3 hours
2.0 Mbps:   4.8 hours

With 32-bit counters, on a 1.5 Mbps Service Flow (very common) in order to
catch an octet counter before it rolls over, the CMTS would have to be
polled about every 5 hours.  With 64-bit counters, polling could occur
daily, weekly, or once per billing period, greatly facilitating operations.

The use of counter64 traffic counters at the CMTS is more desirable than
having the large counters in the CM.  The CMTS is a trusted network element
that allows centralized polling.  CMs are not trusted elements, and counter
information stored in the CM can be lost for several reasons, e.g.,
rebooting the CM, powering off the CM, etc.

doug

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 25, 2002 7:41 AM
To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
Subject: Docs QoS MIB Updates

Thanks,
Will Murwin

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 19 Dec 2002 16:10:42 -0700

Doug and William,

I don't have a problem with this current proposal for the new 64-bit
counters for the QoS MIB.

I feel compelled to point out, though, that the IETF MIB doctor has been
re-rooting our MIBs to new OIDs. For example, the recent Subscriber
Management MIB
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-07.txt is
rooted at { mib-2 xx }. Previous versions were rooted at { docsDev 5 }. This
change was due to comments from the MIB doctor during Area Director review.

Note that if the DOCSIS QoS MIB is similarly re-rooted from { docsIfMib 7 }
to somewhere else by the IETF MIB doctor, then the "backwards compatibility"
arguments below will no longer apply.

-- Rich

-----Original Message-----
From: Doug Jones [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:33 PM
To: Murwin William-LWM008; [email-masked]
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail); [email-masked]
Subject: [ipcdn] RE: Docs QoS MIB Updates

dj
-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 1:20 PM
To: [email-masked]'; Doug Jones
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail); [email-masked]
Subject: RE: Docs QoS MIB Updates

Currently Mike Patrick and Myself are planning to create 64bit counter for
the QoS MIB.
We prefer to create them as new objects:

           docsQosPktClassHCPkts 
           docsQosServiceFlowHCPkts 

These are the only 64bit objects that we are proposing. We don't feel it
necessary to create 64bit
counters for Dropped or Delayed Pkts. We plan to deprecate not obsolete the
existing 32bit counters, since
we want to be backwards compatible with agents that support only the 32bit
counter and that got Docsis 1.1 certified with
QoS MIB v4. The 32bit counters will work in conjunction with the 64bit
counter i.e. the 32bit counters will
represent the lower 32bit of the 64bit counter just like the relationship
between the ifTable and the ifXTable.
The only outstanding issue is whether to make these new objects optional or
required. Since the QoS MIB will still require the 32bit counters, I have no
problem with either option. Suggestions?

Will Murwin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:00 PM
To: Doug Jones
Cc: Docsis-Oss (E-mail); Ipcdn List (E-mail);

Doug, 

docsQosServiceFlowHCPkts 

David 

128 kbps:  75 hours
512 kbps:  19 hours
 1 Mbps:   9.5 hours
1.5 Mbps:   6.3 hours
2.0 Mbps:   4.8 hours

doug

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 25, 2002 7:41 AM
To: Docsis-Oss (E-mail); Ipcdn List (E-mail)
Subject: Docs QoS MIB Updates

Thanks,
Will Murwin