Subject: RE: [Tsvwg] SCTP applicability statement

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 5 Nov 2001 11:00:55 -0800

If this probe is a single-end process, it should be
possible to add this as some kind of extension,
would it not?  BTW, shouldn't this discussion be
on the tsv list rather than sigtran?

Thanks,

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, November 05, 2001 10:25 AM
To: sigtran
Cc: Randall Stewart; [email-masked]; RJ Atkinson;
Phill Conrad
Subject: Re: [Tsvwg] SCTP applicability statement

Phillip,

I agree largely with your comments.  Particularly that separate
probe procedures are called for.

However, I have seen TCP implementations (BSD, Linux) that do
not send new data on probes, but rather send a duplicate segment
with bogus data (or zero length segment) on probes.

I don't see any reason why SCTP cannot send a DATA chunk with
a duplicate TSN (with bogus data) to invoke an immediate SACK
(thus getting rid of the lost SACK problem).  The remainder is
giving the sender the ability to ignore RTOs, counts, cwnd calcs,
etc during the probe.  An upper bound on the probe duration would
be smart (persist timer?).

But how does one go about getting all this into SCTP?

--brian

Phillip Conrad wrote:                                     (Mon, 05 Nov 2001
12:04:30)
> At 09:53 AM 11/5/2001 -0600, Brian F. G. Bidulock wrote:
> >Phillip,
> >
> >It is the "MUST" behavior that we are looking for.  However, what
> >happens to DATA chunks in flight that have RTO timers running
> >against them.  It takes time for the a_rwnd = 0 SACK to reach the
> >peer.  Also SCTP has path and association retransmission counts
> >and congestion window calculations that should not be performed
> >on the "probe" data chunks.  There are a whole series of MUSTs
> >concerning these counters and calculations.  These should be
> >suspended upon calculating a rwnd = 0 and the probing behavior
> >started.  Once rwnd permits new data, cwnd and couters can
> >continue.  Otherwise, a_rwnd = 0 will degrade the association
> >(lower cwnd, back off RTOs).  What is required is simple flow
> >control.
> 
> I agree that simple flow control is needed, and yet, without a
window-probe 
> function, the protocol may deadlock.
> 
> It sounds like what is needed is a clear concept of a "window probe" that 
> is treated differently in a wide variety of respects from regular data 
> chunks.  What may be needed is to carefully spell out the rules pertaining

> to "window probes", and handle the special cases to which you refer so
that 
> window probing does not adversely affect cwnd, RTO, etc.    A window probe

> should not be treated according to the regular retransmission timeout 
> rules, but should be handled with a persist timer, as in TCP.
> 
> RFC2960 has the concept of refraining from sending on a zero window, and 
> the concept of a window probe:
> 
> >A) At any given time, the data sender MUST NOT transmit new data to any 
> >destination transport address if its peer's rwnd indicates that the peer 
> >has no buffer space (i.e. rwnd is 0, see Section 6.2.1). 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). This rule allows the sender to probe for a
change 
> >in rwnd that the sender missed due to the SACK having been lost in
transit 
> >from the data receiver to the data sender.
> 
> However the concept does not seem to appear anywhere else as a special 
> case, which I think, is part of what you are trying to get across to 
> us.  For example:
> 
> >Whenever a transmission or retransmission is made to any address, if
> >    the T3-rtx timer of that address is not currently running, the sender
> >    MUST start that timer.  If the timer for that address is already
> >    running, the sender MUST restart the timer if the earliest (i.e.,
> >    lowest TSN) outstanding DATA chunk sent to that address is being
> >    retransmitted.  Otherwise, the data sender MUST NOT restart the
> >    timer.
> 
> It should say something like: "Whenever a transmission or retransmission 
> {other than a window probe} is made to any address..." Then, there should 
> be explicit reference to a persist timer as in TCP that is used for window

> probes instead of the normal retransmission timer.
> 
> Oddly, I was unable to find a reference to a persist timer in any of the 
> RFCs (either TCP or SCTP)... can anyone help here?  I looked through
RFC793 
> as well as Clark's later treatise on the Silly Window Syndrome (RFC813), 
> but no luck.
> 
> Stevens' text indicates that the persist timer is different from the RTX 
> timer "in that TCP *never* gives up sending window probes." (p. 325).
> 
> Adding a separate persist timer and rules for handling window probes is a 
> fairly significant change to the protocol, but one that is necessary I 
> think.  I had assumed all along that a zero-window would be handled in
SCTP 
> in precisely the same was as in TCP, but it appears not to be the case
from 
> the way things are worded now. Two of the issues:
> 
> * Is there some reading of RFC2960 that would indicate that we DON'T have 
> to take a timeout (and all the associated bad congestion control effects 
> that follow) in the event that we hit a zero window with new data?
> 
> * I'd also think we'd want to avoid, in a multi-homed situation, failing 
> over to an alternate address with retransmissions if the "problem" is 
> clearly that the receiver has a zero window.    Is there text in the RFC
to 
> handle this case?    Repeated window probes should probably stay on the 
> primary as long as acks are coming back from the primary... acks that in 
> this case, DON'T ack the new data, but rather, just indicate that the 
> advertised window is STILL zero.
> 
> (I don't think the introduction of per-stream flow control can make *this*

> problem go away; window probes are still needed to ensure forward
progress)
> Phill

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 05 Nov 2001 17:10:38 -0600

"Brian F. G. Bidulock" wrote:
...snip...
> 1)  Withhold acknolwedgements at ULP control for intervals longer
>     than several seconds without aborting or otherwise degrading
>     an SCTP association.  RFC 2960 says that all new DATA messages
>     MUST be acknowledged and sets upper bounds (usually 200ms) on
>     any acknowledgement.

Brian,

It seems to me that if you use a ULP level acknowledgment, this problem
goes away, right? If so, all you are trying to do is to push more app
specific functions down into SCTP so that the ULP can get simplified. I
think that is wrong.

-Qiaobing