Subject: RE: Network Package

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 May 2001 11:38:15 -0400

I prefer the current design, where the extension inherits the
properties/events/signals/statistics from the base.
I think there are lots of cases where it's better to NOT expose
the base package.  Your proposal would disallow that possibility.
I think the duplication is not much of an issue.

Brian

> -----Original Message-----
> From: Kevin Boyle [mailto:[email-masked]]
> Sent: Thursday, May 31, 2001 11:09 AM
> To: Rosen, Brian
> Cc: [email-masked]'; [email-masked]
> Subject: Re: Network Package
> 
> 
> All,
> 
> It is exactly these kinds of conundrums that prompted me to 
> post some months
> ago about the ability to address signals/etc. by the 
> extension package ID.
> Why is this necessary?  If you support an extension, then, by 
> definition,
> you support the base package.  So why not mandate that 
> signals/etc. from the
> base package be addressed by the base package?  This prevents 
> such silliness
> as getting multiple copies of a statistic (a/t1, b/t1).  Then 
> the only time
> there would be an overlap would be when there is a functional 
> extension of
> the signal/etc. by the extension, such as adding new values for a
> parameter.  Then, if you wish to take advantage of the new 
> values, it would
> be addressed as the extension package.
> 
> To illustrate:
> 
> Package a: e1, e2{parm1=1,2,3}, s1, p1, t1
> Package b extends a: e2{parm1=1,2,3,4}, e3, s2, p2, t2
> 
> These would then be addressed as:
> 
> a/e1
> a/e2{parm1} (in this case, parm1 may only have value 1, 2, or 3)
> b/e2{parm1} (in this case, parm1 may have value 1, 2, 3, or 4)
> b/e3
> a/s1
> b/s2
> a/p1
> b/p2
> a/t1
> b/t2
> 
> This would reduce a lot of these redundancy problems when 
> talking about
> package extensions, and, it seems to me, is a very concise 
> way of handling
> extensions without having to "hide" packages in the MG.  Now, 
> this certainly
> does not handle multiple copies of the same event, but that 
> would qualify
> as, as Brian puts it, a "stupid program".
> 
> That's my two cents worth, anyway...
> Kevin
> 
> "Rosen, Brian" wrote:
> 
> > Like any protocol, you can misuse it.  The design of the protocol
> > can discourage misuse, but it can never eliminate it.  There is
> > nothing that prevents you from, for example, setting an event
> > descriptor that has the SAME event listed twice.
> >
> > What should you do?  It's not an error in the sense that the
> > protocol declares it to be illegal.
> >
> > The results are probably unpredictable.  That is okay.
> > We can't realistically fix stupid programs.  We can specify
> > what happens in realistic situations.  There are reasonable
> > scenarios where an MG may wish to expose the underlying package,
> > but most don't make any sense.  If an MGC is stupid enough to
> > specify both events on the same termination, what it gets may be
> > a surprise.  I won't stay up nights worrying about it.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Thursday, May 31, 2001 7:55 AM
> > > To: [email-masked]
> > > Subject: RE: Network Package
> > >
> > >
> > >
> > >
> > > Hi
> > >
> > > Apart from the IG not mentioning about the "double notify",
> > > we have another
> > > issue....
> > > In case both the events in the ED have an embedded event
> > > descriptor(EED), which
> > > EED should be activated.
> > > Is it decided based upon the sequence of events in the ED ??
> > > ...if it is so we donot guarantee "double notify"...in case
> > > of EEDs...is it
> > > right.
> > >
> > > Would it not be appropriate to restrict the definition of
> > > A/E1 and B/E1 (in case
> > > B extends a package A with event E1), to mean the same event...
> > >
> > > How about restricting MG as well as MGC to expose only "leaf"
> > > packages (extended
> > > packages) but to be lenient enough to accept both base as
> > > well as extended
> > > package definitions....this would take care of any
> > > interoperability and
> > > compatibilty issues too.
> > > Hence, MGC would send only A/E1 in ED but can accept A/E1 and
> > > B/E1 in observed
> > > ED.
> > > and MG shall send only A/E1 in observed ED (or A in Audit
> > > response) and accept
> > > B/E1 in ED etc.
> > > Any comments..
> > >
> > > -Kapil Nayar
> > > Hughes Software Systems
> > >
> > >
> > >
> > > HI Peter/All,
> > >
> > > Might be an implementation issue but let me put the same
> > > query with some
> > > sample code.
> > >
> > > The Section 7.1.9 Events Descriptor 4th paragraph,
> > > "When an event is processed against the contents of an 
> active Events
> > >    descriptor and found to be present in that descriptor
> > > ("recognized"),
> > >    the default action of the MG is to send a Notify command
> > > to the MG."
> > >
> > > After interpretation, the statement above was implemented 
> as follows
> > >
> > > ProcessDetectedEvent( Event detected is passed)
> > > {
> > >   if ( Events Descriptor is active)
> > >   {
> > >       for ( each event in the events descriptor )
> > >       {
> > >            if ( match Found)
> > >            {
> > >                  GenerateNotifyTowardsMGC ( event, timestamp,
> > > RequestId,
> > > etc...)
> > >                  PostEventDetectionProcessing(Event Detected)
> > >                  break;
> > >            }
> > >       }
> > >   }
> > >   else
> > >      ProcessEventAccordingToEventsBufferDescriptor( Event 
> detected is
> > > passed)
> > > }
> > >
> > > Its true that the IG mentions about package extension, but no
> > > where (I mean
> > > either in IG/protocol) its mentioned that if one event
> > > recognition matches
> > > two events in the Events Descriptor...(at First I wondered
> > > how this was
> > > possible...) there will be two Notify commands generated 
> towards MGC.
> > >
> > > IMHO Unless explicitly mentioned about the multiple Notifies
> > > for single
> > > hardware event, the general interpretation of event matching
> > > will be some
> > > thing as shown above...which is actually not the intent.
> > >
> > > Regards
> > > Madhubabu
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Blatherwick, Peter [mailto:[email-masked]]
> > > Sent: Tuesday, May 29, 2001 10:05 PM
> > > To: 'Madhu Babu Brahmanapally'; [email-masked]
> > > Subject: RE: Network Package
> > >
> > >
> > > Now I'm not so sure what you're getting at below -- what is
> > > different from
> > > previous examples.  I see the rules as completely general.
> > > MG simply checks
> > > for events to report (redundant or not, doesn't care or even
> > > necessarily
> > > know), in the order requested, and for each one follows the
> > > buffering/reporting algorithm per current handling settings.
> > > Perhaps a more
> > > explicit example?
> > >
> > > Re the IG, I don't think it explicitly mentions "synonyms"
> > > (nice term by the
> > > way ;-), but does give clear guidance on what is considered
> > > equivalent, how
> > > the MG exposes its interfaces, and how the MGC specifies what
> > > it wants.
> > > Event reporting text in the core protocol document and/or IG
> > > I personally
> > > believe already are clear on how events are reported.  Since
> > > we are not
> > > talking about special cases, simply same handling for all
> > > events requested
> > > by MGC, I don't see that specific text is required.  My opinion.
> > >
> > > -- Peter
> > >
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > > Sent: May 29, 2001 21:44
> > > To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
> > > [email-masked]
> > > Subject: RE: Network Package
> > >
> > >
> > > HI Peter/All,
> > >
> > > I agree that the MG does whatever is said by the MGC. But, if
> > > say Events
> > > Descriptor is X,Y,Z and say X and Z means the same (Similar
> > > to the A/T1 and
> > > B/T1). Now the MG while reporting the event in the Notify
> > > also has to check
> > > events beyond match???? Is this fine???
> > >
> > > 1) Then this has to be true while buffering events in 
> Events Buffer
> > > according to Event Buffer descriptor and
> > > 2) While processing of new events descriptor when Event
> > > Buffer control is
> > > lockstep.
> > >
> > > But I see no such statement in the Protocol Text. If the 
> intention of
> > > matching of event is to match all the "synonyms" of the
> > > event. Then this
> > > text needs to be specified in the IG at least to avoid any
> > > misunderstandings.
> > >
> > > Regards
> > > Madhubabu
> > >
> > >
> > > -----Original Message-----
> > > From: Blatherwick, Peter [mailto:[email-masked]]
> > > Sent: Tuesday, May 29, 2001 9:22 PM
> > > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
> > > [email-masked]
> > > Subject: RE: Network Package
> > >
> > >
> > > As in previous e-mail, just sent, I don't believe the below
> > > error should
> > > apply to the case of MGC requesting both A/T1 and B/T1.   
> MG is simply
> > > responding to the request.   May be a better case for using
> > > this if the
> > > request is for A/T1 and A/T1, but I still don't think so.  MG
> > > simply does as
> > > its told.
> > > -- Peter
> > >
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > > Sent: May 29, 2001 19:19
> > > To: 'Rosen, Brian'; 'Chuong Nguyen'; [email-masked]
> > > Subject: RE: Network Package
> > >
> > >
> > > Brian/All,
> > >
> > > Sorry for wrong information in my earlier mail.... Error 
> code "456 -
> > > Parameter or Property appears twice in this Descriptor" 
> is present for
> > > avoiding multiple instances of properties/parameters. If A/T1
> > > and B/T1 mean
> > > the same doesn't this fall into the above error category.
> > >
> > > Regards
> > > Madhubabu
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of 
> Rosen, Brian
> > > Sent: Tuesday, May 29, 2001 5:47 PM
> > > To: 'Chuong Nguyen'; [email-masked]
> > > Subject: RE: Network Package
> > >
> > >
> > > Well rtp/dur and nt/dur are "the same thing" in the sense
> > > that the mean the
> > > same
> > > thing, but if you implement (expose) both packages, then they
> > > are "separate"
> > > statistics.  Using Events is perhaps easier to understand.
> > > Suppose Package
> > > A
> > > implements event E1, and package B extends Package A, and a given
> > > implementation
> > > exposes both A and B, such that an audit of termination T1 returns
> > > Packages{..A,B..}
> > >
> > > You can say Add=T1{Events=123{B/E1}}
> > > or you can say
> > > Add=T1{Events=123{A/T1}}
> > > or even
> > > Add=T1{Events=123{A/T1,B/T1}}
> > >
> > > In the latter, detection of the event would result in a
> > > notify of both.
> > >
> > > Returning to statistics, the value would be the same, but
> > > they are separate
> > > statistics.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Chuong Nguyen [mailto:[email-masked]]
> > > Sent: Tuesday, May 29, 2001 5:29 PM
> > > To: [email-masked]
> > > Subject: Re: Network Package
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > If you implement any part of a package, you implement all of
> > > it.If a package
> > > extends any part of a package, it extends all of it.
> > >
> > > What is not required is that if you implement a package that
> > > extendsanother
> > > package that you have to "expose" the underlying package.This
> > > means that if
> > > you implement rtp you don't have to expose nt.If you list nt
> > > as one of the
> > > packages in an audit, then you have toimplement nt/dur.
> > >
> > >
> > > <cnn>  I don't quite follow here.
> > >                You seem to imply that nt/dur and rtp/dur are
> > > 2 different
> > > things.
> > >                I thought both nt/dur and rtp/dur are the same
> > > thing w/the
> > > same value.
> > >               If MG exposed nt, what should it return for
> > > duration - nt/dur
> > > or rtp/dur?
> > >
> > >
> > > Do you know the intend of tdmc/os and tdmc/or?
> > > I thought the same as Madhubabu about how they are calculated.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [ mailto:[email-masked]
> > > <mailto:[email-masked]> ]
> > > Sent: Tuesday, May 29, 2001 5:15 PM
> > > To: 'Chuong Nguyen'
> > > Cc: [email-masked]
> > > Subject: RE: Network Package
> > > Hi chuong/all,IMO if PackageB extends PackageA and if one of the
> > > statistic/property of Package A is not valid for 
> termination realizing
> > > packageB then there is no reason why PackageB extends 
> PackageA. Then
> > > PackageB shouldn't extend PackageA (just only to reuse few
> > > properties/statistics) but should define the same properties
> > > (Might be with
> > > different IDs) in packageB. I think the extension of packages
> > > is logical if
> > > the newly defined package can inherit "all" the properties
> > > already defined
> > > in the base package and also define new properties. In your
> > > example, I was
> > > in the impression that "OS" and "OR" can be calculated as
> > > "The number of
> > > octet sent or received is equal to the duration of the 
> Termination, in
> > > seconds, multiplied by the sampling frequency,  8000 Hz.".
> > > (Of course this
> > > seems to be redundant info if the MGC is aware of the
> > > sampling frequency).
> > > Isn't this the intention?????-RegardsMadhubabu
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > >  mailto:[email-masked]
> > > <mailto:[email-masked]> ]On Behalf Of
> > > Chuong Nguyen
> > > Sent: Tuesday, May 29, 2001 4:38 PM
> > > To: [email-masked]
> > > Subject: Network Package
> > > Hi All
> > >
> > >
> > > Is it reasonable to assume that Network Package StatisticsID
> > > will never be
> > > used directly?
> > > That is nt/dur, nt/os and nt/or will normally be rtp/dur,
> > > rtp/os and rtp/or
> > > respectiviely
> > > since rtp package extends nt package.
> > >
> > >
> > > I know that it is agreed that if a termination realizes rtp
> > > package, it also
> > > realizes nt package
> > > and either nt/.. or rtp/.. are valid packageName.
> > >
> > >
> > > But if we allow, nt/... instead of rtp/.., are we saying 
> that if MGC
> > > receives nt/.., it has to
> > > know whether it is for rtp or tmcd termination by the 
> terminationID?
> > >
> > >
> > >
> > > Furthermore, since tdmc package extends nt package, do "octet
> > > sent" (OS) and
> > > "octet
> > > received" (OR) really apply to tdm termination?
> > >
> > >
> > > Also what does it mean for a TDM termination to realize the
> > > "NT" package
> > > properties
> > > of "Maximum Jitter Buffer"?
> > >
> > >
> > > So a more general question, if a termination realizes a 
> packageB that
> > > extends
> > > packageA and there are items in the packageA that does not
> > > make sense to
> > > the termination what should MG/MGC do.
> > >
> > >
> > > Take the above as an example and assuming that it does not
> > > make sense for
> > > TDM
> > > termination to have "OS" and "OR", what should MG return for
> > > TDM termination
> > > statistics if the termination realizes "TDMC" package?
> > > Just "duration".
> > >
> > >
> > > ---
> > > Said it is valid to have "OS" and "OR" for TDM.
> > > IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
> > > termination,
> > > is it valid for MG to return nt/dur, nt/os and nt/or for the
> > > TDM termination
> > > and RTP
> > > termination instead of tdmc/dur, ... vs rtp/dur ?
> > >
> > >
> > > Thanks
> > > Chuong
> > >
> > >
> > >
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet: 
> [email-masked]
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc ****
> > >
> > >
> > > --
> > >
> > >   Alcatel USA, Inc             Internet: 
> [email-masked]
> > >
> > >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613
> > >
> > >   **** The opinions expressed are not those of Alcatel 
> USA, Inc ****
> > >
> > >
> > >
> > >
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 31 May 2001 14:55:18 -0400

I am not sure I see what is gained by the hiding of base packages... they're
not really hidden it at all, they've just had their addressing scheme
changed.  This "hiding" lends itself to misuse in situations like the
statistics reporting concern expressed earlier in the thread, when that
could be prevented by just addressing the package items by their base
address.

I guess I'm looking for some usecases that are specifically addressed by the
ability to "hide" base packages.  Do any come to mind?

Kevin

> > That's my two cents worth, anyway...

[snip]