Subject: [ipcdn] RE: Descriptions for docsQosSer

From: "Pollak, Lucy" <[email-masked]>
Date: Thu, 5 Jun 2003 11:01:58 +0300

Mike and Will.
I still have a number of unanswered questions. 
1. The "Note that this counts the octets after payload header suppression
has been applied." is asymmetric for sender and receiver. It may be
understood for receiver as "after payload header de-suppression..." if
consider "payload header suppression" as common name for
suppression/de-supression operation. May be it will be better: "Note that
the octets suppressed by payload header suppression are not counted into
this object."
2. Please, correct the text in MIB preamble:
	 "The docsQosServiceFlowPkts object 
   counts the total number of packets forwarded beyond the policing 
   function intended for eventual transmission onto the DOCSIS RF 
   network."
It does not match new MIB text for same object.
3. The docsQosServiceFlowPHSUnknowns is not still clarified in your
proposal. It is not defined what to do for DS if classification is not
executed. Is it also permitted to return 0? Is it recommended to count all
the packets into primary DS SF?

Thanks.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Thursday, June 05, 2003 3:16 AM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: Descriptions for docsQosSer

When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list
there had been a disscusion about the descriptions for the objects:
docsQosServiceFlowPkts
docsQosServiceFlowOctets
docsQosServiceFlowPolicedDropPkts
docsQosServiceFlowPolicedDelayPkts

Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt
:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.
                    This object does not count MAC-specific
                    management messages.
                    CMs not classifying downstream packets may report 
                    this object's value as 0.
		
		    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 be incremented for this object.

		    This object does include packets counted by 
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts.

		    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 has been applied. CMs not classifying to a
                    downstream service flow may report this object's 
                    value as 0 for that flow.

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

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "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 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 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 counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."	
    ::= { docsQosServiceFlowStatsEntry 7 }

We do not want to have the same discussion about the description of these
objects when we send our for comments version 9 of the DOCS-QOS-MIB.
If there are any more comments please send then as soon as possible.
Thank you again for reviewing this.

Sincerely,
Mike Patrick & Will Murwin

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

---

From: Minnie Lu <[email-masked]>
Date: Thu, 05 Jun 2003 16:09:59 -0700

Hi,

Probably I miss something.  I don't know why the word "classified" was 
added into these counters.  These counters might be used for usage billing 
purpose.  With the word "classified", CMTS will only MUST report downtream 
service flows traffic statistics because CMTS only MUST classify downtream 
traffic to active downstream service flows.  Any reason could these 
counters not be used for the traffic sent or received via the service flow ?

Thanks !
Minnie

At 08:16 PM 6/4/2003 -0400, Murwin William-LWM008 wrote:
>Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt  :
>
>                     will always report a value of 0 for UGS flows because the

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Fri, 6 Jun 2003 10:45:49 -0400

Lucy,

I thought the wording "after payload header supression has been applied" would be reasonably understood by all readers as not including the bytes that were removed by suppression, for both sender and receiver.
Has there been any instances of a reader (i.e. implementor or tester) that did not get that impression?

-mike

-----Original Message-----
From: Pollak, Lucy [mailto:[email-masked]] 
Sent: Thursday, June 05, 2003 4:02 AM
To: Murwin William-LWM008; Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Patrick Michael-LZZ007
Subject: [ipcdn] RE: Descriptions for docsQosSer

Mike and Will.
I still have a number of unanswered questions. 
1. The "Note that this counts the octets after payload header suppression has been applied." is asymmetric for sender and receiver. It may be understood for receiver as "after payload header de-suppression..." if consider "payload header suppression" as common name for suppression/de-supression operation. May be it will be better: "Note that the octets suppressed by payload header suppression are not counted into this object." 2. Please, correct the text in MIB preamble:
	 "The docsQosServiceFlowPkts object 
   counts the total number of packets forwarded beyond the policing 
   function intended for eventual transmission onto the DOCSIS RF 
   network."
It does not match new MIB text for same object.
3. The docsQosServiceFlowPHSUnknowns is not still clarified in your proposal. It is not defined what to do for DS if classification is not executed. Is it also permitted to return 0? Is it recommended to count all the packets into primary DS SF?

Thanks.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Thursday, June 05, 2003 3:16 AM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: Descriptions for docsQosSer

When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list there had been a disscusion about the descriptions for the objects: docsQosServiceFlowPkts docsQosServiceFlowOctets docsQosServiceFlowPolicedDropPkts docsQosServiceFlowPolicedDelayPkts

		

We do not want to have the same discussion about the description of these objects when we send our for comments version 9 of the DOCS-QOS-MIB. If there are any more comments please send then as soon as possible. Thank you again for reviewing this.

Sincerely,

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Fri, 6 Jun 2003 11:00:40 -0400

Minnie,

I used the word "classified" deliberately because the DOCSIS 1.1 architecture defines the set of packets onto a flow based on a classifer: "The basic model is that the Classifiers associate packets into exactly one Service Flow" (RFIv1.1-IO5 section 8.1.6).  I certainly do NOT want to use the word "transmitted" or "received", both of which introduce the much-discussed complexity regarding whether or not a packet is transmitted. 

The description explictly handles the sole exception, where CMs are not required to classify received packets.   

Are you aware of any instance where an implementor or tester misinterpreted the description wording?

-mike

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, June 05, 2003 7:10 PM
To: Murwin William-LWM008
Cc: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail); Murwin William-LWM008; Patrick Michael-LZZ007
Subject: Re: Descriptions for docsQosSer

Hi,

Thanks !
Minnie

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Fri, 6 Jun 2003 11:18:20 -0400

Kirk,

The compliance statement is correct in that both CMs and CMTSs are required to implement docsQosServiceFlowStats table.  For example, both ends classify outgoing packets to SFs, and so the stats are applicable. For the individual objects which might not be applicable, the description clause explains how to handle the case.

As for your questions, 

1) I had not intended docsQosServiceFlowPolicedDelayPkts to apply to received packets, only transmitted packets that were delayed before transmitting on the RF interface.  In the case of the CMTS, however, it is scheduling bursts (even concatenated ones) to a SID which is associated with a single service flow.  A reasonable question is whether the CMTS is required to increment this counter if it delays granting a request in order to limit the max rate to the SF of the SID.  DOCSIS already requires the CM to not even -make- such a request, so I don't think its reasonable to require the CMTS to count such delays.  Is there any objection (that means you, docsis-oss!) to clarifying that the value reported (by CMs and CMTSs) for docsQosServiceFlowPolicedDelayPkts of incoming flows is implementation-dependent, and may be zero?

2) Likewise, is there any objection to adding to the description that the reported value of docsQosServiceFlowPolicedDropPkts for incoming SFs is implementation-dependent and may be zero?
We'll also clarify that the ifOutDiscards clause will only apply to outgoing SFs. 

-mike & will

-----Original Message-----
From: Kirk Friedman [mailto:[email-masked]] 
Sent: Thursday, June 05, 2003 6:27 PM
To: Murwin William-LWM008; 'Docsis-Oss (E-mail) (E-mail)'; 'IPCDN (E-mail) (E-mail)'
Cc: Patrick Michael-LZZ007
Subject: RE: [ipcdn] Descriptions for docsQosSer

Will and Mike,

Thanks for doing all this work.  The descriptions seem to be written from a CM only perspective.  The compliance statement puts DocsQosServiceFlowStatsTable into the base group for CMs and CMTS.  Section 2.4.2 seems to imply that these statistics are only kept for packets going to/from the RF interface.  That might also need to be rewritten unless that is what is intended.

If that is what is intended, then the individual parameters or compliances should be indicate which directions for the CMTS the parameters apply to. Perhaps the equivalent of "CMTS' MUST report this as 0 for upstream service flows" for the PolicedDrop/Delay packet counters.  Otherwise I have some
questions:

1) From a CMTS perspective, why is docsQosServiceFlowPolicedDelayPkts
applied to upstream SFs at all?  This would be very difficult with concatenation of multiple packets inside of one burst.

2) Regarding docsQosServiceFlowPolicedDropPkts.  Part of the description is "Classified packets dropped due to other reasons must be counted in ifOutDiscards for interface of this service flow."  But for the CMTS, the OSS spec has ifOutDiscards as MUST be 0 for upstream interfaces.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Murwin William-LWM008
Sent: Wednesday, June 04, 2003 5:16 PM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: [ipcdn] Descriptions for docsQosSer

Sincerely,

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Fri, 6 Jun 2003 16:18:37 -0400

Minnie,

I don't suppose you'd let me take a liberal interpretation of the word "classified" for the CMTS upstream flows to mean the CM did the classification :-) ?

The reason for adding the word "classified" was to avoid having to adjust the count if the packet couldn't actually be transmitted due to other reasons (like being too long for a UGS grant, for instance). 
It certainly was not our intention for the CMTS to stop counting -received- service flow packets !!

I suppose we could clarify that "classified" applies to outgoing flows, and the incoming flows (to the CMTS) include those packets which were received. 

This opens a can of worms concerning errors in the receive process. Does anyone feel docsQosServiceFlowPackets has to explicitly specify whether a CMTS counts upstream packets received with errors like checksum errors? [IMO it shouldn't]   Or should it count grants given to a particular service flow even if the CM didn't send a packet in that grant? [IMO, it shouldn't]
Both of these cases involve error troubleshooting that is, IMO, beyond the scope of the docsQosMib.

-mike

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Friday, June 06, 2003 2:12 PM
To: Patrick Michael-LZZ007
Cc: 'Minnie Lu'; Murwin William-LWM008; Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Subject: RE: Descriptions for docsQosSer

Hi, Patrick,

  Thanks for your reply.  Then please help me to understand why "sole 
exception" only apply to CM ?

RFIv1.1-I09-020830, Section 8.1.6, "The CMTS MUST classify downstream 
traffic to Active Downstream Service Flows.". Does it mean that with the 
word "classified", for CMTS which does not classify the upstream traffic, 
those counters with "classified" word will also allow to report 0 for CMTS ?

As I know, some customers could use the service flow counters for usage 
based billing.  SAMIS ECN OSS-N-02197 reports the service flows counters 
for downtreams and upstreams.  Then how could these service flows counters 
be used for usage billing from CMTS's point of view  ?

Another concern is the backward capability. The 
draft-ietf-ipcdn-qos-mib-04.txt which is now used in the field for most of 
vendors' CMTS does not have the word 'classified'. If I remembered right, 
there will be NO NEW ECR for OSSIv1.1 spec. That is, the DOCS-QOS-MIB 
version is still draft-ietf-ipcdn-qos-mib-04.txt in OSSIv1.1 spec..

draft-ietf-ipcdn-qos-mib-04.txt :
docsQosServiceFlowPkts
  "The number of packet counted on this service flow." docsQosServiceFlowOctets
   "The number of octets counted on this service flow
                     after payload header suppression."

Thanks a lot for your help again !
Minnie

At 11:00 AM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
>Minnie,
>
>I used the word "classified" deliberately because the DOCSIS 1.1
>architecture defines the set of packets onto a flow based on a classifer: 
>"The basic model is that the Classifiers associate packets into exactly 
>one Service Flow" (RFIv1.1-IO5 section 8.1.6).  I certainly do NOT want to 
>use the word "transmitted" or "received", both of which introduce the 
>much-discussed complexity regarding whether or not a packet is transmitted.
>
>added into these counters.  These counters might be used for usage 
>billing purpose.  With the word "classified", CMTS will only MUST 
>report downtream service flows traffic statistics because CMTS only 
>MUST classify downtream traffic to active downstream service flows.  
>Any reason could these counters not be used for the traffic sent or 
>received via the service flow ?
>
>Thanks !
>Minnie
>
> >When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling 
> >list there had been a disscusion about the descriptions for the 
> >objects: docsQosServiceFlowPkts docsQosServiceFlowOctets
> >                     maintain the Maximum Sustained Traffic Rate. 
> >This
> object
> >We do not want to have the same discussion about the description of 
> >these objects when we send our for comments version 9 of the 
> >DOCS-QOS-MIB. If there are any more comments please send then as soon 
> >as possible. Thank you again for reviewing this.
> >
> >Sincerely,

---

From: Minnie Lu <[email-masked]>
Date: Fri, 06 Jun 2003 11:11:31 -0700

Hi, Patrick,

draft-ietf-ipcdn-qos-mib-04.txt :
docsQosServiceFlowPkts
  "The number of packet counted on this service flow."
docsQosServiceFlowOctets
   "The number of octets counted on this service flow
                     after payload header suppression."

At 11:00 AM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
> >these

---

From: Minnie Lu <[email-masked]>
Date: Fri, 06 Jun 2003 17:45:18 -0700

Hi, Patrick,

Thanks for your reply.  Please see my response inline.
Thanks!
Minnie

At 04:18 PM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
>Minnie,
>
>I don't suppose you'd let me take a liberal interpretation of the word 
>"classified" for the CMTS upstream flows to mean the CM did the 
>classification :-) ?

[milu]: No.:-)

>The reason for adding the word "classified" was to avoid having to adjust 
>the count if the packet couldn't actually be transmitted due to other 
>reasons (like being too long for a UGS grant, for instance).
>I suppose we could clarify that "classified" applies to outgoing flows, 
>and the incoming flows (to the CMTS) include those packets which were 
>received.

[milu]: Please do.  CM only MUST "classify" the upstream. CMTS only  MUST 
"classify" the downtream as RFI spec.  Both are outgoing flows.  The 
service flows  used for incoming traffic should have the incoming 
statistics, too.

>This opens a can of worms concerning errors in the receive process. Does 
>anyone feel docsQosServiceFlowPackets has to explicitly specify whether a 
>CMTS counts upstream packets received with errors like checksum errors? 
>[IMO it shouldn't]   Or should it count grants given to a particular 
>service flow even if the CM didn't send a packet in that grant? [IMO, it 
>shouldn't]

[milu]: I totally agree with you to count the packet pdu frames received 
actually and exclude errored frames for the incoming traffic.
By the way, I think the word "classified" also has much-discussed 
complexity compared to the word "transmit" (or  "sent") and the word 
'classified' is probably not good for incoming traffic.

For example:
docsQosServiceFlowPkts

The following 3 paragraph to me is the same thing -- packets sent on 
service flow X are counted only on the service flow X's counters.

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

                     [milu]: I interpret it as packets "sent" on the 
primary service flow are 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 be incremented for this object."

                      [milu]: I interpret it as "outgoing unclassified 
packets sent to default service flow should be counted only on the default 
service flow's counters." though it seems only applicable to CM in the 
original description.

                      [milu]: I interpret it as "delayed packets should be 
counted when the packets are sent actually." and "drop packets are not 
sent, so they are not counted here." "excessive delayed packets which are 
dropped eventually for any reason are not counted here because they are not 
sent."

  These are my personal interpretation and I don't meant the object 
description should use them. I might simplify things too much and miss some 
thing. Please let me know.

   Thanks a lot !
   Minnie