RE: AD review of draft-ietf-rddp-sctp-04
"Caitlin Bestler" <[email protected]> Fri, 23 Jun 2006 12:43:22 -0700
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <54AD0F12E08D1541B826BE97C98F99F15F570F@NT-SJCA-0751.brcm.ad.broadcom.com> |
Lars Eggert wrote: > > > Section 6.1., paragraph 2: > > > The Payload Data Chunks for a given session, when sequenced by > their > DDP-SSN, MUST follow one of the patterns defined in > this section. > > The sequence patterns in the remainder of this section don't > include any DDP-SSNs? How can compliance thus be established? > (See next comment.) > > All SCTP Data Chunks generated by the DDP/SCTP Adaptation have a DDP-SSN. Therefore all messages specified in this draft have DDP-SSNs. > Section 6.2., paragraph 3: > > > Passive Side sends a DDP Stream Session Accept message. > > Text above says this section describes a valid message exchange > based on DDP-SSNs. I'd thus have expected this section to talk > about DDP-SSNs, e.g., saying "active Side sends a DDP > Stream Session > Initiate message with DDP-SSN zero", "passive Side sends a > DDP Stream > Session Accept message with DDP-SSN zero" and so on. Am I > making sense? > (Same for Sections 6.3, 6.4 and 6.5.) > The rules for formulating the DDP-SSN are already clear. The fact that the messsages are sequenced clearly mandates what the DDP-SSNs would be. Since implementations are not likely to generate the DDP-SSNs at the layer discussed in these sequence sections, I do not see the value of repeating this information here. > > Section 6.2., paragraph 4: > > > Each side may then send zero or more DDP Segments with > increasing > DDP-SSNs, subject to various layers of flow > control. > > What does "various layers of flow control" mean? What happens > when the DDP-SSN wraps? It's no longer increasing then. > will be changed to "subject to whatever flow control imposed by other protocol layers". As specified earlier, the DDP-SSN has the same semantics that the SCTP SSN would have had if the stream had been SCTP ordered. It is hard to imagine a wire protocol where a field labeled as a "sequence number" did not have wraparound semantics, so I believe the "Same as the SCTP SSN would have been" is sufficiently clear.