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

[Aleksandr Ryabin <[e-mail]>]

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

At 11:49 PM 7/18/2002, [e-mail] wrote:


>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 <[e-mail]> on 07/18/2002 08:44:06 PM
>
>To:   Christer Holmberg <[e-mail]>, [e-mail],
>       Carl Rutter <[e-mail]>, Tom-PT Taylor
>       <[e-mail]>, Kevin Boyle <[e-mail]>,
>       "'Christian Groves'" <[e-mail]>
>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" <[e-mail]>
> > > >To: "Kevin Boyle" <[e-mail]>; "'Christer Holmberg'"
> > > ><[e-mail]>; "'Aleksandr Ryabin'"
> > > ><[e-mail]>; "'Christian Groves'"
> > > ><[e-mail]>; <[e-mail]>
> > > >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; [e-mail]
> > > > > 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:[e-mail]]
> > > > > Sent: Tuesday, July 16, 2002 10:12 AM
> > > > > To: Taylor, Tom-PT [CAR:B602:EXCH]; Aleksandr Ryabin; Christian 
> Groves;
> > > > > [e-mail]
> > > > > 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:[e-mail]]
> > > > > > > Sent: Friday, July 12, 2002 11:11 AM
> > > > > > > To: Christian Groves; [e-mail]
> > > > > > > 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
> > > > > > >


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