First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt


Chronological Thread 
  • From: Randall Stewart <randall AT stewart.chicago.il.us>
  • To: Arun Prasad <arun AT netlab.hcltech.com>
  • Cc: discussion AT sctp.de, tsvwg AT ietf.org, sctpimp AT netlab.hcltech.com
  • Subject: Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt
  • Date: Sun Mar 17 22:17:00 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
Arun:

I did not mention the failing link issue :> I had thought
of it though.. I think it is up to the implementation on
how you wish to solve it. What I did is always rotate
the Window-Probe to an alternate destination.. but do
no thresholding. I figured I would let the HB's take
care of the failure. This makes the handling simpler..

But I think this is an implementation choice...

R

Arun Prasad wrote:
>
> 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
> ****************************************************************

--
Randall R. Stewart
randall AT stewart.chicago.il.us
815-342-5222 (cell phone)


Archive powered by MHonArc 2.6.19+.

Top of page