RE: IETF NCS Sig MIB Gain (loss) plan and tone Levels

 
Sumanth,
 
Here is some recap of the prehistory of the issue with the corresponding
dates:
 
02/12/2005:     e-mail "[pkt-sig-mib] Comments/Resolutions on draft 07" is
circulated with the changes proposed for draft-08 from draft-07. There is no
mentioning of the "pktcNcsEndPntConfigTxGain" and "pktcNcsEndPntConfigRxGain"
MIB objects in it.
 
02/15/2005:     e-mail "IETF NCS Sig MIB Gain (loss) plan and tone Levels" is
circulated which contains the proposal to get the "pktcNcsEndPntConfigTxGain"
and "pktcNcsEndPntConfigRxGain" MIB objects back to draft-08. 
 
02/20/2005 (Sunday):    e-mail "[PKT-SIG-MIB] Draft 08 (Summary Of Changes)"
is circulated. This e-mail includes the proposal to get the
"pktcNcsEndPntConfigTxGain" and "pktcNcsEndPntConfigRxGain" MIB objects back
to the SIG MIB draft.
 
02/22/2005:     e-mail "I-D ACTION:draft-ietf-ipcdn-pktc-signaling-08.txt" is
circulated announcing the publication of the draft-08.
 
It would be very difficult, probably even unrealistic to expect that 5
working days is a sufficent amount of time for the community to be able to
carefully analyse the proposal and to come up with the appropriate comments
on the reflector. This is especially true having in mind that these two
particular objects have been already carefully considered in the past, and
the decision had been made to remove these two objects from the draft-02.
 
Given this, I think, it would be logical and reasonable to recognize that the
resurrection of these two MIB objects in the draft-08 was not sufficiently
discussed as a result of an oversight of the fact that the objects had been
excluded from the draft-02. Further, as the return of these objects already
raised some concerns expressed on the reflector, it would be also reasonable
to make an assumption that these two objects are not present in the draft-08.
Based on this premise we can start discussing the neccessity and arguments
for inclusion of these two objects to the next SIG MIB draft-09.
 
Regards,
 
Eugene.
 

________________________________

From: Sumanth Channabasappa [mailto:[email protected]] 
Sent: Wednesday, June 22, 2005 3:14 PM
To: Eugene Nechamkin; Richard Woundy @ Comcast; Freyman Phillip-FPF300
Cc: [email protected]
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels


Eugene,
 
The discussion resulting in this addition is detailed as COMMENT SET #6/7 in
the email referenced
via the following link (and you did reference the contents in your email as
well):
 
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01594.html
 
 
Since there were no concerns posted then, it was submitted as recommended. 
 
(I should admit that the exclusion in draft-02 was not realized when the
proposal was 
submitted - apologies)
 
I would appreciate other thoughts from implementors or experts on this
subject matter since
the issues raised seem to be that of implementation.
 
 
Thanks
Sumanth
 
 
 
 


________________________________

From: Eugene Nechamkin [mailto:[email protected]] 
Sent: Wednesday, June 22, 2005 12:23 PM
To: Richard Woundy @ Comcast; Freyman Phillip-FPF300
Cc: [email protected]
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels


 
After looking at the "pktcNcsEndPntConfigTxGain" and
"pktcNcsEndPntConfigRxGain" MIB objects more closely, here are some concerns
with these objects resurrected in draft-08 since being obsolete in draft-02.
 
The concerns are two-fold:
 
1. The real value in having this solution for future proofing:
As Rich pointed out, we are trying to future proof the unknown requirements.
If this becomes important in the future then we can figure it out then, it is
impossible to solve everything up front without understanding all the
problems and consequences. The draft-02 has obsolete these two objects after
the extensive discussions. Are the problems these two MIB objects are
presumably solving important enough to consider the draft change given the
current late stage.
 
2. Implementation problems associated with the functionality introduced by
these two objects
We understand the benefits of having configurability to meet different
country specifications. However, the gain/loss plan is only one component in
trying to adapt to different country deployments. The MIB doesn't address
other items such as complex impedance, ring voltage, etc. By trying to
address the gain/loss in isolation we are actually creating implementation
difficulties. This is already solved by MTA manufactures through more
intelligent and coordinated methods using both H/W and S/W
 
Providing the ability to dynamically adjust gains means that you are
inherently limiting the dynamic range of the DSP to try and address all
corner case scenarios. This is a huge implementation problem. Often the per
country matching of complex impedances and gains is done in H/W or within the
analog interface components like the SLIC. These interfaces are configured
for a given country specifications independent of signaling MIBs. This
creates a problem when you want to have the gain setting larger than the
natural country default. The only solution to meet the desired MIB value is
to generate a loud signal (likely clipping within the DSP) in order to adjust
for the analog hardware gain.
 
Eugene Nechamkin,
 
Broadcom Corp.

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