Subject: RE: [Tsvwg] SCTP: Data chunk in flight when a_rwnd = 0

From: [email-masked]
Date: Tue, 6 Nov 2001 14:23:15 +0200

Hi all!

... snip...

> > But if people think that accepting new data chunk above 
> should not be
> > allowed, then I think we need to specify that.  It means 
> that if a receiver
> > is making the sender to calculate a zero send window, the 
> receiver should
> > not accept new data chunks, regardless of its internal buffer space.
> > I think this is a small issue.
> > 
> 
> The above description is exactly how I implemented it in the
> FreeBSD/KAME kernel implementation we are building. Only thing
> I am missing is the SWS code (which I will be adding).
> 
> Now, as far as the required to drop a chunk versus not. Brians
> last email to me makes it clear what he wants. He wishes to
> force the chunks to be dropped so that this mechanism can
> be used as a flow control mechanism at the application 
> layer. 
> 
> a) App sets rwnd (through API call?) to 0.
> b) App reads anything left in queue.
> c) Now app knows what to have resent on another association.
> 
> Of course a item that will happen unless the original assoc
> is torn down is that
> 
> d) When rwnd is restored the old data will stream in.
> 
> Seems to me like a bad idea....

	Well, considering that the most probable future of the association
is that it is going to be aborted, I don't see it as a big issue. Maybe it
is not that neat, but it can be done in any case...

> > like that), please explain why.  Or if SCTP does not behave 
> like the above,
> > please explain the reasons and the difference.  I may have missed
> > something.
> > 
> > On another note, it seems to me that people are suggesting that
> > SCTP should be allowed not to advance cum-ack but use gap ack to
> > sack received data chunk when there is actually no gap.  I may
> > have mis-read Randy's email, but it seems to me that he is doing
> > this with his BSD impl, maybe because he is experimenting 
> copying out
> > to user space and doing checksum at the same time.  But I think
> > this is a hack and should not be allowed.  We need to specify that.
> > Unless we want to explicitly specify (which I think we should not)
> > in the spec that cum-ack is synchronously tied to ULP read, 
> the above
> > is a no no.  If it is not clear in RFC 2960, we should clarify
> > it in the new draft.
> > 
> No, I did not implement it this way on purpose.. I just don't
> check for the error condition:
> 
> SACK(CUM-ACK=50, GAP=51,54);
> 
> As was later pointed out the above is a protocol violation and
> is NON compliant to the spec... So I suppose I will go back
> and write some screening code..
> 
> I am unsure what I should do when I see the above:
> 
> a) Abort the association?
> 
> or
> 
> b) collapse the SACK so that it logically appears
>    as SACK(CUM-ACK=54);
> 
> 
> Any suggestions from the list.. probably the abort would
> be best since the peer may try to renege something considered
> CUM-ACK'd... but I am open to suggestions.
> 
> R

	I would vote for b)... Otherwise, if we would make a normal process
of the SACK, I can think about two basic differences from your b) solution:

	- We won't update the cwnd, as no cumulative advance has happened.
This is bad for the receiver... but it he wants to do so...

	- We won't erase the TSNs sent and acknowledged in the gaps, as they
could be reneged... This could fulfil our own buffer, making us stop
accepting new data from the upper use at some point, and can lead to a
deathlock situation... Everything is acknowledged, and we can't accept new
data, so we don't have any way to probe a change in the cumulative TSN ACK
value... maybe just sending already acknowledged data... I don't like it...
we would probably need another timer, as T3-timer is not running...

	One could also do half and half... Not updating cwnd but at the same
time erasing those TSNs that are "falsely cumulative acked"... But I don't
see the point of making things more complicated here...

	I think that b) is nice...

	BR Iván Arias Rodríguez

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 06:43:47 -0600

Ivan.Arias-Rodriguez,

> is not that neat, but it can be done in any case...

No, for M2PA, the most probable future is that the association
will not be aborted.  Otherwise an abort would have done the
job in the first place.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ 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 ¦