Subject: [rddp] Meaning of preceding

From: "Barry Reinhold" <[email-masked]>
Date: Thu, 22 Apr 2004 16:32:39 -0400

Questions on DDP receiver

Assume a DDP receiver has a set of buffers "associated with" MSN
0,1,2,3,4 and 5. (unexpected association for MSN 0) for a given constant
QN.

Question 1:

If the first DDP segment that arrives has MSN = 0 (no TCP sequence gap,
violation of initial MSN rule) does the receiver: (1) Place and deliver,
(2) place and hold, (3) signal error to ULP.

Question 2:

If MSN 1 has been received, and the next MSN is 3 (with no TCP sequence
gap, sender protocol error) what is the receiver's expected behavior?

The issue here is that the tests of section 9.1 appear to allow
placement for the above two situations. Further the delivery conditions
of section 7.4 use the word "preceding", which up to this point I have
assumed to be understood in TCP sequence number space. If those are the
only two conditions then it seems like DDP should "deliver" for both
questions 1 and questions 2. However if "preceding", for untagged
buffers, is based on MSN number then delivery would not be valid.

So, the bottom line question is - does the receiver have to track the
first missing MSN to determine message delivery?

Barry Reinhold
Lamprey Networks
[email-masked]
(603) 868-8411

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

---

From: "Michael C. Cambria" <[email-masked]>
Date: Thu, 22 Apr 2004 22:54:44 -0400

> (2) place and hold, (3) signal error to ULP.

Assuming you are referring to the start of a connection (e.g. not 
wrapping from MSN 0xffffffff to 0), wouldn't this be covered by:

    5.  The Message Sequence Number falls in the range of legal Message
        Sequence Numbers, for the queue defined by the QN. The legal
        range is defined as being between the MSN value assigned to the
        first available buffer for a specific QN and the MSN value
        assigned to the last available buffer for a specific QN.

A compliant receiver starts their range at MSN=1 for the first buffer, 
MSN=2 for the next etc., so MSN=0 is out of range.  An error should be 
signaled to ULP since (top of 9.1) "...the DDP Segment MUST be validated 
before Placement"

> gap, sender protocol error) what is the receiver's expected behavior?

In this case, your questions re placement & delivery make a good point. 
  When looking for text in section 9 regarding what to do, I found 
nothing re MSN ordering other than that quote above regarding range.  I 
also found no error code for something like "unexpected MSN".

Section 7.3 only says:

    At the Data Source, DDP:

      * MUST transmit DDP Messages in the order they were submitted to
         the DDP layer,
The MSN definition in section 4.3 does state that the MSN increases with 
each DDP message.

Other than intuition, nothing is explicitly said about the "next" MSN 
must/should be used by the sender.  The receiver will find MSN 3 in your 
example to be "in range" with available buffers and as I read things, 
place it, unless there is text I'm (hopefully) missing.  If this isn't 
meant to be allowed, perhaps another test in sec 9 could be added to 
make this explicit.

MikeC

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 23 Apr 2004 03:48:03 -0500 (CDT)

> (2) place and hold, (3) signal error to ULP.

The expected MSN window would be at 1 (since the receiver has
completed no prior receive operations). Therefore MSN 0 is
2**32 messages in the future. I do not believe that more
than 2**31 messages could be in flight with any known LLP.
The SCTP mapping explicitly limits this, and it is implicitly
limited by the number of bytes that can be in-flight for TCP.

More importantly, it is highly unlikely that the receiving ULP
has made anywhere near that many buffers available.

The legal range of MSNs is defined by the base and the number
of available buffers. What is "available" gets tricky if the
local interface uses SRQs, but resolving that is a local issue.

> gap, sender protocol error) what is the receiver's expected behavior?

I presume you mean that there is no gap in the LLP sequencing
between MSN 1 and MSN 3.

In that case the receiver should, at some point, determine that
MSN 2 will never arrive, and teardown the connection.

MSN 3 may have been placed before the error condition can be
noted, but obviously not completed.

I am not aware of any language that requires the receiver to
*promptly* note this condition. As that the only damage is
hanging the connection where the mistake was made, simply
waiting for things to time-out would strike me as acceptable.
The sender is in violation. The receiver MUST protect itself,
but is under no obligation to provide prompt courteous diagnostics.
Of course it is very nice of it to do so.

It should also be noted that when checking for this condition
under SCTP that the adaptation layer's stream sequence number
(which represents the stream specific order of *submission*
to the sending LLP) must be used. Cheking using the TSN,
can result in a mistaken ordering. It is legal for the SCTP
TSN for the chunk containing MSN n to be earlier than for
the chunk containing MSN n+1 because the sending SCTP stack
is allowed to re-order chunks to optimize bundling.

--
Caitlin Bestler
http://asomi.com/