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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Mar 2001 09:05:18 -0500

First comment: I think this error should only affect responses -- can't see
an entity reporting an error because it couldn't formulate a request.

Second comment: the idea that the transaction is rolled back bothers me.
This is easy enough for audits, not so easy for anything else.  I'd suggest
our usual approach: the command which caused the PDU overflow is rolled
back, but any commands which preceded it remain in place.  Remember that
wildcarding creates a long series of individual commands.

As a result, I'd suggest the following wording:

2.58 Error Code # : 534 Name: Response exceeds maximum transport PDU size

Definition: The MG or MGC is unable to assemble a complete transaction
response because the number of bytes for the message would exceed the
maximum protocol data unit size of the underlying transport.  The command
instance the response to which would have caused the overflow is treated as
if it were in error, and the remainder of the transaction is not executed.
Note that this situation will typically arise in conjunction with the use of
wildcarding, which causes the original command to be expanded into a series
of similar command instances.

Implementer's note: detection of PDU overflow must occur at a point where
there is still room in the PDU for the error descriptor.

Package: -
Reference: No
Error Text in the error Descriptor: NA

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2001 1:00 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Christer Holmberg'; [email-masked]; 
> [email-masked];
> Alf Heidermark
> Subject: Re: How does the MGC rebuild a long transaction in ALF/UDP
> 
> 
> 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:
> > 
> > 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: Chuong Nguyen <[email-masked]>
Date: Tue, 27 Mar 2001 09:46:41 -0600

Tom

For the wildcarded command case, said if the wildcarded command expands
into
100 command replies.  There is even room for 50 of the commands.
Should 50 command replies be returned and for the 51st command an error
returned
or the wildcarded command should result in an error?

Thanks
Chuong

Tom-PT Taylor wrote:

>
>
> First comment: I think this error should only affect responses --
> can't see an entity reporting an error because it couldn't formulate a
> request.
>
> Second comment: the idea that the transaction is rolled back bothers
> me.  This is easy enough for audits, not so easy for anything else.
> I'd suggest our usual approach: the command which caused the PDU
> overflow is rolled back, but any commands which preceded it remain in
> place.  Remember that wildcarding creates a long series of individual
> commands.
>
> maximum protocol data unit size of the underlying transport.  The
> command instance the response to which would have caused the overflow
> is treated as if it were in error, and the remainder of the
> transaction is not executed.  Note that this situation will typically
> arise in conjunction with the use of wildcarding, which causes the
> original command to be expanded into a series of similar command
> instances.
>
> Implementer's note: detection of PDU overflow must occur at a point
> where there is still room in the PDU for the error descriptor.
>
> Package: -
> Reference: No

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Richard Chen <[email-masked]>
Date: Tue, 27 Mar 2001 11:42:00 -0500 (EST)

unsubscribe

---

From: "Leo" <[email-masked]>
Date: Wed, 28 Mar 2001 00:38:00 +0800

unsubscribe

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Tue, 27 Mar 2001 11:42:31 -0500

RE: How does the MGC rebuild a long transaction in ALF/UDPHi Tom,
Are there any packages proposed, for invoking scripts at MG from MGC? Do we
have a way to support the IN Capabilities.

best regards
Madhubabu

---

From: Lucy Yang <[email-masked]>
Date: Tue, 27 Mar 2001 09:18:52 -0800 (PST)

unsubscribe  Lucy Yang ([email-masked])

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text