Subject: RE: [Megaco] Wildcarded Action Reply

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 18:30:47 -0400

Hi,

         Sorry for not being clear.
As I indicated Modify is included "in a (wildcard) transaction", that is
a transaction that has wildcard(s) and thus potentially can be large.
Although it does not limit MGC to put it into non-wildcarded transaction
as well it will not do any harm in this case since it will manifest in
one enum iteration (that is reply will have "end=yes").
Since the order of command execution is guaranteed in a transaction
MGC shell place such Modify right before action to be "enumerated".
Thus we can even try to allow MGC to include several Modify commands
within one transaction which has multiple wildcarded actions. This might
complicate the matter so I'll leave it out for now up to the time package
to be worked on, if ever.

Here are simple examples of complete proposed text messages.

1.1 MGC includes Modify with handle=0 to instruct MG that it shell
start enumeration for this transaction which includes a wildcarded action.
It includes Audit descriptor with ObservedEvents token to be sure that
MG sends ObservedEvents descriptor with enumeration handle, e.g.:

!/1 [1.2.3.4]:2944
T=1{C=-{MF=ROOT{E=123{split/enum{end=no,handle=0}},AT{OE}}},
C=*{W-SC=*{MT=FO,RE=905}}}

1.2 MG starts enumeration, generates enumeration handle=567 and
sends it back in observed event descriptor along with partial
replies to wildcarded request. Lets assume MG has active contexts
5,6,7,8,9,10 and reply can only hold 4 of them, e.g.:

!/1 [1.2.3.5]:2944
P=1{C=-{MF=ROOT{OE=123{split/enum{end=no,handle=567}}},
C=5{W-SC=*},C=6{W-SC=*},C=7{W-SC=*},C=8{W-SC=*}}

2.1 Now MGC request to "continue enumeration" by including Modify with
returned by MG handle = 567 and setting end=no. Note that transaction
id is different from previous transaction, e.g.:

!/1 [1.2.3.4]:2944
T=2{C=-{MF=ROOT{E=123{split/enum{end=no,handle=567}},AT{OE}}},
C=*{W-SC=*{MT=FO,RE=905}}}

2.2 At this point there will be no more replies left after this, since MG
has only left to send replies for context 9 and 10, thus MG stops
enumeration, by sending back an observed event descriptor with
handle=567 and end=yes, along with rest of the partial replies
to wildcarded request, e.g.:

!/1 [1.2.3.5]:2944
P=2{C=-{MF=ROOT{OE=123{split/enum{end=yes,handle=567}}},
C=9{W-SC=*},C=10{W-SC=*}}

Enumeration complete, handle discarded.

Note: to be completely RFC compliant in the examples above
first reply should probably include error 533 "Max PDU reached"
as a last command reply, e.g.:

!/1 [1.2.3.5]:2944
P=1{C=-{MF=ROOT{OE=123{split/enum{end=no,handle=567}}},
C=5{W-SC=*},C=6{W-SC=*},C=7{W-SC=*},C=8{W-SC=*},
C=*{W-SC=*{ER=533{"Reached max, ask for more"}}}}

Now come to think about it, even without any package right now
for SeviceChange and Subtract in ALL Context MGC can simply
repeat same request (like it is done above but with no modify)
over and over again until it gets no replies at all, that is it gets
error 435 "no match", since MG will process for each request
as many terminations as it can include in the reply. Thus
eventually all terminations will be returned into NULL context
and no replies will be sent. But again, this would only work for
SC and S in ALL ctx while proposed package approach will
work for any command in any context.

This package can also include "split/compress=yes|no" property
which will act as analog to W-Command for Context. That is if MGC
sets split/compress=yes on ROOT then reply would look exactly as
Ron originally wanted it to be, e.g.
!/1 [1.2.3.5]:2944
P=1{C=*{W-SC=*}}

Thanks
         Aleks

At 03:53 PM 7/9/2002, Kevin Boyle wrote:
>Here's some constructs I've attempted based on the description(text
>examples... I'm not fluent in binary at this moment!):
>
>1) !/2 [1.2.3.4]:2944
>T=1{C=-{MF=Root{E=123{split/enum{end=no,handle=0}},AT{OE}}}
>-- It is not apparent to me how this command solves the problem.  This does
>not seem to perform segmentation of a particular transaction response, and
>the audit is directed only at OE.
>
>2) !/2 [1.2.3.4]:2944
>T=1{C=*{MF=Root{E=123{split/enum{end=no,handle=0}},AT{OE}}}
>-- This will return an error every time.  Root exists solely in Null and
>Null is not part of *.
>
>3) !/2 [1.2.3.4]:2944
>T=1{C=*{MF=<termname>/*{E=123{split/enum{end=no,handle=0}},AT{OE}}}
>-- This would have detrimental effects on existing Events descriptors on the
>given terms.
>
>I can only conclude that I do not properly understand what you are
>proposing.  The idea of utilizing a package is attractive, becuase it means
>that syntax changes are not required to the protocol.  But I am worried
>about possible side effects on established events descriptors in the
>meantime.  Perhaps some more explanation will clear this up for me...
>
>Kevin
>
>-----Original Message-----
>From: Aleksandr Ryabin [mailto:[email-masked]]
>Sent: Tuesday, July 09, 2002 12:41 PM
>To: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]
>Cc: Carl Rutter; 'Christian Groves'; [email-masked]
>Subject: RE: [Megaco] Wildcarded Action Reply
>
>
>Hi,
>
>         This is similar to "enumeration" and now come to think about it
>this functionality could be defined as a package thus I don't see any reason
>
>why can't it be added for any version, including v1.
>
>For example, let say we define a package "split" for ROOT termination with
>event "enum", event parameters "end = yes|no", "handle = <integer>" and
>observed event parameters "end = yes|no", "handle = <integer>".
>Where "handle = 0" from MGC means to start new enumeration.
>
>Then at any time MGC can include Modify on ROOT with
>Events = 123 { split/enum { end = no, handle = 0 }} and Audit {
>ObservedEvents }
>in a (wildcard)  transaction which will direct MG to start "enumeration".
>MG would return then reply with handle in Modify reply as
>ObservedEvents = { split/enum { end = no, handle = 567 }}
>and as many replies to the rest of the transaction as it can.
>MGC then can repeat transaction request including Modify
>with Events = 123 { split/enum { end = no, handle = 567 }}
>and Audit { ObservedEvents } to continue, or
>Events = 123 { split/enum { end = yes, handle = 567 }}
>to stop enumeration. Also MG can reply to Modify with
>ObservedEvents = 123 { split/enum { end = yes, handle = 567 }}
>to let MGC know that there is no more replies.
>MG can also send Notify with ObservedEvents in case there is
>a long delay from MGC, or some kind of error to stop enumeration.
>
>Additional "split/tmo=<integer>" property can be defined for ROOT
>to control the delay time-out.
>The package can also define "stale handle" error to report on stale
>enumeration handles.
>More over to speed up a process we can even define "expect=<integer>"
>observed event parameter to let MGC know in how many iterations MG
>expects the enumeration to be completed such that MGC can fire up
>that number of transactions at the same time once it gets reply to initial
>transaction with a "handle".
>
>Comments?
>
>Thanks.
>         Aleks
>
>At 11:07 AM 7/9/2002, Kevin Boyle wrote:
>
>
>I have given some thought to application-based message segmentation (as
>opposed to transport-based), and I haven't thought of a way to do it that
>works real well, without adding a ton of new complexity.  Here are some
>components of the "best" idea I have personally been able to come up with
>(which really isn't saying much):
>
>- a new "descriptor" that indicates more is coming, and gives a sequence
>number.  This requires the sender to break transactions only in specific
>places.  While the receiver will be able to reassemble the transaction, they
>will not know when the transaction ends.
>
>- a token to indicate "end of transaction" when it is broken across several
>messages.  This allows the receiver to know it can assemble all the pieces
>together and start processing.
>
>- a "partial ack" token, to allow senders to know when pieces have to be
>retransmitted.
>
>In order to make this all work, the sender would have to repeat the message
>from the beginning all the way through the transaction id on EACH piece (for
>example: "!/2 [1.2.3.4]:2944 T=12345{").  The new pieces would go INSIDE the
>transaction, at the action level. ("...action reponse here}, TP{SEQ=1}}")  A
>similar method could be used to segment long action replies.
>
>Now, this all adds a lot of complexity to the protocol that hasn't existed
>before.  It also requires application segmentation of protocol messages,
>which also hasn't existed before.  I am not sure how wise it is to add
>something this complicated to the protocol, and it certainly wouldn't happen
>before v3 at the earliest, as tacking this on would break early v2
>implementations.
>
>I think that using more granular audits is the answer -- but only in some
>cases.  Recovery from a catastrophic failure requires getting as much
>information as possible, as quickly as possible.  The ability to segment
>messages would be a great boon to that recovery effort, instead of trying to
>audit pieces at a time.  I'm not so sure my thoughts are the best way to
>achieve this segmentation, but I would like to eventually see something that
>effectively allows us to generate/process long messages.
>
>Kevin
>
>-----Original Message-----
>From: Carl Rutter [mailto:[email-masked]]
>Sent: Tuesday, July 09, 2002 9:42 AM
>To: 'Christian Groves'; Carl Rutter
>Cc: [email-masked]; [email-masked]
>Subject: RE: [Megaco] Wildcarded Action Reply
>
>Thanks,
>
>We limit the wildcards to a T1 right now on our switch
>so at most 24 replies would come back.
>
>It would be nice to send back a transaction reply
>with a flag saying there is another transaction reply(same transaction #)
>coming with more response data, or something like that??
>This would then break the transaction ack etc.  But some concept
>like this seems warranted??
>
>Carl
>-----Original Message-----
>From: Christian Groves [mailto:[email-masked]]
>Sent: Monday, July 08, 2002 8:22 PM
>To: Carl Rutter
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Megaco] Wildcarded Action Reply
>
>G'Day Carl,
>
>The work around would be to wildcard on a finer grain size. That way you can
>
>manage the number of replies. The alternative is that the MGC shall known
>the
>relationship between Termination IDs and Contexts IDs and it can release
>each as
>appropriate.
>
>Regards, Christian
>
>Carl Rutter wrote:
> >
> > This seems to be a significant flaw.
> > If there are many contexts the transaction would be
> > way too big.  This also would happen on Audits etc.
> > Anyone have thoughts on how we avoid/work around this?
> >
> > Carl
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Monday, July 08, 2002 1:36 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Megaco] Wildcarded Action Reply
> >
> > G'Day Ron,
> >
> > Unfortunately as you have pointed out the wildcarded only works on a
>command
> > level and not a context level. So in the case you point out the response
> > will be
> > larger than the requests. The original intention of w- responses was to
> > limit
> > the sizes of Audit responses.
> >
> > Unfortunately unless there is a protocol change you'll get a long response
>
> > back
> > for commands with wildcarded (ALL) contextIds.
> >
> > Regards, Christian
> >
> > Ron Stoughton wrote:
> > >
> > > Greeting Megaconians:
> > >
> > > If our MG desires to take an interface out of service that has active
> > > circuits engaged in calls on it, it very likely would send a command to
> > the
> > > MGC that looks like the following:
> > >
> > >     MEGACO/2 <mg1.acc.com>:16384
> > >     Transaction = 6 {
> > >             Context = - {
> > >                     W-ServiceChange = DS1/3/1/* {
> > >                             Services {
> > >                                     Method = Forced,
> > >                                     Reason = 905
> > >                             }
> > >                     }
> > >             }
> > >             Context = * {
> > >                     W-ServiceChange = DS1/3/1/* {
> > >                             Services {
> > >                                     Method = Forced,
> > >                                     Reason = 905
> > >                             }
> > >                     }
> > >             }
> > >     }
> > >
> > > My question is, what should I expect the transaction reply to look like?
>
> > I
> > > would prefer to receive something like the following:
> > >
> > >     MEGACO/2 <xanadu>:2944
> > >     Reply = 6 {
> > >             Context = - {
> > >                     ServiceChange = DS1/3/1/*
> > >           },
> > >             Context = * {
> > >                     ServiceChange = DS1/3/1/*
> > >           }
> > >     }
> > >
> > > However, the ABNF does not appear to provide a way to ask for a
>wildcarded
> > > action reply (e.g. by sending "W-Context = *"), so I think I am more
> > likely
> > > to get something like:
> > >
> > >     MEGACO/2 <mgc.acc.com>:2944
> > >     Reply = 6 {
> > >             Context = - {
> > >                     ServiceChange = DS1/3/1/*
> > >           },
> > >             Context = 2 {
> > >                     ServiceChange = DS1/3/1/3
> > >           },
> > >             Context = 5 {
> > >                     ServiceChange = DS1/3/1/11
> > >           },
> > >             Context = 6 {
> > >                     ServiceChange = DS1/3/1/13
> > >           },
> > >             Context = 9 {
> > >                     ServiceChange = DS1/3/1/14
> > >           }
> > >     }
> > >
> > > assuming the MG has 4 active terminations on the interface.
> > >
> > > Is there any way to request a wildcarded reply?
> > >
> > > Ron Stoughton
> > > [email-masked]
> > >
> > > _______________________________________________
> > > 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: Wed, 10 Jul 2002 15:51:13 +1000

G'Dy,

Whilst having this type of functionality in a package is an interesting exercise
I'm a little concerned about the precedent that it is setting in that by setting
a new event you modify the behaviour of the core protocol. ie. the MG rather
than sending replies in a single Transaction Reply must wait for additional
requests and responses. If multiple requests are responses are needed in both
cases then the current mechanism of asking for a limited number of
context/terminations should be fine also. 

I agree that segmentation is an issue that needs to be looked at. My initial
thoughts would be that we have a layer under H.248/Megaco that could be a
general mechanism to achieve segementation where needed. ie. if you have SCTP
you probably don't need it. It would be applicable to all versions of H.248.
Something like sect 7 of I.366.1 could be used for this purpose.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2002 09:39:41 +0300

Hi,

I once gave some thoughts to an idea similar to Kevin's, where a big reply is
"split" into multiple Pending Reply messages. However, as Kevin mentioned (I hope I
understood it correctly :) it would require new protocol functionality, to be to
acknowledge every Pending Reply message (why do I think about PRACK in SIP? :).

Later, I came up with a similar idea, but which would require less changes to the
existing protocol. It goes like this:

1. The MGC sends a wildcarded Audit Request

2. The MG detects that the Reply will be huge, so it will have to be segmented

3. The MG sends a Response (NOTE: NOT Pending!) with PART of all the wildcard
matches

4. The MG also indicates that there are more matches for the wildcard, and provides
some identifier

5. The MGC sends the SAME (different TransactionId, of course) wildcarded Audit
Request again, including the identifier.

6. The MG now sees, because of the identifier, that this Request is related to the
previous, so in the Reply it includes the wildcard matches that didn't "fit" in the
previous Reply.

7. If the MG still isn't able to fit all wildcard matches in the second Reply, it
will again include an identifier, so that the MGC knows there are more information
to get (it will then, again, send a new Request, with the new identifier).

I am NOT saying that this is the ultimate solution, or that it is better/worse than
any other proposal, but I think it should be part of the input to the segmentation
discussion :)

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2002 09:39:41 +0300

Hi,

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Wed, 10 Jul 2002 15:51:13 +1000

G'Dy,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 10:59:51 -0400

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.

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

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.

I know this already was stated before, sorry for repeating this, but to 
further
advocate package approach: it does solve this problem for all versions for
protocol, thus does address your concern of applicability to all versions of
the protocol.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 10:59:51 -0400

Hi Christian,

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 11:24:15 -0400

Hi Christer,

         A quick comment :). The are couple of potential issues here:
1. Make it somehow work for all versions of protocols, as it might require 
some
changes in ABNF/ASN.1 for the "identifier".
2. How MG let MGC know of the end of the sequence?

         It seem that so far we have had protocol solutions that are all 
quite similar.
Can other folks provide some input on any aspects of this problem we did 
not catch
so far and any solutions you can see to fit here?

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 11:24:15 -0400

Hi Christer,

Thanks
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Jul 2002 16:34:26 +1000

G'Day Aleks,

Please see my replies below.

Regards, Christian

> 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. I don't see that the proposed addition
"clarifies", it adds new functionality.

> when to return and that is a primary functionality of MGC, after all it is

[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.

> the protocol, not outside of it, as not to have intentional "holes" in the
[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.

..snip..

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Jul 2002 16:34:26 +1000

G'Day Aleks,

Regards, Christian

..snip..

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2002 09:44:54 +0300

Hi,

> some changes in ABNF/ASN.1 for the "identifier".

It doesn't have to work with all versions of the protocols. There have for example
been lots of discussions about Profiles, and what they really speficy, and this is
one feature which a Profile could specify.

Or, the identifier could be defined as an event without a package. That, of course,
would require that we allow detected events in reply messages, which may not be a
very smart thing to do...

> 2. How MG let MGC know of the end of the sequence?

There could be a specific identifier value indicating that.

...OR, the identifier could be removed if there are no more matches. This would
maybe create less backward compability issues.

I think it's more important to come up with a high-level solution before we start
looking into the details :)

Regards,

Christer Holmberg
Ericsson Finland

> not catch so far and any solutions you can see to fit here?
>
> Thanks
>          Aleks
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2002 09:44:54 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 11 Jul 2002 12:08:15 -0400

Hi Christian,
         Please see below inline [AR] .

At 02:34 AM 7/11/2002, Christian Groves wrote:
>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

[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.

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

>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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 11 Jul 2002 12:08:15 -0400

Hi Christian,

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 11 Jul 2002 12:25:39 -0400

Hi,

Limiting solution to a profile limits interoperability as profile is
not quite the same as just a simple package. I think that usage
of a profile to address this issue is overkill, package is much more
lighter and thus better suited for this case.

Also I'd say that solution that works for any version of a protocol
is much more desirable and that, I believe, should be one of the
key criteria when deciding on which solution to use.

I do agree that we have to come up with a high-level solution first.
That is why I asked for more input.
Folks, lets nail it down! :)

Cheers.
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 11 Jul 2002 12:25:39 -0400

Hi,

Cheers.
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Jul 2002 13:14:24 +1000

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Jul 2002 13:14:24 +1000

G'Day Aleks,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 12 Jul 2002 11:11:28 -0400

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:
> > used it here" :) but as an example in 
> draft-manyfolks-megaco-caspackage-02.txt:
> >

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 12 Jul 2002 11:11:28 -0400

Hi Christian and folks,

Thanks
         Aleks

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jul 2002 01:30:36 +0300

Hi,

I don't think my solution would mean "modifying the protocol", IF the identifier is
defined within a package, within an existing descriptor. Adding a package is NOT
the same as modifying the protocol, it is an extension mechanism within the
protocol.

The package solution WOULD be backward compability, but nodes not supporting the
package would of course not be able to use the feature (the node creating the node
would simply create an error response if the reply is too big to send within one
message, and segmentation is not supported).

HOWEVER, as Christian said, since we DO have transport protocols (TCP and SCTP)
which can be used to solve this issue, I would like to know if anyone has a
scenario where using some of those transport protocols would not solve this issue.
I am not saying I would go as far as making one of those protocols MANDATORY for
AuditXxx commands, but I think it could at least be a RECOMMENDATION... We should
remember that the protocol does not mandate one to use the same transport protocols
for all messages (even if I assume that is what people most often would do...)

Also, no matter what method we will use, I also agree with Christian and Kevin on
the fact that we shall first come up with specific requirements, what exactly we
want to functionality to provide us.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jul 2002 01:30:36 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jul 2002 17:15:54 +1000

G'Day Aleks,

I'll agree with 6 and 7 but 8 is leading to a protocol solution. Once we
evaluate requirements 1 to 7 it should be clear whether transport or application
based is the mechanism we are going for. I don't see that any proposals 1-4 were
drafted with the requirements in mind.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jul 2002 17:15:54 +1000

G'Day Aleks,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jul 2002 17:20:49 +0300

Hi,

I don't really see why we can't go for a transport based mechanism, no matter if we
ALSO will look into a application based mechanism.

After all, a transport based mechanism doesn't require any new stuff to the protocol,
since the protocol already does allow one to use different transport protocols. If
one uses UDP, and the reply will be too long, an error code is sent back. So, unless
the sender wants to "split" the AuditXxx wildcard into smaller pieces, it has to use
another transport protocol (the best thing is of course if the sender realises from
the beginning that the reply will be too big to fit into UDP). Pure and simple. And,
the only thing this would require is perhaps a few lines of
clarification/recommendation/warning/whatever-you-want-to-call-it - but NO core
protocol change.

So, again, I am not against looking into an application based mechansim, but I don't
see why we should have two "choose" between that and a mechanism which already is in
the protocol...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jul 2002 17:20:49 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 15 Jul 2002 12:26:33 -0400

Hi,

         I'd like to note that segmentation apply not only to AuditXxx replies,
but generally speaking to any wildcard contained command reply.

Also proposal to use one transport protocol for non-wildcarded commands
and another transport protocol for wildcard contained commands would not
be in line with req 4 (that is "Minimize dependencies (maximize transparency)
to the Megaco state machine") at least from MGC point of view.

On the other hand using combined solution will always work. That is MGC
usage of transport protocol solution while using application based solution,
since if transport protocol allows to send large messages such that a message
does not have to be segmented then application based solution will not
take place (MG will not be needing to utilize it). If transport protocol does
not provide support for large messages (e.g. segmentation/reassambling) then
application based solution will automatically take place (MG will utilize it).

Thanks
         Aleks.

At 10:20 AM 7/15/2002, Christer Holmberg wrote:

> > > >solved "outside" the core protocol. ie. SCTP. We already have a 
> mechanism
> > > >(error
> > > > > > > To address your concern regarding "a new event you modify the 
> behaviour
> > > > > > of the
> > > > > >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
> > > > > Inclusion of a timestamp in the ObservedEvents descriptor is 
> mandatory
> > > > for the
> > > > > 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
> > > > > > > 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
> > > > > > > the protocol, not outside of it, as not to have intentional 
> "holes"
> > > > in the
> > > > > > > protocol.
> > > > > > >
> > > > > it is not that easy to "fix" a core protocol limitation, by 
> seeking to
> > > > patch it
> > > > > protocol all together :-) You would not just take off and go to 
> Alaska
> > > > because

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 15 Jul 2002 12:26:33 -0400

Hi,

Thanks
         Aleks.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Jul 2002 06:03:41 +0300

Hi,

> but generally speaking to any wildcard contained command reply.

[CHH] True.

> to the Megaco state machine") at least from MGC point of view.

[CHH] Well, you could use the transport protocol you use for the wildcard contained
commands also for
other commands... I am not saying that we have to specify how, what, and when a
specific transport protocol shall be used -
only that the use of specific transport protocols is a way to solve the
segmentation issue on a transport level.

> application based solution will automatically take place (MG will utilize it).

[CHH] Yes (assuming the MGC also supports the application based mechanism).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Jul 2002 06:03:41 +0300

Hi,

[CHH] True.

Regards,

Christer Holmberg
Ericsson Finland