Chronological Thread 

< Chronological >      < Thread >

---

R,
Comments inline....

Randall Stewart wrote:

> Arun:
>
> Actually I set a flag in my data chunk tracking
> structure to indicate that the chunk is being
> used as a window probe.
>
> And of course if the arwnd is NOT 0 you should accept
> the chunk as Brian suggests... In general I have my
> SWS setup in such a way that if we go below a MTU size
> unit we drop to 0 on the sender side.. and the receiver
> side scales its SWS avoidance to 1/4 of the total receiver
> buffer space... so when I get 3/4 full I drop my rwnd
> to 1... if I fill all the way.. I drop it to 0 and start
> to discard...
>
> R
>
> Arun Prasad wrote:
> >
> > Hi Brian
> >
> > "Brian F. G. Bidulock" wrote:
> >
> > > Arun,
> > >
> > > On Fri, 15 Mar 2002, Arun Prasad wrote:
> > >
> > > >
> > > > Hi Brian,
> > > > Comments inline......
> > > >
> > > > "Brian F. G. Bidulock" wrote:
> > > >>
> > > >> Arun,
> > > >>
> > > >> The association does not time out because when doing a zero
> > > >> window probe there is nothing to use to calculate RTT, so
> > > >> a Heartbeat must be sent to the destination within the hearbeat
> > > >> interval. When the Hearbeat Ack is succesfully returned, the
> > > >> retransmission counts are cleared. If you use the recommended
> > > >> values for heartbeat interval, RTO min, and path max retrans
> > > >> you will not lose the association on a zero window probe of
> > > >> indefinite length.
> > > >>
> > > > Ha, I got the point.....The thing which I missed is the
> > > > HeartBeatAck and clearing of the Rtx counter..... I think the the
> > > > first
> > > > issue is cleared ... Now I could derive the solution for it...
> > > > See if
> > > > that is ok...
> > > >
> > > > * There is no need of maintaining a seperate timer for the Zero
> > > > Window probing, as the T3 timer will automatically do this job....
> > > > * There is no special processing required for the zero window
> > > > probing except the following check, the rest can follow the
> > > > procedures
> > > > Rfc 2960...
> > > >
> > > > Check:
> > > > *While trying to send a Data chunk (either new or
> > > > Retransmitted
> > > > one..) and if the SND.WND=0 (Effective SendWindow) then the
> > > > Data
> > > > chunk is sent to the peer only if there is no Outstanding
> > > > chunks......... And by continuiuing this, will lead to the
> > > > Rtx
> > > > counter exceeding the Max.Retrans threshold.... then the path
> > > > will
> > > > become inactive and a HB is sent.... and when an HB-ACK is
> > > > received.... the Path will again go to the ACTIVE state... and
> > > > continue Retransmitting that Data chunk till the ARwnd is
> > > > Non-zero....
> > >
> > > Yup. However, the imp guide also allows the implementation to not
> > > timeout the destination in the first place if the a_rwnd = 0. This is
> > > necessary because heartbeats can be suppressed on a destination basis.
> >
> > Thanks a bunch for clearing this.....
> > Then to handle "not timeout the destination in the first place if
> > the a_rwnd = 0"
> > I think we have to have an additional check during T3 timer
> > expiry.....
> > * If the (ARwnd = 0) then dont increament the Retrans
> > counter......
> > Because in this scenario the T3 timer is acting like a
> > "Persist timer" or
> > "Zero window probing timer"......
> > This I think will ensure that the Retrans counter doesnt reach
> > the Threshold
> > and start sending HB chunk.....
> > I think the above is ok.....
> >

Getting a flaw in my own suggestion..... In the above suggestion
things will
work well, if there is no Path Error... If the link becomes during the
Zero
window probe, then from the above method the Endpoint will keep on
continuing the "Zero window probe"....because the Retrans counter is never
increamented as the zero window probe is going on...... So this method
wont
work.....
We have to definitely keep track of the zero window probe packet sent
and
a SACK is received for it.... If no SACK is received for a Zero Window
probe
then the while T3 expires the Retrans counter should be increamented for
that
path......

To achieve this we can have the following check when we receive the
SACK
during zero window probe....
* Check if the the ARwnd in SACK is zero and currently the
endpoint
is in zero window probe (this means only one data chunk will
be
outstanding...)
If thats the case then treat this Acknowledgement as the
Acknowledgement for the Path on which the only OutStanding
data
chunk is sent..... By considering this way the
Retrans.Counter will
be cleared if the SACK arrives constantly for every zero
window probe...
If the SACK doesnt come for the zero window probing data chunk
(due to path error) then the T3 timer will expire N times
which make
the error counter to reach the Threshold and the Path is
Deactivated......

Is the above solution ok....... I think its better to put some
standard solution
in the draft... otherwise each implementer will implement in his own way and
end up
with a buggy stack.....

> > >
> > >
> > > >
> > > >> In your example with a receive buffer of 500 and an incoming
> > > >> data chunk of 1500, it is typical to not discard this chunk,
> > > >> but to process it (let the rwnd slop by 1000 bytes) and then
> > > >> start advertizing a zero receive window. This way there is no
> > > >> problem.
> > > >>
> > > > But the above point contradicts the implementation
> > > > guide...
> > > > If I have understood the below lines properly..... "The SCTP
> > > > endpoint
> > > > MUST always acknowledge the reception of each valid DATA chunk
> > > > when the
> > > > DATA chunk received is inside its receive window."
> > >
> > > This does not say that the endpoint must discard anything. Nor does it
> > > say that the endpoint is not permitted to ack chunks and slop the
> > > receive
> > > window.
> > >
> >
> > Ok...
> >
> > >
> > > > But even the Receiver discards the data chunk and sends a
> > > > SACK
> > > > of ARwnd = non_zero_value..... the sender will still have the
> > > > SND.WND as
> > > > zero and will be doing the zero window probing....... The below
> > > > is that
> > > > scenario....
> > > >
> > > > * Sender sends a data chunk of size 1500 when its SND.WND=500
> > > > (because one data chunk is allowed to be sent when the Rwnd is not
> > > > sufficient...)
> > > > * Receiver receiving this will discard the chunk as it has the
> > > > Rwnd= 500..... And Sends the Sack as ARwnd = 500...
> > >
> > > Don't discard the chunk. Accept it, SACK it, and advertize a_rwnd = 0.
> > > IMO an implementation should never discard messages due to insufficient
> > > receive buffer space without advertising a_rwnd = 0.
> > >
> >
> > I agree.....
> >
> > >
> > > --brian
> >
> > Thanks
> > -arun
> >
> > >
> > >
> > > > * Sender upon receiving the SACK, will update its SND.WND as
> > > > SND.WND = (500 - 1500) ( ARwnd - number of bytes in
> > > > flight)
> > > > SND.WND = 0
> > > > * Then when the T3 timer expires, the Sender will have no
> > > > OutStanding Data bytes and its SND.WND is zero...... So it will
> > > > again
> > > > resend this Data chunk....
> > > >
> > > > This continues as the first case (explained above in the first
> > > > comment...), as usual
> > > > T3 expires for N times, the path goes INACTIVE... and after
> > > > sending and
> > > > receiving the HB-ACK, again transmission continues......
> > > >
> > > > I think the above illustrations seems to solve the
> > > > querries... If my assumption is not valid or if I have missed some
> > > > point,
> > > > please point out....
> > > >
> > > > Thanks
> > > > -arun
> > > >
> > > >
> > > >
> > > > Both these procedures are provided for by RFC 2960 and the
> > > > implementation guide. We just wanted to clarify some things
> > > > that was not so clear in RFC 2960.
> > > >
> > > > --brian
> > > >
> > > > On Fri, 15 Mar 2002, 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...
> > > > >
> > > > >
> > > > > 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......
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > * 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...
> > > > >
> > > > > 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......
> > > > >
> > > > >
> > > > >
> > > > > *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...
> > > > >
> > > > > 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.....
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > ****************************************************************
> > > >
> > > > --
> > > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to
> > > > the
> > > > ¦
> > > >
> > > > bidulock AT openss7.org
> > > > ¦ world; the unreasonable one persists in
> > > > ¦
> > > > [1]http://www.openss7.org/ ¦ trying to adapt the world to
> > > > himself. ¦
> > > > ¦ Therefore all progress depends on
> > > > the
> > > > ¦
> > > > ¦ unreasonable man. -- George Bernard
> > > > Shaw
> > > > ¦
> > > >
> > > > _______________________________________________
> > > > tsvwg mailing list
> > > >
> > > > tsvwg AT ietf.org
> > > > [2]https://www1.ietf.org/mailman/listinfo/tsvwg
> > > >
> > > > --
> > > > ****************************************************************
> > > > V.Arun Prasad
> > > > HCL Technologies Ltd.
> > > > 51, Jawaharlal Nehru Road,
> > > > Ekkattuthangal,
> > > > Guindy Industrial Estate,
> > > > Chennai - 600097.
> > > >
> > > > Contact # : 9144 - 2334174
> > > > 9144 - 2334181
> > > > extn: 233
> > > > ****************************************************************
> > > >
> > > > References
> > > >
> > > > 1. http://www.openss7.org/
> > > > 2. https://www1.ietf.org/mailman/listinfo/tsvwg
> > >
> > > --
> > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
> > > bidulock AT openss7.org
> > > ¦ world; the unreasonable one persists in ¦
> > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
> > > ¦ Therefore all progress depends on the ¦
> > > ¦ unreasonable man. -- George Bernard Shaw ¦
> > > _______________________________________________
> > > discussion mailing list
> > > discussion AT sctp.de
> > > http://www.sctp.de/mailman/listinfo/discussion
> >
> > --
> > ****************************************************************
> > V.Arun Prasad
> > HCL Technologies Ltd.
> > 51, Jawaharlal Nehru Road,
> > Ekkattuthangal,
> > Guindy Industrial Estate,
> > Chennai - 600097.
> >
> > Contact # : 9144 - 2334174
> > 9144 - 2334181
> > extn : 233
> > ****************************************************************
> >
> > _______________________________________________
> > tsvwg mailing list
> > tsvwg AT ietf.org
> > https://www1.ietf.org/mailman/listinfo/tsvwg
>
> --
> Randall R. Stewart
> randall AT stewart.chicago.il.us
> 815-342-5222 (cell phone)
>
> _______________________________________________
> tsvwg mailing list
> tsvwg AT ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
9144 - 2334181
extn : 233
****************************************************************

---

• [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Ivan.Arias-Rodriguez, 03/14/2002
  • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Arun Prasad, 03/15/2002
    • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Brian F. G. Bidulock, 03/15/2002
      • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Arun Prasad, 03/15/2002
        • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Brian F. G. Bidulock, 03/15/2002
          • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Arun Prasad, 03/15/2002
            • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Randall Stewart, 03/15/2002
              • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Arun Prasad, 03/15/2002
              • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Randall Stewart, 03/15/2002
    • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Arun Prasad, 03/15/2002
    • Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt, Randall Stewart, 03/15/2002

---

Archive powered by MHonArc 2.6.19+.