[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] Proposed Draft 09 descriptions for objects within the docsQosServ iceFlowStatsTable
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:milu@cisco.com]
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.
> 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.
docsQosServiceFlowOctets.
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."
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:
>
>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