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

From: [email-masked]
Date: Thu, 12 Sep 2002 08:44:02 -0400

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

---

From: [email-masked]
Date: Thu, 12 Sep 2002 09:59:51 -0400

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.

>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

To:    [email-masked]
cc:

Brian,

"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."

Barry Nagelberg

Anshoo,

--brian

Peer
continuously
the Link.
be a
Last
ack.

---

From: [email-masked]
Date: Thu, 12 Sep 2002 11:11:56 -0400

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,

Regards,

Jeff Craig

To:    [email-masked]
cc:

Brian,

MUST

Barry Nagelberg

Anshoo,

--brian

Peer
continuously
the Link.
be a
Last
ack.