Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt

From: Milinski Alexander <[email-masked]>
Date: Fri, 21 Mar 2003 12:33:16 +0100

Hi Kevin and Janathan,
the concern raised by Jonathan seems very valid. Like Jonathan I do not think that it is benefitial to make transient information (like details of each ongoing dialog in the SipTransactionEntry) available via the SIP MIB.
Kind regards,
Alexander

Alexander Milinski
Siemens mobile

-----Original Message-----
From: Kevin Lingle [mailto:[email-masked]]
Sent: Wednesday, March 19, 2003 4:40 PM
To: Jonathan Rosenberg
Cc: [email-masked]; Dave Walker
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt

Jonathan Rosenberg wrote:
> 
> Kevin Lingle wrote:
> 
> >>I have begun to look at the mib a bit, and I am a bit concerned that
> >>there is far too much information exposed, in terms of statistics, at
> >>least. I have to apologize for raising this so late in the game, but it
> >>is only recently that my day job has brought me into OAMP areas.
> >
> >
> > not sure if the above reference to statistics is directly related
> > to your comment on sipTransactionTable below or not.
> 
> Yes.
> 
> > if not, are there
> > other statistics that you feel fall into the category or
> > exposing far too much information?
> 
> I want to look some more and provide some additional comments.

that would be great.

> 
> >
> >
> >>One item that struck me as particularly demanding on an implementation
> >>is the sipTransactionTable. There is a huge amount of work in
> >>maintaining this table. I really doubt people will want to implement it.
> >
> >
> > i had similar feedback from others when support of the sipTransactionTable
> > was being considered by a project.    the effort involved in supporting
> > the table was a problem.
> >
> > we can focus some discussion on the viability of the table during wg last call.
> 
> Well, discussion can happen any time. Its happening now, in this email
> thread. I dont know what else you are expecting. 

sorry.  didn't mean to imply what came across.  we can definitely discuss
it now.  i'm just not used to actually having active discussion of the mib.
i'm used to getting one or two sporatic comments and only having focused
discussion during last call - when someone is forced to review the mib ;)

> I don't think the table
> is viable. You had similar feedback. Seems like a clear cut resolution
> to me.

not that i don't take your point of view as very significant, i do.  
i was hoping that others might concur before we decide to remove the table.
the table has been in every revision of the mib, so it has been reviewed
multiple times by multiple people... no one - until now has recommended it
come out.   i guess i had taken that as acceptance of it's potential usefulness
to someone.  my case of one project finding it questionable does not necessarily
make a case for it's removal.   we determined that support was feasible but
not all that useful for our platform.  

implementation experience with a mib usually decides such things and we don't 
have much (any?) feedback in that area (not likely to until the mibs are in an
rfc).   still, if we can resolve the question of usefulness now it would be
better than 
to have to revise the mib (ie, rfc) and deprecate objects found - through 
implementation experience - to be useless.

> 
> > i'd rather do that than to yank the table w/out further discussion.
> 
> *This* is the discussion.

agreed.

> 
> > at the very least, we can definitely make the table optional.
> > right now it appears to be in a mandatory group - which seem wrong to me anyway.
> 
> Mandatory is definitely wrong. I am not even sure optional is useful.
> 
> So - here is the question. What is the bar for putting something in the
> MIB? At one extreme, every piece of state managed by a server could be
> in the mib. At the other extreme, there is nothing, or a single summary
> statistic. I think a reasonable bar, is that there should be clear value
> in monitoring that information, from the perspective of fault and
> performance management in particular. If you cannot demonstrate such a
> use, it should be out.
> 
> I cannot think of a reason that I would want, from an operations center,
> to monitor the current set of transactions held in the system. Thus, I
> think it should be out.

it's hard for me to justify or defend the existence of this table as i
was not the original author of it.  but for the sake of discussion...

is there no value from a troubleshooting perspective?   you mentioned that
this information is likely logged for offline analysis - not real-time.
are transactions generally occuring too fast for real-time analysis to
be of worth?   it would seem to me that unless you know specifically which
transactions are of interest to you, it would be hard to use this table
for anything.  the table is defintely not a logging mechanism as transactions
will not persist for any historically significant time.

from a performance mgmt point of view...
could the increase in entries in this table be used to gain insight into
congestion in this or other parts of the sip network?   even if that were
the case, the simple sipCurrentTransactions gauge object would provide
similar insight (to congestion at least).   perhaps the to/from details 
in the table would lend some more insight to problems elsewhere in the
network?   i'm not sure.   

dave walker was the original author of this table, so maybe
he can offer some insight.  dave? 
i did find one old comment related to this table squirreled away in some 
old emails....

Kurt Robohm <[email-masked]> wrote:
> 
> sipCurrentTransacations         Does this reflect number of
>                                 calls in progress?
>                                 Intent of objects in table to
> sipTransactionTable             provide real time info on
>                                 number of calls being handled
>                                 real time?

Dave Walker <[email-masked]> responded:
> Transactions aren't calls.  The intent, as mentioned in Adelaide,
> is to evolve the transaction table to a call leg table (probably 
> for UAs only).  This hasn't been resolved yet, so no real changes 
> were made.

i can't find any further discussion by dave (or others) in subsequent 
revisions of the draft to work out any further evolution of this table.  
only minor comments related to the table - none questioning its existence.
dave's involvement in the last couple of revisions of the draft have been nil.
so perhaps the table is an articfact of an idea that was not fully
conceived or fleshed out.  that would lend itself to removal imo.

kevin
> 
> Is not our aim to take things out of protocols until we can't take out
> any more, rather than the other way around?
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 23 Mar 2003 15:23:56 +0200

There is a delicate balance to be looked for here. I doubt that 'every piece pf state' is useful information, both on grounds of resources, as well quantity of information that needs to be processed. SNMP agents run on the same hosts that run protocols, and the management information carried from SNMP agents to SNMP clients (managers) competes for bandwidth with other data traffic. When designing a MIB one needs to take into account that in order for the MIB to be useful, it needs to run in the context of the host and application resources, and that the management traffic that is generated needs to be a reasonable fraction of the traffic of the protocol or application that is being managed. In the context of the current discussion it looks to me that large state or session tables should be avoided, with more compact indications, or threshold based alarms being put in place instead.

Dan