Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-signalling-over-sctp- applic-04.txt

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Feb 2003 02:57:04 -0700

Coene,

Although many of these comments were handled between draft-04 and draft-07,
there are a number that have not been addressed.

Please consider the unresolved comments in this list as comments for LC.

--brian

Coene Lode wrote:                                                                    (Thu, 07 Mar 2002 09:10:05)
> Brian,
> 
> Thank you for the detailed list.
> I will not answer them point for point as the document itself was/is not
> fully baked yet. 
> With your input It looks like we'll get much nearer that goal.
> We will take into account all the points you mentioned during our editing in
> Minneapolis.
> I hope that after a new release all your points will have taken care of.
> 
> yours sincerly,
> Lode
> 
> Siemens atea
> atealaan 34          2200 Herentals, Belgium
> E-mail: [email-masked]
> Tel: +32-14-252081
> Fax: +32-14-253212
> 
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, March 06, 2002 11:47 AM
> > To: Coene Lode
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] I-D
> > ACTION:draft-ietf-sigtran-signalling-over-sctp-applic-04.txt
> > 
> > 
> > Lode,
> > 
> > A few comments on this draft:
> > 
> > Section 2:
> > 
> > >   ...            Message boundaries are preserved during data
> > >   transport and so no message delineation is needed. ...
> > 
> > Yet, each UA message has a common header which contains a label
> > and a length which indicates the length of the message.  This is
> > a message delimitation.  Why is it present in each UA if it is
> > not required?
> > 
> > >                                                  ... The 
> > user data can
> > >   be delivered by the order of transmission within a stream(in
> > >   sequence delivery) or the order of arrival.
> > 
> > Unordered delivery in SCTP and "order of arrival" delivery 
> > are different
> > things.  SCTP is permitted to place a priority on out of order packets
> > from various streams.  Preference for delivery of stream "0" unordered
> > packets ahead of other stream unordered packets is of 
> > significant advantage
> > to most UAs (regarless of order of arrival).  Please use the term
> > "unordered delivery" instead of "order of arrival".
> > 
> > >   SCTP can be used to provide redundancy and fault tolerance at the
> > >   transport layer and below. Telephony applications needing 
> > this level
> > >   of fault tolerance can make use of SCTP's multi-homing support.
> > 
> > "Fault tolerance" usually has a different connotation when used in
> > telephony related computing.  It indicates a level of reliability
> > (greater than 5 9's).  Please reword as follows:
> > 
> > <   SCTP can be used to provide redundancy at the transport layer and
> > <   below. Telephony applications needing this level of redundancy can
> > <   make use of SCTP's multi-homing support.
> > 
> > Section 3.1:
> > 
> > >                                               ...  Additionally,
> > >   telephony applications may use SCTP stream based flow control
> > >   [SCTPFLOW].
> > 
> > I believe that stream based flow controls were dropped (in favor of
> > application level flow controls).  Please remove this sentence.
> > 
> > Section 3.2:
> > 
> > >   Telephony systems often must achieve high availability in 
> > operation.
> > 
> > Again, "high availability" has the connotation of a specific level
> > of reliability in telephony related computing (in this case less than
> > 5 9's).  Please reword as:
> > 
> > <   Telephony systems often must achieve redundancy in operation.
> > 
> > or
> > 
> > <   Telephony systems often must have no single point of failure in
> > <   operation.
> > 
> > >   transport layer and below must be detected very fast so that the
> > 
> > grammar, reword as:
> > 
> > <   transport layer and below must be detected quickly so that the
> > 
> > >   For example, they are often required to be able to preserve stable
> > >   calls during a component failure. Therefore error 
> > situations at the
> > >   transport layer and below must be detected very fast so that the
> > >   application can take approriate steps to recover and preserve the
> > >   stable calls. ...
> > 
> > This example is a poor one and shows an utter lack of understanding
> > for telephony.  Stable calls have *no* signalling associated 
> > with them.
> > It is only a call in transition that has signalling.  Signalling
> > transport need not worry about affecting stable calls.  Only redundant
> > systems maintaining call state need worry about this.  While this is
> > a system requirement for an MG or MGC, it has nothing to do with
> > signalling components.  Also, sharing of call state between redundant
> > systems is explicitly excluded from the scope of the UAs.  Please
> > remove this example: it makes the applicability statement 
> > sound foolish.
> > 
> > On the other hand, telephony applications pose requirements on the
> > availability of signalling paths to meet service availability and
> > performance requirements.  SS7 has such signalling relation 
> > availability
> > requirements.  These are the telephony requirements which impose on
> > SCTP's ability to detect failures.  (Again, nothing to do with call
> > state.)  Please replace this example in section 3.2 with words to this
> > effect.
> > 
> > Section 3.2.2:
> > 
> > >   For faster detection of (un)availability of idle paths, the
> > >   telephony application may consider lowering the SCTP parameter
> > >   HB.interval. It should be noted this will result in a 
> > higher traffic
> > >   load.
> > 
> > It is not always true that lowered HB.interval will incresae traffic
> > load.  Please change "will result" to "might result".
> > 
> > Section 3.2.3:
> > 
> > >   Setting Path.Max.Retrans and Association.Max.Retrans SCTP 
> > parameters
> > >   to lower values will speed up both destination address and peer
> > >   failure detection. However, if these values are set too low, the
> > >   probability of false detections will increase.
> > 
> > What false detection?  A retransmission is a retransmission.  There is
> > no "false" retransmission or "false detection" mentioned anywhere.
> > In tests we have shown that Path.Max.Retrans of zero (0) (changing
> > destination address on every retransmission) works quite 
> > fine.  I don't
> > understand what you are trying to warn against here...
> > 
> > Section 3.3:
> > 
> > >   Telephony applications often require short end-to-end message
> > >   delays.  The methods described in section 3.2.1 on 
> > lowering RTO and
> > >   not using delayed SACK may be considered.
> > 
> > Not using delayed SACK does nothing to shorten end-to-end message
> > delay.  Please remove it.
> > 
> > Section 4:
> > 
> > >   Users Adaptation Layers are defined to substitute the telephony
> > >   signaling protocol that is below of the telephony 
> > signaling protocol
> > >   to be relayed.
> > 
> > "that is below of the"????  This sentence is so malformed I don't know
> > what it means.  Please correct.
> > 
> > Section 4:
> > 
> > >      - Support management of SCTP transport associations and traffic
> > >         between SGs and ISEPs or two ISEPs
> > 
> > It is a sore point that several UAs do *not* adequately support
> > management between "two ISEPs."
> > 
> > Section 4:
> > 
> > >                 SP:   Signaling Protocol
> > 
> > What is shown is not a signalling protocol, but a signalling protocol
> > user.  Please change to SPU (Signalling Protocol User).
> > 
> > >                 TTST: Traditional Telephony Signaling Transport
> > 
> > The only traditional SS7 signalling that qualifies as a transport
> > is TCAP.  I suggest you use "Protocol" instead of "Transport".
> > Please replace TTST with TTSP (Traditional Telephony Signalling
> > Protocol).
> > 
> > >   It is also referred as SG to AS communication. AS I the name that
> > 
> > Typo: change "AS I the name" to "AS is the name"
> > 
> > >   It is also referred as IPSP communication. IPSP is the name of the
> > >   role that an IP-based node plays UAL usually gives to the ISEP
> > >   nodes. It stands for IP Signaling Point.
> > 
> > English usage.  Please reword this entire paragraph (especially the
> > middle line "IP-based node plays UAL usually").
> > 
> > Section 4.1:
> > 
> > >                                             ... The default 
> > orientation
> > >   would be for the SG to take on the role of server while 
> > the ISEP is
> > >   the client. ...
> > 
> > Grammar: change "would be for" to "is for".
> > 
> > >   Examples of the upper layers to be transported would be Q.931 and
> > >   QSIG.
> > 
> > Grammar: change "would be" to "are".
> > 
> > >   communication where the ISEP role is typically played by a node
> > >   called MGC defined in [RFC2719].
> > 
> > Grammar: change "called MGC defined" to "called an MGC, as defined".
> > 
> > >   The value assigned by IANA for the Payload Protocol 
> > Identifier in the
> > >   SCTP Payload Data chunk is ô1ö
> > 
> > Non-ascii characters at the end of this sentence.
> > 
> > Section 4.2:
> > 
> > >                                                   ... It is 
> > basically
> > >   implemented in an interworking scenario with SG.
> > 
> > Usage: change "basically" to "typically".
> > 
> > >           AN    û Access Network
> > >           NIF   û Nodal Interworking Function
> > >           LAPV5 û Link Access Protocol for the V5 channel
> > 
> > Non-ascii characters in text.
> > 
> > Section 4.3:
> > 
> > >   The DUA is built on top of IUA defining the necessary 
> > extensions to
> > >   IUA for a DPNSS/DASS2 transport. ...
> > 
> > grammar: change "top of IAU defining" to "top of IUA and defines"
> > 
> > >                                ... DPNSS stands for Digital Private
> > >   Network Signaling System and DASS2 for Digital Access Signaling
> > >   System No 2
> > 
> > Missing period at end of sentence.
> > 
> > >   The value assigned by IANA for the Payload Protocol 
> > Identifier in the
> > >   SCTP Payload Data chunk is ôTBDö.
> > 
> > Non-ascii text at end of sentence.
> > 
> > Does not DUA have a PPI assigned yet?
> > 
> > Section 4.4:
> > 
> > >   This protocol would be mainly used between a Signaling 
> > Gateway (SG)
> > >   and Media Gateway Controler (MGC). ...
> > 
> > Grammar: change "would be" to "is"; change "mainly" to "typically" or
> > "largely" or "usually".
> > 
> > >   The only SS7 MTP2 User is MTP3 that is the protocol transported by
> > >   this UAL.
> > 
> > Really bad sentence formation:  change to:
> > 
> > <   MTP3 is the only MTP2-User that is transport by this UAL.
> > 
> > Besides, the statement is incorrect: MTP3b could also be transported.
> > 
> > >   The SG provides a interworking of transport functions with the IP
> > >   transport, in order to transfer the MTP2-User signaling 
> > messages to
> > >   and from an Application Server (e.g. MGC) where the peer MTP2-
> > >   User protocol layer exists.
> > 
> > This is a relly awkward paragraph.  I think you mean "interworking of
> > SS7 transport functions with IP transport functions".  Change 
> > "in order
> > to" to "to", change "the MTP2-User" to "MTP2-User"; change 
> > "to and from"
> > to "with"; change "Application Server (e.g., MGC) where the peer
> > MTP2-User protocol layer exists" to "MTP2-User at an 
> > Application Server
> > (e.g., MGC)."
> > 
> > >   The value assigned by IANA for the Payload Protocol 
> > Identifier in the
> > >   SCTP Payload Data chunk is ô2ö
> > 
> > Non-ascii text at end of sentence.
> > 
> > Section 4.5:
> > 
> > >   This protocol is used between SS7 Signaling Points 
> > employing the MTP
> > >   Level 3 protocol. The SS7 Signaling Points may also 
> > employ standard
> > >   SS7 links using the SS7 MTP Layer 2 to provide transport 
> > of MTP Layer
> > >   3 signaling messages.
> > 
> > Word usage: change "employing" to "using" and "employ" to "use".
> > 
> > There is no such thing as "MTP Layer 2" or "MTP Layer 3"; in SS7 it is
> > referred to as "MTP Level 2" and "MTP Level 3".
> > 
> > >   Both configurations: intercommunication of SS7 and IP with SG and
> > >   communication between ISEPs are possible.
> > 
> > There is no such word as "intercommunication".  "Communication" is
> > already between two things ("inter").
> > 
> > Besides, M2PA only provides for communication between SPs.  There is
> > no need for the two diagrams for M2PA.  There is no 
> > distinction between
> > the first diagram and the right-hand side of the second diagram for
> > M2PA.
> > 
> > >   These figures are only an example. Other configurations 
> > are possible.
> > >   For example, IPSPs without traditional SS7 links could use the
> > >   protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages 
> > in a network
> > >   with all IP links.
> > >
> > >   Another example is that two SGs could be connected over 
> > an IP network
> > >   to form an SG mated pair similar to the way STPs are 
> > provisioned in
> > >   traditional SS7 networks.
> > 
> > These statements sound foolish.  M2PA is really just a different sort
> > of SS7 link.  Plesae remove.
> > 
> > >   The value assigned by IANA for the Payload Protocol 
> > Identifier in the
> > >   SCTP Payload Data chunk is TBD
> > 
> > Does not M2PA have a PPI yet?
> > 
> > >      b. M2PA: SG-IPSP connection is an SS7 link.
> > >         M2UA: SG-MGC connection is not an SS7 link. It is an
> > >               extension of MTP to a remote entity.
> > 
> > There is nothing stopping M2UA from being used in a peer-to-peer
> > fashion.
> > 
> > >      c. M2PA: SG is an SS7 node with a point code.
> > >         M2UA: SG is not an SS7 node and has no point code.
> > 
> > This is not necessarily a correct statement.  There is nothing
> > restricting an M2UA SG from having a point code or being an
> > SS7 node in its own right.
> > 
> > >      d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
> > >         M2UA: SG does not have upper SS7 layers since it 
> > has no MTP3.
> > 
> > Same is true here.  The above statement is false.
> > 
> > >      e. M2PA: relies on MTP3 for management procedures.
> > >         M2UA: uses M2UA management procedures.
> > 
> > If need explanation of the absurdity of this statement, consider
> > this SG:
> >                      ____
> >                     |
> >                     |
> >                 +------+
> >                 | M2UA |
> >                 +------+
> >                 | M2PA |
> >                 +------+
> >                     |
> >              _______|
> > 
> > Which is referred to in the M2UA document.
> > 
> > This SG is an M2PA SG, but it has no point code, has no local MTP3,
> > has no local upper layers (SCCP), and relies on M2UA for management
> > procedures.
> > 
> > Section 4.6:
> > 
> > >      - Interconnection of SS7 and IP nodes
> > 
> > Grammar: replace "Interconection" with "Connection".
> > 
> > 
> > >   It works using the client-server philosophy. ...
> > 
> > This might be ok in German, but is awkward in English.  Reword as:
> > 
> > <   M3UA uses a client-server architecture.
> > 
> > >                                            ... ISEP is 
> > recommended to
> > >   be client when talking with a SG.
> > 
> > <   It is recommended that the ISEP act as the client and initiate
> > <   SCTP associations with the SG.
> > 
> > >                                 ... The reserved port by 
> > IANA is 2905
> > >   to listen to possible client connections.
> > 
> > <   The port reserved by IANA is port number 2905.  This is the port
> > <   upon which the SG should listen for client connections.
> > 
> > >   The assigned payload protocol identifier for the SCTP 
> > DATA chunks is
> > >   ô3ö.
> > 
> > Non-ascii text at end of sentence.
> > 
> > 
> > Section 4.7:
> > 
> > >                 ... SUA can support only non-call related signaling.
> > 
> > Almost all SUA signalling is call related.  I think you mean
> > non-call-associated signalling; but, then, *all* SS7 signalling is
> > non-call-associated signalling.  Please strike this sentence.
> > 
> > >   SUA does not pose stringent timing constraints on SCTP due to the
> > >   fact that SUA applications have broad timing requirement 
> > (from 10 of
> > >   seconds to hours) which the applications guard themselves and the
> > >   timing supervision of the application is end-to-end, not hop-by-
> > >   hop(as with ISUP).
> > 
> > This statement is false and misleading.  SCCP, particularly for the
> > cited applications: MAP, INAP, SMS, BSSAP, RANAP, has very stringent
> > timing requirements, often more stringent than ISUP due to the fact
> > that these represent transaction which are made during ISUP 
> > call setup.
> > 
> > Tens of seconds to hours is false; and atypical.  Transaction timers
> > an performance requirements for INAP, for example, are 1 
> > second maximum
> > with 100 ms nominal query/response times.  Please remove this 
> > paragraph.
> > 
> > >      - Interconnection of SS7 and IP
> > 
> > Change "Interconnection" to "Connection".
> > 
> > >   connections. The payload protocol identifier for the SCTP 
> > DATA chunks
> > >   is ô4ö.
> > 
> > Non-ascii text.
> > 
> > 
> > General:
> > 
> > There is a mixture of "signalling" (two l's British/Canadian spelling)
> > and "signaling" (American spelling).  As the title contains signalling
> > with two l's, please use signalling with two l's throughout.
> > 
> > --brian
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Coene Lode <[email-masked]>
Date: Tue, 25 Feb 2003 13:43:49 +0100

i've looked through the list of Brian and there were still some stuff we did
miss. 
I've updated the draft and I will send the list of points with their
resolution to the list. 
Sorry for taking so long, but I experienced a minor system
malfunction(translation: I fell sick) and there are still some yellow
warning lights flashing at my end. I hope to get it out at the end of this
week.

yours sincerly,
Lode

Siemens atea

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Monday, February 24, 2003 12:35 PM
> To: [email-masked]'; Coene Lode
> Cc: [email-masked]
> Subject: RE: [Sigtran] I-D
> ACTION:draft-ietf-sigtran-signalling-over-sctp- applic-04.txt
> 
> 
> Hi Brian, 
> 
> All the points you refer here were taken into account during 
> the session edition in Minneapolis. And the result was 
> version 5. If there is any particular point that is not there 
> now, and you want to discuss it, just point it, and we'll 
> show the reasons why we included or excluded it.
> 
> Thanks // Javier.
> 
> 
> Sent: miércoles, 19 de febrero de 2003 10:57
> To: Coene Lode
> Cc: [email-masked]
> ACTION:draft-ietf-sigtran-signalling-over-sctp- applic-04.txt
> 
> 
> Coene,
>