You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and completing the handshake, it uses the I-DATA-Chunk, which should be acceptable, because of section 2.2.1. of sctp-ndata internet draft:
A sender MUST NOT send an I-DATA chunk unless both peers have
indicated its support of the I-DATA chunk type within the Supported
Extensions Parameter as defined in [RFC5061]. If I-DATA support has
been negotiated on an association, I-DATA chunks MUST be used for all
user messages and DATA-chunk MUST NOT be used. If I-DATA support has
not been negotiated on an association, DATA chunks MUST be used for
all user messages and I-DATA chunks MUST NOT be used.
If one outstanding user message is abandoned it uses the I-FORWARD-TSN-Chunk that the other endpoint does not support. It should use the FORWARD-TSN-Chunk i assume. See the following test-case for more details:
You can't use the FORWARD-TSN chunk in combination with the I-DATA chunk. The text in draft-ietf-tsvwg-sctp-ndata-08.txt doesn't seem to explicitly cover this situation. You might want to bring this question up on the [email protected] mailing list. The ID is currently in WG-last call.
Yeah, FORWARD-TSN-Chunk does not make sense because there is no ssn value with the I-DATA-Chunk right?
Should I expect an ERROR-Chunk instead? I have never sent questions to the [email protected] mailing list. Do I have to write a mail to [email protected] with the subject WG-last call to do so?
You can subscribe to the list and then send an e-mail asking about how an implementation should behave when it received an INIT (or INIT-ACK) chunk indicating I-DATA and only FORWARD-TSN support or only DATA and I-FORWARD-TSN.
I guess I would expect I-FORWARD-TSN only be used if both sides indicate support and also indicate I-DATA support. If both sides support I-DATA and one side only FORWARD-TSN, then not PR-SCTP can be used. This is what I would suggest. But we need clear text in the spec.
When an endpoints wants to use the user message interleaving and activates it by calling:
+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_FRAGMENT_INTERLEAVE, [2], 4) = 0
+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_INTERLEAVING_SUPPORTED, {assoc_value=1}, 8) = 0
after receiving an INIT-Chunk like:
INIT[flgs=0, tag=1, a_rwnd=1500, os=16, is=16, tsn=1, FORWARD_TSN_SUPPORTED[], SUPPORTED_EXTENSIONS[types=[FORWARD_TSN, I_DATA]]]
and completing the handshake, it uses the I-DATA-Chunk, which should be acceptable, because of section 2.2.1. of sctp-ndata internet draft:
If one outstanding user message is abandoned it uses the I-FORWARD-TSN-Chunk that the other endpoint does not support. It should use the FORWARD-TSN-Chunk i assume. See the following test-case for more details:
The text was updated successfully, but these errors were encountered: