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

[Aleksandr Ryabin <[e-mail]>]

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
> > > > > >
> > > > > > 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
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > > > >
> > > > > > _______________________________________________
> > > > > > Megaco mailing list
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > > >
> > > > > _______________________________________________
> > > > > Megaco mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > >
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/megaco
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/megaco


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