Micheal,
My question here is different,
If we take a case as below,
SCTP Local SCTP Peer
msg(TSN 100)------------------------>
<------------------------SACK msg(Cum TSN 100)
msg(TSN 101)------------------------->
No SACK for TSN 101
msg(TSN 102)------------------------>
<------------------------SACK msg(Cum TSN 100, GAP Acks start 2, end 2)
msg(TSN 103)------------------------>
<------------------------SACK msg(Cum TSN 100, GAP Acks start 2, end 3)
msg(TSN 101)------------------------>
Again no SACK's for TSN 101.
msg(TSN 104)------------------------>
<------------------------SACK msg(Cum TSN 100, GAP Acks start 2, end 4)
msg(TSN 105)------------------------>
<------------------------SACK msg(Cum TSN 100, GAP Acks start 2, end 5)
This is what the scenario is, where are storing the msgs 102 to 105 even though they are acked.
For the all the msgs having the TSN number more than 100 are queued in the SEND Q even though from TSN No 102 to 105 are Acked in the GAP Acks.
What is purpose behind this? If we get an ACK for the TSN 101, any way we are going to drop all the msgs till TSN 105 from the SEND Q. Do we really need to store the msgs that are acked by GAP Acks?
Please clarify,
Thanks
Manju
Motorola Inc
Manjunatha Shetty K
Phone: 1-847-632-2503
-----Original Message-----
From: Michael Tuexen [mailto:Michael.Tuexen AT micmac.franken.de]
Sent: Friday, January 02, 2004 2:32 PM
To: Shetty K Manjunatha-A1465Z
Cc: discussion AT sctp.de; ajung AT exp-math.uni-essen.de
Subject: Re: [SCTP-Discussion] FW: SCTP...
Manjunatha,
SCTP allows the peer to 'withdraw' an acknowledgement when it is still above the cumulative ack. From RFC 2960:
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk as
available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no retransmit
timer is running for the destination address to which the DATA
chunk was originally transmitted, then T3-rtx is started for
that destination address.
So there is no chance to do free the memory for GAP acked chunks when
you
want to be compliant with RFC 2960.
The only think I can suggest if memory is a problem is that you write a memory management for the sctplib and delete all calls to malloc by
using
some sort of pools (mbufs or whatever...)
Best regards
Michael
On 2. Jan 2004, at 20:58 Uhr, Shetty K Manjunatha-A1465Z wrote:
> Micheal,
> We are using the VxWorks and we don't have unlimited buffers. Please
> let me know if you have any other alternatives.
> Is it not a good idea to drop the messages acked by the peer even
> though one of the lower TSN is not yet acked?
>
> Pls advise
>
> Manjunatha Shetty K
> Phone: 1-847-632-2503
>
>
>
> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen AT micmac.franken.de]
> Sent: Friday, January 02, 2004 12:56 PM
> To: Shetty K Manjunatha-A1465Z
> Cc: discussion AT sctp.de; ajung AT exp-math.uni-essen.de
> Subject: Re: [SCTP-Discussion] FW: SCTP...
>
>
> Manjunatha,
>
> from the chargen_server.c:
>
> SCTP_getAssocDefaults(sctpInstance, &instanceParameters);
> instanceParameters.maxSendQueue = SEND_QUEUE_SIZE;
> SCTP_setAssocDefaults(sctpInstance, &instanceParameters);
>
> This shows how you limit the sendqueue. If you do not do this, the
> sendqueue is unlimited. It is the same as setting it to 0, the
> default.
>
> The implementation works as follows:
> The sctplib always uses malloc if it needs memory. Using this strategy
> no send call will ever block. To provide this feature (needed for the
> chargen
> server, for example) we introduced the sendqueue limit. It is only a
> counter
> which supervises the number of chunks queued. But it is no real memory
> management.
>
> I hope this clarifies things a bit
> Michael
>
> On 2. Jan 2004, at 18:08 Uhr, Shetty K Manjunatha-A1465Z wrote:
>
>> Micheal,
>> Thanks for the reply.
>> What is this option "sctplib without any limits"? Could you please
>> provide me more information on this? You mean we need to increase the
>> size of the stack? Or some thing else? Please advise.
>>
>> Manjunatha Shetty K
>> Phone: 1-847-632-2503
>>
>>
>>
>> -----Original Message-----
>> From: Michael Tuexen [mailto:Michael.Tuexen AT micmac.franken.de]
>> Sent: Thursday, January 01, 2004 12:04 PM
>> To: Shetty K Manjunatha-A1465Z
>> Cc: ajung AT exp-math.uni-essen.de; discussion AT sctp.de
>> Subject: Re: [SCTP-Discussion] FW: SCTP...
>>
>>
>> Using the limited queues we are limiting the resources the sctplib is
>> using. Since all chunks have to be stored until the cumulative TSN
>> acks passes the TSN of the chunk we have to store TSN10 to TSN100.
>> This behaviour is required by SCTP.
>>
>> You can use the sctplib without any limits. Then you can send as much
>> as you like (and memory is available at the host).
>>
>> Best regards
>> Michael
>>
>> On 1. Jan 2004, at 1:43 Uhr, Shetty K Manjunatha-A1465Z wrote:
>>
>>> All,
>>> Any body can help in answer the question below?
>>>
>>> Manjunatha Shetty K
>>> Motorola Inc
>>> Phone: 1-847-632-2503
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Shetty K Manjunatha-A1465Z
>>> Sent: Wednesday, December 31, 2003 5:18 PM
>>> To: 'Michael Tüxen'
>>> Cc: Shetty K Manjunatha-A1465Z
>>> Subject: RE: SCTP...
>>>
>>>
>>> Micheal,
>>>
>>> I have a quick question on SCTP stack. Quick response would really
>>> helpful. If I am transmitting data from TSN 1 to TSN 200. But I am
>>> getting SACK or ACK for all the frames other than say TSN 10. I am
>>> pumping the data at the higher rate. Will my SEND Q will store all
>>> the msgs with TSN value above 10 till I get ACK for this msg or it
>>> will clear off all the msgs from the SEND Q which got ACK from the
>>> PEER.
>>>
>>> Scenario:
>>> SCTP LOCAL SCTP PEER
>>>
>>> Msg(TSN1) ==================>ACKED back
>>> Msg(TSN2)===================> ACKED back ..........................
>>> .....
>>> Msg(TSN10) ===================> NOT RECEIVED (Say Dropped) so no ACK.
>>> ..... Re transmission Msg(TSN10)====================> Dropped, no ACK
>>> ..... Msg(TSN99)====================> ACKED
>>> Msg(TSN100)===================>ACKED
>>> Retransmission Msg(TSN10)===============> ACKED Now!!!!!
>>>
>>> Now the question is what happens to SEND Q? Will store all the
>>> msgs(TSN 11 to TSN 100) in the SEND Q till it gets the ACK for TSN
>>> 10 or not? Please clarify me.
>>>
>>> In the heavy traffic condition we are seeing that Send Q is getting
>>> full! Your explanation on handling of SEND Q would be very helpful.
>>>
>>> Manjunatha Shetty K
>>> Phone: 1-847-632-2503
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Michael Tüxen [mailto:Michael.Tuexen AT micmac.franken.de]
>>> Sent: Tuesday, September 09, 2003 2:17 PM
>>> To: Manjunatha Shetty
>>> Subject: Re: SCTP...
>>>
>>>
>>> Hi,
>>>
>>> I can not remember that Bug. We are currently testing 1.0.0 of the
>>> sctplib for release and I will test that this works with the
>>> released version. You report is very good, we can reproduce the
>>> scenario.
>>>
>>> Do you have any further problems?
>>>
>>> Best regards
>>> Michael
>>>
>>> On Tuesday, Sep 9, 2003, at 15:53 Europe/Berlin, Manjunatha Shetty
>>> wrote:
>>>
>>>> Thanks for the quick response,
>>>>
>>>> We are facing problems with sctp, Problem description is mentioned
>>>> below.
>>>>
>>>> Can you please help in this regard. We are using SCTP stack which
>>>> has SCTP Freeware..
>>>>
>>>> I could see in some FAQ present in SCTP discussion email
>>>> list,where there are some problems in the area of re-transmission.
>>>>
>>>>
>>>> Problem Sequence:
>>>>
>>>> SCTP Peer SCTP
>>>> ---- ---------
>>>>
>>>> DATA REQ (TSN 10)
>>>> -------------------------------------------> getting dropped
>>>> DATA REQ (TSN 11)
>>>> ------------------------------------------->
>>>> SACK (TSN 11, GAP TSN 10)
>>>> <------------------------------------------
>>>> DATA REQ (TSN 10)
>>>> ------------------------------------------> Re-Transmission,
>>>> ------------------------------------------> getting
>>>> dropped
>>>> DATA REQ (TSN 12)
>>>> ------------------------------------------>
>>>> SACK (TSN 12 GAP TSN 10)
>>>> <------------------------------------------
>>>> DATA REQ (TSN 13)
>>>> ------------------------------------------>
>>>> SACK (TSN 13, GAP TSN 10)
>>>> <------------------------------------------
>>>> DATA REQ (TSN 14)
>>>> ------------------------------------------>
>>>> SACK (TSN 14, GAP TSN 10)
>>>> <------------------------------------------
>>>>
>>>> After the first retransmission there is no re-transmission, even
>>>> though the SACK is indicating that there is a missing TSN 10.
>>>>
>>>> I really appreciate if could help me out in this regard. Whether
>>>> this is a known bug or not?
>>>>
>>>> Thanks,
>>>> Manju
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Michael Tüxen [mailto:Michael.Tuexen AT micmac.franken.de]
>>>> Sent: Tuesday, September 09, 2003 6:06 PM
>>>> To: Manjunatha Shetty
>>>> Subject: Re: SCTP...
>>>>
>>>>
>>>> Hi Manju,
>>>>
>>>> there is no such repository. Internally we use CVS but it not fix
>>>> by fix...
>>>>
>>>> Best regards
>>>> Michael
>>>>
>>>> On Tuesday, Sep 9, 2003, at 10:39 Europe/Berlin, Manjunatha Shetty
>>>> wrote:
>>>>
>>>>> Would like to know is there any repository where all the bug fixes
>>>>> information are stored?
>>>>>
>>>>> Thanks & Regards,
>>>>> Manju
>>>>>
>>>>> -------------------------------------------------
>>>>> | Manjunatha Shetty K.
>>>>> | Wipro Technologies,
>>>>> | Creator 4th Floor,
>>>>> | International Tech Park,
>>>>> | Whitefield Road.
>>>>> | PH: 8411990 Extn: 1003
>>>>> -------------------------------------------------
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> discussion mailing list
>>> discussion AT sctp.de http://www.sctp.de/mailman/listinfo/discussion
>>>
>>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de http://www.sctp.de/mailman/listinfo/discussion
>
Archive powered by MHonArc 2.6.19+.