Issue with Forward-TSN-Chunks containing high cum_tsn

DISCUSSION Julian Cordes 4 participants 7 messages Jan 17, 2017 – Jan 19, 2017 SCTP protocol

Share & tools

Julian Cordes

author

2017-01-17 13:07 UTC #0 lore raw

When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.

Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt

Marcelo Ricardo Leitner

maintainer

2017-01-17 16:38 UTC #1 lore raw

Quoted 4 lines · Julian Cordes

When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.

You mean, with the cum_tsn specified on the *injected* FORWARD-TSN. Is that so?

Quoted 3 lines

Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt

Xin Long

maintainer

2017-01-18 06:01 UTC #2 lore raw

In reply to Julian Cordes

Quoted 8 lines · Marcelo Ricardo Leitner

Quoted 4 lines · Julian Cordes
When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.
You mean, with the cum_tsn specified on the *injected* FORWARD-TSN. Is that so?

from the test script
+0.0 < sctp: FORWARD_TSN[cum_tsn™999, ids=[{1, 1}]] I think so.

But 99999 is so high relative to the base_tsn of tsnmap, it overflowed tsnmap, such a big gap is disallowed in linux sctp. it has to drop this packet.

        /* Verify that we can hold this TSN and that it will not
         * overlfow our map
         */
        if (!TSN_lt(tsn, map->base_tsn + SCTP_TSN_MAP_SIZE))
                return -1;

Hi, Julian, maybe you can improve your script by using a lower value for linux.

Quoted 10 lines

Quoted 4 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Michael Tuexen

2017-01-18 14:53 UTC #3 lore raw

In reply to Julian Cordes

Quoted 20 lines · Xin Long

Quoted 8 lines · Marcelo Ricardo Leitner
Quoted 4 lines · Julian Cordes
When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.
You mean, with the cum_tsn specified on the *injected* FORWARD-TSN. Is that so?
from the test script
+0.0 < sctp: FORWARD_TSN[cum_tsn™999, ids=[{1, 1}]] I think so.
But 99999 is so high relative to the base_tsn of tsnmap, it overflowed tsnmap, such a big gap is disallowed in linux sctp. it has to drop this packet.

Quoted 8 lines

       /* Verify that we can hold this TSN and that it will not
        * overlfow our map
        */
       if (!TSN_lt(tsn, map->base_tsn + SCTP_TSN_MAP_SIZE))
               return -1;

Hi, Julian, maybe you can improve your script by using a lower value for linux.

but this would mean that Linux only supports the peer skipping some small number of TSN's. Isn't this a limitation of the implementation?

Best regards
Michael

Quoted 15 lines

Quoted 11 lines
Quoted 5 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Xin Long

maintainer

2017-01-18 15:47 UTC #4 lore raw

In reply to Julian Cordes

Quoted 26 lines · Michael Tuexen

Quoted 26 lines · Xin Long
Quoted 8 lines · Marcelo Ricardo Leitner
Quoted 4 lines · Julian Cordes
When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.
You mean, with the cum_tsn specified on the *injected* FORWARD-TSN. Is that so?
from the test script
+0.0 < sctp: FORWARD_TSN[cum_tsn™999, ids=[{1, 1}]] I think so.
But 99999 is so high relative to the base_tsn of tsnmap, it overflowed tsnmap, such a big gap is disallowed in linux sctp. it has to drop this packet.
       /* Verify that we can hold this TSN and that it will not
        * overlfow our map
        */
       if (!TSN_lt(tsn, map->base_tsn + SCTP_TSN_MAP_SIZE))
               return -1;

Quoted 4 lines

Quoted 2 lines
Hi, Julian, maybe you can improve your script by using a lower value for linux.
but this would mean that Linux only supports the peer skipping some small number of TSN's. Isn't this a limitation of the implementation?

not really, there is map->base_tsn, it will grow when the tsn has been sacked. like tsn€00 and below 8000 have been sacked, map->base_tsn could be 8000, then the map range would be 8000 ~ 8000 + SCTP_TSN_MAP_SIZE.

But the test case sent tsn=1, then try to skip tsn™999, that's really not a normal case.

and to set SCTP_TSN_MAP_SIZE@96 for reasons:

/* Guess at how big to make the TSN mapping array.
* We guarantee that we can handle at least this big a gap between the
* cumulative ACK and the highest TSN. In practice, we can often
* handle up to twice this value.
*
* NEVER make this more than 32767 (2^15-1). The Gap Ack Blocks in a
* SACK (see section 3.3.4) are only 16 bits, so 2*SCTP_TSN_MAP_SIZE
* must be less than 65535 (2^16 - 1), or we will have overflow
* problems creating SACK's.
*/
#define SCTP_TSN_MAP_INITIAL BITS_PER_LONG
#define SCTP_TSN_MAP_INCREMENT SCTP_TSN_MAP_INITIAL
#define SCTP_TSN_MAP_SIZE 4096

Quoted 19 lines

Best regards
Michael
Quoted 15 lines
Quoted 11 lines
Quoted 5 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Michael Tuexen

2017-01-18 18:02 UTC #5 lore raw

In reply to Julian Cordes

Quoted 42 lines · Xin Long

Quoted 26 lines · Michael Tuexen
Quoted 26 lines · Xin Long
Quoted 8 lines · Marcelo Ricardo Leitner
Quoted 4 lines · Julian Cordes
When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.
You mean, with the cum_tsn specified on the *injected* FORWARD-TSN. Is that so?
from the test script
+0.0 < sctp: FORWARD_TSN[cum_tsn™999, ids=[{1, 1}]] I think so.
But 99999 is so high relative to the base_tsn of tsnmap, it overflowed tsnmap, such a big gap is disallowed in linux sctp. it has to drop this packet.
      /* Verify that we can hold this TSN and that it will not
       * overlfow our map
       */
      if (!TSN_lt(tsn, map->base_tsn + SCTP_TSN_MAP_SIZE))
              return -1;
Quoted 4 lines
Quoted 2 lines
Hi, Julian, maybe you can improve your script by using a lower value for linux.
but this would mean that Linux only supports the peer skipping some small number of TSN's. Isn't this a limitation of the implementation?
not really, there is map->base_tsn, it will grow when the tsn has been sacked. like tsn€00 and below 8000 have been sacked, map->base_tsn could be 8000, then the map range would be 8000 ~ 8000 + SCTP_TSN_MAP_SIZE.
But the test case sent tsn=1, then try to skip tsn™999, that's really not a normal case.
and to set SCTP_TSN_MAP_SIZE@96 for reasons:

Quoted 13 lines

/* Guess at how big to make the TSN mapping array.
* We guarantee that we can handle at least this big a gap between the
* cumulative ACK and the highest TSN. In practice, we can often
* handle up to twice this value.
*
* NEVER make this more than 32767 (2^15-1). The Gap Ack Blocks in a
* SACK (see section 3.3.4) are only 16 bits, so 2*SCTP_TSN_MAP_SIZE
* must be less than 65535 (2^16 - 1), or we will have overflow
* problems creating SACK's.
*/
#define SCTP_TSN_MAP_INITIAL BITS_PER_LONG
#define SCTP_TSN_MAP_INCREMENT SCTP_TSN_MAP_INITIAL #define SCTP_TSN_MAP_SIZE 4096

That seems OK for dealing with a data transfer not using PR-SCTP. It is fine to drop the packet since the peer will retransmit lower TSNs. However, in the case of PR-SCTP it is perfectly valid that the peer drops up to 2**31-1 TSNs... At least this is my understanding of the protocol...

Best regards
Michael

Quoted 20 lines

Quoted 20 lines
Best regards
Michael
Quoted 15 lines
Quoted 11 lines
Quoted 5 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Xin Long

maintainer

2017-01-19 17:53 UTC #6 lore raw

In reply to Julian Cordes

Quoted 56 lines · Michael Tuexen

Quoted 42 lines · Xin Long
Quoted 26 lines · Michael Tuexen
Quoted 26 lines · Xin Long
Quoted 8 lines · Marcelo Ricardo Leitner
Quoted 4 lines · Julian Cordes
When a FORWARD-TSN-Chunk with a relative high cum-tsn-value is injected then the linux kernel ignores this valid FORWARD-TSN-Chunk. It should instead send an SACK-Chunk where the cum_tsn is equal to the cum_tsn specified in the FORWARD-TSN.
You mean, with the cum_tsn specified on the *injected* FORWARD-TSN. Is that so?
from the test script
+0.0 < sctp: FORWARD_TSN[cum_tsn™999, ids=[{1, 1}]] I think so.
But 99999 is so high relative to the base_tsn of tsnmap, it overflowed tsnmap, such a big gap is disallowed in linux sctp. it has to drop this packet.
      /* Verify that we can hold this TSN and that it will not
       * overlfow our map
       */
      if (!TSN_lt(tsn, map->base_tsn + SCTP_TSN_MAP_SIZE))
              return -1;
Quoted 4 lines
Quoted 2 lines
Hi, Julian, maybe you can improve your script by using a lower value for linux.
but this would mean that Linux only supports the peer skipping some small number of TSN's. Isn't this a limitation of the implementation?
not really, there is map->base_tsn, it will grow when the tsn has been sacked. like tsn€00 and below 8000 have been sacked, map->base_tsn could be 8000, then the map range would be 8000 ~ 8000 + SCTP_TSN_MAP_SIZE.
But the test case sent tsn=1, then try to skip tsn™999, that's really not a normal case.
and to set SCTP_TSN_MAP_SIZE@96 for reasons:
Quoted 13 lines
/* Guess at how big to make the TSN mapping array.
* We guarantee that we can handle at least this big a gap between the
* cumulative ACK and the highest TSN. In practice, we can often
* handle up to twice this value.
*
* NEVER make this more than 32767 (2^15-1). The Gap Ack Blocks in a
* SACK (see section 3.3.4) are only 16 bits, so 2*SCTP_TSN_MAP_SIZE
* must be less than 65535 (2^16 - 1), or we will have overflow
* problems creating SACK's.
*/
#define SCTP_TSN_MAP_INITIAL BITS_PER_LONG
#define SCTP_TSN_MAP_INCREMENT SCTP_TSN_MAP_INITIAL #define SCTP_TSN_MAP_SIZE 4096

Quoted 4 lines

That seems OK for dealing with a data transfer not using PR-SCTP. It is fine to drop the packet since the peer will retransmit lower TSNs. However, in the case of PR-SCTP it is perfectly valid that the peer drops up to 2**31-1 TSNs... At least this is my understanding of the protocol...

got you, we will think about it, thanks :)

Quoted 24 lines

Best regards
Michael
Quoted 20 lines
Quoted 20 lines
Best regards
Michael
Quoted 15 lines
Quoted 11 lines
Quoted 5 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html