Subject: [Tsvwg] Re: SCTP query

From: [email-masked]
Date: Wed, 3 Oct 2001 13:54:12 +0530

Hi Randall

I agree with you that the interval between
two probes for a non-zero rwnd should be
increased exponentially. But it should not
be done using RTO timer. If RTO is changed
due to non receipt of SACK for TSN = 50
(as in my example), the RTT would also get
modified incorrectly.

Thus a separate probing timer should be maintained.
At start of probing the value of Probing Timer should be set
equal to the current RTO. Whenever sending a probe
packet, only Probe Timer should be started. On expiry
of Probe timer, only Probe Timer should be backed off.
In case of Destination IP switchover (multihomed association),
the Probe Timer should be set equal to the RTO of next
destination IP if it is less than it.

Vakul

Mails exchanged on this issue on the tsvwg list.
---------------------------------------------------------------------

Hi Armando

Section 4.2.2.17 of RFC 1122 states:

4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42

            Probing of zero (offered) windows MUST be supported.

            A TCP MAY keep its offered receive window closed
            indefinitely.  As long as the receiving TCP continues to
            send acknowledgments in response to the probe segments, the
            sending TCP MUST allow the connection to stay open.

            DISCUSSION:
                 It is extremely important to remember that ACK
                 (acknowledgment) segments that contain no data are not
                 reliably transmitted by TCP.  If zero window probing is
                 not supported, a connection may hang forever when an
                 ACK segment that re-opens the window is lost.

                 The delay in opening a zero window generally occurs
                 when the receiving application stops taking data from
                 its TCP.  For example, consider a printer daemon
                 application, stopped because the printer ran out of
                 paper.

            The transmitting host SHOULD send the first zero-window
            probe when a zero window has existed for the retransmission
            timeout period (see Section 4.2.2.15), and SHOULD increase
            exponentially the interval between successive probes.

            DISCUSSION:
                 This procedure minimizes delay if the zero-window
                 condition is due to a lost ACK segment containing a
                 window-opening update.  Exponential backoff is
                 recommended, possibly with some maximum interval not
                 specified here.  This procedure is similar to that of
                 the retransmission algorithm, and it may be possible to
                 combine the two procedures in the implementation.

-----------------------------------------------------------------------------------------------------

I interpret from this text and your mail that a separate timer for probing the
receiver
window size should be kept. The Probing timeout should be increased
exponentially. But this should not affect RTO in any case.

Comments?

Vakul

Armando>>>>> Yes, I agree.

"Armando L. Caro Jr." <[email-masked]> on 09/28/2001 06:24:40 PM

To:   [email-masked]
cc:   Vakul Garg/HSS@HSS, [email-masked]

Subject:  RE: [Tsvwg] SCTP query

On Fri, 28 Sep 2001 [email-masked] wrote:

> > After timeout, TSN = 50 would be retransmitted by SCTP1. As this
> > happens, exponential backoff algoritm is applied to recalculate the
> > value of RTO. Let again SACK with Cummulative TSN = 49 and arwnd = 0
> > arrive. Thus more timeout happen and we end up increasing the RTO
> > to some value RTO.max.
>

Ivan>>>    Yes...

Armando>>> Hmm... I couldn't find any text in the rfc which addressed this
scenario,
but I think modifying the RTO due to dropped probes is the wrong thing to
do.

Ivan>>> Well, there is congestion... Not at the network but at the receiver
> side... Its buffer is full... There are two kinds of congestion, the one
> that cwnd and ssthresh tries to avoid (congestion in the network) and the
> one rwnd tries to avoid (congestion at the receiver). In any of these two
> cases your transmission is not progressing and the datagrams are being
> dropped somewhere, so it makes sense reducing your sending rate as you are
> wasting bandwidth...

Armando>>>Yes... When the receiver's buffer is full, it makes sense to reduce
the
sending rate, but NOT increase the RTO.  There is no relationship between
the status of the receiver's buffer and the RTT.

> > Please correct me where I am wrong.
>

Ivan>>>>>    I don't think you are wrong at all... Maybe somebody else can
> correct us... :-)

Armando>> I don't think it is wrong to say that this is what would happened if
the
rfc is followed. HOWEVER, I do think it is the wrong thing to do.

~armando

-----------------------------------------------------------------------
Armando L. Caro Jr.                                  [email-masked]
University of Delaware                   http://www.cis.udel.edu/~acaro
-----------------------------------------------------------------------

Randall Stewart at work <[email-masked]> on 10/02/2001 04:27:19 PM

To:   Vakul Garg/HSS@HSS
cc:

Subject:  Re: SCTP query

[email-masked] wrote:
>
> Hi Randall
>
> I am having some doubt regarding the RTO calculation in SCTP.
>
> Suppose two SCTP instances SCTP1 and SCTP2 have established
> an association. SCTP1 is transferring DATA chunks to SCTP2.
>
> Let DATA chunk with TSN = 49 is sent by SCTP1.
> SACK is sent by SCTP2 with cummulative TSN = 49 and arwnd = 0.
> Assume RTO at SCTP1 is RTO.min at this point of time.
>
> When arwnd of SCTP2 is 0, SCTP1 is allowed to send one data chunk
> to probe any change in the window at SCTP2.
> So another chunk is sent by SCTP1 which has TSN = 50.
> An SACK again is sent by SCTP2  with Cummulative TSN = 49 arwnd = 0.
>
> When SCTP1 receives this chunk, it discards it as TSN = 49 has already
> been acknowledged.
>
> After timeout, TSN = 50 would be retransmitted by SCTP1. As this
> happens, exponential backoff algoritm is applied to recalculate the
> value of RTO. Let again SACK with Cummulative TSN = 49 and arwnd = 0
> arrive. Thus more timeout happen and we end up increasing the RTO
> to some value RTO.max.
>
> My understanding about RTO is that it is increased exponentially in the
> anticipation that the network has got congested. In this situation, the
network
> has not got congested, but due to temporary problem at receiving SCTP2,
> RTO is being increased incorrectly at sending SCTP1.
>
> Please correct me where I am wrong.
>
> Regards
>
> Vakul

Vakul:

No you are quite correct. If a peer sets its rwnd to 0, then you will
slowly
exponentially back off. One minor cavet, is that when the TSN == cum-ack
i.e. TSN = 49 you must still look for either different gaps or in this
case a rwnd update.

I think this exponential backoff is ok since it makes no sense to pound
the network when the receiver is locked... maybe in a while(1) ;
type loop or something and not reading...  If the application is just
slow I don't see that much of the exponential backoff will happen.. If
it
is broken.. then you can't communicate with it anyway...

Ps: I have also seen some TCP implementations that will send a
gratuatious
SACK as well when the receiver actually starts to read its data. This
would
then free up the sender to send more aka TSN51 etc, and thus the FR
algorithm
would be invoked and TSN50 would get through quicker...

R

--
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart at work <[email-masked]>
Date: Wed, 03 Oct 2001 05:44:52 -0500

Yes, I believe this is well within the spec and 
what TCP does....

R