Subject: [Ips] Question about Reject and DataSN gaps

From: William Studenmund <[email-masked]>
Date: Thu, 22 Sep 2005 12:45:00 -0700

In talking with a customer recently, a question came up about what 
should happen when there's a DataSN discontinuity in a write sequence.

The scenario is a write sequence where the DataSN jumps by two between 
two packets. So rather than ..., 2, 3, 4, 5, 6, 7, ..., we have ..., 2, 
3, 5, 6, 7, 8, ...

There is no disagreement that the target is supposed to notice this 
jump, and to either kill the task or institute some form of recovery 
R2T. In the specific case, DataSequenceInOrder is Yes (as there's only 
one outstanding R2T and ERL > 0), and so the whole initial R2T gets 
retried.

The question though is if a Reject should be sent in response to the 
jump. The customer indicated that a test suite expects one. To be 
specific, this would be in response to the PDU that had a DataSN of 5 
above.

I however think that no such reject should be sent, for three reasons. 
First, the target will actually use the PDU; the problem isn't with 
this PDU, it's with some other PDU that disappeared. Or it would be if 
we weren't being subjected to a test. :-) Second, Reject seems 
appropriate for cases either where the target gets something it can't 
work with or where the initiator really seems to have messed up. The 
most likely case I can see for a DataSN gap is that we had a header 
digest failure and we used markers to recover other PDUs. Everything 
else we do in reaction to header digest failure does not use Reject on 
the PDUs that make it through. :-)

Third, the recovery pseudocode in section E.2.3 describes this case 
("if (current DataSN is not expected)"), and indicates that sending a 
recovery R2T is the correct action. As there are other parts of this 
section which explicitly indicate that sending a Reject is the correct 
corse of action, I believe that not sending a reject is a perfectly 
valid corse of action.

What does everyone else think?

Take care,

Bill
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Ken Sandars" <[email-masked]>
Date: Fri, 23 Sep 2005 14:22:23 +0100

Hi Bill,

Sounds like an overly proscriptive test suite.

If you detected a data digest error you could authoritively provide a Reject
in addition to the processing you are doing. But that's not the scenario you
have described.

BTW, I'd have thought it's valid to issue a Recovery-R2T for just the
missing Data-Out PDU. Section 10.8 indicates Recovery-R2T PDUs are not
constrained by DataSequenceInOrder.

Cheers
Ken