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

Eugene,
 
I am not disagreeing, but trying to get more input on this issue since
it has been around since 02/12/2005 as you indicated and is 
being raised now.
 
regards
Sumanth

  _____  

From: Eugene Nechamkin [mailto:[email protected]] 
Sent: Wednesday, June 22, 2005 7:40 PM
To: Sumanth Channabasappa
Cc: [email protected]
Subject: RE: [ipcdn] 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