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
- [ipcdn] Proposed Draft 09 descriptions for object… Murwin William-LWM008
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Greg White
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Minnie Lu
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Pollak, Lucy
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Margo Dolas
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Murwin William-LWM008
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Minnie Lu
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Murwin William-LWM008
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Minnie Lu
- RE: [ipcdn] Proposed Draft 09 descriptions for ob… Pollak, Lucy