Hi Wei,
thanks.
Best regards
Michael
On Oct 14, 2008, at 2:30 AM, Wei Yongjun wrote:
Michael Tüxen wrote:
Hi Wei,
this is an RFC 4960 issue.
Can you bring this up on tsvwg@xxxxxxxx?
I had posted a query to tsvwg@xxxxxxxxx Link is:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg08653.html
Thanks a lot.
Best regards
Michael
On Oct 13, 2008, at 5:25 AM, Wei Yongjun wrote:
Hi Vlad:
Hi Wei
If I can't take that without a patch that processes SHUTDOWN
chunks in
SHUTDOWN_RECEIVED state.
The problem is that if B in your example has more data to send,
it will ignore subsequent SHUTDOWN chunks. If A uses only
SHUTDOWNS
to acknowledge data, then this would results us ignoring acks and
retransmitting and eventually ABORTING the association.
I think the current kernel has the same problem when process
SHUTDOWN in
ESTABLISHED state:
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<----------- DATA (TSN=1)
<----------- DATA (TSN=2)
SHUTDOWN(TSN=1) ------------> enter SHUTDOWN-RECEIVED state
<----------- DATA (TSN=2)
SACK(TSN=2) ------------>
SHUTDOWN(TSN=2) ------------> discard
I have not test it, and check it later.
RFC4960 said:
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it
MUST NOT
send a SHUTDOWN in *response to a ULP request*, and should
*discard*
subsequent SHUTDOWN chunks.
The old RFC 2960 said:
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA
chunk(s)
*with a SACK*, a SHUTDOWN chunk, and restart the T2-shutdown
timer. If
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
entering the SHUTDOWN-ACK-SENT state. If the timer expires, the
endpoint must re-send the SHUTDOWN ACK.
The old RFC2960 force to send a sack to the DATA sender, so after
received the
sack, the assoc can be shutdown correctly.
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<----------- DATA (TSN=1)
<----------- DATA (TSN=2)
SHUTDOWN(TSN=1) ------------> enter SHUTDOWN-RECEIVED state
<----------- DATA (TSN=2)
SHUTDOWN(TSN=2) ------------> discard
SACK(TSN=2) ------------> accept
<----------- SHUTDOWN-ACK
SACK in SHUTDOWN-RECEIVED state will cause a SHUTDOWN-ACK be sent,
if
the SACKcan ack all of the outstanding DATA chunks.
But new RFC 4960 said:
While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST
immediately respond to each received packet containing one or more
DATA chunks with *a SHUTDOWN chunk* and restart the T2-shutdown
timer.
If a SHUTDOWN chunk by itself cannot acknowledge all of the
received
DATA chunks (i.e., there are TSNs that can be acknowledged that are
larger than the cumulative TSN, and thus gaps exist in the TSN
sequence), or if duplicate TSNs have been received, then a SACK
chunk
MUST also be sent.
This maybe wrong since the SACK will not send if the SHUTDOWN
chunk can
acknowledge all of the received DATA chunks, and SHUTDOWN chunk is
discard
in SHUTDOWN-RECEIVED state.
We need to fix RFC4960, either force to send SACK in SHUTDOWN-SENT
state
or accept the SHUTDOWN in SHUTDOWN-RECEIVED state. (The current code
is force send SACK)
-vlad
Wei Yongjun wrote:
If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint
should enter
the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack
field of
the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN
chunk can
acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be
sent.
But now endpoint just silently discarded the SHUTDOWN chunk.
SHUTDOWN received in SHUTDOWN-PENDING state can happend when
the last
SACK is lost by network, or the SHUTDOWN chunk can acknowledge
all of
the received DATA chunks. The packet sequence(SACK lost) is
like this:
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<----------- DATA
<--- shutdown
Enter SHUTDOWN-PENDING state
SACK ----lost---->
SHUTDOWN(*1) ------------>
<----------- SHUTDOWN-ACK
(*1) silently discarded now.
This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as
the same
as ESTABLISHED state.
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
