Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 22 Mar 2001 11:27:39 -0500

Section 9.1 details how you enforce ordering of commands across 
transactions.

Each transaction MUST be different (unique) TransactionId.
Therefore, if you break up a transaction into multiple smaller
transactions, each smaller part will have a different transactionId.
The reciever doesn't need to know that the transactions are related.
The sender can track this with internal state if it needs to.

Brian

> -----Original Message-----
> From: Susumu YAMAMOTO [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 2:59 AM
> To: [email-masked]
> Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP
> 
> 
> Dear Brian,
> 
> Thank you for your suggestion.
> 
> What is the identified mechanisms you mentioned below?
> Please tell me where it is described in H.248/MEGACO.
> 
> When one transaction would be broken into multiple small transactions,
> what is the transaction ID of each transactions?
> I think that all small transactions should have the same 
> transaction ID
> and an MG must show an MGC that multiple transactions must be rebuilt
> to one transaction.
> I do not understand the way to relate transactions.
> 
> Is my idea wrong?
> 
> Regards,
> 
> Susumu
> 
> ---
> >Probably, you would be advised to break the transaction into
> >multiple smaller transaction, and use the identified mechanisms
> >to enforce sequential execution of these smaller transactions.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Susumu YAMAMOTO [mailto:[email-masked]]
> > > Sent: Wednesday, March 21, 2001 3:25 AM
> > > To: [email-masked]
> > > Subject: How does the MGC rebuild a long transaction in ALF/UDP
> > >
> > >
> > > Hi all,
> > >
> > > I have a question about ALF/UDP in Annex D.1 of the H.248.
> > > (I think that ALF stands for Application Level Framing.)
> > >
> > > If an MG has a transaction which is longer than 64KB to send over
> > > UDP/IP, the MG must divide the transaction to some pieces each
> > > of which is shorter than 64KB and send them by other message each
> > > other.
> > >
> > > In this case, each message contains the transactions which is
> > > specified with the same transactionID but differs in contents.
> > >
> > > But we have no parameter to specify the total length of the
> > > transactions or the total length of the messages.
> > >
> > > How does the MGC rebuild the original transaction?
> > >
> > > I think an MG may have a longer transaction than 64KB  to 
> send as a
> > > transaction reply in the wildcard situation.
> > >
> > > Regards,
> > >
> > > Sususmu
> > >
> > > -*-*-*
> > > SUSUMU YAMAMOTO
> > > NTT Network Service Systems Laboratories
> > > mailto: [email-masked]
> > > TEL:+81 422 59 2744  ISDN-FAX:+81 422 37 7467
> > >
> 
> -*-*-*
> SUSUMU YAMAMOTO
> NTT Network Service Systems Laboratories
> mailto: [email-masked]
> TEL:+81 422 59 2744  ISDN-FAX:+81 422 37 7467
>

---

From: "P.S.K. Chakravarthi" <[email-masked]>
Date: Thu, 22 Mar 2001 13:29:34 -0600 (CST)

Brian,

In case of a transaction you are correct.  But how Reply can be split.  In
case of Audit, Audit reply may cross 64k.  This can not be sent using 2
transaction Ids, because MGC can not expect Reply in a un-known
transaction Id.

thanks
Chak

  ALCATEL, USA Inc.                      Email: [email-masked]
  1000 Coit Road Plano, Texas 75075
  ******** The opinions expressed are not those of Alcatel USA, Inc.********

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2001 23:30:29 +0200

Hi,

I will give a few comments on this, since a similar issue also exists
for SIP.

So, that fact is that UDP has some restrictions. Now, there are two
options:

1. You try solve this on the application level (in this case in the
H.248 protocol), for example by adding fragmentation headers, or maybe
by having some kind of "fragmentation package"... or something
similar...

2. You accept the limitations you have by using UDP as transport
protocol, and if you can't live with that you use TCP or SCTP (I guess
this is one of the few advantages of defining multiple transport
protocols for H.248 in the first place :)...

Maybe I'm wrong, but I don't see any solution for 1) in the core
protocol, so I guess you would have to define some kind of package - if
it would even work then.

...or, you use 2).

Also, you could maybe send multiple provisional reply messages, each
containing parts of the response, and the final reply message would then
indicate that the whole response has arrived. But, I don't know how well
that would work either, and/or if it also requires some extensions
(packages, etc.)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Susumu YAMAMOTO <[email-masked]>
Date: Fri, 23 Mar 2001 13:32:02 +0900

Hi all,

As Chakravarthi said, I meant the case that transaction REPLY
is longer than 64KB.

Transaction REPLY from MG may be longer than 64KB, if MGC
send the "Audit" transaction REQUEST which is specified with
wildcard "ALL".

In this case, transaction ID has defined with transaction REQUEST
in MGC and the related transaction REPLYs (if we must brake it
into some multiple transactions) from MG must use the same
transaction ID, I think.

Probably many implementations will adopt UDP as transport and
the number of terminations in MGs like trunking GWs apts to
increase recently.

If an MG has 2,000 (it may have a interface of STM-1) of physical
terminations, only 32B are allowed for one termination to restrict
the total size of transaction REPLY to less than 64KB.

We should not have such a restrictions in the case of UDP.

As Christer pointed out, we can solve this by adding two fragmentation
headers(*) with transaction REPLY as option in the case of UDP below.

   TransactionReply ::= SEQUENCE
   {
      transactionId
    *total number of the transactions with the same Id
    *sequence of the transaction with the same Id
      immAckRequired
      transactionResult
      {  ... }
   }

Any ideas  do you have?

Regards,

Susumu

---

-*-*-*
SUSUMU YAMAMOTO

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Mar 2001 08:31:48 +0200

Hi,

>into some multiple transactions) from MG must use the same

I was talking about the REPLY :) Maybe I used the word "response"
sometime, but I meant the same...
 
>the total size of transaction REPLY to less than 64KB.

I DO agree that it is a problem, but my mail was more about if we should
try to solve it on the application level, or simply use another
transport protocol.

>We should not have such a restrictions in the case of UDP.

One option could be to use TCP for Audits, while you still use UDP for
other commands. After all, you're not going to send that many Audits,
and probably not at the same time if you use wildcarding, so I don't
think that using TCP would be a problem from that point of view.
 
>     *sequence of the transaction with the same Id

The problem with this solution is that you have to know how many
fragments you will have before you can start sending the reply messages,
ie you must first collect the information from all your thousands of
terminations, then calculate how many messages are needed to send the
information, and then start to send the fragments.

In this case, I THINK using pending (provisional) response messages
would be better - and faster. You send the information as you get it,
and when you don't have anymore to send you send your final REPLY.

I know that none of the proposals above (except for the option to use
TCP for Audits only) are acording to the current standard. But, like I
said earlier, I think that application level fragmentation is not
supported by the current standard, so if we want to support this
something has to be done.
 
>Any ideas do you have?

I think that the easiest (maybe NOT the best) solution would be to use
TCP for Audits, because that would not affect the current standard.

Regards,

Christer Holmberg
Ericsson Finland