Subject: SCTP zero-window probing and path selection

From: Michael Larsen <[email-masked]>
Date: Fri, 18 Mar 2011 10:31:03 +0100

Hello list,

Looking into SCTP zero window probing on a multi-homed association and path 
failures, it looks to me like RFC4960 has room for an improvement.

Imagine the following setup with two host and a multi-homed association:

Local                    Peer

IP1 -------------------- IPa

IP2 -------------------- IPb

Imagine that we ('Local') is sending data on IP1-IPa while peer is sending 
data on IP2-IPb.  Subsequently, imagine that peer announces a_rwnd=0 and we 
begin zero-window probing (on IP1-IPa).  In the mean-time peer continues to 
send data on IP2-IPb and we dutifully return SACK of that data on IP2-IPb.

Now IP1-IPa breaks and our window-probes no longer reaches peer. Reading 4960 
literally we will not detect this and may never detect when peer rwnd opens.

The reason for this is the following statement from 4960 (Section 6.1, item 
A):

     "If the sender continues to receive new packets from the receiver
      while doing zero window probing, the unacknowledged window probes
      should not increment the error counter for the association or any
      destination transport address."

I.e. we are receiving "new packets" (albeit DATA chunks on IP2-IPb) so we do 
not increment the error counter and does not change destination of the window 
probes.

4960 is not clear on whether IP1-IPa is "idle" in this situation such that the 
destination is probed through heartbeats (we have sent data so strictly 
speaking HBs should not be sent). IF we read 4960 such that HBs should be sent 
then they will eventually clear up the reachability problem but this is a 
side-effect and given that heartbeat intervals can be tuned and heartbeat 
disabled this reaction may come too late or not at all.

The solution seems to me that instead of "new packets" 4960 should have said 
"SACK chunks" because the SACK chunk is the proper 'alive indication' returned 
in response to our window probe.  DATA chunks are not, because they belong to 
the independent data-flow going in the other direction.

Regards,
Michael

---

From: Randy Stewart <[email-masked]>
Date: Sat, 26 Mar 2011 13:06:58 -0400

Michael:

I thought I had responded to this already... I know I typed
an email in response.. but somehow it never got sent ... sorry about
that :-)

Some comments for you below.

> the independent data-flow going in the other direction.

When writing a protocol specification many things are left to implementations. Notice
that none of the text you quote has MUST or even SHOULD in the wording.

So yes, you could do as you suggest and consider only SACK's (as an implementation
decision) to not advance the error counter on the net... but there are a few
other things you should consider on this:

1) Since the peer is sending on path-2 data, often times it will send a window
   update sack... if it fits I would expect it to come bundled on the path-2 with
   the data.

2) When the retransmission timer on the window-probe expires and no sack has
   been seen since the original transmission, I would expect the implementation
   to be moving the data to the alternate path. After all in most cases when
   the T3-Timer fires this is what an implementation does... unless of course
   they are zero-window probing and they HAVE seen a SACK since the last send (if
   they track such).

Throughout the RFC you will find things "left to the implementation". This allows
some freedom in how things are implemented.. which is important.

I don't see this as a defect in the spec since as an implementor you can interpret
it the way you say... only sacks... or you can do it with the second method.. i.e.
move the data to the alternate path. In fact a third way would be to always move
the data to the alternate path.. no matter if its a window probe or not. That way
one does not have to keep track of a "did a sack happen since my last send of the
probe" field...

Again I think the key here is to let implementers have room to innovate and yet
still stay compatible and within the bounds of all of the cc issues and of course giving
a complete service to the user...

Best wishes

R

> Michael

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Sat, 26 Mar 2011 13:07:30 -0400

Michael:

Best wishes

R

-----
Randall Stewart
[email-masked]