Subject: [Sigtran] M2PA Send ACK Timer

From: "Hecht Martin" <[email-masked]>
Date: Tue, 7 Oct 2008 10:53:29 -0400

I implemented M2PA about four years ago and at that time I used a timer
for ack'ing a received user data message when no user data messages
where pending transmission.  I used a 200ms timer and sent the empty
user data message when the timer expired.

I am now updating the M2PA to the RFC level and would like to know if
this timer is no longer used.

Thanks,
Martin

Martin Hecht
Engineering
Signaling Core Group
Comverse
Office: +856 608-2712
[email-masked]
www.comverse.com <http://www.comverse.com/> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Oct 2008 10:25:54 -0600

Hecht,

No, I don't believe that a timer is necessary.  What I do is
when there is a received MSU to acknowledge, I check if there
are MSUs queued for transmission in the TB and the L2 state
machine is sending MSUs, and the RTB is not full, in which case
I defer sending a separate ack to piggyback on the outgoing MSU.

There was even some discussion a while ago that indicated that
delaying acks harmfully interacts with the T7 timer and the L2
state machine.  This was captured in the RFC in section 4.2.1:

   When there is a message to acknowledge, M2PA MUST acknowledge the
   message with the next User Data message sent.  If there is no User
   Data message available to be sent when there is a message to
   acknowledge, M2PA SHOULD generate and send a User Data message with
   no data payload, without delay.  ...

--brian

Hecht Martin wrote:                           (Tue, 07 Oct 2008 10:53:29)
> 
>    I implemented M2PA about four years ago and at that time I used a
>    timer for ack'ing a received user data message when no user data
>    messages where pending transmission.  I used a 200ms timer and sent
>    the empty user data message when the timer expired.
> 
>    [1][email-masked]
>    [2]www.comverse.com
> 
> References
> 
>    1. mailto:[email-masked]
>    2. http://www.comverse.com/

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