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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Mar 2001 09:25:45 -0500

I think the error code would be a good idea.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Saturday, March 24, 2001 2:26 PM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: Re: How does the MGC rebuild a long transaction in ALF/UDP
> 
> 
> 
> Hi,
> 
> >I agree that the use of TCP for audits is the sensible solution, but
> >it does mean that the MG has to support TCP and also that if UDP is
> >subsequently desired a new association has to be set up.  Since the
> >transport is controlled by the MG rather than the MGC this may be a
> >bit difficult to achieve.
> > 
> >The only practical solution according to the present standard is for
> >the MGC to restrict the number of terminations covered by any one
> >audit query.
> 
> What about having an error code indicating that the wildcard can't be
> used, since the reply would be too big? The MGC can then 
> choose to split
> up the Audit in multiple requests.
> 
> And, if the MG is really smart, it could perhaps also tell 
> the MGC what
> kind of wildcard value would be suitable for the requested information
> for this specific Audit. This feature should be optional, however, I
> think.
> 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> > 
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:[email-masked]]
> > > Sent: Friday, March 23, 2001 1:32 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: How does the MGC rebuild a long transaction 
> in ALF/UDP
> > >
> > >
> > >
> > > Hi,
> > >
> > > >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.
> > >
> > > I was talking about the REPLY :) Maybe I used the word "response"
> > > sometime, but I meant the same...
> > >
> > > >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.
> > >
> > > 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.
> > >
> > > >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
> > > >       {  ... }
> > > >    }
> > > >
> > >
> > > 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
> > >
> > > >
> > > > Regards,
> > > >
> > > > Susumu
> > > >
> > > > ---
> > > > >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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >"P.S.K. Chakravarthi" wrote:
> > > > > >
> > > > > > 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.********
> > > > > >
> > > > > > On Thu, 22 Mar 2001, Rosen, Brian wrote:
> > > > > >
> > > > > > > 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
> > > > > > > >
> > > > > > >
> > > >
> > > > -*-*-*
> > > > SUSUMU YAMAMOTO
> > > > NTT Network Service Systems Laboratories
> > > > mailto: [email-masked]
> > > > TEL:+81 422 59 2744  ISDN-FAX:+81 422 37 7467
> > >
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 27 Mar 2001 15:59:52 +1000

G'Day Tom, all,

A suggestion - do we agree to add the following to the H.248 Annex L -
Error Code and Service Change Reasons:

2.58 Error Code # : 534 Name: Message exceeds maximum transport PDU size
Definition: The MG or MGC is unable to assemble a message due to that
the number of bytes for the message exceeds the underlying transport's
maximum protocol data unit size. The actions included in the transaction
request are not carried out. If the request contained wildcarded a
transaction ID the MGC or MG should resend the request with a smaller
subset of termination Ids.
Package: -
Reference: No
Error Text in the error Descriptor: NA
Comment: -

Cheers, Christian

Tom-PT Taylor wrote:
> > > > From: Christer Holmberg
> [mailto:[email-masked]]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Mar 2001 10:12:51 +0300

Hi,

I think the text is ok. One issue, though.

Assume that the transaction contains two (or more) actions. The first
command may, for example, be an ADD for a single termination, so no
problem there. The following command is then an Audit with a huge
wildcard value, which will generate the 534 error code. So, isn't it
wrong to say that the actions included are not carried out? Isn't it
only the Audit that is NOT carried out, but the ADD still is? This is
the general way H.248 works, so...

Regards,

Christer Holmberg
Ericsson Finland