Subject: SCTP zero window probes

From: Karoline Malmkjær<[email-masked]>
Date: Thu, 18 Sep 2008 13:35:40 +0200

Hello list.

I have a question about zero window probing and error counters.

RFC4960 states that:

      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 assume that this implies that if *no* packets have been received
from peer between the time the probe was sent and the time the
timer goes off, then the error counters should be incremented?

But if that is the case, when does the error counter get cleared?
The SACK replying to the probe does not acknowledge the probe,
it is just a dup-ack, so that would not clear any counters?

  Thanks for any replies!
     Karoline

--
Karoline Malmkjær, Software Developer
TietoEnator A/S, IP Solutions
www.tietoenator.com

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 19 Sep 2008 10:07:51 +0200

Hi Karoline,

my understanding is the following.
Assume that the sender has sent up to N and the receiver has
acknowledged all TSNs up to N - 1 and announces a zero window.

So the sender sends TSN N and gets back a SACK with cumack N-1.
Then you should not increment the error count... This sequence
can go forever. However, in FreeBSD we transmit each TSN only
a limited number of times and would finally fail the association
(we would call the chunk, the unlucky one...)

Hope that helps.
Best regards
Michael

---

From: Karoline Malmkjær<[email-masked]>
Date: Fri, 19 Sep 2008 10:43:36 +0200

Hi Michael.

Thanks for the reply.

I understand that the error count should not be
incremented when the SACK arrives.  But suppose
the link drops some packets, say one out of 10.
Then the error count would be incremented every
time a packet is lost.  Will these errors ever be
cleared, or will the association eventually die?

Best regards,
  Karoline

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 19 Sep 2008 09:48:38 -0400

> cleared, or will the association eventually die?

Are you asking this in the context of 0-window probes?
What I mean is the the loss of some number of TSNs caused
a 0-window situation on the receiver?

In that case, the error counter is incremented every time a
retransmission timer fires.  However, when the retransmission
happens and the tsn gets through, the receiver will renege
and advance the cumulative tsn in it's SACK.  That action
will clear the error counter on the send side.

-vlad

---

From: Karoline Malmkjær<[email-masked]>
Date: Fri, 19 Sep 2008 16:15:57 +0200

> will clear the error counter on the send side.

Not really.  I'm asking in the context of zero window
probing because the peer application has stopped reading.
Peer will never SACK the probe (at least not until
tomorrow, because someone pressed ^Z in his console and
left the building).

If SCTP sends a zero window probe above the window (with
TSN=N) and peer replies with a SACK (with c-ack=N-1), no
error counters are increased, that much is clear.

If SCTP sends a window probe and receives no packets
from peer, I assume the error counters are increased.  If
this happens 10 times in a row, the association times out.

The question is: if SCTP sends 20 window probes (TSN=N)
and receives 10 SACKs (c-ack=N-1), one for every second
probe, will the association then time out?

And if not, when are the counters cleared?

It would be nice if the SACKs could do it, but as far as
I can see, the RFC does not allow this, as the incoming
SACKs are duplicates, they do not ack any data.

Thanks!
  Karoline

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 19 Sep 2008 10:50:14 -0400

> probe, will the association then time out?

It shouldn't.  Since you are still receiving SACKs and you
detect that you've doing 0-window probes, you clear the error
counts.

> SACKs are duplicates, they do not ack any data.

I wouldn't call these duplicate SACKs.  The acknowledge the
receipt of 0-window probes and are used as such.

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 20 Sep 2008 10:58:52 +0200

Hi Karoline,

comments in-line.

Best regards
Michael

> tomorrow, because someone pressed ^Z in his console and
This is only correct if you use a user land implementation.
A kernel implementation will continue to send SACKs...
> this happens 10 times in a row, the association times out.
Correct.
> probe, will the association then time out?
No.
> And if not, when are the counters cleared?
Whenever you get a SACK with cumack=N.
> SACKs are duplicates, they do not ack any data.
The RFC says "new packets" and all the packets containing the
SACKs are new, since SACKs are never retransmitted.
Each SACK is generated by the packet used for the zero
window probing.

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 20 Sep 2008 11:01:33 +0200

Hi Karoline,

what I forgot: If you think the wording in RFC 4960 is misleading,
please bring this up on [email-masked]. This is not an implementation
specific issue. Based on the discussion there, we might can issue
an errata note making the text clearer... It seems that the text
is not clear enough.

Best regards
Michael

---

From: Karoline Malmkjær<[email-masked]>
Date: Mon, 22 Sep 2008 09:07:11 +0200

Hi Michael.

Thanks for your answer.  I'm afraid my description of
the scenario was not sufficiently precise, please see
inline comments.

Thanks!
  Karoline

> A kernel implementation will continue to send SACKs...
Sorry, my phrasing was imprecise.  I meant that peer
will send SACKs, but they will c-ack N-1, ie, they will
not cumulatively ack the probe.
> Whenever you get a SACK with cumack=N.
That was my understanding, yes.  But all the SACKs we
get are for N-1, so I still don't see when the counters
are cleared?
> Each SACK is generated by the packet used for the zero
OK, but that only explains why the counters are not
*increased*.  The RFC does not say to *clear* counters
on incoming new packets (which is very understandable,
since incoming data should not clear counters).

---

From: Karoline Malmkjær<[email-masked]>
Date: Mon, 22 Sep 2008 10:02:35 +0200

Hi Michael.

No, I actually think the text in 4960 is very clear on this
point.

If TSN N is outstanding and times out, it says the counters
should be increased, *except* if N is a window probe and a
new packet has arrived from peer recently.

If N is acknowledged, ie a SACK with c-ack N arrives, or if
a heartbeat is acknowledged, it says to clear the counters.

I.e., if a SACK with c-ack N-1 arrives, the counters are not
increased and not cleared.

Following the rules above on a link that loses some packets,
the errors will accumulate and the association will eventually
time out.  This is a strategy that probably makes sense in a
lot of scenarios (not all, of course).

Of course, if we can't agree that this is what the RFC says,
then I'm wrong and it *is* unclear :-)

Or if the behavior described was not the intended behavior,
then it is misleading.  But I wouldn't know what the intention
was.  And I don't think an implementor like me, who arrives
on the scene after an RFC is published, should implement
things differently than what is described in the RFC with
the argument "I don't think they meant that".

Best regards,
  Karoline

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 22 Sep 2008 15:58:03 +0200

Karoline,

comments in-line.

Best regards
Michael

> not cumulatively ack the probe.
OK.
> get are for N-1, so I still don't see when the counters
Sorry.... I meant, with cumack=N-1...
> since incoming data should not clear counters).
If during zero window probing every other DATA chunk or
SACK chunk gets lost, it should continue... This is
at least my understanding. But the RFC is not clear on
that...

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 22 Sep 2008 16:00:50 +0200

> increased and not cleared.
But this does not make sense...
> lot of scenarios (not all, of course).
But normally you will clear the counter whenever you get
"an appropriate answer". A SACK with cumack=N-1 is one in
my understanding.
> the argument "I don't think they meant that".
Can you please bring this up on [email-masked]?

We can figure out if I'm wrong or the RFC is unclear. In case
of the RFC being unclear we can provide an errata so that
it is clear to everyone what to do...