Subject: Re: [Tsvwg] SCTP applicability statement

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 08:59:14 -0600

Randall,

Randall Stewart wrote:                                    (Mon, 05 Nov 2001 08:18:23)
> "Brian F. G. Bidulock" wrote:
> > 
> > Randall,
> > 
> > Randall Stewart wrote:                                    (Mon, 05 Nov 2001 07:21:12)
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > RJ,
> > > >
> > > > It has been presented here (TSVWG and SIGTRAN) and will be presented
> > > > again:
> > > >
> > > > For failover between associations the ULP needs to be able to
> > > > do the following things:
> > > >
> > > > 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.
> > > >
> > >
> > > Yes, and has Tom George pointed out one can do as mentioned by
> > > NOT advancing the cum-ack and putting new chunks in GAP acks.
> > > This of course penalizes our cwnd growth since the cwnd is
> > > not allowed to grow unless the cum-ack advances but this
> > > should not be a problem for sigtran. And there may be some
> > > implementations that abort when this occurs.. but it is not
> > > wrong so you should NOT abort really..
> > >
> > >
> > > > 2)  Cause the remote peer to stop transmitting new data.  RFC 2960
> > > >     permits an association to send new DATA regardless of whether
> > > >     it has receive a_rwnd = 0.
> > >
> > >
> > > As I mentioned before this is a arguable point but I will gladly
> > > add the clearification to the implementors guide ..
> > >
> > > >
> > > > 3)  Have sent messages acknowledged or have the ability to retrieve
> > > >     unsent and unacknowledged messages after an ABORT.  This is
> > > >     currently possible and is largely the responsibility of the
> > > >     implementation.
> > >
> > > The socket api that is a wg item allows this.. I do need to
> > > get the latest version in though...
> > >
> > > So I don't see any of your problems as problems.. they all
> > > have been addressed..
> > >
> > 
> > So we will see both (1) and (2) clarified as required in the
> > "implementor's guide" or whatever follow-on RFC?
> > 
> 
> I don't know about (2) since it is already allowed behavior
> but for sure we can clearify (1) above..

(2) is clearly not allowed behaviour due to the MUST in
Section 6.2 that says:

    "In paticular, the SCTP endpoint MUST fill in the Cumulative
     TSN Ack field to indicate the latest sequential TSN (of a
     valid DATA chunk) it has received."

In fact, in the mail threads cited by David, the concensus was
that this was a "protocol violation".

What makes it "allowed behavior" now?

--brian

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

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 05 Nov 2001 09:22:21 -0600

> What makes it "allowed behavior" now?

Ok, its not allowed behavior.. I still don't understand the problem.

A lot of implementations it will work.. I don't think most
will go to the trouble of checking this.. I know I did not
in any implementation.

But my base problem is why is this needed? If you are thinking
in terms of per-stream-flow control I believe the next pass
of the add-ip draft is supposed be updated to either

a) drop the sender flow limits 

and

b) (hopefully if Phil will provide the text :> this is again
    a nudge Phil) provide a per-stream flow control that 
   satisfy's this behavior.

--
R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)