Subject: [ipcdn] Proposed Draft 09 descriptions for objects within the docsQosServ iceFlowStatsTable

From: Murwin William-LWM008 <[email-masked]>
Date: Thu, 14 Aug 2003 17:24:29 -0400

Here is the proposed docsQosServiceFlowStatsTable object's descriptions for draft-ietf-ipcdn-qos-mib-09.txt.
I would like to hash out any problem with these descriptions before submitting version 09. Please read thoroughly.
Please respond if you have made comments in the past about these object and you now approve of these descriptions.
I will be out of the office for a couple of days, but will respond to your comments as soon as I return:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "For outgoing service flows,  this object counts the number
                    of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function. For CMTS incoming upstream service
                    flows, this object counts the number of Packets Data PDUs received with
                    a SID in the DOCSIS header that identifies the service flow. CMs not classifying
                    downstream packets may report this object's value as 0 for downstream service flows.
	        This object does not count MAC-specific
                    management messages.
		
		    Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant 
                    size should be counted only on the primary service 
                    flow's counters.	    	
	            
		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the default upstream
		    service flow should increment this object for that service flow.
	                
		    This object does include packets counted by 
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts 
	        and docsQosServiceFlowPHSUnknowns.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 1 }

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC 
	            header HCS to the end of the CRC for all packets counted 
                    in the docsQosServiceFlowPkts object for this row. 
                    Note that this counts the octets after payload header
                    suppression and before payload header expansion has 
	            been applied. CMs not classifying to a
                    downstream service flow may report this object's 
                    value as 0 for downstream service flows.

                    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 2 }

docsQosServiceFlowPHSUnknowns OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of packets received on the service flow
                    with an unknown payload header suppression index for a service flow
	        identified by a SID in the DOCSIS Header of an upstream packet or 
                    an SAID in the downstream BPI Extended Header.

	            This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 5 }

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "For outgoing service flows, this object counts the number 
                    of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay while
	                    enforcing the Maximum Sustained Traffic Rate; or
		   (2) UGS packets dropped due to exceeding the 
	                   Unsolicited Grant Size with a 
	                   Request/Transmission policy that requires such 
                               packets to be dropped.
	  
                     Classified packets dropped due to other reasons must be
	         counted in ifOutDiscards for interface of this 
	         service flow. This object reports 0 for incoming service flows.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 6 }

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only outgoing packets delayed in order to 
		    maintain the Maximum Sustained Traffic Rate. This object 
	            will always report a value of 0 for UGS flows because the
		    Maximum Sustained Traffic Rate does not apply.
	                This object is 0 for incoming service flows.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."	
    ::= { docsQosServiceFlowStatsEntry 7 }

______________________________
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: "Greg White" <[email-masked]>
Date: Fri, 15 Aug 2003 13:15:11 -0600

Hi William,

Sorry if I missed the discussion on this item, but the following
sentence in docsQosServiceFlowPkts doesn't make sense to me:

                    For outgoing service flows,  
                    this object counts the number
                    of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.

What would make more sense to me is the following:

                    For outgoing service flows,  
                    this object counts the number
                    of Packet Data PDUs forwarded on this 
                    service flow.

Also, this is just an editorial item, but two paragraphs in the
description of docsQosServiceFlowPkts use different terminology to mean
the same thing:

		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the default upstream
		    service flow should increment this object for that 
                service flow.

Perhaps it would be better to reword as:

                Particularly for UGS flows, packets sent on the
                primary service flow in violation of the UGS grant 
                size should be counted only by the instance of 
                this object that is associated with the primary 
                service flow.

		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the primary upstream
		    service flow should be counted by the instance of 
                this object that is associated with the primary 
                service flow.

Alternatively, the two paragraphs could be combined:

                Data packets sent on the primary upstream service flow 
                without having been classified there (i.e. unclassified 
                user data packets, or data packets that exceed a 
                UGS grant size) should be counted only by the instance 
                of this object that is associated with the primary 
                service flow.                 

Thanks for the opportunity to review the text before submitting
draft-09.

-Greg

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]] 
Sent: Thursday, August 14, 2003 3:24 PM
To: [email-masked]'; [email-masked]'; DOCSIS OSS Majordomo List;
IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Michael W. Patrick (E-mail)
Subject: [ipcdn] Proposed Draft 09 descriptions for objects within the
docsQosServ iceFlowStatsTable

Here is the proposed docsQosServiceFlowStatsTable object's descriptions
for draft-ietf-ipcdn-qos-mib-09.txt.
I would like to hash out any problem with these descriptions before
submitting version 09. Please read thoroughly.
Please respond if you have made comments in the past about these object
and you now approve of these descriptions.
I will be out of the office for a couple of days, but will respond to
your comments as soon as I return:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "For outgoing service flows,  this object counts the
number
                    of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function. For CMTS incoming
upstream service
                    flows, this object counts the number of Packets Data
PDUs received with
                    a SID in the DOCSIS header that identifies the
service flow. CMs not classifying
                    downstream packets may report this object's value as
0 for downstream service flows.
	        This object does not count MAC-specific
                    management messages.

		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the default upstream
		    service flow should increment this object for that
service flow.
	                
		    This object does include packets counted by 
                    docsQosServiceFlowPolicedDelayPkts, but does not
include
                    packets counted by docsQosServiceFlowPolicedDropPkts

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC 
	            header HCS to the end of the CRC for all packets
counted 
                    in the docsQosServiceFlowPkts object for this row. 
                    Note that this counts the octets after payload
header
                    suppression and before payload header expansion has 
	            been applied. CMs not classifying to a
                    downstream service flow may report this object's 
                    value as 0 for downstream service flows.

docsQosServiceFlowPHSUnknowns OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of packets received on the service flow
                    with an unknown payload header suppression index for
a service flow
	        identified by a SID in the DOCSIS Header of an upstream
packet or 
                    an SAID in the downstream BPI Extended Header.

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "For outgoing service flows, this object counts the
number 
                    of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay
while
	                    enforcing the Maximum Sustained Traffic
Rate; or
		   (2) UGS packets dropped due to exceeding the 
	                   Unsolicited Grant Size with a 
	                   Request/Transmission policy that requires
such 
                               packets to be dropped.
	  
                     Classified packets dropped due to other reasons
must be
	         counted in ifOutDiscards for interface of this 
	         service flow. This object reports 0 for incoming
service flows.

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only outgoing packets delayed in
order to 
		    maintain the Maximum Sustained Traffic Rate. This
object 
	            will always report a value of 0 for UGS flows
because the
		    Maximum Sustained Traffic Rate does not apply.
	                This object is 0 for incoming service flows.

---

From: Minnie Lu <[email-masked]>
Date: Fri, 15 Aug 2003 16:55:50 -0700

Hi, William and Greg,

Thanks a lot for letting me review the text before submitting draft-09.
  I have some comments/questions.

1. docsQosServiceFlowPkts:
  I feel the same as Greg's comment.  Maybe I missed the discussion long 
time ago and sorry to bring this up again.  First of all, I don't 
understand why the word "classified" is needed.

   If the word "classified" is really needed, how about CMTS unclassified 
DOWNSTREAM users data packets forwarded to the default DOWNSTREAM service 
flow ?

2. docsQosServiceFlowOctets :
    You have already had
      "The number of octets from the byte after the MAC
       header HCS to the end of the CRC for all packets counted
      in the docsQosServiceFlowPkts object for this row. "

      Do you still need the following ? To me it is redundant.
      " CMs not classifying to a
         downstream service flow may report this object's
          value as 0 for downstream service flows."

      By the way, would you please take the description in  the 
SP-RFIv2.0-I04-030730 C.2.2.5.5 Assumed Minimum Reserved Rate Packet Size 
into consideration for the octets count ? Quoted as below.

      "If the Service Flow sends packets of a size smaller than this 
specified value, such packets will be treated as being of the size 
specified in this parameter for calculating the minimum Reserved Traffic 
Rate and for calculating bytes counts (e.g., bytes transmitted) which may 
ultimately be used for billing."

     This parameter could also be used by upstream according to the same 
RFI spec section 10.2.7 Table 10-4.  For CMTS, this is related to how the 
bytes counts for RECEIVING packets.

     Thanks a lot !
    Minnie

---

From: Murwin William-LWM008 <[email-masked]>
Date: Thu, 28 Aug 2003 16:08:09 -0400

Sorry about that Minnie,

	I was about to send an email to you addressing this topic, and got pulled into a meeting.
	The description from the SP-RFIv2.0-I04-030730 C.2.2.5.5 should be clarified, this is not meant for 
	Billing but rather is used for Admission Control for QOS which is used to assume the worst case per 
	packet overhead for minimum size packet. Customers should not be charged for the extra bytes added in 
	the token bucket algorithm so that the packet size is equal to the assumed minimum reserved rate packet 
	size.

	We recommending changing the Spec SP-RFIv2.0-I04-030730 C.2.2.5.5, so that this does not sound as if
	the added bytes are billable.

Thanks,
Will 

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]]
Sent: Thursday, August 28, 2003 3:10 PM
To: Murwin William-LWM008
Cc: 'Margo Dolas'; Pollak, Lucy; 'Minnie Lu'; Greg White; DOCSIS OSS
Majordomo List; IPCDN (E-mail) (E-mail); Michael W. Patrick (E-mail)
Subject: RE: [ipcdn] Proposed Draft 09 descriptions for objects within
the docsQosServ iceFlowStatsTable

Hi, William,

   Thanks for letting me review the description.  I did not see my comments 
below in the docsQosServiceFlowOctets.

>bytes counts for RECEIVING packets.

docsQosServiceFlowOctets.
                       been applied.

  Thanks a lot !
  Minnie

At 02:09 PM 8/28/2003 -0400, Murwin William-LWM008 wrote:
>I would like to thank all of you that have commented on the descriptions 
>of the  docsQosServiceFlowStatsTable objects. For those of you who have 
>made comments please responded back if your are satisfied with the 
>descriptions of these objects.
>
>Here is the revised proposed text:
>
>                       number of Packet Data PDUs forwarded to this
>                     service flow. For CMTS incoming upstream service flows,
>                     this object counts the number of Packets Data PDUs
>                         actually received on the service flow identified 
> by the SID
>                         for which the packet was scheduled.
>                     CMs not classifying downstream packets
>                         may report this object's value as 0 for 
> downstream service
>                     flows. This object does not count MAC-specific
>                     management messages.
>
>                     size should be counted only by the instance of this 
> object
>                         that is associated with the primary service flow.
>
> this
>                         object that is associated with the primary 
> service flow.
>
>                       been applied.
>     DESCRIPTION    "For CMTS incoming upstream service flows, this object
>                       counts the number of packets received
>                     with an unknown payload header suppression index.
>                         The service flow is identified by the SID for 
> which the
>                         packet was scheduled.
>
>                         On a CM, only this object's instance for the primary
>                         downstream service flow count packets received 
> with an
>                         unknown payload header suppression index. All other
>                         downstream service flows on CM report this 
> objects value
>                         as 0.
>
>                         All outgoing service flows report this object's 
> value as 0.
>
> service
>                     flows.
>     DESCRIPTION    "This object counts only outgoing packets delayed in order
>                       to maintain the Maximum Sustained Traffic Rate. This
>                     object will always report a value of 0 for UGS flows
>                     because the Maximum Sustained Traffic Rate does not
>                     apply. This object is 0 for incoming service flows.
>
>Thanks,
>Will
>From: Margo Dolas [mailto:[email-masked]]
>Sent: Monday, August 18, 2003 6:13 PM
>To: Pollak, Lucy; 'Minnie Lu'; Greg White; Murwin William-LWM008
>Cc: DOCSIS OSS Majordomo List; IPCDN (E-mail) (E-mail); Michael W.
>Patrick (E-mail)
>Subject: RE: [ipcdn] Proposed Draft 09 descriptions for objects within
>the docsQosServ iceFlowStatsTable
>
>
>William,
>
>I believe that the intent of bringing up classifiers in the
>docsQosServiceFlowPkts was to exclude the counting of packets
>discarded due to rate shaping.  How about adding a phrase along those lines,
>something like "... not discarded due to rate shaping" to the end of either
>Greg or Minnie's suggested text?
>
>With regards to PHSUnknowns on the downstream, I believe that if counted,
>PHSUnknowns on the downstream must be counted on the primary flow, and
>should be 0 for other flows.  I think that this is the only possible
>implementation for the CM.  Besides the issues raised by Lucy, if the packet
>is PHS suppressed and the PHS rule is unknown, it cannot be classified (the
>data used for classification of the packet is suppressed), so it can't be
>counted on the appropriate flow.  Perhaps the text can be clarified along
>these lines?
>
>Regards,
>Margo
>
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Pollak, Lucy
>Sent: Sunday, 17 August, 2003 5:35 AM
>To: 'Minnie Lu'; Greg White; Murwin William-LWM008
>Cc: DOCSIS OSS Majordomo List; IPCDN (E-mail) (E-mail); Michael W.
>Patrick (E-mail)
>Subject: RE: [ipcdn] Proposed Draft 09 descriptions for objects within
>the docsQosServ iceFlowStatsTable
>
>
>Hi, William.
>I also agree with Greg, but I have a serious objection on the next texts:
>...
>                     For CMTS incoming upstream service
>                     a SID in the DOCSIS header that identifies the service
>flow."
>
>...
>               "The number of packets received on the service flow
>The "PDUs received with a SID in the DOCSIS header" seems incorrect. The
>DOCSIS header is divided to MAC header and a number of extended headers.
>Only extended piggyback header contains SID. But this is not the same SID
>that packet itself by definition (see BPI spec). Moreover this header may or
>may not be placed into packet as all other extended headers. Then upstream
>packet can not be identified by DOCSIS header at all. I guess, that CMTS
>scheduler, which assign grants to CMs and their SIDs can associate packet
>with SID without the this addition in MIB text.
>About PHS I have more objections. SAID in BPI headed has not any connection
>to service flow. It may be primary/dynamic/static BPI SAID. How it may
>identify Service Flow? I already 3 times asked how to implement
>docsQosServiceFlowPHSUnknowns counter. CM, which does not classify DS
>traffic can not report even docsQosServiceFlowPkts and
>docsQosServiceFlowOctets. How such CM can report
>docsQosServiceFlowPHSUnknowns, if packed may be even corrupted because of
>unknown PHS? I proposed 2 solutions: or report 0 as for
>docsQosServiceFlowPkts/docsQosServiceFlowOctets or report all
>docsQosServiceFlowPHSUnknowns packets into primary DS Service Flow. Both
>will be acceptable.
>Please, correct me if I am mistaken.
>Thanks.
>Lucy
>
>
>
>From: Minnie Lu [mailto:[email-masked]]
>Sent: Saturday, August 16, 2003 2:56 AM
>To: Greg White; Murwin William-LWM008
>Cc: [email-masked]; Pollak, Lucy; DOCSIS OSS Majordomo List; IPCDN
>(E-mail) (E-mail); Michael W. Patrick (E-mail)
>Subject: RE: [ipcdn] Proposed Draft 09 descriptions for objects within
>the docsQosServ iceFlowStatsTable
>
>
>Hi, William and Greg,
>

---

From: Minnie Lu <[email-masked]>
Date: Thu, 28 Aug 2003 12:09:58 -0700

Hi, William,

  Thanks a lot !
  Minnie

---

From: Murwin William-LWM008 <[email-masked]>
Date: Thu, 28 Aug 2003 14:09:51 -0400

I would like to thank all of you that have commented on the descriptions of the  docsQosServiceFlowStatsTable objects. For those of you who have made comments please responded back if your are satisfied with the descriptions of these objects.

		        actually received on the service flow identified by the SID
		        may report this object's value as 0 for downstream service 
		
		        Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant 
                    size should be counted only by the instance of this object
		        that is associated with the primary service flow.
	            
		        Unclassified upstream user data packets (i.e. non 
		        MAC-management) forwarded to the primary upstream
		        service flow should be counted by the instance of this 
		        object that is associated with the primary service flow.

		        The service flow is identified by the SID for which the 
		        packet was scheduled. 
		    
		        On a CM, only this object's instance for the primary 
		        downstream service flow count packets received with an 
		        unknown payload header suppression index. All other 
		        downstream service flows on CM report this objects value 
		        as 0. 

		        All outgoing service flows report this object's value as 0.

	  
                    Classified packets dropped due to other reasons must be
	              counted in ifOutDiscards for interface of this 
	              service flow. This object reports 0 for incoming service
                    flows.

Thanks,
Will

-----Original Message-----
From: Margo Dolas [mailto:[email-masked]]
Sent: Monday, August 18, 2003 6:13 PM
To: Pollak, Lucy; 'Minnie Lu'; Greg White; Murwin William-LWM008
Cc: DOCSIS OSS Majordomo List; IPCDN (E-mail) (E-mail); Michael W.
Patrick (E-mail)

William,

Regards,
Margo

-----Original Message-----

Hi, William.

              with an unknown payload header suppression index for a service
flow

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]]
Sent: Saturday, August 16, 2003 2:56 AM
To: Greg White; Murwin William-LWM008
Cc: [email-masked]; Pollak, Lucy; DOCSIS OSS Majordomo List; IPCDN

Hi, William and Greg,

     Thanks a lot !
    Minnie

---

From: Minnie Lu <[email-masked]>
Date: Thu, 28 Aug 2003 14:24:05 -0700

Hi, William,

   Thanks a lot for your clarification.  So the MIB octets count is the 
real bytes.  Anyone would help to change the RFI spec, so the RFI and OSS 
are consistent ?

   Thanks a lot !
   Minnie

At 04:08 PM 8/28/2003 -0400, Murwin William-LWM008 wrote:
>         We recommending changing the Spec SP-RFIv2.0-I04-030730 
> C.2.2.5.5, so that this does not sound as if
> order