Subject: M2PAv03 status BUSY

From: Vladi Arbetov <[email-masked]>
Date: Wed, 24 Oct 2001 17:48:39 +0200

In MTP2 - RX congestion, indicated to the peer by BUSY status, should
cause the peer MTP2 to stop message transmission. It continues to
receive messages from upper layer and saves them into it's TX buffer. 
During the pause - the RX buffer of the congested side will get free and
BUSY status will be ceased. Then peer get indication BUSY end - it
continue to transmit the messages from the buffer. Timer T6 should
prevent the TX buffer overload - link should be stopped after T6
timeout.

In M2PA  - receive congestion is detected by SCTP and cause to BUSY
status  sending to the peer. But - "The peer M2PA shall continue
transmitting messages to SCTP while its T6 timer is running, i.e., while
the other end is Busy".(m2pa-03-draft 4.1.5)
SCTP layer at the other end of the link don't treat the M2PA BUSY too
and continues transmitting messages.

So BUSY status doesn't cause any action at both sides of the link and
seems to me as senseless in M2PA. 

Correct me if I'm wrong.

Thanks a lot in advance,

Vladimir Arbetov
Airslide Systems Ltd.

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Al Varney <[email-masked]>
Date: Wed, 24 Oct 2001 14:49:44 -0500

>receive messages from upper layer and saves them into it's TX buffer.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>transmitting messages to SCTP while its T6 timer is running, i.e., while
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    In M2PA, SCTP is taking the place of MTP2.  So "receive messages from 
the upper layer" and "M2PA ...continue transmitting messages to SCTP" are 
equivalent.

    Another way of looking at this is, for both MTP and M2PA, a peer BUSY 
indication results in the stopping of TRANSMISSION, but messages continue 
to be placed in the TRANSMIT BUFFER.

>SCTP layer at the other end of the link don't treat the M2PA BUSY too
                                           ^^^^^^^^^^^^^^^^^^^^ (true)
>and continues transmitting messages.
        ^^^^^^^^^^^^^^^^^^^^ (not true)

    The M2PA should not send BUSY if it's SCTP is accepting messages.  It 
SCTP isn't accepting messages, the peer SCTP should not be transmitting 
(other than probes).  It's true the peer SCTP doesn't know anything about 
M2PA BUSY, but it knows about "rwnd" of the local SCTP.

>seems to me as senseless in M2PA.

    Well, it manages a timer (T6) that will take action if SCTP can't clear 
congestion in that time.  This is probably the easiest way to map MTP 
congestion indications onto SCTP (rather than trying to use the data 
lifetime option).  Without this option, you could have an M2PA sitting with 
a transmit buffer full of data, and no trigger to cause it to try another 
(working) M2PA association.

At least that's the way it seems to me --
Al Varney

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Oct 2001 15:40:55 -0500

Al,

Al Varney wrote:                                               (Wed, 24 Oct 2001 14:49:44)
> >receive messages from upper layer and saves them into it's TX buffer.

But Al, SCTP does not stop TRANSMISSION when it becomes congested:
it only stops TRANSMISSION when the peer's receive buffer is full.

>     The M2PA should not send BUSY if it's SCTP is accepting messages.

SCTP accepts messages until if fails or its TX buffer gets full.  So,
are you saying that M2PA should never send BUSY?

> It SCTP isn't accepting messages, the peer SCTP should not be transmitting 
> (other than probes).

The only way that an SCTP can stop accepting messages is by setting arwnd
to 0, placing it in a SACK and waiting for the other end to get the SACK.
Normally, an ULP has no control over this other than to set the receive
buffer size.  Effectively SCTP always accepts messages until it encounters
congestion and then the other side finds out about it some time later.
Messages are always acked when received by SCTP (they are not sent to the
ULP before they are acked) and may even be acked before placing them in
the receive buffer.  SCTP will only stop acking received messages when the
receive buffer is full (i.e., arwnd = 0).

Besides rwnd is used for flow control not congestion.

> It's true the peer SCTP doesn't know anything about 

Yes, but there is a problem here too.  The arwnd is SCTP's receive buffer,
not the ULPs receive buffer.  That is, this occurs only when SCTP is in
receive congestion (probably never) not when MTP Level 3 is in receive
congestion.  This is just another extension of the problem that messages
at MTP Level 2 are acked after queueing them to Level 3.  SCTP acks them
before (and sometimes long before) they are queued to Level 3.

> (working) M2PA association.

Placing an M2PA level (vs. and SCTP level) ack in M2PA would allow
M2PA to exhibit SS7 Level 2 behavior in a far cleaner way.

> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 25 Oct 2001 09:52:13 +0100

Brian,

>receive buffer is full (i.e., arwnd = 0).

In Section 4.1.5 M2PA is expected to detect receive congestion of its local 
SCTP and send a Busy message to its peer. Would it not be appropriate to 
change this so that SCTP reports a arwnd of zero from the peer to its local 
M2PA which then responds by starting T6? In this scenario a Busy message is 
not used.

>before (and sometimes long before) they are queued to Level 3.

Instead, M2PA trying to detect if its SCTP is in receive congestion it 
should send a Busy to its peer if its MTP3 is busy or in overload (which is 
determined via some implementation dependent method).

Amish

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Oct 2001 04:19:12 -0500

Amish,

Amish Chana wrote:                                          (Thu, 25 Oct 2001 09:52:13)
> M2PA which then responds by starting T6? In this scenario a Busy message is 

Actually, I was to quick with my statement... :\  RFC 2960 does not
require that a receiver stop acking received messages when it has
advertized a_rwnd = 0.  In fact, some implementations continue to ack
and "slop" over the receive buffer even for TCP.  The RFC recommends
that the sender stop transmitting once it receives a_rwnd = 0,
but it is allowed to keep one MTU of data in flight even when rwnd is
zero.  If an MTU is fairly large, that means that the SCTP transmitter
could send a large number of MSUs even after rwnd = 0.

So, advertizing a_rwnd = 0 is neither an effective way to stop acking
received data, nor an effective way to stop the sender from transmitting.

> determined via some implementation dependent method).

Yes, I agree.  However, sending BUSY whilst SCTP underneath is merrily
acking frames and cutting them from the sender's retransmit buffer will
not do.  A separate M2PA-level ack is necessary.  This has been brought
up on the list several times.  A sequencce number for the purposes of
acking in M2PA would permit equivalent behavior to that of SS7 regardless
of SCTP's antics with rwnd and congestion and such.  Then when M2PA
sends BUSY, it also stops acking data at the M2PA level and the peer
M2PA holds this data available for retransmission on an alternate link.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---