RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

["Eduardo Cardona" <[e-mail]>]

Thanks Bert for the review

I am also expecting validation from vendor at the least this week so I
can publish D-14 by the end of the week 

To your question :
4+4*64 or 4+8*64
The total number of taps ( forward and reverse ) are up to 64 

Your interpretation of 8*64 seems to indicate to me you are assuming:
Forward taps  =  Reverse Taps (Always) and up to 64 taps

To make that clear, few text suggestions to the TEXTUAL-CONVENTION are
below  
...
           1 byte Number of forward taps: n
           1 byte Number of reverse taps: m
...
           DOCSIS specifications requires up to a maximum of 
           64 equalizer taps (n + m); therefore, this object size 
           can get up 260 bytes (4 + 4x64).  


Thanks

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[e-mail]] 
Sent: Sunday, October 16, 2005 5:06 PM
To: Eduardo Cardona; Ipcdn (E-mail); [e-mail]
Cc: Randy Presuhn (E-mail)
Subject: RE: [ipcdn] RE: AD
re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

Sorry that it took a while to respond.

I think the most important 2 things are:
- Have a CLEAR description of the MIB objects, so that implementers
  (both at the agent and at the manager side) know what to do and/or
  what to expect. The discussion below is clearly helping to go
  for a solution in that direction.
- From a MIB doctor perspective, your proposals look OK. It is 
  important though to have those vendors that have been providing
  input DO take a look at your proposed changes and agree as to
  what the best solution is and to make sure that that is what
  they have (or plan to) implement(ed).

One thing I wondered. Is the max length not 4+8*64 instead of 4+4*64?
If not, then I do not understand the DESCRIPTION clause of the TC.

Bert

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf Of
> Eduardo Cardona
> Sent: Tuesday, October 11, 2005 13:59
> To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
> [e-mail]
> Subject: RE: [ipcdn] RE: AD
> re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
> docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData
> 
> 
> Does anyone get the chance to review the proposed clarifications ? 
> 
> Please reply with comments by the end of the week 
> 
> Thanks
> 
> Eduardo
> 
> 
> 
> -----Original Message-----
> From: Eduardo Cardona 
> Sent: Monday, October 03, 2005 3:35 PM
> To: Ipcdn (E-mail); Wijnen, Bert (Bert); [e-mail]
> Subject: RE: [ipcdn] RE: AD
> re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
> docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData
> 
> Hi IPCDN participants,
> 
> Here is an update on one of the pending items from Bert's review:
> After consultations with DOCSIS vendors, I am proposing the
> clarifications required to define the size constraints for
> docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData
> 
> Please review the details and send your comments.
> 
> You will find in this email a summary of the proposed changes 
> as well as
> a log of comments provided by vendors to place the discussion in the
> context of the IPCDN participants. 
> 
> 
> Please comment on the proposals and make the appropriate comments 
> Item  a)
> Item  c)
> Item  d)
> Comments and pick an alternative from
> b-1) 
> and 
> b-2)
> 
> 
> 
> ----  
> 
> CM/CMTS Equalizer Data: 
> 
> 
> Summary:
> docsIfSigQEqualizationData and  
> docsIfCmtsCmStatusEqualizationData have
> OCTET STRING with no constraints in the object size (RFC 
> 2669), in fact
> the format of the pre-equalizers was never normalized and left vendor
> specific
> In draft 06 of RFIv2.0 It was added a size constraint of 512 
> octets but
> no special reason was defined:
> Some basic Math will indicate that up to 64 taps ( RFI 
> requirements) and
> 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was
> selected.
> 
> Even though the selection of 256 (or 512) does not seem to be accurate
> number considering some possible byte controls to indicate:
> - Taps could be T, T/2 or T/4 spaced. 
> - Forward Taps and Reverse Taps could have different numbers
> - Not required by the spec : Reverse Taps (DS equalizers) 
> could be also
> T, T/2 and T/4 spaced
> - Any need to indicate main tap position ( or the highest value is
> enough indication of that 
> 
> The discussions held with RF experts identified the following 
> management
> requirements : 
>  
> 1) CM DS post-equalization have been defined in
> docsIfSigQEqualizationData 
> 
> 2) CM Upstream pre-equalizer ( not to be defined in this 
> version of the
> MIB) something to reflect the CMTS RNG-RSP equalizer value 
> 
> CMTS equalization Data:
> 3) Equalization in the Upstream has relative importance for CMTS CM
> path, docsIfCmtsCmStatusEqualizationData
> Meanings:
> When Pre-eq is off, the value will indicate the CM-CMTS path RF
> distortions. 
> When re-eq is on, the value indicates how well pre-equalization is
> working as the value of all should be close to zero with the exception
> of the main tap
> 
> 4) The equalization data per US interface defined as an 
> average value in
> docsIfSigQEqualizationData 
> This concept is confusing since there is no in the RFI spec a
> methodology to calculate that average. 
> It could include : 
> - CMs with different configuration: pre-eq on|off, 
> - Different number of Taps per CM, 
> - Tap spacing per CM
> The average formula should've being 
> The recommendation is to remove that requirement
> 
> 
> Proposed resolution:
> a) 
> Use the same format as in the CM equalization data for 1) and 3)  for 
> CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData
> 
> b) 
> remove the CMTS requirement for docsIfSigQEqualizationData
> - Future spec efforts will work to define more meaningful values for
> CMTS US that could lead to objects that defines MER measurements prior
> and after channel signal compensation or mitigation by the CMTS
> 
> c) Description of docsIfCmtsCmStatusEqualizationData
> 
> d)
> CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS
> specification and RFI MIB updates
>  
> 
> Proposal details :
> 
> a) 
> 
> -- Add a new textual Convention
> DocsEqualizerData ::= TEXTUAL-CONVENTION
>      STATUS       current
>      DESCRIPTION
>          "This data type represents the equalizer data
>           as measured at the receiver interface.
>           The format of the equalizer follows a similar structure
>           Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI 
>           v1.1 specification with slight modifications as
>           follows :
>           1 byte Number of forward taps per symbol
>           1 byte Number of reverse taps per symbol
>           1 byte Number of forward taps: n
>           1 byte Number of reverse taps: m
>           
>           Following are the equalizer coefficients:
>           First forward taps coefficients :
>           2 bytes F1 (real),  2 bytes  F1 (imag)
>           ...
>           2 bytes Fn (real),  2 bytes  Fn (imag)
>           
>           Then reverse taps coefficients :
>           2 bytes D1 (real),  2 bytes  D1 (imag)
>           ...
>           2 bytes Dm (real),  2 bytes  Dm (imag)
> 
>           The equalizers coefficient are considered signed 16 bit
>           integers in the range -32768 (0x8000) to 32767 (0x7FFF).
>          
>           DOCSIS specifications requires up to a maximum of 
>           64 equalizer taps (N + M), therefore, this object size 
            can get up 260 bytes (4 + 4x64).
>           The minimum object size (other than zero) for a t-spaced Tab
>           with a minimum of 8 symbols will be 36 (4 + 4x8)"
>      SYNTAX       OCTET STRING(SIZE 0|36..260))
> 
> 
> alternative b-1) 
> 
> docsIfSigQEqualizationData OBJECT-TYPE
>         SYNTAX      DocsEqualizerData
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>             "At the CM, returns the equalization data for the 
> downstream
>              channel.
>              
>              At the CMTS, this object is not applicable and 
> might return
> 
>              a zero-length OCTET STRING. Note that previous CMTS 
>              implementations may instantiate this object in two ways:
>              - An equalization value different of the zero-length
>                octet string to indicate an equalization average for
>                the upstream channel. Those values have vendor 
>                dependent interpretation.
>              - Return a zero-length OCTET STRING as described below.
>              
>              A returned zero-length OCTET STRING indicate the value
>              is unknown or if there is no equalization data available
>              or defined."
>         REFERENCE
>             "DOCSIS Radio Frequency Interface Specification,
>              Figure 6-23."
>         ::= { docsIfSignalQualityEntry 7 }
> 
> --Note: same compliance statements as in draft 13
> 
> 
> alternative b-2) 
> 
> docsIfSigQEqualizationData OBJECT-TYPE
>         SYNTAX      DocsEqualizerData
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>             "At the CM, returns the equalization data for the 
> downstream
>              channel.
>              
>              At the CMTS, this object is not applicable and is not 
>              instantiated. Note that previous CMTS implementations 
>              may instantiate this object in two ways:
>              - An equalization value different of the zero-length
>                octet string to indicate an equalization average for
>                the upstream channel. Those values have vendor 
>                dependent interpretation.
>              - Return a zero-length OCTET STRING as described below.
>              
>              A returned zero-length OCTET STRING indicate the value
>              is unknown or if there is no equalization data available
>              or defined."
>         REFERENCE
>             "DOCSIS Radio Frequency Interface Specification,
>              Figure 6-23."
>         ::= { docsIfSignalQualityEntry 7 }
> 
> -- Changes in compliance statements: 
> docsIfBasicGroupV2 OBJECT-GROUP
>      OBJECTS {
>          docsIfDownChannelId,
> -- ... snip ...
> -- delete
> --         docsIfSigQEqualizationData,
> --- ...snip ...
>      }
>      STATUS      current
>      DESCRIPTION
>          "Group of objects implemented in both cable modems and
>           cable modem termination systems."
>      ::= { docsIfGroups 5 }
> 
> 
> docsIfCmGroupV2 OBJECT-GROUP
>      OBJECTS {
>          docsIfCmCmtsAddress,
> -- ... snip ...
>         docsIfCmServiceExtTxSlotsDed,
> -- Add
>          docsIfSigQEqualizationData
> --- ...snip ...
>      }
>      STATUS      current
>      DESCRIPTION
>          "Group of objects implemented in cable modems."
>      ::= { docsIfGroups 6 }
> 
> c)
> docsIfCmtsCmStatusEqualizationData OBJECT-TYPE
>      SYNTAX      OCTET STRING (SIZE (0..512))
>      MAX-ACCESS  read-only
>      STATUS      current
>      DESCRIPTION
>          "Equalization data for this CM as measured by the CMTS.
>           Returns the zero-length OCTET STRING if the value is 
>           unknown or if there is no equalization data available
>           or defined."
>      REFERENCE
>          "Data-Over-Cable Service Interface Specifications: Radio
>           Frequency Interface Specification SP-RFIv2.0-I07-041210,
>           Figure 8-23."
>      ::= { docsIfCmtsCmStatusEntry 8 }
> 
> 
> 
> 
> Summary of comments received in a vendor internal discussion
> Copied for IPCDN participants background 
> 
> ------------------  
> Hal Roberts - ADC
> 
> Colleagues,
>  
> While we are looking at this question we should make sure we 
> end up with
> precise definitions of the equalization coefficient format for DOCSIS
> 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal
> Quality Monitoring goals include:
>  
> -	Pre-Equalization (Already in spec) 
> *	Review language to make sure output is standardized for
> processing. 
>  
> docsIfSigQEqualizationData
> For the cable modem "the equalization data for the downstream channel"
> has an unambiguous meaning.  So for the cable modem it is the 
> tap format
> which must be made unambiguous (this should be agreed upon by cable
> modem and/or cable modem chip manufacturers).
> With regard to the CMTS, the MIB docsIfSigQEqualizationData 
> is supposed
> to provide the 'average' equalization data for the upstream channel as
> seen by the CMTS. This is an ambiguous statement. There is no 
> 'average'
> equalization data since the equalization coefficients 
> uniquely apply to
> each upstream path from each CM to the CMTS receiver. These 
> coefficients
> are complex numbers, so in what way does one average them? If one can
> define a formula that results in a single real number from each set of
> coefficients as they come from the CMTS for each CM then one could
> envision averaging these numbers into something approaching a 
> meaningful
> assessment of the linear distortions on a given upstream channel. (Tom
> Kolze has just such a formula and we have found it to be an accurate
> estimate of the MER of a channel due to distortions alone. Tom may be
> willing to share this with the working group).
>  
> Therefore I think that the definition of 'average 
> equalization data for
> the upstream channel' must be clarified or the CMTS portion of the MIB
> should be removed.
>  
> docsIfCmtsCmStatusEqualizationData
> With regard to the MIB docsIfCmtsCmStatusEqualizationData, when
> pre-equalization is on there is little or no meaning to the 
> equalization
> coefficients from the CMTS (even on a per-cable-modem basis 
> rather than
> per channel). If pre-equalization is working correctly there should be
> very little residual channel distortion left and the coefficients will
> no longer have any relationship to the channel 
> characteristics. Possibly
> the only use for these coefficients when pre-equalization is on, is to
> actually see if pre-equalization is doing the job.
>  
> On the other hand, when pre-equalization is turned off,
> docsIfCmtsCmStatusEqualizationData will accurately reflect distortions
> on the RF path between the given cable modem and the CMTS receiver.
>  
> Therefore I think that agreeing on the format of this MIB is what is
> necessary. One other suggestion, the text "Equalization data for this
> CM" might be clearer if it stated "Equalization data for this CM, as
> measured by the CMTS"
>  
> Hal
>  
>  
> docsIfSigQEqualizationData OBJECT-TYPE
>         SYNTAX      OCTET STRING
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>             "At the CM, returns the equalization data for the 
> downstream
>              channel. At the CMTS, returns the average equalization
>              data for the upstream channel. Returns an empty string
>              if the value is unknown or if there is no equalization
>              data available or defined."
>         REFERENCE
>             "DOCSIS Radio Frequency Interface Specification,
>              Figure 6-23."
>         ::= { docsIfSignalQualityEntry 7 }
>  
> ------------------------  
> 
> Andre Lejeune - ATI
> 
> We report the docsIfSigQEqualizationData for our CM in the following
> format:
>  
> F1 (real) 16 bits,   F1 (imag) 16 bits
> F2 (real) 16 bits,   F2 (imag) 16 bits
> ...
> Fn (real) 16 bits,   Fn (imag) 16 bits
>  
> The number of taps is deduced from the length of the octet string.
> 
> 
> ------------------------  
> 
> David Hull - Conexant 
> 
> The DS equalizer has never been specified in terms of its exact
> implementation.  This has been left to the individual silicon vendor;
> therefore they are all a bit different. Some implementations use T
> spaced all the way through and (I believe) some 
> implementations may use
> fractional spacing for the front end (prior to the reference 
> tap).  Not
> all implementations have the same length of DS equalizer or the same
> center tap position (relative to the overall length) either.  
> If all we
> want to do is compute the frequency response by a DFT on the tap
> weights, I don't think it matters what the CT position is but 
> the length
> and the tap spacing would need to be conveyed if fractional spacing is
> used.
> 
> ------------------------  
> 
> Andre Lejeune - ATI
> 
> 
> I am sorry I took some time to respond. I clearly needed to 
> discuss this
> internally before continuing on the subject.
>  
> The format I sent earlier was for our modem. But now I 
> realize that even
> our own solution will be changing and the format below won't be
> appropriate. I agree that more information needs to be carried in this
> MIB. A solution proposed by Mike Grimwood is to use the format from
> DOCSIS 1.1, figure 6.23 (without the type and length), which 
> allows for
> Main Tap Location, Spacing, number of FF and FB taps. Even 
> that may not
> be sufficient, if I properly understand Dave below, if different
> fractional spacing is used for the different taps. I'll let 
> Dave explain
> this further if he thinks it is necessary. The main tap 
> location is not
> absolutely required, as it generally can be easily derived, 
> but could be
> useful under certain error conditions:
>  
> Main Tap Location (1 byte)
> Number of forward taps per symbol (1 byte)
> Number of forward taps (1 byte)
> Number of reverse taps (1 byte)
> F1 (real) 16 bits,   F1 (imag) 16 bits
> F2 (real) 16 bits,   F2 (imag) 16 bits
> ...
> Fn (real) 16 bits,   Fn (imag) 16 bits
> 
> D1 (real) 16 bits,   D1 (imag) 16 bits
> D2 (real) 16 bits,   D2 (imag) 16 bits
> ...
> Dn (real) 16 bits,   Dn (imag) 16 bits
>  
> ------------------------  
> Hal Roberts  - ADC 
> 
> To summarize:
> 1.	Equalization MIBS from the CM - We need well defined MIBs from
> the CM for both the downstream post-equalizer and the upstream
> pre-equalizer values. If no uniform format for the downstream taps can
> be defined due to proprietary implementations, perhaps the vendors can
> simply provide a 'frequency response or impulse response' as 
> calculated
> from the equalizer (but in a uniform format). For the upstream taps it
> should be easy to provide a uniform tap format as it is already mostly
> defined in the RFI.
> 2.	Equalization MIBS from the CMTS when Pre-equalization is OFF -
> As mentioned before, an average equalization data from the 
> CMTS on a per
> upstream channel basis is not defined and could take a number of
> meanings. Without an unambiguous definition of channel based
> equalization data, it would be better to remove this part of the
> definition as it simply leads to mass confusion. Note that 
> equalization
> MIBs from the CMTS on a per CM basis do have significant 
> value for plant
> monitoring and debug purposes. These merely need to be defined in
> format; this format could be the same format as in the 
> pre-equalizer MIB
> from the CM as they are representing the same plant characteristic.
> 3.	Equalization MIBS from the CMTS when Pre-equalization is ON -
> These have no significant value other than seeing if 
> pre-equalization is
> operating properly. When pre-equalization is operating 
> properly then the
> CMTS should see little or no plant distortion and the equalizer
> coefficients should be close to all-zeros except for the main tap for
> all modems.
> Hal
> 
> ------------------------  
> David Hull -Conexant 
> 
> With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec
> that Andre referred to seems good enough but I would allow 
> the number of
> taps per symbol to be defined independently for the forward 
> section AND
> the reverse section just in case someone implemented the two sections
> with different tap spacing.  Short of officially "specifying" the DS
> equalizer like we have done for the upstream one, I don't see too much
> more that could be done.
> 
> ------------------------  
> Hal Roberts - ADC 
> 
> Dave,
>  
> It may be elsewhere in the spec or it may be obvious but I 
> think we need
> to have more detail, for example the numbers should be 
> represented in a
> specific numerical format perhaps:
>  
> "Standard twos-complement format, from -32768 (0x8000) to 32767
> (0x7FFF)"
>  
> as an example.
>  
> Hal
> 
> ------------------------  
> 
> 
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 



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