Re: a_rwnd=0 - heartbeat messages allowed?

Michael Tüxen <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
On Jan 25, 2010, at 7:56 AM, Brian F. G. Bidulock wrote:

> 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.
You are correct, I'm assuming that the echo server functionality
works.
> 
> 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.
Then the upper layer implementation might be broken...  
> 
> 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.
Again: The point is not that the data is sent when the window opens
again, but if only one DATA chunk is used for zero probing.
Therefore you only need pending data as the SUT.
> 
> 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.
It is a good idea to verify the echo functionality before relying on it...
Currently this is just assumed.
Best regards
Michael
> 
> --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/
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.