Subject: Query regarding CONFIRMED address behaviour in SCTP RFC

From: Nagesh <[email-masked]>
Date: Mon, 23 Aug 2010 20:20:15 +0530

Hi Group,
	Greetings. I have a doubt regarding SCTP RFC 4960, section 5.4, it
mentions that any messages should always be sent on the CONFIRMED address
but sending message on UNCONFIRMED address is optional.

	Especially, in the following scenario the association may not be
established, if stack does not implement sending on CONFIRMED address.

	Scenario as below:

Client				Server
------------------------------------------
IP1				IP3

IP2				IP4

	Message sequence as below:
INIT -> IP1 -> IP3
INIT-ACK -> IP3 -> IP1
COOKIE-ECHO -> IP1 -> IP3
After sending COOKIE-ECHO, IP1 goes down, 
COOKIE-ACK -> IP3 -> IP1 is lost
Retransmit COOKIE-ECHO -> IP2 -> IP3
COOKIE-ACK -> IP3 -> IP1 (Reply is always to CONFIRMED address).

Then even after many retransmissions, server will always send COOKIE-ACK to
IP1 (sending only to CONFIRMED address), so finally INIT.MAX.RETRANS is
reached and association gets aborted.

	So, my question is, why sending COOKIE-ACK on UNCONFIRMED address is
OPTIONAL behavior.  Please let me know, if I am missing something here.

Thanks and Regards,
Nagesh.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 23 Aug 2010 17:21:47 +0200

On Aug 23, 2010, at 4:50 PM, Nagesh wrote:

> Hi Group,
> 
>         Greetings. I have a doubt regarding SCTP RFC 4960, section 5.4, it mentions that any messages should always be sent on the CONFIRMED address but sending message on UNCONFIRMED address is optional.
> 
> 
>         Especially, in the following scenario the association may not be established, if stack does not implement sending on CONFIRMED address.
> 
> 
>         Scenario as below:
> 
> Client                          Server
> 
OK, so the client considers IP3 as CONFIRMED.
> After sending COOKIE-ECHO, IP1 goes down,
So the server considers IP1 as CONFIRMED.
> COOKIE-ACK -> IP3 -> IP1 (Reply is always to CONFIRMED address).
I would expect a packet containing the COOKIE-ACK bundled with a HEARTBEAT (including a nonce)
to be sent to IP2, which is UNCONFIRMED. But this is what is described in the third bullet of
the exception list in section 5.4 of RFC 4960.
> 
> 
> Then even after many retransmissions, server will always send COOKIE-ACK to IP1 (sending only to CONFIRMED address), so finally INIT.MAX.RETRANS is reached and association gets aborted.
Using the above, you can establish the association.

Best regards
Michael
> 
> 
>         So, my question is, why sending COOKIE-ACK on UNCONFIRMED address is OPTIONAL behavior.  Please let me know, if I am missing something here.
> 
> Thanks and Regards,
> 
> Nagesh.
>

---

From: Nagesh <[email-masked]>
Date: Tue, 24 Aug 2010 10:02:36 +0530

Hi Michael,
	Yes, by sending COOKIE-ACK bundled with a HEARTBEAT (including a
nonce) on CONFIRMED address (IP2) will solve the problem, but my question
is, why sending COOKIE-ACK + HEARTBEAT is an optional behavior as per the
RFC 4960.

	Snippet from RFC.
A COOKIE ACK MAY be sent to an UNCONFIRMED address, but it MUST be
      bundled with a HEARTBEAT including a nonce.  An implementation
      that does NOT support bundling MUST NOT send a COOKIE ACK to an
      UNCONFIRMED address.

	As per the above text this behavior is "MAY" which is again
optional, I feel this should have been "MUST".

Thanks and Regards,
Nagesh.

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: Monday, August 23, 2010 8:52 PM
To: Nagesh
Cc: [email-masked]; 'prasad'; [email-masked]
Subject: Re: Query regarding CONFIRMED address behaviour in SCTP RFC

> COOKIE-ACK -> IP3 -> IP1 (Reply is always to CONFIRMED address).
I would expect a packet containing the COOKIE-ACK bundled with a HEARTBEAT
(including a nonce)
to be sent to IP2, which is UNCONFIRMED. But this is what is described in
the third bullet of
the exception list in section 5.4 of RFC 4960.
> 
> 
> Then even after many retransmissions, server will always send COOKIE-ACK
to IP1 (sending only to CONFIRMED address), so finally INIT.MAX.RETRANS is
reached and association gets aborted.
Using the above, you can establish the association.

Best regards
Michael
> 
> 
>         So, my question is, why sending COOKIE-ACK on UNCONFIRMED address
is OPTIONAL behavior.  Please let me know, if I am missing something here.

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 24 Aug 2010 09:23:08 +0200

On Aug 24, 2010, at 6:32 AM, Nagesh wrote:

> Hi Michael,
> 
>         Yes, by sending COOKIE-ACK bundled with a HEARTBEAT (including a nonce) on CONFIRMED address (IP2) will solve the problem, but my question is, why sending COOKIE-ACK + HEARTBEAT is an optional behavior as per the RFC 4960.
> 
> 
>         Snippet from RFC.
> 
>         As per the above text this behavior is "MAY" which is again optional, I feel this should have been "MUST".
Hi Nagesh,

the point is that support for bundling (on the sender side) is optional...

Best regards
Michael

---

From: Nagesh <[email-masked]>
Date: Tue, 24 Aug 2010 14:07:35 +0530

Hi Michael,
	Thanks for the reply.

Regards,
Nagesh

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 12:53 PM
To: Nagesh
Cc: [email-masked]; 'prasad'; [email-masked]
Subject: Re: Query regarding CONFIRMED address behaviour in SCTP RFC

Best regards
Michael
> >         Greetings. I have a doubt regarding SCTP RFC 4960, section 5.4,
it mentions that any messages should always be sent on the CONFIRMED address
but sending message on UNCONFIRMED address is optional.
(including a nonce)
the third bullet of
> >         So, my question is, why sending COOKIE-ACK on UNCONFIRMED
address is OPTIONAL behavior.  Please let me know, if I am missing something
here.