Subject: [Sigtran] SIGTRAN Interop M2PA Issues, Day 3

From: Marc Beauchesne <[email-masked]>
Date: Thu, 15 Sep 2005 06:55:26 -0400 (EDT)

Issue:

draft m2pa-13 section 4.1.5 Level 2 Flow Control says:

	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.

It is unclear if T7 should be restarted with the whole value, or simply
continued with it's remaining value prior to starting T6.

It seems like continuing T7 rather than restarting would be in keeping
with having a constant lifetime for messages awaiting acks.

Marc Beauchesne

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Sep 2005 06:31:30 -0600

Marc,

It doesn't really matter.  No implementation should be sending Link
Status Busy in the wild anyway.

That said, T6 is greater than T7, so the "remaining" life-time could
be negative.  It is fine to just start it over again.  This is what
SS7 does anyway.

Busy is an intentional posponement of T7.  The lifetime concept was
to handle unintentional posponement of T7 caused by dribbling acks.

--brian

Marc Beauchesne wrote:                                                                (Thu, 15 Sep 2005 06:55:26)

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

---

From: Marc Beauchesne <[email-masked]>
Date: Thu, 15 Sep 2005 08:34:49 -0400 (EDT)

Brian,

What I suggested as a continuation, is based on the remaining value of T7
before T6 was started. In effect "pausing" T7 while T6 is running, and
then resuming T7 at the end of T6. There would never be a negative value.
Thereby  implementing a postponement of T7.

Marc Beauchesne

> That said, T6 is greater than T7, so the "remaining" life-time could be
> negative.  It is fine to just start it over again.  This is what SS7
> does anyway.
>
> Busy is an intentional posponement of T7.  The lifetime concept was to
> handle unintentional posponement of T7 caused by dribbling acks.
>
> --brian
>
>
> Marc Beauchesne wrote:
>> It is unclear if T7 should be restarted with the whole value, or
>> simply continued with it's remaining value prior to starting T6.
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Sep 2005 06:45:23 -0600

Marc,

But the transmitting MTP2 state machines expect a full T7 to be available
after busy ends.

Although receive congestion is implementation specific in SS7, it is
most often implemented by receive buffer occupancy.  When receive buffer
occupancy exceeds a threshhold, the implementation cannot be sure that
it will meet its deadlines for acknowledgement and it starts busy state.
Once RB occupancy falls below the (possibly another, possibly the same)
threshold, the receive is confident that it can meet its deadlines and
busy ends.  However, it is confident that it can meet the full T7
deadline (as per SS7) and not a reduced T7 deadline.  Changing to
remaining time could cause links to fail immediately after leaving the
busy state.  Which would be strange and difficult to diagnose in the
field.  Best to leave it at the entire T7.

--brian

Marc Beauchesne wrote:                                                                (Thu, 15 Sep 2005 08:34:49)

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