Hi Arun,
I didnt get one thing.........i have written
that thing below in the capital letters...
Regards,
Vijay
Hi all, In the
draft-ietf-tsvwg-sctpimpguide-03.txt section 2.15 "Window probes in
SCTP".... we felt some contradictions....
--------- 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.
When the receiver's
advertised window is 0, the receiver MUST drop all new incoming DATA chunk and
immediately send back a SACK with the current receive window showing only
DATA chunks received and accepted so far.
The above point
specifies that when we receive any Data chunks and the Rwnd is zero
then we have to drop those packets and those chunks' TSN will
not be included in the SACK sent........ Consider the following
example... * Sender sends a probing data chunk
of "Tsn x" to Receiver when the Receiver
has advertised the the
ARwnd as zero.... * Receiver upon receiving this
chunk will check its Rwnd, Since the Rwnd is zero
it will drop the chunk and sends
a SACK with CUM_TSN as " x-1" (not
including "TSN x"....
* Sender upon receiving this SACK cannot send
another "Zero Window Probe"
because there is an OutStanding Data chunk ( this condition is from the
same section.. "Note that zero window probe SHOULD only be sent when
all outstanding DATA
chunks have been cumulatively acknowledged "...) but its
RTX timer will expire and
sends the same Data chunk "TSN x" one more
time...( note, that zero
window probe is no more used...) ... * Receiver
again drops the packet and sends a SACK as above......
I THINK WHENEVER WE RECEIVE THE SACK WE SET THE ASSOC RETRANS COUNT AND
PATH RETRANS COUNT TO ZERO....MAY BE I M WRONG
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 )
********************* 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...) *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).
)
*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......
Are the issues making sense... Atleast for me...
its totally confusing..... The Probing ideas given in the draft is condradictory in the sense, the
Send side Alg follows the TCP way,
but not the Receive side.... ( I guess in TCP, when the ARwnd is
zero, it will still accept the data chunks
from the Sender.... anyway in TCP case the zero window probing will be done with "one byte", but in
SCTP a whole CHUNK is sent....)
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
****************************************************************
____________________________________________________ IncrediMail -
Email has finally evolved - Click
Here
|