Chronological Thread 

< Chronological >      < Thread >

---

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
****************************************************************

---

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