Chronological Thread 

< Chronological >      < Thread >

---

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.....
>
> >
> >
> > >
> > >> 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)

---

• [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+.