Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

From: [email-masked]
Date: Fri, 19 Jul 2002 09:19:12 +0530

Aleksandr,
           When the discussion started on the list on the segmentation issue, I
had a look at
  this draft of MGCP that you mention below.

As far as my understanding goes,  the package concept of MGCP gives
 far more flexibility of extending the protocol as compared to MEGACO. While
MEGACO permits
 you to add new events, signals, properties and statistics through packages,
MGCP allows
 you to add any new parameter in the protocol. Thus, if you see the MGCP Bulk
Audit draft, it
 adds a new parameter "BA:". This parameter is at the same level as the "R:" or
Requested
Events (equivalent to the Event Descriptor in MEGACO) parameter. The package
also adds
 new return values for the AuditEndpoint command. In my view, adding new
parameters
 and new return arguments to an API is almost like adding a new command. I don't
think
 the MEGACO protocol definition allows this level of extensibility.

Rgds,

Vikas Bajaj

Aleksandr Ryabin <[email-masked]> on 07/18/2002 08:44:06 PM

To:   Christer Holmberg <[email-masked]>, [email-masked],
      Carl Rutter <[email-masked]>, Tom-PT Taylor
      <[email-masked]>, Kevin Boyle <[email-masked]>,
      "'Christian Groves'" <[email-masked]>
cc:    (bcc: Vikas Bajaj/HSS)

Subject:  Re: Segmentation  (was Re: [Megaco] Wildcarded Action Reply)

Hi,

BTW It just hit me that MGCP already has a proposed "bulk audits" draft
http://www.ietf.org/internet-drafts/draft-foster-mgcp-bulkaudits-02.txt
I know MGCP is not MEGACO :), but this is just an advocate the idea
of using a package to solve the issue.

Cheers.
         Aleks

At 11:02 AM 7/18/2002, Christer Holmberg wrote:

>Hi,
>
>I don't think we have to define "large" and "small" wildcards. The point
>is that
>when wildcards are used there is a risk that the reply messages may be too
>big for
>UDP. Short and simple :)
>
>I am not even sure audits is the biggest problem (there may eg be bigger
>issues
>with subtracts), but that's also beside the point. Wildcarding and UDP just
>doesn't match (assuming you don't use an application based segmentation
>mechanism,
>that is) - no matter the command :)
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>Aleksandr Ryabin wrote:
>
> > But you will still have problem with wildcard context audits (as Kevin
> noted)
> > as well as when the "smallest" wildcard (e.g. one trunk) still produces too
> > large reply.
> >
> >          Aleks
> >
> > At 06:49 AM 7/18/2002, Carl Rutter wrote:
> > >In addition to what Tom just said,
> > >If not TCP or SCTP
> > >The MGs will send up 533s and the MGCs that are dealing with large
> trunking
> > >etc Gateways
> > >will have to deal with paring their requests down, as currently discussed.
> > >
> > >Carl
> > >----- Original Message -----
> > >From: "Tom-PT Taylor" <[email-masked]>
> > >To: "Kevin Boyle" <[email-masked]>; "'Christer Holmberg'"
> > ><[email-masked]>; "'Aleksandr Ryabin'"
> > ><[email-masked]>; "'Christian Groves'"
> > ><[email-masked]>; <[email-masked]>
> > >Sent: Thursday, July 18, 2002 1:35 AM
> > >Subject: RE: Segmentation (was Re: [Megaco] Wildcarded Action Reply)
> > >
> > >
> > > >
> > > >
> > > > In v1 we deliberately left the segmentation issue for another day.  We
> > > > figured it was more important to get implementation experience and see
> > >what
> > > > was really required.  I can only suggest that if these massive
> audits are
> > > > really required, large v1 gateways will have to support TCP or SCTP:
> > >market
> > > > pressures will make themselves felt.
> > > >
> > > > -----Original Message-----
> > > > From: Boyle, Kevin [NCRTP:3R90:EXCH]
> > > > Sent: Tuesday, July 16, 2002 12:13 PM
> > > > To: Christer Holmberg; Taylor, Tom-PT [CAR:B602:EXCH]; Aleksandr
> Ryabin;
> > > > Christian Groves; [email-masked]
> > > > Subject: RE: Segmentation (was Re: [Megaco] Wildcarded Action Reply)
> > > >
> > > >
> > > > I'm not so much worried about termination audits -- those are easily
> > > > segmented through judicious use of partial wildcards in the requests.
> > > > However, CONTEXT audits are not so easily segmented, especially since
> > > > partial wildcards are not allowed in context IDs.
> > > >
> > > > Consider this:
> > > >
> > > > !/2 [1.2.3.4]:2944 T=5{C=*{AV=Root{AT{}}}}
> > > >
> > > > The response would be:
> > > >
> > > > !/2 [1.2.3.5]:2944
> > > >
> > >P=5{C=1{AV=Root{}},C=2{AV=Root{}},C=3{AV=Root{}},...,C=4294967295{AV=Ro
> ot{}}
> > > > }
> > > >
> > > > Remember that the context ID space is 32 bits wide, and very large
> > >gateways
> > > > could have thousands (or more) of calls at any given moment.  This
> > >response
> > > > is about 1.5K in size at about 100 contexts.  It grows faster as the
> > >context
> > > > IDs get larger.
> > > >
> > > > That being said, I, personally, have no problem with saying that this
> > >should
> > > > be handled via transport.  But, keep in mind that:
> > > >
> > > > 1) MGs may choose to support only UDP,
> > > > 2) MGCs cannot establish TCP/SCTP connections to MGs -- they have to be
> > > > established by the MG,
> > > > 3) we can't remove UDP from v1 and v2.
> > > >
> > > > I believe that if we are going to allow the use of UDP, and we are
> going
> > >to
> > > > allow the construction of giant messages, that we should be able to
> send
> > > > those messages.
> > > >
> > > > Here's a couple additional thoughts on requirements for a potential
> > > > segmentation solution:
> > > >
> > > > The MG should be able to initiate segmentation on its own, not
> depend on
> > >the
> > > > MGC segmenting the request upon receipt of an error.
> > > > Not only should segmentation/reassembly errors be detected, the
> mechanism
> > > > should gracefully recover from those errors.
> > > > Since this would apply to UDP, the exisiting ALF mechanism should be
> > >reused
> > > > with as little change as possible.
> > > >
> > > > I am not so attached to having a unified solution for all
> versions.  Part
> > >of
> > > > the point of a new version is adding enhancements that were
> overlooked in
> > > > the previous ones, such as individual property audit.  This seems,
> to me,
> > >to
> > > > be one of those kinds of enhancements.
> > > >
> > > > Kevin
> > > >
> > > > -----Original Message-----
> > > > From: Christer Holmberg [mailto:[email-masked]]
> > > > Sent: Tuesday, July 16, 2002 10:12 AM
> > > > To: Taylor, Tom-PT [CAR:B602:EXCH]; Aleksandr Ryabin; Christian Groves;
> > > > [email-masked]
> > > > Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)
> > > >
> > > >
> > > >
> > > > >I was planning to mention the SIP stuff myself, but I didn't since I
> > >think
> > > > there
> > > > >are some different issues between the problem in SIP and H.248
> (they are
> > > > pretty
> > > > >relevant, however, so we don't need to go into those...).
> > > >
> > > > Non-relevant, that is... ;)
> > > >
> > > > Regards.
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > >
> > > > Christer Holmberg wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I was planning to mention the SIP stuff myself, but I didn't since I
> > >think
> > > > there
> > > > > are some different issues between the problem in SIP and H.248
> (they are
> > > > pretty
> > > > > relevant, however, so we don't need to go into those...).
> > > > >
> > > > > I also think that for AuditXxx the problem can be solved pretty
> easy by
> > > > > splitting the wildcard into smaller pieces. For wildcarded Subtracts,
> > > > however,
> > > > > it MAY be more difficult. It really depends on how much the MGC knows
> > > > about the
> > > > > MG (we should assume it may not know anything), the MG termination
> > >naming
> > > > > pattern, and how time critical the operation is, etc etc etc.
> > > > >
> > > > > However, I think the first question we should ask: for how many
> people
> > > > would it
> > > > > be a problem if we only had a transport based mechanism? In other
> words,
> > > > is it a
> > > > > problem to use some other transport protocols (for specific, or all,
> > > > messages)
> > > > > than UDP? Again, I don't have anything against having an application
> > >based
> > > > > segmentation mechanism, but what I'm trying to figure out is how much
> > >it's
> > > > > really needed :)
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > > Tom-PT Taylor wrote:
> > > > >
> > > > > > I've been rather maxed out or else pretty well inaccessible for the
> > >last
> > > > few
> > > > > > weeks, but here I am now.  I'm not really convinced that you
> need an
> > > > > > application-level solution to a transport problem.    SIP has
> run into
> > > > the
> > > > > > same difficulty, and are facing the reality that they have to
> use TCP
> > >or
> > > > > > SCTP.  I should note that H.248v2 provides part of an answer by
> > >allowing
> > > > > > more selective auditing (thanks to Christian's efforts).
> > > > > >
> > > > > > In any event, "requirement" 8 is not a requirement -- it is a
> > >technical
> > > > > > proposal.  I also want to make sure one point is well understood:
> > >there
> > > > are
> > > > > > only two versions of the protocol, 1 and 2.  3015corr is version 1
> > >with
> > > > all
> > > > > > corrections rolled in.  That said, if you really want to meet
> > > > requirement 7,
> > > > > > it has to be by clever use of existing version 1 protocol
> mechanisms.
> > > > These
> > > > > > mechanisms are defined by the main body of the specification.  You
> > > > cannot
> > > > > > contradict anything in the main body by what you write in a
> package.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Aleksandr Ryabin [mailto:[email-masked]]
> > > > > > Sent: Friday, July 12, 2002 11:11 AM
> > > > > > To: Christian Groves; [email-masked]
> > > > > > Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action
> Reply)
> > > > > >
> > > > > > Hi Christian and folks,
> > > > > >
> > > > > > And I'd like to add another several requirements (which might be
> > >given,
> > > > > > or optional, or even questionable, but worth mentioning):
> > > > > >
> > > > > > 6. provide backward compatibility
> > > > > > 7. provide unified solution for all versions of protocol
> > > > > > 8. provide "application based" message segmentation
> > > > > >
> > > > > > Now I'd like to sum what solutions have been proposed so far:
> > > > > >
> > > > > > 1. Kevin B.: modify protocol and define descriptor with "sequence
> > > > number",
> > > > > > add "end of transaction" token and a "partial ack" token.
> > > > > >
> > > > > > 2. Christer H.: modify protocol to include "identifier" to be
> used to
> > > > > > reassemble separate transactions.
> > > > > >
> > > > > > 3. Aleks R.: Define "split" package to control flow of reply
> messages
> > > > > > (obsoleted: define an extension for "enumeration" mechanism).
> > > > > >
> > > > > > 4. Christian G.: Use "transport based" message segmentation.
> > > > > >
> > > > > > I understand the protocol was designed with no segmentation
> > >provisions,
> > > > > > but so far we have three proposals for "application based" message
> > > > > > segmentation, which means that req 8 is really important.
> > > > > > Before going into any further analysis does folks agree on that?
> > > > > >
> > > > > > Thanks
> > > > > >          Aleks
> > > > > >
> > > > > > At 11:14 PM 7/11/2002, Christian Groves wrote:
> > > > > > >G'Day Aleks,
> > > > > > >
> > > > > > >Segmentation is new functionality, however you try to bend it, it
> > >does
> > > > not
> > > > > > >clarify
> > > > > > >or fix because when we designed Megaco we were all well aware that
> > > > > > >segmentation
> > > > > > >wasn't in it. It was given UDP had this problem. If you use ATM
> > > > transport
> > > > > > then
> > > > > > >you don't need to implement UDP. The example you gave of
> timestamps
> > >is
> > > > not
> > > > > > the
> > > > > > >same akin to this topic as timestamps already exist in the core
> > > > protocol.
> > > > > > >
> > > > > > >I assume that we are operating in the real world because today
> > > > segmentation
> > > > > > is
> > > > > > >solved "outside" the core protocol. ie. SCTP. We already have a
> > > > mechanism
> > > > > > >(error
> > > > > > >code 533) where by the MG can indicate that a response is too
> large
> > >and
> > > > > > >then the
> > > > > > >MGC can ask for smaller replies. This is effectively what is being
> > > > proposed
> > > > > > in
> > > > > > >the segmentation package.
> > > > > > >
> > > > > > >Let's talk about requirement rather than protocol solution. A
> start
> > >for
> > > > > > some
> > > > > > >requirements would be:
> > > > > > >o provide an efficient means to segment and reassemble H.248
> protocol
> > > > > > messages
> > > > > > >o provide a means to detect segmentation/reassembly errors
> > > > > > >o Minimise protocol overhead in terms of signalling, BW,
> processing
> > > > > > >o Minimise dependencies (maximise transparency) to the Megaco
> state
> > > > machine
> > > > > > >o Maximise throughput of signalling data
> > > > > > >
> > > > > > >Regards, Christian
> > > > > > >
> > > > > > >
> > > > > > >Aleksandr Ryabin wrote:
> > > > > > > >
> > > > > > > > Hi Christian,
> > > > > > > >          Please see below inline [AR] .
> > > > > > > >
> > > > > > > > At 02:34 AM 7/11/2002, Christian Groves wrote:
> > > > > > > > >G'Day Aleks,
> > > > > > > > >
> > > > > > > > >Please see my replies below.
> > > > > > > > >
> > > > > > > > >Regards, Christian
> > > > > > > > >
> > > > > > > > >Aleksandr Ryabin wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Christian,
> > > > > > > > > >
> > > > > > > > > > To address your concern regarding "a new event you
> modify the
> > > > > > behaviour
> > > > > > > > > of the
> > > > > > > > > > core protocol" I'd like to point out that there are
> numerous
> > > > drafts
> > > > > > out
> > > > > > > > > > there that
> > > > > > > > > > extend and alter protocol behavior. Thus I think as long as
> > > > altered
> > > > > > > > > > behavior does
> > > > > > > > > > not contradict (e.g. breaks) basic protocol
> functionality, but
> > > > > > rather
> > > > > > > > > > clarifies how
> > > > > > > > > > MGC controls MG that should be fine.
> > > > > > > > >
> > > > > > > > >[CHG] Could you please point me to these drafts for Megaco?
> > >Perhaps
> > > > > > > the reason
> > > > > > > > >that they are still drafts is that they weren't accepted for
> > > > approval.
> > > > > > > Just
> > > > > > > > >because a draft is written and submitted to the IETF
> doesn't mean
> > > > that
> > > > > > > it is
> > > > > > > > >right. For example the call flows document and the association
> > > > draft, I
> > > > > > > > >wouldn't
> > > > > > > > >base an implementation on these.
> > > > > > > >
> > > > > > > > [AR] Any package which has "Procedures" paragraph does
> clarify how
> > > > and
> > > > > > what
> > > > > > > > has to be changed in MGC-MG messaging to utilize that package.
> > > > > > > >
> > > > > > > > I do not want to go into debate of "what did you precisely mean
> > >and
> > > > why
> > > > > > you
> > > > > > > > used it here" :) but as an example in
> > > > > > > draft-manyfolks-megaco-caspackage-02.txt:
> > > > > > > >
> > > > > > > > "7.6.1 Timestamp Procedures.
> > > > > > > > Inclusion of a timestamp in the ObservedEvents descriptor is
> > > > mandatory
> > > > > > > for the
> > > > > > > > RBS package. The timestamp reflects the detection time for the
> > >event
> > > > > > > and may
> > > > > > > > be used by services (e.g. automatic message accounting) on the
> > >MGC."
> > > > > > > >
> > > > > > > > Note how package mandates of inclusion of a timestamp which in
> > >core
> > > > > > > protocol
> > > > > > > > is optional, thus it does modify, or I'd say clarify core
> protocol
> > > > > > > behavior.
> > > > > > > >
> > > > > > > > >I don't see that the proposed addition
> > > > > > > > >"clarifies", it adds new functionality.
> > > > > > > >
> > > > > > > > [AR] Yes it does indeed, as any package does. Although at
> the same
> > > > time
> > > > > > it
> > > > > > > > clarifies and "fixes" usage of core protocol in the place
> where it
> > > > has
> > > > > > > a flaw.
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I mean for this specific case, where does the the
> protocol say
> > > > that
> > > > > > > MG has
> > > > > > > > > > to return
> > > > > > > > > > exactly the same reply to two exactly the same transactions
> > >with
> > > > > > only
> > > > > > > > > > difference
> > > > > > > > > > in time sent and transaction ids? Thus MG can possibly
> return
> > > > even
> > > > > > > > > right now
> > > > > > > > > > replies like in examples below (less of course the "split"
> > > > package
> > > > > > > > > stuff), but
> > > > > > > > > > the only problem would be for MGC to "assemble" them. Thus
> > > > "split"
> > > > > > > package
> > > > > > > > > > approach does not invent here anything, but rather
> "controls"
> > >MG
> > > > on
> > > > > > > > > what and
> > > > > > > > > > when to return and that is a primary functionality of MGC,
> > >after
> > > > > > > all it is
> > > > > > > > > > a Media
> > > > > > > > > > Gateway Controller :)
> > > > > > > > >
> > > > > > > > >[CHG] You do not need the "split" package for the MGC to
> do this.
> > > > We
> > > > > > > already
> > > > > > > > >have error code 533 which enables the MGC to requests more
> atomic
> > > > > > replies.
> > > > > > > >
> > > > > > > > [AR] As I already suggested, granularity is not going to
> work in
> > >all
> > > > > > > the cases.
> > > > > > > > The only case it will work all the time if no wildcards used at
> > >all,
> > > > > > which
> > > > > > > > is not a best solution in some cases, thus we have this
> discussion
> > > > :)
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I'd like to stress a "protocol" solution as I do
> believe that
> > >it
> > > > > > > has to be
> > > > > > > > > > addressed in
> > > > > > > > > > the protocol, not outside of it, as not to have intentional
> > > > "holes"
> > > > > > > in the
> > > > > > > > > > protocol.
> > > > > > > > > >
> > > > > > > > >[CHG] Why? Shouldn't we look at the benefits of such an
> approach?
> > > > Less
> > > > > > > > >signalling, more timely responses. It seems to me to have it
> > > > outside
> > > > > > the
> > > > > > > > >protocol is more natural. SCTP for instance already
> provides this
> > > > > > service.
> > > > > > > >
> > > > > > > > Let me rephrase. I have nothing against using of benefits
> outside
> > > > the
> > > > > > > protocol.
> > > > > > > > In fact I'm very much for it, but in real world when you have a
> > >real
> > > > > > > > application
> > > > > > > > it is not that easy to "fix" a core protocol limitation, by
> > >seeking
> > > > to
> > > > > > > patch it
> > > > > > > > on outside of a protocol. Sometimes it is easier to switch
> to some
> > > > other
> > > > > > > > protocol all together :-) You would not just take off and go to
> > > > Alaska
> > > > > > > because
> > > > > > > > it is always hot in your home. Instead you will probably
> first see
> > > > if
> > > > > > > you can
> > > > > > > > install an air conditioner :)
> > > > > > > >
> > > > > > > > All I'm saying is if a protocol (not specifically MEGACO)
> defines
> > > > set
> > > > > > > of rules,
> > > > > > > > these set of rules (in ideal world) SHELL work all the time.
> > > > Applying
> > > > > > this
> > > > > > > > to MEGACO: the protocol defines that UDP transport protocol is
> > > > mandatory
> > > > > > > > for MGC and it defines usage of wildcard, but in a real
> world this
> > > > is
> > > > > > not
> > > > > > > > going
> > > > > > > > to work due to limitations of UDP.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >          Aleks
> > > > > > > >
> > > > > > > > >..snip..
> > > > > >
> > > > > > _______________________________________________
> > > > > > Megaco mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > > > >
> > > > > > _______________________________________________
> > > > > > Megaco mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > > >
> > > > > _______________________________________________
> > > > > Megaco mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > >
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 19 Jul 2002 10:45:08 -0400

Hi Vikas,

         I did say "I know MGCP is not MEGACO" :)
The point was to show that MGCP follows the route of package to deal with
segmentation and that the basic semantics are similar to proposed "split" 
package.
That is using some kind of sequence-number/identifier/handle/or-something-to-
indicate-segmentation control size of replies as well as provide a mechanism
to reassemble multiple transactions which logically belong to one 
request/reply.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 19 Jul 2002 10:45:08 -0400

Hi Vikas,

Thanks
         Aleks