Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)

From: [email-masked]
Date: Wed, 1 Oct 2003 08:00:05 -0400

Hello All,

I agree with Brian. The current draft text sufficiently addresses
this issue.  I do not think that an unrealistic implementation
(a test harness geared toward negligible traffic rates for testing)
at the Plugtest is a good example to justify adding a requirement
to the draft that prevents flexibility that may be required in some
deployments.

If those advocating a draft change won't drop this matter, then I
suggest that they propose new language that does not contain words like
'MUST' or 'immediately' or 'eight'. I also suggest that they account
for all of the exceptions to the rules that they propose. They probably
can come up with some text that I will agree to, though it will probably
just be a more complex way of saying 'ACK promptly'.

Regards,

Jeff

                      "Brian F. G.                                                                                                
                      Bidulock"                To:      Nitin Vairagare <[email-masked]>                               
                      <bidulock@openss         cc:      Javier Kim <[email-masked]>, Andrew Booth <[email-masked]>,               
                      7.org>                   [email-masked], [email-masked], [email-masked]                
                      Sent by:                 Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)                          
                      sigtran-admin@ie                                                                                            
                      tf.org                                                                                                      

                      09/30/03 07:16                                                                                              
                      PM                                                                                                          
                      Please respond                                                                                              
                      to bidulock                                                                                                 

Nitin,

Nitin Vairagare wrote:
(Tue, 30 Sep 2003 17:30:15)
> Brian,
>
> But unfortunately, that's what some one interpreted..

Ago.  But now everyone agrees 0.5 seconds is not promptly.

Also anyone waiting 0.5 seconds did not give careful
consideration to the impact on SS7 network performance as
is warned as part of the recommendation in the current draft.

Anyone is free to ignore this recommendation at their own
peril.  It does not:

a) cause interoperability problems (because proper transmit
   flow controls are necessary anyway),

and

b) it does not endanger the (IP) network.

Therefore, all the requirement could be is a SHOULD anyway.
As the current text stands.

If you try to pick a number (200ms<- Javier, 0ms <-Me) then
there will be disputes based on network operating requirements.

Anything between 0 and 200ms and there will be a dispute.

Sufficient discussion has gone by that if anyone asks what
"promptly" means, the answer is "as soon as possible" and
"don't go setting any timers and going away first".

We can leave it at that.

--brian

> And there may be more implementations similar to that.
>
> If someone has disagreements, we could further discuss
> the maximum number of MSUs that can be withheld without
> being ACKed. And what should be the value of the timer.
>
> Also, in addition to Javier's original text we might have to
> add text to mention exceptions like PO, receive congestion
> or other MTP2 procedures that requires to withheld the
> ACKs implicitly.
>
> Regards,
> Nitin
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2003 5:00 PM
> To: Javier Kim
> Cc: Nitin Vairagare; Andrew Booth; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)
>
> Javier,
>
> I think everyone is agree that 0.5 seconds delay is not "promptly".
>
> --brian
>
> Javier Kim wrote:
> (Tue, 30 Sep 2003 14:47:21)
> >
> > Hi all,
> >
> > That's exactly the problem. One implementation sent the MSU ACK
> > promptly(within .5 second) in the last plugtest. Any decent protocol
> > has a finite and measurable rule to prevent accumulation of a large
> number
> > of items on the retransmission queue.  It happened already and will
> happen
> > again and again. Can you live with 1000s of items in the
> retransmission
> > queue?  I don't think anybody in their right mind can.
> >
> > IMHO the current draft does NOT address the issue sufficiently. I
> firmly
> > believe that my proposed text cures the problem, without limiting
> > the current method of sending the MSU_ACK promptly.
> >
> > Best regards,
> >
> > Javier
> >
> >
> > On Tue, 30 Sep 2003, Brian F. G. Bidulock wrote:
> >
> > > Date: Tue, 30 Sep 2003 14:56:01 -0600
> > > From: Brian F. G. Bidulock <[email-masked]>
> > > To: Nitin Vairagare <[email-masked]>
> > > Cc: Andrew Booth <[email-masked]>, [email-masked],
> > >      Javier Kim <[email-masked]>, [email-masked],
> [email-masked]
> > > Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)
> > >
> > > Nitin,
> > >
> > > Nitin Vairagare wrote:
> (Tue, 30 Sep 2003 15:14:03)
> > > >
> > > > In absence of any specific guidelines there will be
> implementations that
> > > > may buffer upto 1000s of MSUs before they send the ACK.
> > >
> > > Only by ignoring the recommendation to send acks promptly.
> > >
> > > >
> > > > If everyone agrees to the fact that networks can handle
> retransmission
> > > > of 1000s of MSUs in an event of link failure without causing any
> further
> > > > damage
> > > > or flushing of 1000s of MSU after PO, then surely we can drop this
> > > > issue.
> > >
> > > An implementation can institute proper transmit congestion controls
> > > long before it needs to buffer 1000's of MSUs.
> > >
> > > So, I suppose we can drop this issue?
> > >
> > > --brian
> > >
> > > >
> > > > IMO, there should be some limit on how many maximum MSUs can be
> > > > outstanding without being acked. Leaving the interpretation open
> may
> > > > cause the issues
> > > > discussed earlier on this thread including bringing up the
> implementors
> > > > guide at later point.
> > > >
> > > > Regards,
> > > > Nitin
> > > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Tuesday, September 30, 2003 2:27 PM
> > > > To: Andrew Booth
> > > > Cc: [email-masked]; Javier Kim; Nitin Vairagare;
> > > > [email-masked]; [email-masked]
> > > > Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)
> > > >
> > > > Andrew,
> > > >
> > > > I agree with the draft text too.  I was just trying to
> > > > accomodate Javier.
> > > >
> > > > If we have concensus on the draft text, can we drop this
> > > > issue?
> > > >
> > > > --brian
> > > >
> > > > Andrew Booth wrote:
> > > > (Tue, 30 Sep 2003 14:47:32)
> > > > > Hi All,
> > > > >
> > > > > I agree with Jeff.  I prefer the draft text.
> > > > >
> > > > > Andrew
> > > > >
> > > > > [email-masked] wrote:
> > > > >
> > > > > >Hello All,
> > > > > >
> > > > > >Interesting discussion...
> > > > > >
> > > > > >
> > > > > >
> > > > > >>>Perhaps you would prefer the original text that said "SHOULD"
> and
> > > > > >>>
> > > > > >>>
> > > > > >"promptly".
> > > > > >
> > > > > >I still prefer the original draft text and think it
> sufficiently
> > > > addresses
> > > > > >this issue.
> > > > > >I do not agree with the newly proposed 'MUST' or 'immediately'
> > > > regarding
> > > > > >sending ACKs.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >Jeff
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > > > >                      "Brian F. G.
> > > >
> > > > > >                      Bidulock"                To:      Nitin
> > > > Vairagare <[email-masked]>
> > > > > >                      <bidulock@openss         cc:      Javier
> Kim
> > > > <[email-masked]>, [email-masked]
> > > > > >                      7.org>                   Subject: Re:
> [Sigtran]
> > > > M2PA MSU_ACK frequency issue (fwd)
> > > > > >                      Sent by:
> > > >
> > > > > >                      sigtran-admin@ie
> > > >
> > > > > >                      tf.org
> > > >
> > > > > >
> > > >
> > > > > >
> > > >
> > > > > >                      09/26/03 10:53
> > > >
> > > > > >                      PM
> > > >
> > > > > >                      Please respond
> > > >
> > > > > >                      to bidulock
> > > >
> > > > > >
> > > >
> > > > > >
> > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >Nitin,
> > > > > >
> > > > > >SCTP acks packets (TSNs) not M2PA messags (SSNs).  SCTP is
> already
> > > > able to
> > > > > >wait briefly (the Nagle algorithm with Minshall modifications
> is
> > > > quite
> > > > > >useful
> > > > > >int his regard) and coallesce M2PA messages into SCTP packets.
> Do no
> > > > > >assume
> > > > > >that 1 M2PA will be placed into each SCTP packet.  The SACK
> engine is
> > > > > >independent of the M2PA ack mechanism.  Also, in SCTP, delaying
> SACKs
> > > > is
> > > > > >completely optional in circumstances that permit it and
> forbidden in
> > > > > >circumstances that doe not (duplicate TSNs reports, gaps, etc).
> > > > > >
> > > > > >While the Nagle algorithm benefits the network by reducing the
> number
> > > > of
> > > > > >undersized packets in the network (and thus the packet overhead
> for a
> > > > given
> > > > > >amount of application data), it does so at cost to latency.
> Delaying
> > > > > >SACKs (with the hope of bundling them with outher chunks) is
> far less
> > > > > >beneficial to the network than Nagle.  Even still both are
> optional,
> > > > > >neither
> > > > > >are required to protect the network, and they becom operational
> > > > decisions.
> > > > > >
> > > > > >However, delaying SACKs too long *is* harmful to the network
> (because
> > > > it
> > > > > >cause
> > > > > >unnecessary retransmissions), and this is why SCTP places
> absolute
> > > > maximums
> > > > > >on
> > > > > >the amount of time that one can delay a SACK.  (An SCTP that
> always
> > > > SACKs
> > > > > >immediately and without delay is completely conformant to RFC
> 2960.)
> > > > Also,
> > > > > >delaying SACKs at all under some circumstances is harmful to
> the
> > > > network
> > > > > >(dup
> > > > > >reports, gaps, etc.) because they again cause an excessive
> numebr of
> > > > > >retransmissions.  Thus RFC 2960 (and similarly for TCP) makes
> > > > requirements
> > > > > >upon when an SCTP receiver MUST send a SACK immediately, and on
> its
> > > > own
> > > > > >if there are no other messages with which to bundle it.
> > > > > >
> > > > > >When you consider Nagle (with Minshall modifications) and
> delayed
> > > > SACK, it
> > > > > >is
> > > > > >quite likely the case under normal operation that if there is
> no
> > > > DATA, that
> > > > > >successive DATA-ACKs generated by M2PA will in fact be bundled,
> and
> > > > they
> > > > > >will
> > > > > >have a delayed SACK piggybacked with them.
> > > > > >
> > > > > >But this is the domain of SCTP an well outside the scope of
> M2PA.
> > > > M2PA
> > > > > >should
> > > > > >send acknowlegements immediately and let SCTP sort out
> precisely when
> > > > to
> > > > > >send
> > > > > >acks and SACKs.
> > > > > >
> > > > > >On of the major differences between MTP Level 2 ack mechanism
> and
> > > > SCTP SACK
> > > > > >mechanism is that MTP Level 2 only acknowledges messages once
> they
> > > > are
> > > > > >assured
> > > > > >to be delivered to MTP Level 3.  So when there is a processor
> outage,
> > > > or
> > > > > >receive congestion towards MTP Level 3, acknowledgements are
> > > > withheld.
> > > > > >This
> > > > > >is why we abandonned using the SACK mechanism for
> acknolwedgement in
> > > > M2PA.
> > > > > >It
> > > > > >was impossible for an SCTP ULP to suppress sending SACK in
> these two
> > > > > >circumstances.  So, whereas SCTP's ack is an acknowledgement
> that the
> > > > > >message
> > > > > >was received correctly, M2PA's ack is an acknowledgement to the
> M2PA
> > > > peer
> > > > > >that the message was actually delivered to MTP Level 3.
> > > > > >
> > > > > >I would even go so far as to say that we should have put
> > > > acknowledgements
> > > > > >on
> > > > > >stream 0 in M2PA.  This is because it might be a good idea for
> > > > > >acknowledgements to not be delayed waiting for a HOL blocked
> data
> > > > message
> > > > > >in
> > > > > >stream 1.  Consider the following:
> > > > > >
> > > > > >               _______
> > > > > >                | | | |
> > > > > >                | | | |
> > > > > >        ------->| | | |------------------------>
> > > > > >                | | | |
> > > > > >               _|_|_|_|
> > > > > >                                        _______
> > > > > >                                       | | | |
> > > > > >                                       | | | |
> > > > > >        <------------------------------| | | |<---
> > > > > >                                       | | | |
> > > > > >                                       |_|_|_|_
> > > > > >
> > > > > >Both peers have 1 second of DATA messages backed up in queue to
> be
> > > > > >transported
> > > > > >by SCTP.  When one peer receives a message, it responds
> immediately.
> > > > > >However,
> > > > > >because the DATA-ACK goes in stream 1, it will have to wait 1
> seconds
> > > > to be
> > > > > >delivered to the peer.  The messages received are already 1
> second
> > > > old, so
> > > > > >the
> > > > > >DATA-ACK will arrive at the peer 2 seconds after the message
> was
> > > > sent.  If
> > > > > >T7
> > > > > >is 1.2 seconds, this link wll fail due to excessive delay of
> > > > > >acknowledgement,
> > > > > >causing changeover and increased loss of data in ther SS7
> network.
> > > > If
> > > > > >acknowledgements are sent on stream 0, a different queue
> applies and
> > > > SCTP
> > > > > >can
> > > > > >deliver DATA-ACKs ahead of the data.  Also the expediting
> nature for
> > > > stream
> > > > > >0
> > > > > >of some SCTP implementations could be utilized.  In that case
> the
> > > > link will
> > > > > >not fail and failure detection has dropped to a about 1.0
> seconds
> > > > from 2.0
> > > > > >seconds.
> > > > > >
> > > > > >Consider that SCTP SACKs can be delayed about 200ms (or
> sometimes
> > > > every
> > > > > >other
> > > > > >message) and then they are sent immediately.  If M2PA
> acknowledges
> > > > messages
> > > > > >immediately, they are still queued in SCTP and may take some
> time to
> > > > reach
> > > > > >the
> > > > > >other end.
> > > > > >
> > > > > >Given that bundling is performed by SCTP (Nagle/Minshall), and
> M2PA
> > > > > >acknowledgement indicates successful delivery to MTP3 rather
> than
> > > > > >successful
> > > > > >receipt, it is best if M2PA does not delay at all.
> > > > > >
> > > > > >Because of the effect described above, we should have probably
> kept a
> > > > > >separate
> > > > > >DATA-ACK message that was sent on stream 0.  That would have
> also
> > > > relieved
> > > > > >our
> > > > > >problems with LSB, LSBE, LSPO, and LSPR because the
> acknowledgements
> > > > would
> > > > > >be
> > > > > >in the same stream as these messages that indicate delay or
> > > > withholding of
> > > > > >acknowledgement.
> > > > > >
> > > > > >So, you see, MTP Level 2 does delay acknowledgements, after
> sending
> > > > SIB or
> > > > > >SIPO.  The rest of the time they are immediate.  For an M2PA
> > > > implementation
> > > > > >to delay acknowledgement without sending LSB or LSPO is to
> court
> > > > failling
> > > > > >links due to excessive delay of acknowledgement.  MTP Level 3
> is
> > > > especially
> > > > > >succeptable to catastrophic cascade failures due to link
> failures
> > > > under
> > > > > >excessive delay of acknowledgement because, upon changeover,
> MTP
> > > > Level 3
> > > > > >transfers large buffers to the next link (which fails for the
> same
> > > > reason)
> > > > > >and then adds them all to the next link (which fails for the
> same
> > > > reason)
> > > > > >etc.  M2PA must meet MTP3's needs.  It cannot harm the network
> > > > because it
> > > > > >is an SCTP ULP, not a transport protocol.
> > > > > >
> > > > > >That said, send them ever other received message if you would
> like.
> > > > The
> > > > > >proposed text said "immediately" and did not say "before
> processing
> > > > any
> > > > > >other received message".  Just don't delay.  So, if you can
> process
> > > > > >20 received message in a batch, acknowledge them with one
> DATA-ACK.
> > > > Just
 > > > > > >don't go away and wait for the next received message before
> sending
> > > > it.
> > > > > >But in the wild that won't happen, because DATA is moving in
> both
> > > > > >directions at about the same rate.
> > > > > >
> > > > > >Perhaps you would prefer the original text that said "SHOULD"
> and
> > > > > >"promptly".
> > > > > >
> > > > > >--brian
> > > > > >
> > > > > >
> > > > > >Nitin Vairagare wrote:
> > > > > >(Fri, 26 Sep 2003 17:39:15)
> > > > > >
> > > > > >
> > > > > >>Javier/Brian,
> > > > > >>
> > > > > >>We need to understand that the underlying infrastructure for
> > > > > >>traditional ss7 links (56/64kbps or HSL 2.048Mbps) is
> different
> > > > > >>from the M2PA. In most of the cases we have much more
> bandwidth
> > > > > >>available for M2PA. At the same time we do not have stringent
> > > > > >>constraints for declaring bad link in absence of FISUs or
> > > > > >>immediate ACK.
> > > > > >>
> > > > > >>The SCTP is already doing Acks for every other message in
> absence of
> > > > > >>user data messages. So not sending M2PA Ack for 200Ms or till
> 8
> > > > messages
> > > > > >>is not going to prevent SCTP from generating that extra SACK
> > > > traffic.
> > > > > >>Instead we should take the advantage and synchronize the M2PA
> with
> > > > > >>underlying SCTP. We should be able to use the same procedure
> as the
> > > > SCTP
> > > > > >>
> > > > > >>and prevent SCTP from generating that extra SACK.
> > > > > >>
> > > > > >>So, I think what M2PA should do is, in absence of any User
> > > > > >>Data traffic generate ACK for every other received packet. If
> no
> > > > other
> > > > > >>Packet is received then the timeout should generate the ACK.
> The
> > > > timeout
> > > > > >>
> > > > > >>Value should be set sufficiently less than SCTP Receive timer
> so
> > > > that
> > > > > >>M2PA generates the ACK (which is user data for SCTP) before
> SCTP
> > > > > >>generates SACK.
> > > > > >>
> > > > > >>Regards,
> > > > > >>Nitin
> > > > > >>
> > > > > >>-----Original Message-----
> > > > > >>From: Javier Kim [mailto:[email-masked]]
> > > > > >>Sent: Friday, September 26, 2003 4:26 PM
> > > > > >>To: [email-masked]
> > > > > >>Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue (fwd)
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>Date: Fri, 26 Sep 2003 09:29:20 -0500
> > > > > >>>
> > > > > >>>
> > > > > >>Hi all,
> > > > > >>
> > > > > >>
> > > > > >>We seem to be having a problem in resolving a clarification of
> the
> > > > ACK
> > > > > >>procedure for M2PA.  What is at stake is some fairly ordinary
> > > > concerns
> > > > > >>for the regular or exceptional operating situations for the
> > > > operation of
> > > > > >>the protocol.  Both regular and exceptional protocol
> situations must
> > > > be
> > > > > >>covered, but an unreasonable burden of overhead should not be
> > > > introduced
> > > > > >>into the standard at this time (or any time).  Particularly
> changes
> > > > > >>should
> > > > > >>not be done for no or negligible benefit.
> > > > > >>
> > > > > >>There is a proposal to send ACKs with ordinary data MSUs or in
> the
> > > > > >>absence
> > > > > >>of outbound data MSUs, ACK with an zero-length MSU after
> reception
> > > > > >>of at most 8 received MSUs or the passage of 200mS whichever
> comes
> > > > > >>first.
> > > > > >>
> > > > > >>With respect to the recent remarks concerning the pressing
> need for
> > > > > >>immediate M2PA acknowledgment packets, the comment is largely
> > > > without
> > > > > >>insight into how real protocol stacks work in real time.  When
> > > > receiving
> > > > > >>an MSU, the majority of cases stacks have no queued nor unsent
> > > > outbound
> > > > > >>MSUs.
> > > > > >>Therefore nearly all received MSUs would result in a needless
> ACKs
> > > > were
> > > > > >>they to be required IMMEDIATELY.  However, typically within
> > > > microseconds
> > > > > >>an MTP3 or higher layer response will likely arrive at M2PA
> that can
> > > > > >>carry the
> > > > > >>same ACK information in a user content carrying MSU (obviating
> the
> > > > > >>separate
> > > > > >>ACK).
> > > > > >>
> > > > > >>The proposal to always ACK when the M2PA layer has no data
> waiting
> > > > to
> > > > > >>send is un-insightful of this last point and therefore
> "wastes" the
> > > > > >>link and host bandwidth by not postponing the ACK a very short
> > > > interval.
> > > > > >>Further the writer confuses the situation by stating "that
> delaying
> > > > ACKs
> > > > > >>would degrade M2PA...".  This couldn't be further from the
> truth.
> > > > It is
> > > > > >>precisely the same reason that SCTP delays SACKs (so that
> > > > immediately
> > > > > >>forthcoming response DATA chunks may carry a SACK) to not
> waste
> > > > > >>bandwidth
> > > > > >>and CPU perturbation.  There is no loss and no degradation in
> a
> > > > short
> > > > > >>delay with only a few intervening received MSUs until a
> response
> > > > (which
> > > > > >>is almost surely forthcoming) arrives.  The savings to M2PA
> and the
> > > > > >>underlying machine is very substantial (up to 50% reduction of
> > > > overhead)
> > > > > >>and the most of the unlikely penalty is 1 to 8 MSUs stored in
> the
> > > > > >>sending
> > > > > >>host's retransmit buffer pending retrieval in the rare event
> of link
> > > > > >>loss and changeover.
> > > > > >>
> > > > > >>The writer points to degradation.  Where is the degrading?  At
> the
> > > > worst
> > > > > >>case (I suggest a brief review of mini-max principles)  0-7
> messages
> > > > can
> > > > > >>be retrieved rather quickly by the sender.  However, of
> significant
> > > > > >>interest to protocol designers is the average or nominal case
> of
> > > > > >>routine operation.  Therefore, to saddle M2PA  with a certain
> 30-50%
> > > > > >>packet overhead (IMMEDIATE acknowledgment overhead) forever is
> a
> > > > real
> > > > > >>and certain degradation.
> > > > > >>
> > > > > >>Best regards,
> > > > > >>
> > > > > >>Javier
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>Javier,
> > > > > >>>
> > > > > >>>200ms is too long.  Waiting 1 received message is too long.
> The
> > > > text
> > > > > >>>
> > > > > >>>
> > > > > >>in
> > > > > >>
> > > > > >>
> > > > > >>>M2PA-09 attempts to state the differences between M2PA and
> Q.703
> > > > with
> > > > > >>>regards to positive acknowledgment.  Q.703/5.2.3 says:
> > > > > >>>
> > > > > >>>  "The receiving signalling link terminal acknowledges the
> > > > acceptance
> > > > > >>>
> > > > > >>>
> > > > > >>of
> > > > > >>
> > > > > >>
> > > > > >>>   one or more message signal units by assigning the forward
> > > > sequence
> > > > > >>>   number value of the latest accepted message signal until
> to the
> > > > > >>>   backward sequence number of the next signalling unit sent
> in the
> > > > > >>>
> > > > > >>>
> > > > > >>next
> > > > > >>
> > > > > >>
> > > > > >>>   signal unit sent in the opposite direction."
> > > > > >>>
> > > > > >>>Now, Q.703 has busy transmitters, so if there are no MSUs
> available
> > > > > >>>
> > > > > >>>
> > > > > >>for
> > > > > >>
> > > > > >>
> > > > > >>>transmission in the opposite direction, then the next FISU to
> be
> > > > sent
> > > > > >>>will carry the acknowledgment.  This means that the mean
> delay
> > > > before
> > > > > >>>emission of an acknowledgment is the mean of the emission
> time for
> > > > an
> > > > > >>>
> > > > > >>>
> > > > > >>SU
> > > > > >>
> > > > > >>
> > > > > >>>in the opposite direction.  For a 64kbs link that is idle in
> the
> > > > > >>>opposite direction with 1 flag between FISUs is about 375
> > > > microseconds
> > > > > >>>(yes, MICROseconds).  Because the delay depends on SU
> emission time
> > > > > >>>only, the delay for a 2.048Mbps Annex A link (idle in the
> opposite
> > > > > >>>direction) is 11.7 microseconds.  The mean emission times and
> the
> > > > > >>>acknowledgment delay associated with mean emission times
> based on
> > > > MSU
> > > > > >>>size and Erlang loading of a signalling link are considered
> in the
> > > > > >>>queuing model for MTP presented in Q.706.  Queuing models
> (Q.706)
> > > > for
> > > > > >>>MTP assume 30ms loop delay for terrestrial links INCLUDING
> > > > PROCESSING
> > > > > >>>TIME AT THE SIGNALLING TERMINAL (caps for emphasis).
> > > > > >>>
> > > > > >>>If a Q.703 (or Annex A) link waited 200ms to acknowledge
> receipt of
> > > > an
> > > > > >>>MSU it would destroy the usability of the link for use with
> Q.704.
> > > > So
> > > > > >>>what makes you think that 200ms is any better than the 500ms
> > > > > >>>
> > > > > >>>
> > > > > >>experienced
> > > > > >>
> > > > > >>
> > > > > >>>in inter-op testing?  Either would make an M2PA link
> unsuitable for
> > > > > >>>replacement of even a 64kbps Q.703 link, regardless of the
> > > > performance
> > > > > >>>of the underlying SCTP transport.
> > > > > >>>
> > > > > >>>Back to Q.703/5.2.3 above and M2PA-09, M2PA-09 says:
> > > > > >>>
> > > > > >>>  "If there is no other User Data messages to be sent when
> there is
> > > > a
> > > > > >>>   message to acknowledge, M2PA SHOULD send a User Data
> message
> > > > with
> > > > > >>>
> > > > > >>>
> > > > > >>no
> > > > > >>
> > > > > >>
> > > > > >>>   data payload.  The FSN for this empty User Data message is
> not
> > > > > >>>   incremented. It MUST contain the same FSN as the most
> recently
> > > > sent
> > > > > >>>   User Data message containing Data. This message SHOULD be
> sent
> > > > > >>>   promptly in order to prevent poor SS7 performance."
> > > > > >>>
> > > > > >>>This is an attempt to mimic the passage from Q.703/5.2.3
> above
> > > > given
> > > > > >>>
> > > > > >>>
> > > > > >>the
> > > > > >>
> > > > > >>
> > > > > >>>consideration that M2PA does not have a busy transmitter
> (i.e. does
> > > > > >>>
> > > > > >>>
> > > > > >>not
> > > > > >>
> > > > > >>
> > > > > >>>idle FISUs).  So the idea is to say that the acknowledgment
> goes
> > > > out
> > > > > >>>
> > > > > >>>
> > > > > >>on
> > > > > >>
> > > > > >>
> > > > > >>>the next DATA message available for transmission (to SCTP)
> and that
> > > > if
> > > > > >>>one is not immediately available for transmission (to SCTP),
> then a
> > > > > >>>DATA-ACK message must be generated and transmitted (to SCTP).
> > > > > >>>
> > > > > >>>So, I disagree strongly with any statement that would give
> one the
> > > > > >>>impression that waiting any amount of time is acceptable.
> > > > > >>>
> > > > > >>>Considering this, I don't see a problem with rewording the
> passage
> > > > > >>>
> > > > > >>>
> > > > > >>from
> > > > > >>
> > > > > >>
> > > > > >>>M2PA-09 as follows:
> > > > > >>>
> > > > > >>>  "When there is a message to acknowledge, M2PA MUST
> acknowledge
> > > > the
> > > > > >>>   message with the next User Data message sent.  If there is
> no
> > > > User
> > > > > >>>   Data message available to be sent when there is a message
> to
> > > > > >>>   acknowledge, M2PA MUST generate and send a User Data
> message
> > > > with
> > > > > >>>
> > > > > >>>
> > > > > >>no
> > > > > >>
> > > > > >>
> > > > > >>>   data payload, without delay.  The FSN for this empty User
> Data
> > > > > >>>   message is not incremented. It MUST contain the same FSN
> as the
> > > > > >>>
> > > > > >>>
> > > > > >>most
> > > > > >>
> > > > > >>
> > > > > >>>   recently sent User Data message containing Data."
> > > > > >>>
> > > > > >>>I believe that makes the statements be closer to the effect
> of the
> > > > > >>>statements in Q.703.  An implementation that artificially
> waits 2ms
> > > > to
> > > > > >>>acknowledge a message is in violation of both.
> > > > > >>>
> > > > > >>>So, you see, stating 200ms would not improve M2PA, it would
> degrade
> > > > > >>>
> > > > > >>>
> > > > > >>it.
> > > > > >>
> > > > > >>
> > > > > >>>It was always the intention that M2PA generate a DATA-ACK to
> carry
> > > > the
> > > > > >>>acknowledgment that Q.703 would carry in the next outbound
> FISU.
> > > > If
> > > > > >>>
> > > > > >>>
> > > > > >>you
> > > > > >>
> > > > > >>
> > > > > >>>can propose better language to that effect, please send it
> without
> > > > > >>>
> > > > > >>>
> > > > > >>delay
> > > > > >>
> > > > > >>
> > > > > >>>;)
> > > > > >>>But waiting even so much as 1ms, or even 1 inbound message,
> to
> > > > > >>>
> > > > > >>>
> > > > > > > generate
> > > > > >
> > > > > >
> > > > > >>>an acknowledgment is IMO unacceptable.
> > > > > >>>
> > > > > >>>On the other side, the sender had better be prepared to
> buffer T7
> > > > > >>>
> > > > > >>>
> > > > > >>worth
> > > > > >>
> > > > > >>
> > > > > >>>of messages at maximum throughput or institute N2 RTB full
> and
> > > > Q.704
> > > > > >>>transmission congestion procedures in conformance with the
> portions
> > > > of
> > > > > >>>Q.703 that are unchanged by M2PA, because it may take SCTP
> just
> > > > less
> > > > > >>>than T7 to deliver the ack.  (See test case 3.8.3 "Check RTB
> full"
> > > > in
> > > > > >>>draft-bidulock-m2pa-test-04.txt and test case Q.781/8.3.)  At
> > > > 20Mbps
> > > > > >>>effective throughput and 64 byte User Data messages with a
> 1.0
> > > > second
> > > > > >>>T7, that would mean buffering about 40,000 messages awaiting
> ack in
> > > > > >>>
> > > > > >>>
> > > > > >>the
> > > > > >>
> > > > > >>
> > > > > >>>RTB or instituting RTB full and Q.704 transmission congestion
> > > > > >>>
> > > > > >>>
> > > > > >>procedures
> > > > > >>
> > > > > >>
> > > > > >>>before that point (setting N2 < 40,000).
> > > > > >>>
> > > > > >>>Taking the link out of service at 1500 messages isn't
> acceptable
> > > > > >>>
> > > > > >>>
> > > > > >>either.
> > > > > >>
> > > > > >>
> > > > > >>>If your RTB holds a maximum of 1500 messages, set N2 to a
> maximum
> > > > of
> > > > > >>>1500.  If your RTB is byte limited instead of message
> limited, use
> > > > N1.
> > > > > >>>Set your Q.704 transmission congestion thresholds based on
> TB,
> > > > TB/RTB
> > > > > >>>
> > > > > >>>
> > > > > >>or
> > > > > >>
> > > > > >>

> > > > > >>>RTB occupancy appropriately as well to signal congestion
> before
> > > > > >>>congestion discard occurs.  (Note that with the "Check RTB
> Full"
> > > > test
> > > > > >>>cases, the link must remain in service.)
> > > > > >>>
> > > > > >>>--brian
> > > > > >>>
> > > > > >>>Javier Kim wrote:
> > > > > >>>(Thu, 25 Sep 2003 18:01:54)
> > > > > >>>
> > > > > >>>
> > > > > >>>>Brian,
> > > > > >>>>
> > > > > >>>>The proposed text is offered for section 4.2.1. Are you
> suggesting
> > > > > >>>>
> > > > > >>>>
> > > > > >>to
> > > > > >>
> > > > > >>
> > > > > >>>>add Q.2110(MaxPD, etc) style method in the M2PA draft?
> > > > > >>>>
> > > > > >>>>200ms is proposed to set maximum time for INFO_TRANSFER
> state, not
> > > > > >>>>
> > > > > >>>>
> > > > > >>in
> > > > > >>
> > > > > >>
 > > > > > >>>LPO
> > > > > >>>
> > > > > >>>
> > > > > >>>>or any other exceptional states, which should be discussed
> > > > elsewhere
> > > > > >>>>
> > > > > >>>>
> > > > > >>>in
> > > > > >>>
> > > > > >>>
> > > > > >>>>the draft anyway.  Rationale is that in one hand, we don't
> want
> > > > > >>>>
> > > > > >>>>
> > > > > >>>penalize
> > > > > >>>
> > > > > >>>
> > > > > >>>>implementaions that wish to wait for a reasonable time for
> > > > ourgoing
> > > > > >>>>MSUs from MTP3, and  the other hand, we don't want to
> accumulate
> > > > too
> > > > > >>>>
> > > > > >>>>
> > > > > >>>many
> > > > > >>>
> > > > > >>>
> > > > > >>>>MSUs queued in the re-transmission queue either. The
> proposed text
> > > > > >>>>
> > > > > >>>>
> > > > > >>>will
> > > > > >>>
> > > > > >>>
> > > > > >>>>allow to send MSU_ACK as frequently as or as fast as one
> elects to
> > > > > >>>>
> > > > > >>>>
> > > > > >>do
> > > > > >>
> > > > > >>
> > > > > >>>so. I
> > > > > >>>
> > > > > >>>
> > > > > >>>>believe that 20 or 30ms is too short.  We don't want to
> agrevate
> > > > > >>>>
> > > > > >>>>
> > > > > >>>throughput
> > > > > >>>
> > > > > >>>
> > > > > >>>>by specifying shorter timer than SCTP's.  I welcome your
> porposal
> > > > > >>>>
> > > > > >>>>
> > > > > >>for
> > > > > >>
> > > > > >>
> > > > > >>>>reasonable timer value.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> The actual event experienced during the plugtest 'forced'
> us to
> > > > > >>>>
> > > > > >>>>
> > > > > >>wait
> > > > > >>
> > > > > >>
> > > > > >>>>500ms.  Nobody violated any rule described in the draft v09,
> it
> > > > led
> > > > > >>>>
> > > > > >>>>
> > > > > >>to
> > > > > >>
> > > > > >>
> > > > > >>>>unacceptable situation.  How are we going tell that the
> > > > > >>>>
> > > > > >>>>
> > > > > >>implementation
> > > > > >>
> > > > > >>
> > > > > >>>is
> > > > > >>>
> > > > > >>>
> > > > > >>>>sloppy or bad?  As far as I can see,  they have violated
> nothing.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>Without
> > > > > >>>
> > > > > >>>
> > > > > >>>>a specific method, it did not work, and it will not work, no
> > > > matter
> > > > > >>>>
> > > > > >>>>
> > > > > >>>how
> > > > > >>>
> > > > > >>>
> > > > > >>>>many times or how loudly we repeat the word "promptly".
> > > > > >>>>
> > > > > >>>>Yet, I need to hear one compelling reason why we don't want
> to
> > > > > >>>>
> > > > > >>>>
> > > > > >>improve
> > > > > >>
> > > > > >>
> > > > > >>>the
> > > > > >>>
> > > > > >>>
> > > > > >>>>draft by adding a simple and straight forward rule.  A
> protocol
> > > > > >>>>
> > > > > >>>>
> > > > > >>>without
> > > > > >>>
> > > > > >>>
> > > > > >>>>specific rule to cover problematic senario like this, only
> promote
> > > > > >>>>on-going IG, and diminish its applicability.  Why bother?
> > > > > >>>>
> > > > > >>>>Best regards,
> > > > > >>>>
> > > > > >>>>Javier
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>_______________________________________________
> > > > > >>Sigtran mailing list
> > > > > >>[email-masked]
> > > > > >>https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >>
> > > > > >>_______________________________________________
> > > > > >>Sigtran mailing list
> > > > > >>[email-masked]
> > > > > >>https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >--
> > > > > >Brian F. G. Bidulock
> > > > > >[email-masked]
> > > > > >http://www.openss7.org/
> > > > > >
> > > > > >_______________________________________________
> > > > > >Sigtran mailing list
> > > > > >[email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >_______________________________________________
> > > > > >Sigtran mailing list
> > > > > >[email-masked]
> > > > > >https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Andrew Booth, Software Developer
> > > > > Signaling Systems Group, Performance Technologies
> > > > > 613-237-4344
> > > > >
> > > > > Visit www.pt.com/mailing.html to subscribe to our Packets &
> Signals
> > > > eLetter.
> > > > >
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > >
> > >
>
> --
> 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

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

---

From: Tom George <[email-masked]>
Date: Mon, 06 Oct 2003 16:53:33 -0500

I will try to summarize my thoughts from this discussion.

1. M2PA should not wait 500ms to ack a message (except in cases where it
is required to withhold acks). This causes too many messages to
build up in the peer's retransmit buffer and degrades SS7 performance.
In the example from the plugtest, messages were being transmitted at
3500/sec, so in 500ms there were about 1700 messages in the RTB. If the
link fails, that is too many messages to retrieve for changeover.

2. Putting a 200ms limit on the acknowledgement is not a good solution.
If 1700 messages build up in 500ms, then 680 could build up in 200ms.
This is also a lot of messages to retrieve for changeover. Another
problem with the 200ms limit is that it gives the impression that it is
OK to wait that long, when it isn't. The implementors who claimed that a
500ms wait was compliant will probably claim that a 200ms wait is
compliant if that is the stated limit.

3. Any time limit on the M2PA acks would be very hard to test.

4. Besides the ack delay, there is also delay in the network, delay in
SCTP at each end, etc. The T7 timer is there to determine when
acknowledgements are being excessively delayed, regardless of the reason.

5. The M2PA sending the messages should not rely on an acknowledgement
time limit at the peer to protect against excessive build-up in the RTB.
Even if the peer M2PA acks each message instantly, there can be delay
from other sources. In the absence of transmit congestion controls,
there can be up to
     (max transmission rate) * T7
messages in the RTB. The sender must use transmit congestion procedures
to prevent the build-up of too many messages in the RTB.

6. I am not trying to make up a new way of acking messages for M2PA. I
just want to imitate MTP2. MTP2 sends an ack on the next outgoing MSU,
or, if there is no MSU, FISU. M2PA should work the same way. If there is
an outgoing User Data message, use that to send the ack. If there is not
a User Data message to transmit, generate an empty user data ack message
in place of the FISU that would have been used in MTP2.

7. I do not see a problem with numerous empty ack messages being sent if
the message is acked quickly. If there are no messages queued up to be
sent, then presumably the network is capable of handling an empty user
data message to carry the ack.

8. With all of that said, here is what I would propose to replace the
"promptly" paragraph in 4.2.1. It is very similar to what Brian proposed.

=====
When there is a message to acknowledge, M2PA MUST acknowledge the
message with the next User Data message sent.  If there is no User Data
message available to be sent when there is a message to acknowledge,
M2PA SHOULD generate and send a User Data message with no data payload,
without delay.  (In other words, in the case where MTP2 would
acknowledge a message with a FISU, M2PA SHOULD acknowledge the message
with an empty User Data message.) The FSN for this empty User Data
message is not incremented. It MUST contain the same FSN as the most
recently sent User Data message containing Data. Delaying of
acknowledgements can result in poor SS7 performance.
=====

9. The requirement for generating the empty User Data message is a
SHOULD. A good reason for not following this would be to process several
incoming messages so that they can be acknowledged with one outgoing
message. A bad reason would be to wait 500ms.

10. This is one of those performance-related issues that will be hard to
address until there is some operational experience. If that experience
tells us that the requirements are inadequate, this issue can be
addressed again before M2PA becomes a "standard".

* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Oct 2003 16:16:41 -0600

Tom,

I like your text.  Can we put this to rest with that, at least for
the purpose of advancing the draft?

--brian

Tom George wrote:                                                                      (Mon, 06 Oct 2003 16:53:33)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Javier Kim <[email-masked]>
Date: Tue, 7 Oct 2003 13:00:33 -0700 (PDT)

Dear Tom,

Thank you for your  excellent summary.  It's time to move on. I agree
with you that it is hard to address until there is some real-world
operational experience. I also understand your reluctancy of specifiying
any specific timer limitation or number of MSU received value at present
time. I appreciate your immense patience shown following this debate which
 turned out to be one of the most crucial characteristics for the future
of M2PA protocol, in my opinion.

Let's move on, Thank you, Brian, Jeff, and others for your valuable input.

Best regards,

Javier

On Mon, 6 Oct 2003, Tom George wrote:

> Date: Mon, 06 Oct 2003 16:53:33 -0500
> From: Tom George <[email-masked]>
> Cc: [email-masked]