Thanks
-arun
Arun Prasad wrote:
Hi Ivan,
Thanks for the response.... Please see the comments inline...
[Arias-Rodriguez Ivan (NRC/Helsinki)] :-/What is then a "zero window probe"? I guess that the concept applies to any DATA chunk sent when rwnd is zero... So, it seems to me that you are doing a zero window probe here...
Maybe the mistake comes from the fact that once the T3 timer expires, the DATA chunk is marked for retransmission and thus, not considered outstanding any more...
Since it is not outstanding, you immediately make a zero window probe... I hope I'm not missing anything...
<arun>
I accept with you, that when T3 timer expires, there
will be no Outstanding
data, and the same data chunk will be retransmitted... as a zero window
probe...
But when the procedure continues, the T3 timer will expire for say
the Max.Retrans
threshold value and then the Path goes down (if its the only path Assoc
goes down..)
The error counter will not be clear when SACK is received due to the
following
condition....
Sec 8.2 of 2960:
When an outstanding TSN
is acknowledged or a HEARTBEAT sent to that
address is acknowledged with a HEARTBEAT
ACK, the endpoint shall
clear the error counter of the
destination transport address to which
the DATA chunk was last sent
(or HEARTBEAT was sent).
So I think it should be made clear....... My suggestiong are ...
* When a Data Chunk is to be
sent and (SND.WND = 0) then the transmission
should
be considered "Zero Window Probe" and T3 timer should not be
started.....
Instead some timer say like "Persist Timer" should be started.
When
the Persist timer expires, the same data chunk should be again used
for
"Zero Wnd Probe".... this procedure should follow till the Peer advertises
a
non-zero window....
OR
* When a T3 timer expires
and the (ARwnd = 0) then the Rtx Counter should
not
be increamented ( this ensures that the counter will not reach the
threshold
and
make the Path INACTIVE)... This ensures that during "Zero
Window
probe"
the T3 timer will act as the "Persist timer"... and this will come to
normal
when the the endpoint receives a SACK with non-zero ARwnd.....
I think if we dont follow any of the schemes as above, we will end up in
mixing the Retransmission procedure with the
Zero Windo Probe.. and Aborting the
Association... which should not be done......
<arun end>
* Receiver again drops the packet and sends a SACK as above......
This procedure continues till the Maximum Retransmission Counter goes
off and the Association closes.... (According to section 2.15.2 "When a sender is
doing zero window probing, it should not time out the association if it continues to
receive new packets from the receiver", this again contradicts )[Arias-Rodriguez Ivan (NRC/Helsinki)] I guess this question is answered by my previous comment...
*********************
Next issue is from the lines
"---------
New text: (Section 6.2)
---------The SCTP endpoint MUST always acknowledge the reception of each
valid DATA chunk when the DATA chunk received is inside its receive
window."Considere the below scenario:
* Sender sending a data chunk of size 1000 when SND.WND = 1500
* Receiver receives the data chunk and sends a SACK wth ARwnd = 500
(It cant apply SWS avoidance here by sending a (ARwnd = 0), because that
would violate SCTP principle that a window cannot shrink by moving the
right edge...)[Arias-Rodriguez Ivan (NRC/Helsinki)]
*Sender receiving the SACK, will send another Data chunk of size 1500 when
SND.WND = 500 ( this is allowed according to the RFC, "However,
regardless of the value of rwnd (including if it is 0), the data sender can always
have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B
below). )[Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, but this means that you are not supposed to surpass rwnd. You can always have one DATA chunk outstanding, but I think that the only special case when you can surpass the rwnd is when the received a_rwnd is 0 and you don't have any TSN outstanding...
<arun>
I think ur statement
above contradicts the the statement from the draft.....
"However, regardless of the value
of rwnd (including if it is 0), the data sender
can always have one DATA chunk in flight to
the receiver if allowed by cwnd".
It says, "Including if it is 0".... which
I think means... any ARwnd value even it is
zero..... Have I misunderstood something
here......
<arun end>
*Receiver on receivin this data chunk will do the check as specified above
( data chunk's size is less than Rwnd), since this check fails, it will drop the
packet and sends a SACK of ARwnd = 500....Here again we came to the same issue as the first one.... Here we never
go into "Zero Window Probing" as we never get ARwnd = 0......
[Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, you are right... The point is that you shouldn't send a DATA chunk carrying more user data than the rwnd allows... unless it is completely impossible not to surpass this value, i.e. you make a 0 window probe...
<arun>
Again Iam to the same
confusion..... and couldnt get the solutions for my
doubt of "when the Receiver drops the Data chunk
from the Sender because it
doesnt contain enough Rwnd.... and it contiues
to advertise the small ARwnd (non
zero) it has.... Which will not trigger
the "Zero window probe procedure" in the
Sender side...
Not
sure where Iam missing, but Iam missing something.....
<arun end>
Thanks
-arun
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.Contact # : 9144 - 2334174
9144 - 2334181
extn : 233
****************************************************************
--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.
Contact # : 9144 - 2334174
9144 - 2334181
extn : 233
****************************************************************
Archive powered by MHonArc 2.6.19+.