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

From: Coene Lode <[email-masked]>
Date: Thu, 7 Mar 2002 09:10:05 +0100

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/
> 

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