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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 15 Jul 2002 23:48:33 -0400

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Jul 2002 17:12:28 +0300

>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:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Jul 2002 17:12:28 +0300

Regards.

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Jul 2002 17:10:00 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Jul 2002 17:10:00 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland