Subject: [Sigtran] Something improper with ASP state change procedures.

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 23 Nov 2010 14:36:08 +0000

Hi All,

We are seeing some strange in the M3UA ASP state change procedures.  Please
find the description of the problem below.

ASP                                                              SGP
=======================================
ASPUP               -------------->  Processes ASPUP and sends ASPUP_ACK

Move ASP to
INACTIVE state   <-------------   ASPUP_ACK

SCTP-SACK
for ASPUP_ACK  ------------->  Missed or lost in the network

ASPAC               -------------->  Processes ASPAC and sends ASPAC_ACK

Move ASP to
ACTIVE state      <-------------   ASPAC_ACK

 SCTP-SACK
for ASPAC_ACK  ------------->  Missed or lost again in the network

 Move ASP to
INACTIVE state   <-------------   SCTP layer at SGP retransmits the
ASPUP_ACK, ASPAC_ACK because of lost SACKs.
because of
ASPUP_ACK
in ACTIVE state

SCTP-SACK        ------------->  Reached the SCTP layer of SGP

In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE state
whereas it is not the case.  Since ASP is in INACTIVE state, all the data
packets that were sent by SGP will be dropped (without sending any error
message back to network).  The above problem will lead to a potential
message loss in the network.

Considering the above behavior, I think the state machine should be tuned
accordingly.

Please pass on the comments on this.

Thanks & Regards,
Naveen.

---

From: Dario Filjar <[email-masked]>
Date: Tue, 23 Nov 2010 06:46:53 -0800 (PST)

Hi Naveen,
 
it seems that ASP does not behave correctly after reception of out-of-blue ASP Up Ack message.
According to RFC4666, section 4.3.4.1:
 
"If the ASP receives an unexpected ASP Up Ack message, the ASP should consider itself in the ASP-INACTIVE state. If the ASP was not in the ASP-INACTIVE state, it should send an Error message and then initate procedures to return to its previos state."
 
So in your case, ASP shall initiate ASP Active procedure again after which it will align the state with SGP.
 
BR Dario

--- On Tue, 11/23/10, Naveen Kottapalli <[email-masked]> wrote:

From: Naveen Kottapalli <[email-masked]>
Subject: [Sigtran] Something improper with ASP state change procedures.
To: [email-masked]
Date: Tuesday, November 23, 2010, 3:36 PM

Hi All,
 
We are seeing some strange in the M3UA ASP state change procedures.  Please find the description of the problem below.
 
ASP                                                              SGP
 
Move ASP to
 
SCTP-SACK

Move ASP to

SCTP-SACK

Move ASP to
INACTIVE state   <-------------   SCTP layer at SGP retransmits the ASPUP_ACK, ASPAC_ACK because of lost SACKs.
because of
ASPUP_ACK
in ACTIVE state

In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE state whereas it is not the case.  Since ASP is in INACTIVE state, all the data packets that were sent by SGP will be dropped (without sending any error message back to network).  The above problem will lead to a potential message loss in the network.
 
Considering the above behavior, I think the state machine should be tuned accordingly.

Thanks & Regards,
Naveen.

-----Inline Attachment Follows-----

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

---

From: Andrew Booth <[email-masked]>
Date: Tue, 23 Nov 2010 10:10:04 -0500

Naveen,

The M3UA layer at the ASP should never see this second ASP UP ACK.  The ASP is still active.

From your description, the second ASP UP ACK is an SCTP retransmission.  This means it has the same TSN as the original ASP UP ACK.  The SCTP layer at the ASP should recognize this as a duplicate chunk and should not pass it on to the M3UA layer.

Andrew

[email-masked] wrote: -----

To: [email-masked]
From: Naveen Kottapalli
Sent by: [email-masked]
Date: 11/23/2010 09:36AM
Subject: [Sigtran] Something improper with ASP state change procedures.

Hi All,

ASP                                                              SGP

Move ASP to

SCTP-SACK

Move ASP to

SCTP-SACK

Move ASP to

because of

ASPUP_ACK

in ACTIVE state

Thanks & Regards,
Naveen.

---

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 23 Nov 2010 15:30:11 +0000

The previous state was INACTIVE.  So, the ASP will be moved back to INACTIVE
instead of reactivating.  Is my assumption right?

Yours,
Naveen.

On 23 November 2010 14:46, Dario Filjar <[email-masked]> wrote:

> "If the ASP receives an unexpected ASP Up Ack message, the ASP should
> consider itself in the ASP-INACTIVE state. If the ASP was not in the
> ASP-INACTIVE state, it should send an Error message and then initate
> procedures to return to its previos state."
>
> --- On *Tue, 11/23/10, Naveen Kottapalli <[email-masked]>* wrote:
>
>
> In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE
> state whereas it is not the case.  Since ASP is in INACTIVE state, all the
> data packets that were sent by SGP will be dropped (without sending any
> error message back to network).  The above problem will lead to a potential
> [email-masked]<http://de.mc300.mail.yahoo.com/mc/compose?to=[email-masked]>

---

From: Aditya Sehgal <[email-masked]>
Date: Tue, 23 Nov 2010 21:25:49 +0530

Naveen,
The M3UA layer at the ASP will NOT see those re-transmissions. The SCTP
layer would know that these are re-transmissions (as the TSN would be the
same) and therefore will not pass those messages to M3UA. So, in the
scenario you describe, the state at the ASP would still be ACTIVE.

Regards,
Aditya

On Tue, Nov 23, 2010 at 9:00 PM, Naveen Kottapalli
<[email-masked]>wrote:

> The previous state was INACTIVE.  So, the ASP will be moved back to
> INACTIVE instead of reactivating.  Is my assumption right?
>
> Yours,
> Naveen.
>
>
>> We are seeing some strange in the M3UA ASP state change procedures.
>> Please find the description of the problem below.
>>
>> ASP                                                              SGP

-- 
There are only 10 type of people in this World...Those who understand binary
and those who dont

---

From: "David Laight" <[email-masked]>
Date: Tue, 23 Nov 2010 16:12:01 -0000

The systematic lost packets are probably caused by SCTP ending the data
between an IP address pair other than the one on which the connection
was established, and on which it hasn't successfully sent a heartbeat.
The SCTP stacks I've used seem to do this a lot, but to my mind they
should not, and the observered behaviour ought to be considered a bug.
 
At connection establishment time, SCTP seems to assume that the IP
addresses of one system should be able to send to all the addresses of
the other system, and that any required links are actually working.
This isn't a good assumption to make!
 
Consider the following 3 systems:
 
a) public IP 1.1.1.1, private network 192.168.1.1
 
b1) public IP 1.2.1.1, private network 192.168.1.2 (shared with machine
b2)
b2) public IP 1.2.1.2, private network 192.168.1.3 (shared with machine
b1)
 
An SCTP connection between 'b1' and 'b2' can use either network.
An SCTP connection between 'a' and 'b1' (or 'b2') must only use the
public addresses.
 
It isn't obvious to me how anyone is supposed to know the network
topology well enough to make this work properly.
 
    David

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Naveen Kottapalli
	Sent: 23 November 2010 14:36
	To: [email-masked]
	Subject: [Sigtran] Something improper with ASP state change
procedures.

	Hi All,
	 
	We are seeing some strange in the M3UA ASP state change
procedures.  Please find the description of the problem below.
	 
	ASP
SGP
	=======================================
	ASPUP               -------------->  Processes ASPUP and sends
ASPUP_ACK
	 
	Move ASP to
	 
	SCTP-SACK
	 
	ASPAC               -------------->  Processes ASPAC and sends
ASPAC_ACK
	 
	Move ASP to
	 
	SCTP-SACK
	for ASPAC_ACK  ------------->  Missed or lost again in the
network
	 
	Move ASP to
	INACTIVE state   <-------------   SCTP layer at SGP retransmits
the ASPUP_ACK, ASPAC_ACK because of lost SACKs.
	because of
	ASPUP_ACK
	in ACTIVE state

	In the above behavior the M3UA at SGP thinks that the ASP is in
ACTIVE state whereas it is not the case.  Since ASP is in INACTIVE
state, all the data packets that were sent by SGP will be dropped
(without sending any error message back to network).  The above problem
will lead to a potential message loss in the network.
	 
	Considering the above behavior, I think the state machine should
be tuned accordingly.

	Thanks & Regards,
	Naveen.