Subject: Re: [Sigtran] Re: M2PA Clarification

From: Tom George <[email-masked]>
Date: Sat, 13 Jul 2002 22:06:20 -0500

Somebody please help me with a Q.703 question. When MTP2 becomes busy,
it withholds acks. Does this effectively make the other end stop
transmitting new messages?

tomG.

"Brian F. G. Bidulock" wrote:
> 
> Anshoo,
> 
> You bring up a good point.  Now that there are sequence numbers
> for acknowledging MSUs, there is no longer a need for the sending
> M2PA to withold messages from SCTP.  It should just not expect
> an acknowledgement (BSN) from the other side corresponding to these
> messages during T6, just as in normal SS7 link operation.  Unacknowledged
> messages would then be held at the sending M2PA and be available for
> retrieval under changeover at MTP3.
> 
> This previous text was only a workaround for the lack of an M2PA level
> acknowledgment, which is not available using FSN/BSN.
> 
> I propose that the related text be updated to reflect normal SS7 link
> operation in this regard.
> 
> --brian
  [...]

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

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

---

From: Tom George <[email-masked]>
Date: Sat, 13 Jul 2002 22:25:20 -0500

Here is my list of comments. For the most part, they are arranged by
the thread from the SIGTRAN list.

Everyone please make comments. I think the discussion would go more
smoothly if you only talked about one item per e-mail.

1. Section 2.2. FSN/BSN should be 24 bits, not 23.

A: This was a typo. It will be 24 in M2PAv6.

2. 05/06/02 Jeff Craig "[Sigtran] (M2PA) What actions should be taken
   if LSA or User Data Received in PROVING?" There is no guidance
   about anomalous events during alignment/proving.

A: I agree that some text should be added. I have not worked out the
details and would welcome suggestions.

3. 05/10/02 Jeff Craig, "[Sigtran] (M2PA) Please standardize M2PA
   protocol timer identifiers" and Jeff Craig 06/21/02 "m2pa comment:
   timers". Line up timer names in Q.703 and M2PA. Add the T7 timer.

A: This is what I got out of the discussion:

   Keep same names for T1, T3, T4, T6.

   Rename M2PA T2 to T4.

   Don't use "timer" names for the rate parameters.

4. 05/17/02 Jeff Craig, "[Sigtran] (M2PA) Please add a Network
   Appearance parameter to the M2PA protocol". A suggestion that a NA
   parameter be added to M2PA.

A: I prefer not to add this. 

5. 05/22/02 anssharma, "[Sigtran] M2PA Clarification". In level 2 flow
   control, M2PA stops transmitting. What does it do with the
   messages?

A: I think is an implementation matter. 

6. 05/24/02 Lisa Gorgone, "[Sigtran] M2PA:Questions on sequence
   number". Some questions about bad values of FSNR and BSNR.

A: M2PAv5 (4.2.1) says to fail the link if one FSNR is out of order. I
think that is OK. There is nothing about bad BSNR values. I would be
inclined to fail the link in this case as well, since one end is
acking messages that the other does not have in its (re)transmit
buffer.

7. 05/24/02 Brian Bidulock "[Sigtran] Re: M2PA Clarification". Does
   M2PA need to withhold messages from SCTP during busy?

A: If this is how Q.703 works, we should copy it. I just sent a
question to the list about the Q.703 procedure.

8. 06/18/02 amish.chana "[Sigtran] M2PA Comment: Multi-homing". Should
   M2PA support multi-homing?

A: It is allowed. The only change needed is in 4.1.2 so that it says
"the IP address (or IP addresses if multi-homing is used)".

9. 06/19/02 Lisa Gorgone "Re: [Sigtran] M2PA Comment:Retrieval
   State". Does M2PA need a RETRIEVAL state? Does RETRIEVAL state
   cause harm?

A: I would like to have more discussion about this. 

10. 06/21/02 Javier Pastor-Balbas "[Sigtran] M2PA Comment:
    Multi-homing". Also 06/21/02 "[Sigtran] Multiplexed M2PA links on
    an association".  Should M2PA allow multiple links per
    association?

A: The disadvantage of this is that if the association dies, you lose
all the links on the association. (According to the SCTP authors, it
is intended that all the streams in an association follow the same
physical path.) This is one of the main reasons I did allow for
multiple links in an association.

11. 06/21/02 Andrew Booth "[Sigtran] M2PA Comment: T7 Timer" and
    several of the earlier threads. Should there be an equivalent of
    MTP2 T7?

A: OK, you finally convinced me. 8-)

12. 06/25/02 Lyndon Ong "RE: [Sigtran] M2PA Queries - summary". Just a
    summary of the discussion.

A: No answer needed.

13. 06/26/02 Karen King "[Sigtran] A couple of comments on M2PA
    processor outage". Recommend adding text to 4.1.4 Processor Outage
    about flushing buffers as in Q.703.

A: Even though this is in Q.703, the action is taken by MTP3. Section
4.1.4 (next to last paragraph) does allow for the flush. Flush is
described in 4.2.4. So I think this is taken care of (although there
may be problems in 4.2.4 - that's another thread).

14. 06/28/02 Ray Singh "[Sigtran] Comment on M2PA - Performance
    Monitoring". Add back the monitoring of SCTP association that was
    in draft version 3.

A: The reason I took this out is that I never had any solid ideas
about what SCTP parameters should be monitored and what the acceptable
values would be. If we could come up with something helpful, I am not
opposed to adding the monitoring back in. But I don't see the point of
adding it if the criteria will be some implementation-dependent
parameters having implementation-dependent values. 8-(

15. 07/12/02 anssharma "[Sigtran] M2PA - Flush Buffers". Questions
    about Flush.

A: These are good questions but I have not had time to think about
them.

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 13 Jul 2002 23:38:08 -0700

> transmitting new messages?

No. But Q.703 is designed for a dedicated bandwidth link,
so sending something is better than dead air. The receiver
may quite likely drop the new messages and ask for
retransmission later. However, sending the new messages
immediately wastes no bandwidth, because the
bandwidth is dedicated anyway.

-- 
// Jakob Heitz. Tel:510-747-2917

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 15 Jul 2002 10:08:17 -0400

Tom,

> multiple links in an association.
[TOLGA] What is benefit of allowing multiple links on an association? For
SS7, if number of links between two nodes is increased, the reason is either
redundancy or demand for higher bandwith or both. By carrying multiple links
over the same association neither redundancy nor bandwith is increased.
In IP network -without any additional mechanism- there is no guarantee that
packets from one endnode to another one will follow always the same
physicall path. So, the statement "All the streams in an association follow
the same physicall path" is not true, but I think what really matters is,
whether the the physicall path is dependent on streamId, and it isn't.

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 15 Jul 2002 16:53:37 -0400

Tom and all,

Some more comments/questions are below.

   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Monday, July 15, 2002 10:08 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the same SCTP association
>
>
> Tom,
>
[TOLGA] Currently the only benefit I could think of is, with multiple links
approach one can use multiple streams and so can avoid head-of-line
blocking. Whether this is a significant advantage over using separate
associations per link is another question.

BTW, in M2PA 1.7.4 it says:
"SCTP allows a user-specified number of streams to be opened during the
initialization.  It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association.

M2PA uses two streams in each direction for each association. Stream 0
in each direction is designated for Link Status messages. Stream 1 is
designated for User Data messages. Separating the Link Status and User
Data messages onto separate streams allows M2PA to prioritize the
messages in a manner similar to MTP2."

How are Stream 0 and Stream 1 used to prioritize Link Status messages? I
don't think sending messages from stream 0 will ensure that they arrive to
the destination faster than messages sent via stream 1, IP routing is
independent of streamId.
Secondly, is this really matching with MTP2 behavior? With MTP2, when a User
Data message is sent and afterwards a Link Status message, there isn't the
possibility that LS arrives before UD to the destination, because they are
transferred over a dedicated physical medium, but by sending them via
different streams, there is the possibility of missequencing. What is the
reason for such a strategy?

---

From: Al Varney <[email-masked]>
Date: Mon, 15 Jul 2002 17:02:47 -0500

>bandwidth is dedicated anyway.

    Jakob states the major protocol perspective well.  As both he and Tom 
are probably aware, a detailed answer regarding MTP2 behavior is somewhat 
less succinct:

1) (for the Basic Error Correction method), the transmitter must stop 
sending NEW MSUs when its retransmission buffer fills or all sequence 
numbers have been assigned to unacknowledged MSUs.  During "busy" (by 
definition) no MSUs can be acked OR NACKed by the "busy" receiver, so any 
MSUs in the retransmission buffer will sit there until "busy" ends or the 
link fails.

    Thus the answer here is:  The other end will not stop sending NEW 
messages (unless the retransmission buffer is full), but it will stop 
retransmitting old messages unless it is in the middle of a retransmission.

2) (for the Preventive Cyclic Retransmission Error Correction method), the 
transmitter will continue to send both NEW and OLD MSUs until they are 
acknowledged.  If the retransmission buffer is full, only OLD MSUs will be 
sent.

3) The version of ANSI T1.113 approved in 2000 added text to MTP2 
supporting a management option that would block transmission of NEW MSUs if 
"busy" has been received.  This was part of a set of changes to 
clarify/enhance MTP2 and MTP3 protocol under various congestion situations.

    So whether or not NEW MSUs are blocked could depend on the presence of 
this management option.  Even with the option in effect, OLD MSUs continue 
to be sent if the PCR Error Correction method is in use.

Al Varney

---

From: Al Varney <[email-masked]>
Date: Tue, 16 Jul 2002 07:29:12 -0500

> are probably aware, a detailed answer regarding MTP2 behavior is somewhat 
...

>supporting a management option that would block transmission of NEW MSUs 
>if "busy" has been received.  This was part of a set of changes to 

    OOPS:  I had ISUP on the brain when I responded.  The ANSI reference 
for MTP2 is T1.111.3 (Chapter 3 of T1.111), not T1.113.  Sorry for any 
confusion.

Al Varney

---

From: Tom George <[email-masked]>
Date: Fri, 19 Jul 2002 18:41:51 -0500

Comments below....

Tolga Asveren wrote:
  [...]
> > over the same association neither redundancy nor bandwith is increased.

Correct.

> associations per link is another question.

There is no head-of-line blocking problem either way. If multiple links
per association were allowed, there would be no HOL blocking between the
links. If you have links running on different associations, there is
still no HOL blocking between the links. 
 
  [...]
> > whether the the physicall path is dependent on streamId, and it isn't.

Thanks for clearing that up. 

tomG.