Subject: [NAILS REQUESTED PREVIEW]: Re: Just what does "new" mean ?

From: [email-masked]
Date: Tue, 30 Mar 2004 17:31:32 -0800 (PST)

Michael Tuexen wrote:

> This does not have to be in the spec, because it is local behaviour.
> You should always have room to accept the missing data. How you do
> this depends on your implementation. You might have a shared buffer
> (MBUFs, for example) for the whole protocol. You example assumes that
> you really have a specific buffer for an association.
> The number 1500 is only an example. Looking at implementations you
> use some pool elements of fixed size. You only have the choice between
> some values. I just wanted to make clear that you might reduce the a_rwnd
> due to gaps. I do know that the above description is vage, but there
> is a lot of implementation dependent stuff and if you really have no
> space left you have to reneg. That is why reneg exists.

I think we should separate this protocol behavior discussion from
buffer management.  The receiver may have GBs of memory left to hold
more packets.  The question is whether it should.  And we need
to look at it in two cases.  The first is if it is a protocol
specification error such that this can happen when both sides conform
to the spec.  The second is the protocol spec is correct but one side
violates it.

The current thread seems to focus on the latter case.  I think we
should also verify if this scenario can happen legitimately.  For
example, what if the receiver shrinks (illegal?) its receive window?
Other legitimate cases?

For the second case, I think the normal practice is not to change
the implementation to cope with that.  So in this case, the sender
will eventually time out and the association will be aborted.  But
we should also consider if this is a common enough violation so that
we should deal with it or if the fix is "trivial" and does not have
any impact.  I think the change is not "trivial" as it is in the normal
receive code path.  Any such change is not "trivial" and requires
careful scrutiny.  And it does not seem to be a very common violation.
Thus it can be dealt with in the usual way, inform the implementor
of the stack to fix it.

Could Andreas comment on whether this scenario is an isolated incident?

> You just have to apply the correct meaning of 'new', I think.

I think "new" is very well defined.  Any packets not received before
should be considered "new."  Any deviation from this obvious meaning
may cause even more confusion.  In Andreas' example, TSN 1 may as well
be delayed such that it is received out of order.

-- 

						K. Poon.
						[email-masked]