Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-06.txt

From: Ming Lin <[email-masked]>
Date: Sun, 01 Sep 2002 12:08:13 +0800

Dear Tom,

I think we should remove RETRIEVAL state, this state will result in many problem but no use,
for example the No. 18 issue.

"18. 08/09/02 Howard May "[Sigtran] M2PA - Minor corrections?" 
     In Figure 7, RETRIEVAL receives MTP Start. Go to AIP, not OOS.
 A: Yes.  [Done.]"

----- Original Message ----- 
From: "Tom George" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 30, 2002 11:30 PM
Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-06.txt

> M2PA Changes for version 6
> 08/28/2002
> 
> Here are the changes in draft-ietf-sigtran-m2pa-06.txt (M2PAv6).
> 
> If anyone wants to study the changes in detail, I have a "diff" file I
> can send.
> 
> This is not a complete list of changes. I did not include minor
> rewording.
> 
> 
> This is the list of comments received on M2PAv5 on the SIGTRAN list.
> 
> ==================================================================
> 
> 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.  [Done.]
> 
> 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.
> 
>    My ideas:
> 
>    User Data received during PROVING should be discarded.
> 
>    Link Status Alignment received during PROVING should be ignored.
> 
>    [Done.]
> 
> 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, T6. [Done.]
> 
>    Rename M2PA T2 to T4. [Done.]
> 
>    Don't use "timer" names for the rate parameters.  [Done.]
> 
>    T7 - see #11 below.  [Done.]
> 
> 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.  [Done.]
> 
> 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.  [Done.]
> 
> 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 transmit buffer.
> 
>    I have a question about the BSNR values on the list. 2 out of 3
>    consecutive messages with bad BSNRs?
> 
>    Eliminate acks on the Status stream. All acks go over the Data
>    stream. If there is no User Data message to be sent, send one with
>    no data in it. Get rid of Link Status In Service, since its only
>    purpose was to carry an ack. [Done.]
> 
> 7. 05/24/02 Brian Bidulock "[Sigtran] Re: M2PA Clarification". Does
>    M2PA need to withhold messages from SCTP during busy?
> 
> A: This is how Q.703 works, so we should copy it. Before there were
> M2PA sequence numbers, messages were withheld while the peer was Busy
> to prevent message loss in case the link later failed. Now that M2PA
> has its own sequence numbers, this is no longer a danger. So M2PA can
> continue transmitting while its peer is Busy. 
> 
>    I updated secion 4.1.5 Level 2 Flow Control.  [Done.]
> 
> 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)".  [Done.]
> 
> 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. 
> 
>    Since there has not been more discussion, I will leave this as is
>    for M2PA version 6.  [Done.]
> 
> 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. This is one of the main reasons I
> did not allow for multiple links in an association. 
> 
>    No change to the draft is needed.  [Done.]
> 
> 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-) I added the T7 timer in 4.2.1
> Sending/receiving messages and 4.1.5 Level 2 Flow Control.  [Done.]
> 
> 12. 06/25/02 Lyndon Ong "RE: [Sigtran] M2PA Queries - summary". Just a
>     summary of the discussion.
> 
> A: No answer needed. [Done.]
> 
> 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).  [Done.]
> 
> 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-( [Done.]
> 
> 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.
> 
> 
> 16. 07/19/02 Ray Singh "[Sigtran] Comment on M2PA - Slow Start". What
>     kind of warning is needed about slow start?
> 
> A: I proposed a general warning about slow start to replace specific
> warnings throughout the document.
> 
> alignment, changeover, path failure (multihoming), reduced volume. See
> Tolga, 07/26/02. [Done.]
> 
> 
> 17. 07/22/02 Tolga Asveren "[Sigtran] M2PA : LS messages on stream
>     0". Are there problems with sending Status and Data on different
>     streams? What mimics MTP2 best?
> 
> A: The problem with putting LS and Data on the same stream is that a
> LS message can get stuck behind a Data retransmission. This is
> contrary to the message priority of MTP2. (Brian Bidulock 08/13/2002
> 21:00 pointed out that this is a problem that MTP2 does not have.)
> 
> The problem with using SCTP unordered transmission for LS messages is
> that they can get out of order with each other. For example, a LS Proc
> Outage could get out of order with a LS Proc Outage Ended. 
> 
> MTP does not require that LSSUs and MTUs be associated with each other
> in any particular way. It has MTP2 put LSSUs ahead of MTUs in the
> transmit buffer. So it should not be required that M2PA transmit LS in
> order with Data.
> 
> Having M2PA put LS at the front of the M2PA transmit queue helps some,
> but it does not do anything about the messages that are in the SCTP
> send queue. To truly imitate MTP2 at this point, we would need a way
> to give a message to SCTP and tell it to put the message at the front
> of its send queue.
> 
> (Or, we could restrict SCTP to just 1 message in its send buffer. This
> would allow M2PA to prioritize like MTP2. But this would create severe
> problems of its own. No one seemed to like this option.)
> 
> Sending LS and Data on different streams allows for a partial
> imitation of the MTP2 transmission priority. If the receiving M2PA
> gives priority to reading incoming LS messages (on stream 0) over Data
> messages (on stream 1), then LS messages can be received sooner than
> if they waited behind the Data messages. Also, it is possible for
> SCTP, by some implementation-dependent method or some future SCTP
> extension, to give a higher priority to sending messages on stream 0.
> 
> My conclusion is to leave the draft alone. Having separate Status and
> Data streams does not exactly imitate MTP2, but it is as close as we
> can get using SCTP.  [Done.]
> 
> Some related matters:
> 
> I will add to 4.1.7 so that it says that M2PA transmits LS messages
> before Data messages. This is in addition to the attempt to prioritize
> SCTP stream 0. [That was already there. Done.]
> 
> The FSN should be ignored in the LS messages. FSN should be
> incremented only for Data messages. [That was already there. Done.]
> 
> I will add a warning that one has to watch out for a wraparound of the
> FSN/BSN numbers. This is unlikely with 24 bits, but should probably be
> mentioned. [Done.]
> 
> 
> 18. 08/09/02 Howard May "[Sigtran] M2PA - Minor corrections?" 
> 
>     In Figure 7, RETRIEVAL receives MTP Start. Go to AIP, not OOS.
> 
> A: Yes.  [Done.]
> 
> 
> ==================================================================
> 
> More detailed list of changes:
> 
> 2.2  M2PA Header: Changed BSN and FSN to 24 bits in diagram.
> 
> 2.3.2 Link Status: Removed In Service (10) from list of values.
> 
> 2.3.2.1 Link Status Proving, 1st para: Removed statement about SCTP
> slow start.
> 
> 3.  M2PA Link State Control, Figure 7: M2PA Link State Transition
> Diagram:
> 
>     T2 is renamed T4.
> 
>     Added T7 expiry.
> 
>     In RETRIEVAL, MTP3 Start goes to AIP instead of OOS.
> 
> 4.1.2 MTP and SCTP Entities, 2nd para: Added "(or IP addresses, if
> multi-homing is used)".
> 
> 4.1.3 Link Alignment, 1st para: Removed list item 3 about SCTP slow
> start.
> 
> 4.1.3 Link Alignment, several places: Renamed T2 to T4.
> 
> 4.1.3 Link Alignment, para "Anomalous...": Added this paragraph.
> 
> 4.1.5 Level 2 Flow Control, para "The peer M2PA should...": Changed
> "shall cease transmitting messages" to "should continue transmitting
> messages".
> 
> 4.1.5 Level 2 Flow Control, para "The peer M2PA shall not...": Added
> this paragraph about T7.
> 
> 4.2.1 Sending and receiving messages, para "When M2PA receives a User
> Data message...": Specified that this is a _User Data_ message.
> 
> 4.2.1 Sending and receiving messages: Removed paragraph stating that
> ack may be sent in User Data or Link Status.
> 
> 4.2.1 Sending and receiving messages, para "M2PA should follow the
> criterion...": Added this paragraph about 2-out-of-3 criterion.
> 
> 4.2.1 Sending and receiving messages, para "M2PA should ignore...":
> Added this paragraph.
> 
> 4.2.1 Sending and receiving messages, para "Note: In all
> calculations...": Added this paragraph.
> 
> 4.2.1 Sending and receiving messages, para "If there is no other User
> Data...": Changed this to say M2PA sends User Data with no payload
> instead of LS In Service.
> 
> 4.2.1 Sending and receiving messages, last 2 paragraphs: Added these
> paragraphs about T7.
> 
> 4.3 SCTP Considerations: Added this section to discuss slow start.
> 
> 5.1  Link Initialization, several places: Renamed T2 to T4.
> 
> 7.1 SCTP Payload Protocol Identifier: Registered User Port Number is
> 3565. Removed UDP.
> 
> 9.  References: Updated some of the references.
> 
> 10.  Author's Addresses: New address for Brian Bidulock.
> 
> (end)
> 
> 
> -- 
> * 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
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran