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

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 16 Jul 2002 12:12:47 -0400

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=Root{}}
}

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2002 13:47:32 +1000

G'Day Kevin,

I think what you have is a fair summary. I agree that we can't remove UDP from
v1 or v2. Perhaps in v3 (whenever it comes) we'll remove the requirement that if
you support IP you have to support UDP. I think the first 2 requirements listed
below are probably a good idea. I'm not sure what the effects of your third
requirement are. I assume that if we support UDP we still have to be compliant
to ALF defined in v1 and v2.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2002 13:47:32 +1000

G'Day Kevin,

Regards, Christian