Subject: RE: [Sigtran] M2PA busy/lpo questions

From: "Davidson, Mark" <[email-masked]>
Date: Wed, 2 Nov 2005 12:41:45 -0600

Brian,

>Q1) I think it is clear that LSPO does not clear LSB, only LSBE does.

It is clear how a busy clear condition is signaled, but not when it
ends.
There is a difference. 

>   Under M2PA both PO and Busy conditions can exist at the same time.

Works for me, but where does it say that?

>Q2) I think buffered messages are buffered messages, regardless of
>   what condition prevailed when they were buffered.  When M2PA exits
v   PO state and Busy still prevails, I think the text is clear with
>   regard to how data messages are treated before LSBE is sent or
>   received, in the passages you quoted.

The text I quoted says NOTHING about buffering received msgs, so I 
don't see how it can be clear on the subject.

Anyway, I think this is your interpretation:

During local busy OR LPO (or both) buffer and do not acknowledge
received MSUs.

When BOTH conditions are cleared, process and acknowledged buffered
messages.  This is handled explicitly by PO procedures, for local busy 
an ack must be sent if there was at least one data message buffered 
(per other text requiring immediate ack).

Local busy can continue during LPO and still be in effect after LPO
ends.

-Mark

>
>--brian
>
>Davidson, Mark wrote:                         (Wed, 02 Nov 2005
08:21:20)
>> 
>>    Flow control RFC text included at bottom for convenience...
>> 
>> 
>> 
>>    Trying to sort out Busy/Busy End and LPO/ LPO End interactions.
>> 
>> 
>> 
>>    The Level 2 flow control text doesn't say anything about buffering
>> 
>>    during local busy (just says don't ack), but I'm assuming that's
>> 
>>    the intent, i.e. to avoid retransmissions since M2PA doesn't
>> 
>>    retransmit. (I'm a little confused as to why LPOR needs those
>> 
>>    LSRs afterwards but LSBE doesn't, but that's not my real
question.)
>> 
>> 
>> 
>>    Anyway, it gets really interesting when you have a (local)
>> 
>>    busy condition, then LPO condition.  MTP2 spec is clear - Stop
>> 
>>    T5, move to PO state. When PO ends, MSUs may again trigger
>> 
>>    Busy condition, but if there's no traffic, then no Busy condition.
>> 
>> 
>> 
>>    The reverse, LPO followed by Busy does not occur in MTP2 because
>> 
>>    MSUs are discarded in LPO, so busy is not triggered.
>> 
>> 
>> 
>>    Question 1. In M2PA , should an LSBE be expected in the case where
>> 
>>    there is a local busy followed by LPO? It seems unnecessary to
>> 
>>    me - the LSPO message should imply an end to the Busy condition.
>> 
>>    Buffered Busy messages can become buffered LPO messages that are
>> 
>>    acked during LPO recovery.
>> 
>> 
>> 
>>    Question 2. Assuming traffic is buffered in M2PA during local
busy,
>> 
>>    it is possible that the busy condition may not subside during a
>> 
>>    transient LPO condition.  I.e. LPO ends but queues are still
backed
>> 
>>    up.  Should the Busy resume? What should be acked? Should we wait
>> 
>>    for the LSRs to be exchanged before sending LSB?
>> 
>> 
>> 
>>    -Mark Davidson
>> 
>> 
>> 
>    From the RFC:
> 
> 
> 
>    4.1.5.  Level 2 Flow Control
> 
> 
> 
>       The Link Status Busy message replaces the SIB message of MTP2.
The
>       message SHOULD NOT be transmitted continuously.  M2PA SHALL send
a
>       Link Status Busy message to its peer at the beginning of a
receive
>       congestion condition where MTP2 would send SIB.  M2PA MAY send
>       additional Link Status Busy messages as long as that condition
>       persists.  When the condition ends, M2PA SHALL send a Link
Status
>       Busy Ended message to its peer.
> 
> 
> 
>       M2PA SHALL continue transmitting messages while it is in receive
>       congestion, but MUST NOT acknowledge the message that triggered
the
>       sending of the Link Status Busy message, nor any messages
received
>       before the sending of Link Status Busy Ended.
> 
> 
> 
>       When the peer M2PA receives the first Link Status Busy message,
it
>       SHALL start the Remote Congestion timer T6 if there are messages
in
>       the retransmission buffer awaiting acknowledgement (i.e., T7 is
>        running).   M2PA  SHALL  stop  the  T7  timer  if  it  is
running.
>    Additional
>       Link Status Busy messages received while T6 is running do not
cause
>       T6 to be reset and do not cause T7 to be started.  While T6 is
>       running, T7 SHALL NOT be started.
> 
> 
> 
>        When the peer M2PA receives the Link Status Busy Ended message
and
>    T6
>        has  not expired, it SHALL stop T6 (if T6 is running) and start
T7
>    (if
>       there are messages awaiting acknowledgement in the
retransmission
>       buffer).
> 
> 
> 
>       The peer M2PA SHOULD continue receiving and acknowledging
messages
>       while the other end is busy, but MUST NOT send User Data
messages
>       after receiving Link Status Busy and before receiving Link
Status
>       Busy Ended.

> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran