Re: a_rwnd=0 - heartbeat messages allowed?

Michael,

Well, no...  Somebody might have just failed to configure the SUT as
an echo server, or the echo server might be malfunctioning, or the
echo server might not yet have been applied at the time the initial
DATA arrived (preamble mis-sychronization), or the test harness
might be malfunctioning.

For the test to be conclusive requires knowledge that data is
pending at the SUT, otherwise it may just have been the echo server
that failed and not the SUT.

When full ferry-clip testing is performed it can be concluded from
the ferry-clip that data is pending.  When performing black-box
testing, it is the responsible for the PT to ensure these things.
Perhaps if the test harness can be relied upon to previously have
tested the echo behavior of the SUT in this regard one might be a
little more confident that data is pending.  Otherwise, opening rwnd
back up and receiving data is far more conclusive that data was
indeed pending than it is if data is simply not forthcoming at all.

Another approach I suppose would be to send data while rwnd=1500 and
verify that data is echoed properly before setting rwnd=0 (i.e.
making proper echo server operation part of the preamble or embedded
in the test), but I did not see that exchanged in Des' original
message sequence chart.  His MSC did not; however, include any
preamble.

--brian

Michael Tüxen wrote:                     (Sun, 24 Jan 2010 22:36:47)
> On Jan 21, 2010, at 12:38 PM, Brian F. G. Bidulock wrote:
> 
> > Des,
> > 
> > This is really an SCTP question (for [email protected]), however,
> > an SCTP endpoint is allowed to send SACK with rwnd=0.  The
> > tester may send it; however, the tester must also send HEARTBEAT
> > ACK in response to HEARTBEAT if it wants to keep the association
> > alive.
> The SUT acts as an echo server. So the point here is to verify
> that the SUT reflects the received DATA after having received
> the SACK(arwnd=0).
> > 
> > I would guess that the tester is testing zero-window probing by
> > the SUT, RFC 4960 6.1. A:
> > 
> >  When the receiver's advertised window is zero, this probe is
> >  called a zero window probe.  Note that a zero window probe SHOULD
> >  only be sent when all oustanding DATA chunks have been
> >  cummulatively acknowledged and no DATA chunks are in flight.  Zero
> >  window probing MUST be supported.
> > 
> > If that is the case, it is expecting DATA not HEARTBEAT, and
> > this may be why the test case is failing (timing out) rather
> > than responding properly to the HEARTBEAT with HEARTBEAT ACK.
> The Tester expects a DATA chunk so it ignores the HEARTBEATs.
> > To be conclusive that the SUT is failing a zero-window probe
> > test, it needs to be verified that the SUT has DATA oustanding
> > after receiving SACK (rwnd=0).
> The SUT has data to send (that is why the tester is sending DATA),
> so it MUST send it even if the arwnd is 0. The SUT is NOT sending
> it, so it failed the test.
> > 
> > One way for the tester to conclude this (if it is unable to do
> > so by ferry-clip) would be to send HEARTBEAT ACK and SACK
> > (rwnd=1500) in response to the first HEARTBEAT and see if the
> > SUT sends DATA immediately, in which case it might conclude that
> > the SUT has failed a zero-window probe test.
> The objective to test is: Does the SUT send zero window probes
> when the peer window is 0. The SUT fails this...

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