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

From: "Pollak, Lucy" <[email-masked]>
Date: Sun, 17 Aug 2003 12:34:58 +0300

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:[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,

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

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

---

From: "Margo Dolas" <[email-masked]>
Date: Mon, 18 Aug 2003 18:13:03 -0400

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

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