On Thu, Jan 19, 2017 at 2:02 AM, Michael Tuexen
<Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
> On 18 Jan 2017, at 16:47, Xin Long <lucien.xin@xxxxxxxxx> wrote:
>>
>> On Wed, Jan 18, 2017 at 10:53 PM, Michael Tuexen
>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>>>> On 18 Jan 2017, at 07:01, Xin Long <lucien.xin@xxxxxxxxx> wrote:
>>>>
>>>> On Wed, Jan 18, 2017 at 12:38 AM, Marcelo Ricardo Leitner
>>>> <marcelo.leitner@xxxxxxxxx> wrote:
>>>>> On Tue, Jan 17, 2017 at 02:07:52PM +0100, Julian Cordes wrote:
>>>>>> 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=99999, 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.
>>> 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=8000 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=99999, that's really not
>> a normal case.
>>
>> and to set SCTP_TSN_MAP_SIZE=4096 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
> 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 :)
>
> Best regards
> Michael
>>
>>>
>>> Best regards
>>> Michael
>>>>
>>>>>
>>>>>>
>>>>>> 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 majordomo@xxxxxxxxxxxxxxx
>>>>> 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 majordomo@xxxxxxxxxxxxxxx
>>>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
