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

From: "Nitin Vairagare" <[email-masked]>
Date: Tue, 30 Sep 2003 17:30:15 -0500

Brian,

But unfortunately, that's what some one interpreted.. 
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/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Sep 2003 17:16:05 -0600

Nitin,

Nitin Vairagare wrote:                                                               (Tue, 30 Sep 2003 17:30:15)
> 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

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