Subject: [rddp] Last call comments on SCTP RDMA/DDP Adaptation draft

From: "Shah, Hemal" <[email-masked]>
Date: Tue, 5 Apr 2005 23:39:09 -0700

SCTP RDMA/DDP Adaptation draft authors,

Below are my comments on draft-ietf-rddp-sctp-01.txt:

1.       Section 2.1, page 5, first paragraph: The last sentence is not
clear on whether the mix traffic is allowed on a single stream
association or not. Suggest rephrasing the sentence to "An application
that needs to mix DDP and non-DDP traffic must use different stream
associations for the DDP traffic and non-DDP traffic."

2.       Section 2.2, page 5, second paragraph, third line: grammatical
correction. Sentence should be "DDP Segments are used for the messages
sent between DDP endpoints."

3.       Section 2.2: The spec does not explicitly state 1:1 mapping of
SCTP payload data chunk and DDP Segment. Suggest adding the following
"Each DDP Segment is exactly contained in one SCTP payload data chunk
with the payload protocol identifier 0x00000001." 

4.       Section 2.2.1: This section does not say how DDP-SSN is
incremented. Suggest adding the following text "DDP-SSN is increased by
one (modulo 65536) with each DDP message submitted to the SCTP layer."

5.       Section 2.1: Need to add a requirement that DDP-SSN for the DDP
Segments of a DDP message should be same. Suggest adding the text: "The
DDP-SSN field of the Payload Data Chunks of the DDP segments of a DDP
Message MUST be the same."

6.       Section 2.2.1: This section does not mention whether DDP-SSN is
passed to DDP layer or not. For delivery, it is important. Suggest
adding the following text "The adaptation layer passes DDP-SSN to the
DDP layer for the in-order delivery of DDP Messages."

7.       Section 2.2.1: Who maintains DDP-SSN, adaptation layer or DDP
layer? Please clarify it in this section.

8.       Suggest renaming section 2.2.2 to "DDP Segment Payload Data
Chunk".

9.       Suggest renaming section 2.2.3 to "DDP Stream Session Control
Payload Data Chunk".

10.   Section 2.2.3: This section does not say how the length of the
private data is derived. Suggest adding the text "The length of private
data is derived from the length of Payload Data Chunk."

11.   Section 6, third paragraph: This sentence combines two conditions:
MUST NOT with an exception case. It is little bit confusing. Suggest
splitting the sentence into two sentences: "SCTP Data Chunk
fragmentation MUST NOT be used for the cases where IP fragmentation is
not required. SCTP data chunk fragmentation MAY be used to avoid IP
fragmentation."

12.   Section 6, fourth paragraph: Is there any specific formula for
deriving the maximum DDP segment size based on the theoretical maximum
size of the SCTP Data Chunk?

13.   Section 7, third paragraph: in the end says "Typical ULP flow
control will exclusively deal with tagged messages,..". Replace "tagged
messages" with "DDP Messages".

14.   Section 7: Is there any requirement on the adaptation layer on
passing DDP-SSN to DDP layer? If yes, then please specify ("The
adaptation layer SHOULD pass DDP-SSN along with the DDP Segment to the
DDP layer."). If no, then please clarify.

Hemal  

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 6 Apr 2005 10:00:43 -0700

Hemal,
 
Thanks for a thorough proofreading.
 
Most suggestions are noted, and I will update accordingly
after all changes are collected.
 
There are a few exceptions, noted in-line below.
 
> 4.       Section 2.2.1: This section does not say how DDP-SSN
>          is incremented. Suggest adding the following text
>          "DDP-SSN is increased by one (modulo 65536) with each
>          DDP message submitted to the SCTP layer."

It is once per SCTP Data Chunk, which would be once per DDP Segment.
That is clear in the definitons section, but I agree that repeating
that definition in section 2.2.1 would improve the document.

> 5.       Section 2.1: Need to add a requirement that DDP-SSN for
>          the DDP Segments of a DDP message should be same. Suggest
>          adding the text: "The DDP-SSN field of the Payload Data
>          Chunks of the DDP segments of a DDP Message MUST be the
same."

The DDP-SSN numbers DDP Segments/SCTP Data Chunks, not messages.

One of its purposes is to allow easy determination when all prior
segments have been received for normal DDP ordering rules. When the
DDP Segment is untagged and has an L bit, it generates a completion.
But only after all prior segments have been received. The difference
with the SCTP adaptation versus MPA is that the SCTP adaptation uses
a 16 bit sequence number with 1 tick per segment rather than a 32 bit
TCP sequence number that has n ticks per segment.

> 6.       Section 2.2.1: This section does not mention whether DDP-SSN
>          is passed to DDP layer or not. For delivery, it is important.
>          Suggest adding the following text "The adaptation layer
passes
>          DDP-SSN to the DDP layer for the in-order delivery of DDP
Messages." 

The DDP specification already requires that "ordering information" be
supplied
from the LLP, so no explicit statement is really necessary. But if one
were
added it should be more along the lines of "The adaptation layer passes
DDP-SSN
to the DDP layer as the required LLP ordering information to allow the
DDP layer
to sequence DDP segments properly." 

This avoids suggesting that the DDP Segments are delivered to the DDP
layer in order.

> 7.       Section 2.2.1: Who maintains DDP-SSN, adaptation layer or
>          DDP layer? Please clarify it in this section. 

I'll think about the best clarification. The DDP-SSN is fully equivalent
of
the TCP sequence number, it is the property of the LLP. It is also
basically
equivalent to what the SCTP Stream Sequence Number would have been had
ordered
delivery been used. Unfortunately using ordered chunks would have
undesirable
effects, such as causing many SCTP stacks to hold Data Chunks until they
were
in order. Use of unordered data chunks reduces the complexity of the
required
SCTP functionality and guarantees the SCTP stack will forward the data
chunks
to the adaptation layer as promptly as possible.