Subject: Re: Response from Service Change

From: Brian Rosen <[email-masked]>
Date: Tue, 5 Oct 1999 17:20:29 -0400

How can part of the wildcard match, and some other part
not match?  If the wildcard matches any terminations,
it matches.  Whatever it matches is affected by the command.
Part of a match is not a match, it matches or it doesn't.

th*s

matches this and thus, but doesn't match that.

Brian

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Tuesday, October 05, 1999 5:09 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Response from Service Change
>
>
>
> Oh no, you would need to optimize if part of the wildcard is
> matched and executed successfully and part of was not.
> In other words, returning the wildcard as is will not work
> for all cases.
>
> Abdallah Rayhan
>
> Brian Rosen wrote:
>
> > I'm not sure if I agree or don't with your conclusion,
> > but you made one error.
> >
> > Wildcard response would simply return whatever string the
> > request specified.  No string optimization.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Abdallah Rayhan [mailto:[email-masked]]
> > > Sent: Tuesday, October 05, 1999 4:29 PM
> > > To: Brian Rosen
> > > Cc: [email-masked]
> > > Subject: Re: Response from Service Change
> > >
> > >
> > > This is an interesting problem, thanks to wildcard.
> > >
> > > Zillion responses is out of the question, if TCP is slow as being
> > > argued before, this is a killer.
> > >
> > > Wildcard response leads to strings optimization which introduces
> > > delay. On the other hand, TerminationIDList seems be lengthy
> > > in some cases.
> > >
> > > If we assume that a terminationID string length is 10 bytes
> > > in average,
> > > and the MG/MGC supports/controls 1k-10k terminations, then we are
> > > looking into 11k-110k byte transaction, not to mention
> few bytes for
> > > the header. What is the average segment length ? Here
> where we will
> > > disagree, but for the sake of argument, say 5k. Then we are
> > > looking into
> > > 2-22 segments. Wildcard optimization may not be bad after
> all but we
> > > must allow temrinationIDList as well for cases where wildcard
> > > calculation
> > > is expensive.
> > >
> > > The ROOT is general and may not apply to all cases.
> > >
> > > My choice: is to allow wildcard and terminationIDList in
> > > service change reply.
> > >
> > > In case of audit, if the MGC decides to know what
> terminations exist,
> > > then there is no other way but to flood it with all
> > > terminations it asked for
> > > and no wildcards in this case.
> > >
> > > Probably, we need to point out in the MEGACO document
> that these kind
> > > of cases generate traffic bursts and should be handled with
> > > caution of the
> > > request side.
> > >
> > > Abdallah Rayhan
> > >
> > > Brian Rosen wrote:
> > >
> > > > Chuong Nguyen [[email-masked]] pointed out
> > > > a problem to me:
> > > >
> > > > What happens if you take a group of terminations out of
> > > > service with ServiceChange using a wildcard?
> > > >
> > > > Do you get a response for each termination that matches the
> > > > wildcard?  Is that what you want?
> > > >
> > > > The simple case of the whole gateway, using root, is
> > > > easy, you get one response.
> > > >
> > > > A trunk gateway with an OC3 going down is another story.
> > > >
> > > > I see 3 choices:
> > > >         Leave it, accept the zillion response messages
> > > >         Allow ServiceChange to return a terminationIDList
> > > >                 of all terminations that match
> > > >         Just say you only ever get one response, which
> > > >                 matches what you sent (wildcard response)
> > > >
> > > > Please remember, your answer may affect what the next
> > > > guy wants to do with an audit response using a wildcard!
> > > >
> > > > Brian
> > >
>

---

From: Michael Brown <[email-masked]>
Date: Tue, 12 Oct 1999 17:39:57 -0400

Sorry for the delay in responding to this thread... The problem here is a
misplaced clause. That is I think what Abdallah meant was that for the set
of all terminations which match the wildcard, some of them execute
successfully and others fail. The suggestion then is that the
terminationIDList is required to be able to determine specifically which
succeeded and which failed. I think this is definitely a good idea and is
one that is very important for efficient handling of bulk service change
requests on large MGs. In order to save on bandwidth and operating on the
assumption that the majority of the time the requests WILL succeed, perhaps
the list should include only the terminationIds which failed to execute the
Service Change request.

Actually, related to this, I think we also need to have the capability to
use the terminationIDList in the Service Change request as well as the
reply. Given that we don't require hierarchical naming for terminations or
make any requirement that whatever naming convention used is contiguous and
sequential, I think that this is a highly desirable capability. It is easy
to envision a logical group of lines, such as a Centrex group, where the
naming convention of the terminations does not have any imposed
hierarchical significance to allow wildcarding.

Michael

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Oct 1999 13:37:22 +0200

Having a terminationIDlist and allow wildcarding without returning each
instance of the wildcard termination sounds like a good thing to have in
the service change. The last thing an MGC/MC needs at a time when it
fails/restarts is to have to send/process lots of messages for
essentially the same information when a simple '*' or list in a
command/response would have been sufficient.

Cheers, Christian