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

"Pollak, Lucy" <Lucy.pollak@ti.com> Sat, 20 September 2003 01:37 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01600 for <ipcdn-archive@odin.ietf.org>; Fri, 19 Sep 2003 21:37:26 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhDT020140 for <ipcdn-archive@odin.ietf.org>; Fri, 19 Sep 2003 21:37:06 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82G2xA8019122 for ipcdn-archive@odin.ietf.org; Tue, 2 Sep 2003 12:02:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uDcN-0004wV-Tk; Tue, 02 Sep 2003 12:02:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u3EM-0005vm-JF for ipcdn@optimus.ietf.org; Tue, 02 Sep 2003 00:57:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27374 for <ipcdn@ietf.org>; Tue, 2 Sep 2003 00:57:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u3EG-0002tX-00 for ipcdn@ietf.org; Tue, 02 Sep 2003 00:57:21 -0400
Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx with esmtp (Exim 4.12) id 19tTeM-0006pI-00 for ipcdn@ietf.org; Sun, 31 Aug 2003 10:57:54 -0400
Received: from dlep52.itg.ti.com ([157.170.134.103]) by dragon.ti.com (8.12.9/8.12.9) with ESMTP id h7VEvCxe010096; Sun, 31 Aug 2003 09:57:12 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep52.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7VEvB8E010544; Sun, 31 Aug 2003 09:57:11 -0500 (CDT)
Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.1.21]) by dlep90.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7VEv8J5020609; Sun, 31 Aug 2003 09:57:09 -0500 (CDT)
Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id <Q6F2KZR0>; Sun, 31 Aug 2003 17:57:08 +0300
Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A01FD352D@dile03.itg.ti.com>
From: "Pollak, Lucy" <Lucy.pollak@ti.com>
To: 'Murwin William-LWM008' <W.Murwin@motorola.com>, 'Margo Dolas' <mdolas@broadcom.com>, 'Minnie Lu' <milu@cisco.com>, Greg White <g.white@cablelabs.com>
Cc: DOCSIS OSS Majordomo List <docsis-oss@cablelabs.com>, "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>, "Michael W. Patrick (E-mail)" <mpatrick@dma.isg.mot.com>
Subject: RE: [ipcdn] Proposed Draft 09 descriptions for objects within the docsQosServ iceFlowStatsTable
Date: Sun, 31 Aug 2003 17:57:07 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>

William,
Thank you, it seems OK.
Only one comment - docsQosServiceFlowOctets does not contain now:  
"CMs not classifying downstream packets may report this object's value as 0
for downstream service flows."
I agree that: "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." covers all the cases including DS. But from my POV to
tell this directly without reference to packet counter will be better.
Thanks.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Thursday, August 28, 2003 9:10 PM
To: 'Margo Dolas'; Pollak, Lucy; 'Minnie Lu'; Greg White
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


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:

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

		        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. 

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

	              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 }


Thanks,
Will

-----Original Message-----
From: Margo Dolas [mailto:mdolas@broadcom.com]
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

-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]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:
docsQosServiceFlowPkts OBJECT-TYPE
...
                    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."

docsQosServiceFlowPHSUnknowns OBJECT-TYPE
...
              "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.

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



-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com]
Sent: Saturday, August 16, 2003 2:56 AM
To: Greg White; Murwin William-LWM008
Cc: milu@cisco.com; 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,

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



At 01:15 PM 8/15/2003 -0600, Greg White wrote:
>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:
>
>                 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.
>
>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:W.Murwin@motorola.com]
>Sent: Thursday, August 14, 2003 3:24 PM
>To: 'milu@cisco.com'; 'Lucy.pollak@ti.com'; 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.
>
>                     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: W.Murwin@motorola.com
>Tel: (508) 851-8385
>
>
>_______________________________________________
>IPCDN mailing list
>IPCDN@ietf.org
>https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn