Subject: Re: Just what does "new" mean ?

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Mar 2004 22:47:30 -0700

Kacheong,

On Wed, 31 Mar 2004, Kacheong Poon wrote:

> 
> What we are dealing with here is that at the protocol level, SCTP
> should not accept new packets when its receive window is full.  We need
> to make sure that no conforming SCTP implementation will hit the dead
> lock situation discussed so far.  If this is true, then we can think
> of whether good SCTP implementations should accommodate non-conforming
> implementations.  And I don't think this has to be tied to the attack
> you mentioned above.
> 
> 

It is not a protocol issue, only an implementation issue.  In Andreas' case
the sender does not conform (is violating the protocol), because it is sending
beyond the peer's available receive window.

Taking the protocol perspective, however, why distinguish "new" from "old"?
What "old" TSNs did anyone think the implementation needed to accept when its
receive window is closed?  Indeed, I don't think that the receiver needs to
accept *any* TSNs while its receive window is closed, strictly from a protocol
perspective.  So I really don't worry too much about the definition of "new".
What about "accept".  I would say accept means taking the TSN and storing the
data in the receive buffer.  This includes already seen TSNs that have been
renegged upon and retransmitted.  But new or old, why accept either?

I would say that "old" TSNs are those TSNs that do not occupy the receive
window (i.e. they have been delivered to the user), and "new" TSNs are those
that will occupy receive window.  That is, when the receive window is closed,
the receiver does not accept any TSNs that would otherwise decrease the
available receive window ("new").  But then those that wouldn't aren't
accepted either, because they are duplicates.  If one is saying that the
receive is required to report duplicate TSNs in SACKs regardless of the fact
that the receive window is closed, and that this is somehow "accepting" those
"old" TSNs then fine.

(Along different lines, there is a case where a similar lock-up can occur
between conforming implementations: if a message is sent (segmented of course)
that is larger than the receive window when the receiver does not support a
partial delivery api (which is not mandatory).  That is, consider a receive
window of 2000 bytes and a 3000 byte message is sent, segmented into three,
say, 1000 byte segments.  After the first two segments the receive window is
closed and the sender cannot send the third (or any other) segment.  The
receiver cannot deliver the first two segments, because it does not support a
partial delivery api.  Either message size needs to be restricted a fraction
of the receive window or the partial delivery API needs to be made
mandatory.)

--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 ¦