Subject: Re: [Sigtran] M2PA : FSN value in Zero Data Acks

From: Tom George <[email-masked]>
Date: Thu, 21 Nov 2002 14:40:43 -0600

I updated the paragraph in 4.2.1 and added a couple of new ones:

===============
If there is no other User Data message to be sent when there is a
message to acknowledge, M2PA may send a User Data message with no data
payload. The FSN for this empty User Data message is not
incremented. It must contain the same FSN as the most recently sent
User Data message containing Data. 

If M2PA receives an empty User Data message, it shall not send an
acknowledgement of that message. 

Note that there is no reason to place empty User Data messages in the
M2PA transmit buffer, since the empty messages are not retransmitted
and timer T7 (below) does not apply to them. 
===============

Is it necessary to draw a distinction between a "transmit buffer" and a
"transmitted buffer"? The idea I had was a buffer where messages
(transmitted and waiting-to-be-transmitted) stayed until they are
acknowledged. 

The paragraph in question does state that the message has been
transmitted:

===============
   (a) There is at least one message in the M2PA transmit buffer that
       has been sent.
===============

If there is something I am missing, please let me know. 

tomG.

[email-masked] wrote:
> 
> Jeff,
> 
> 1. I agree that "immediately" should be deleted. I was somehow trying to
> state that it must be acked before the peer's T7 timer expires. If the
> data throughput is high enough, there shouldn't be a problem.
> 
> 2. I also agree that no change is necessary to condition (a) of timer T7.
> I forgot that 0-byte messages wouldn't be placed in the transmited buffer
> anyway.
> 
> 3. I suggest, as you already noted, that we change "transmit buffer" to
> "transmitted buffer".
> 
> Barry Nagelberg
> 
> [email-masked]
> Sent by: [email-masked]
>  09/12/2002 09:59 AM
> 
> 
>         To:     [email-masked]
>         cc:     [email-masked]
>         Subject:        Re: [Sigtran] M2PA : FSN value in Zero Data Acks
> 
> Hello Barry,
> 
> I agree with everyone that 0-byte user data messages (ACKs) should not
> increment FSN.
> 
> >"If M2PA receives a User Data message with an FSN incremented by 1, it
> >MUST immediately respond with a User Data message. If M2PA receives
> >a User Data message with an FSN that has not been incremented, it MAY
> >respond with a User Data message."
> 
> I don't agree with "MUST immediately respond". This suggests that ACKs
> are generated out of the inbound thread of an implementation. This
> should not be a requirement. There needs to be an opportunity to ACK
> using the outbound traffic, if it has a high enough rate. This would
> minimize the need for 0-byte user data messages.
> 
> >Also, we must modify condition (a) of the Timer T7 paragraph:
> >"(a) There is at least one message with an incremented FSN in the M2PA
> >transmit buffer that has been sent."
> 
> 0-byte user data messages (ACKs) should not be on the transmitted
> buffer, since they are really peer-to-peer primitives, not MSUs.
> Since ACK is not ACK'd, T7 does not apply to them.
> 
> Regards,
> 
> Jeff Craig
> 
> [email-masked]@ietf.org on 09/12/2002 08:44:02 AM
> 
> Sent by:    [email-masked]
> 
> To:    [email-masked]
> cc:
> Subject:    Re: [Sigtran] M2PA : FSN value in Zero Data Acks
> 
> Brian,
> 
> Andrew's suggestion makes sense. But it should be stated explicitly in the
> draft.
> 
> Even more importantly, the "acknowledgement" concept is poorly documented.
> It is never stated when data must be acked, and when data should not be
> acked.
> 
> I suggest adding a paragraph before the one quoted by Anshoo below:
> 
> "If M2PA receives a User Data message with an FSN incremented by 1, it
> MUST
> immediately respond with a User Data message. If M2PA receives a User Data
> message with an FSN that has not been incremented, it MAY respond with a
> User Data message."
> 
> Also, we must modify condition (a) of the Timer T7 paragraph:
> 
> "(a) There is at least one message with an incremented FSN in the M2PA
> transmit buffer that has been sent."
> 
> Barry Nagelberg
> 
> "Brian F. G. Bidulock" <[email-masked]>
> Sent by: [email-masked]
>  09/12/2002 02:38 AM
>  Please respond to bidulock
> 
>         To:     [email-masked]
>         cc:     [email-masked], [email-masked]
>         Subject:        Re: [Sigtran] M2PA : FSN value in Zero Data Acks
> 
> Anshoo,
> 
> Andrew Booth already brought this up about a week ago on the
> list.  I think that we all agree that the FSN should not be
> incremented on the zero length DATA message used as an ack.
> 
> --brian
> 
> [email-masked] wrote:                           (Thu, 12 Sep 2002
> 09:47:38)
> >
> >
> >
> > Hi,
> >
> > M2PA Draft v6 says that...
> >
> > "If there is no other User Data message to be sent when there is a
> > message to acknowledge, M2PA may send a User Data message with no data
> > payload. The FSN for this empty User Data message is incremented as
> > with any other User Data message."
> >
> > If M2PA would increment the Sequence Number for the Data Ack also. The
> Peer
> > would need to acknowledge this New Dummy Ack.
> > This would end up in a recursive cycle where M2PA peers would be
> continuously
> > exchanging Zero Data Acks whenever there is no Data to be sent across
> the Link.
> > Since SCTP already provides the heartbeat mechanism, this exchange would
> be a
> > waste of network bandwidth.
> >
> > Shouldn't we keep the FSN value of the Zero Data Ack same as that of the
> Last
> > Message sent. The Peer then would not need to acknowledge this Zero Data
> ack.
> >
> > Regards
> > Anshoo.
> > www.hssworld.com
> >
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB7-SWPRO; Plano TX 75075-5813  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Nov 2002 14:52:36 -0700

Tom,

Q.703 refers to such a buffer as the "Retransmit Buffer (RTB)".  The
"Transmit Buffer (TB)" contains messages awaiting transmission, where
as the RTB holds messages awaiting acknowledgement.  Particularly as
the CLEAR-RTB and CLEAR-BUFFERS primitives must be handled by M2PA,
it would be wise to keep the terminology consistent between Q.703 and
M2PA.  Please call that buffer a "Retransmit Buffer (RTB)".

--brian

Tom George wrote:                              (Thu, 21 Nov 2002 14:40:43)

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

---

From: Tom George <[email-masked]>
Date: Thu, 21 Nov 2002 16:22:37 -0600

Should I call it a "retransmit" buffer if it doesn't retransmit?

> > I updated the paragraph in 4.2.1 and added a couple of new ones:
  [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Nov 2002 15:28:55 -0700

Tom,

It does retransmit.  When the link fails, these MSUs are retrieved
and retransmitted on another link.

--brian

Tom George wrote:                                (Thu, 21 Nov 2002 16:22:37)

---

From: Tom George <[email-masked]>
Date: Fri, 22 Nov 2002 16:51:40 -0600

OK. I can go along with that.

tomG.