Re: TPA and ebXML Header question

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Shimamura-san,

Thank you for clarifying the example.  I now understand that in general,
deadlock will not happen.

I have one more question.  You said:

   Here is condition which causes retry sequence in the Sender:

     - First message in the window:
         - detection of timeout
         - window is full


Is the above condition an OR condition or an AND condition?  If the
condition is "detection of timeout OR window is full", there should not be
a deadlock.  If it is "detection of timeout AND window is full", deadlock
is possible if there are not enough outgoing messages to fill the window.

Regards,
Martin Sachs
*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



SHIMAMURA Masayoshi <shima@rp.open.cs.fujitsu.co.jp> on 10/27/2000 07:27:35
AM

To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-transport@lists.ebxml.org
cc:   ebxml-tp@lists.ebxml.org
Subject:  Re: TPA and ebXML Header question



Mr. Martin W Sachs,

On Thu, 26 Oct 2000 09:23:47 -0400
"Martin W Sachs/Watson/IBM" <mwsachs@us.ibm.com> wrote:
>
> Regarding deadlocks, I have some questions and comments.
>
> The example shows a fixed window size of 4.  Who or what determines the
> window size?
>

One possible idea is that the window size is determined by system
administrator and then it is specified in TPA.

One of most important factor to determine the window size is
communication performance between the Sender and the Receiver. Following
simple model and formula can be used as a sample to determine the window
size.

+--------+                      +--------+
| Sender +--------Message------>|Receiver|
|        | A                    |        |
|        | |                    |        |
|        | |T[s]                |        |
|        | |                    |        |
|        | V                    |        |
|        |<-------Message(Ack)--+        |
+--------+                      +--------+

- Turn around time:  T [s]
- Data rate:  S [bit/s]
- Length of the Message:  M [bit]
- Window Size:  W = (T * S) / M

> What is in a single window?
>      Only messages for one conversation?
>      Only messages for one pair of application instances?

The window has not any relationship with application level semantics.

>      All messages going on the same outbound link?
>

Yes.

> What happens if application-level responses are owed to all sent messages
> but there aren't enough sent messages to fill the window?
> I believe the answer is: deadlock, but I may not have understood
something
> in this proposal.
>

Here is condition which causes retry sequence in the Sender:

  - First message in the window:
      - detection of timeout
      - window is full

  - Other messages except the first message in the window:
      - detection of timeout

Thus even if there are not enough sent messages to fill the window, the
Sender initiates retry sequence when the Sender detects timeout.

> Example 1 shows that the sending message service waits until the window
is
> filled before attempting to retry message 3.  If that is correct, then it
> will deadlock if there aren't enough outgoing messages to fill the
window.

In the example, if the window does not become full, the Sender will
detect timeout of Ack of message 3. Here is modification of the
example:

   ------------------------------------------------
    Ex. 3 (modification of Ex.1) [Window Size = 4]
   ------------------------------------------------
    [Sender]                  [Receiver]
    Seq No.1      ----------> Passed to App
    Ack for No.1 <----------

    Seq No.2      ----------> Passed to App
    Ack for No.2 <----------

    Seq No.3     ---> LOST                     A
                                               |
    [the Sender detects timeout                |
     of ack of sent message No.3               | Window (size = 4)
     and initiates retry]                      |
                                               |
    Seq No.3 (retry) -------> Passed to App    |
    Ack for No.3 <----------                   |
                                               |
    [no next message]           [the window does not become full
                                 but all the messages reach the Receiver]


Regards,

--
SHIMAMURA Masayoshi
E-mail: shima@rp.open.cs.fujitsu.co.jp
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED