Subject: RE: [Sigtran] M2PA : LS messages on stream 0

From: [email-masked]
Date: Tue, 23 Jul 2002 13:23:50 -0400

Hello Al,

Yeah, it would definately clarify M2PA v5 4.2.1 to make an appropriate
reference to Q.703 concerning the treatment of sequence numbers.

>    So you should not validate the FSN or the BSN of any LS message, per
>Q.703.  M2PA doesn't contradict this, does it?

So one should not use LSI as an ACK in the absence of outbound user data?
What should be used?

Regards,

Jeff

Al Varney <[email-masked]>@ietf.org on 07/23/2002 12:43:50 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: [Sigtran] M2PA : LS messages on stream 0

At 09:23 AM 7/23/02 -0400, [email-masked] wrote:

>Hello Anshoo,
>
>I have encountered several scenarios of out-of-sequence link status
>messages during testing of my M2PA v5 implementation.
>
>I addressed the problem in the following manor:
>
>1) The FSN of a link status message is ignored.
>2) The FSN of a user data message must be in-sequence,
>otherwise it is a protocol error.
>3) The BSN of any message is validated. If valid, it is
>used to drain the retransmit queue (an ACK) and update
>link L2 data. If not valid, then the BSN is simply ignored.

    I think you should address the "problem" by following Q.703
requirements.  Both the FSN AND BSN of LSSUs are effectively ignored by
MTP2 (see Q.703 5.2.2(b) and Figure 14, Sheet 2 for BEC method and Q.703
section 6.3.1 and Figure 16, Sheet 2 for PCR method).

    So you should not validate the FSN or the BSN of any LS message, per
Q.703.  M2PA doesn't contradict this, does it?

Al Varney

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

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

---

From: Al Varney <[email-masked]>
Date: Tue, 23 Jul 2002 13:50:22 -0500

>So one should not use LSI as an ACK in the absence of outbound user data?

    I don't know.  Obviously some "non-Data" message has to be used to ACK 
received Data messages when no Data message is available to send.

    If Stream 0 is used for LS messages, then the FSN/BSN of LS messages 
must be ignored.  Use of the BSN could result in a race condition where the 
LS BSN would ACK a recent Data message rather than an older Data message 
with the same FSN.  As I recall, this type of ACK procedure states receipt 
of an ACK with BSN=X allows a new Data message with FSN=X-1 to be sent.  If 
there are still unread messages in the pipeline with BSN=X-1, those unread 
messages would be thought to ACK the new FSN=X-1 message, rather than the 
old message really being acknowledged.  Perhaps an "empty" Data message 
would serve as an ACK where needed -- just as FISU does in MTP2.

    If, as Tolga suggests, LS and UserData messages use the same stream, 
then BSN can be used in both and M2PA can use LSI for ACK.  In this case, 
the FSN of LS messages would reuse the last FSN of the previous MSU, but 
would not increment FSN.

    The same number of non-Data ACKs would be sent in either case.

Al Varney

---

From: Tom George <[email-masked]>
Date: Thu, 25 Jul 2002 15:02:49 -0500

The Link Status In Service message was created for this purpose, i.e.,
to ack a message when there was no outgoing data (or other Link Status)
message to send.

> So one should not use LSI as an ACK in the absence of outbound user data?
  [...]

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; 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. *

---

From: Al Varney <[email-masked]>
Date: Thu, 25 Jul 2002 15:47:08 -0500

At 03:02 PM 7/25/02 -0500, Tom George wrote:
>Al et. al.,
>
>I did not think about the race condition that you suggested. If that
>happened, it would be a problem. With 24-bit sequence numbers, how
>likely is this kind of wraparound problem?
>
>tomG.

    Very improbable -- it would require SCTP to buffer/delay a Stream 0 
message for a long time (asking for retransmission after retransmission of 
the ACK, waiting for application to read Stream 0, etc.) while millions of 
Data messages get generated (but not necessarily delivered).  On the other 
hand, if you know a comparable same-cost mechanism that has zero 
probability of this occurring (using an empty Data message as an ACK, for 
example), why would you choose to run the risk?

    But it's your protocol.  So long as you put a note regarding the 
possibility of this occurrence in the Draft and any RFC, and it gets past 
the editors, it's no worse than other protocols that rely on number 
wrap-around having a very low probability.

Al Varney

>Al Varney wrote:

---

From: Tom George <[email-masked]>
Date: Thu, 25 Jul 2002 15:02:44 -0500

Al et. al.,

tomG.

Al Varney wrote:
  [...]