Subject: [Sigtran] What to do if it receives a SACK cold?

From: Jacques Rajchgod <[email-masked]>
Date: Tue, 05 Feb 2002 14:34:51 -0600

Hi, SIGTRAN...

We are in the midst of analyzing and assessing a problem where no clear-cut
M3UA specs exist. Would appreciate opinions.

The problem:

1) An MGC ("a") establishes an SCTP session with an SG ("b") OK. It goes
from "INIT" to "COOKIE" and all is well.
2) A couple of SCTP Heartbeats go-by.
3) The first DATA pack generated by the MGC ("a") is a BUNDLED one,
consisting of a SACK and an ASPUP.
4) The SG ("b"), upon receiving that pack - hangs cold. Does not generate
any error message to the MGC ("a"). All comms are hung dry.
5) A SIGTRAN analyzer shows that the ASPUP was sent OK "a"-to-"b".
6) From the perspective of the MGC ("a"), it has sent an ASPUP and never got
an ACK on that.
7) If one removes the SACK from the BUNDLE, the SG ("b") responds ASPUP_ACK
perfect.

We are debating the following, and would appreciate comments and opinions:

a) A node should not ever hang dry - no matter what is sent to it. An error
should be generated by the receiver ("b") to let the sender ("a") know that
something is wrong.
b) There are no governing M3UA specs on that. Ref: M3UA-10, Section "3.8.1",
Page "54". No error would seemingly be applicable other than "06" -
UNEXPECTED MESSAGE".
c) Error "6" (UNEXPECTED MESSAGE) might be OK to employ since the SACK
should not have been employed by "a" yet, as there had been no DATA Payloads
ever exchanged up to ASPUP time, to ACK via Cumulative TSN.
d) It looks like the SG knew that a SACK was not employable that early, and
needed to react, but just hanged dry. Vendor is saying that no M3UA error
can be employed from list of available errors, and therefore, that it is up
to the MGC to fire-off good messages.
e) Our concern is relative to a Production environment where revenues would
be at stake: A customer should not ever be left hanging dry, especially
since from the perspective of the MGC, an ASPUP was sent and never been
responded-to...

Please kindly advise...
Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

---

From: Jacob Heitz <[email-masked]>
Date: Tue, 05 Feb 2002 12:54:45 -0800

> Jacques Rajchgod wrote:
> 
> Hi, SIGTRAN...
> 
> We are in the midst of analyzing and assessing a problem where no clear-cut M3UA specs exist. Would appreciate opinions.
> 
> The problem:
> 
> 1) An MGC ("a") establishes an SCTP session with an SG ("b") OK. It goes from "INIT" to "COOKIE" and all is well.
> 3) The first DATA pack generated by the MGC ("a") is a BUNDLED one, consisting of a SACK and an ASPUP.
> 4) The SG ("b"), upon receiving that pack - hangs cold. Does not generate any error message to the MGC ("a"). All comms are hung dry.
> 6) From the perspective of the MGC ("a"), it has sent an ASPUP and never got an ACK on that.

"a" sent a data chunk. If it receives no ack, it will retransmit.
Why is the SACK in the bundle an error ?  Does it contain a
bad Cum Ack number ?

> 7) If one removes the SACK from the BUNDLE, the SG ("b") responds ASPUP_ACK perfect.
> 
> a) A node should not ever hang dry - no matter what is sent to it. An error should be generated by the receiver ("b") to let the sender ("a") know that something is wrong.
> b) There are no governing M3UA specs on that. Ref: M3UA-10, Section "3.8.1", Page "54". No error would seemingly be applicable other than "06" - UNEXPECTED MESSAGE".
> c) Error "6" (UNEXPECTED MESSAGE) might be OK to employ since the SACK should not have been employed by "a" yet, as there had been no DATA Payloads ever exchanged up to ASPUP time, to ACK via Cumulative TSN.
> d) It looks like the SG knew that a SACK was not employable that early, and needed to react, but just hanged dry. Vendor is saying that no M3UA error can be employed from list of available errors, and therefore, that it is up to the MGC to fire-off good messages.
> e) Our concern is relative to a Production environment where revenues would be at stake: A customer should not ever be left hanging dry, especially since from the perspective of the MGC, an ASPUP was sent and never been responded-to...
> 
> Please kindly advise...
> 
> Jacques Rajchgod
> MCI Worldcom

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Tue, 05 Feb 2002 15:09:31 -0600

-----Original Message-----
From: Jacob Heitz [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 2:55 PM
To: Jacques Rajchgod
Cc: Sigtran
Subject: Re: [Sigtran] What to do if it receives a SACK cold?

> Jacques Rajchgod wrote:
>
> Hi, SIGTRAN...
>
> We are in the midst of analyzing and assessing a problem where no
clear-cut M3UA specs exist. Would appreciate opinions.

from Jacques:

SACK is considered an error at that point by virtue of the SCTP definitions
at RFC 2960 Section 3.3.4 Page 33:
This section states that a SACK is used to ack received DATA packs. Since
there can be no DATA packs ever exchanged before a successful combo of ASPUP
and a follow-up ASPUP_ACK, the use of a SACK (bundled with ASPUP) is invalid
at this point, matter why the SG attempted to react to it by (incorrectly)
keeping shut...
A SACK can only be used stand-alone or bundled with DATA if there are DATA
payloads to ack via the SACK's Cumulative TSN (Section 1.4, page 10 - SCTP).

Jacques Rajchgod
MCI Worldcom

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 5 Feb 2002 15:20:42 -0600

Jacques,

Please see comments below...

Jacques Rajchgod wrote:                                   (Tue, 05 Feb 2002 14:34:51)
>    1) An MGC ("a") establishes an SCTP session with an SG ("b") OK. It
>    goes from "INIT" to "COOKIE" and all is well.
>    
>    4) The SG ("b"), upon receiving that pack - hangs cold. Does not
>    generate any error message to the MGC ("a"). All comms are hung dry.
>    
>    6) >From the perspective of the MGC ("a"), it has sent an ASPUP and
>    never got an ACK on that.
>    
>    a) A node should not ever hang dry - no matter what is sent to it. An
>    error should be generated by the receiver ("b") to let the sender
>    ("a") know that something is wrong.

True.

>    
>    b) There are no governing M3UA specs on that. Ref: M3UA-10, Section
>    "3.8.1", Page "54". No error would seemingly be applicable other than
>    "06" - UNEXPECTED MESSAGE".

Even if your SCTP hangs, because the MGC does not receive and ASPUP Ack in
response to the ASPUP, the MGC should follow the procedures of section 4.3.4.1
MGC Up Procedures.  Pertinent passages are as follows:

	When the ASP sends an ASP Up message it starts timer T(ack).  If the 
	ASP does not receive a response to an ASP Up message within T(ack), the 
	ASP MAY restart T(ack) and resend ASP Up messages until it receives an 
	ASP Up Ack message.  T(ack) is provisionable, with a default of 2 
	seconds.  Alternatively, retransmission of ASP Up messages MAY be put 
	under control of Layer Management.  In this method, expiry of T(ack) 
	results in an M-ASP_UP confirm primitive carrying a negative 
	indication.  

	The ASP must wait for the ASP Up Ack message before sending any other 
	M3UA messages (e.g., ASP Active or REG REQ).  If the SGP receives any 
	other M3UA messages before an ASP Up message is received (other than 
	ASP Down - see Section 4.3.4.2), the SGP MAY discard them.

>    should not have been employed by "a" yet, as there had been no DATA
>    Payloads ever exchanged up to ASPUP time, to ACK via Cumulative TSN.

It is perfectly legal to bundle a SACK with DATA at any time in RFC 2960.
Rather, this looks like a bug in one of your implementations.  Anyway,
M3UA error messages are not generated directly in response to SCTP protocol
conditions.

>    d) It looks like the SG knew that a SACK was not employable that
>    early, and needed to react, but just hanged dry. Vendor is saying that
>    no M3UA error can be employed from list of available errors, and
>    therefore, that it is up to the MGC to fire-off good messages.

I would suspect an error in the SG SCTP implementation rather than the
M3UA implementation.  Also, I would suspect that the MGC M3UA implementation
would be better to use the optional procedures from section 4.3.4.1 and set
a T(ack) timer when it sends ASPUP and at least report and tear-down the
association when it reattempts too many times.

>    e) Our concern is relative to a Production environment where revenues
>    would be at stake: A customer should not ever be left hanging dry,
>    especially since from the perspective of the MGC, an ASPUP was sent
>    and never been responded-to...

One of the only reasons for sending ASPUP is to check that the peer M3UA
is alive and well.  If no reponse (ASPUP Ack) is received, then obviously
the peer M3UA is dead (wherever the problem has occured: SCTP bugs, network
failure, etc.)  I would question the usability in a production environment
of any implementation exhibiting the characteristics at the SCTP and M3UA
level that your describe here.

To recap:

In this situation RFC 2960 provides for the bundling of SACK in _any_ message
where DATA exists.  SACK may be sent _at_any_time_ that DATA may be sent,
because a peer is always allowed to send SACK to update rwnd.  A number of
implementations at the last interop sent SACK either initially with the first
DATA chunk.  Our implementation even sent SACK bundled with DATA in the
COOKIE ACK (which is also legal).  The SG implementation here IMHO is poorly
designed or has bugs.

IMO the MGC has made some poor design choices or is buggy as well.  The reason
being that, certainly for the production environment, if no ASUP Ack is
returned within a time interval, the implementation should not just hang, it
should at least inform management.

With that said, Jacques, I don't believe that you should be bringing
up vendor management issues on this mailing list.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 5 Feb 2002 15:26:57 -0600

Jacques,

Please see below:

Jacques Rajchgod wrote:                                   (Tue, 05 Feb 2002 15:09:31)
> payloads to ack via the SACK's Cumulative TSN (Section 1.4, page 10 - SCTP).

The statement above is incorrect: (RFC 2960 Section 6.2)

   "A SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data."

An implemetation can always send SACK to update rwnd.  An intelligently
designed implementation should always be prepared to receive SACK with DATA.

In any event, if the SG does not like the SACK, it should ABORT the
association, not hang.  Also, the MGC should not hang, it should inform
management of the lack of receipt of an ASPUP Ack in repsonse to one or
more attempts at ASPUP.

--brian

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