Skip to main content

Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
RFC 8260

Yes

(Spencer Dawkins)

No Objection

Alvaro Retana
(Adam Roach)
(Alexey Melnikov)
(Deborah Brungard)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 12 and is now closed.

Alvaro Retana No Objection

(Ben Campbell; former steering group member) Yes

Yes (2017-08-29 for -12)
I wish this had been around back when we were figuring out how to share connections in MSRP.

Otherwise, just a couple of editorial comments:

- Abstract: "Multiple ways for performing
   this selection, called stream schedulers, are defined. "
I assume you mean that they are defined in this document rather than in previously existing documents, but it seems ambiguous.

- 2.1: "The sender uses two counters for
      each outgoing stream, one for ordered messages, one for unordered
      messages.  All counters are independent and initially 0."

s/ all / both  ; unless this rule is intended to apply to more counters than the ones mentioned in the previous sentence.

(Mirja Kühlewind; former steering group member) Yes

Yes (2017-08-28 for -12)
Mostly editorial comments:
1) Why, after all, is SSN renamed to MID? I understand that the MID was extended to 32 bit and that the name might be more appropriate but I still find it confusing given both fields have the same semantics. Maybe it would help to point this out more explicitly in the document.

2) It could be helpful for the reader to also name the I and the U bits in section 2.1; especially the U bit could be referenced when MID is explained.

3) Should there maybe be a recommendation that re-assotiating without interleaving support could be tried if a ABORT message is received. I guess that failure case could occur if the negation was altered in the network and one end thinks it support interleaving but the other not...?

4) Related to my first point: I guess you only need a new I-FORWARD-TSN chunk because you use MID instead of SSN. This seem to me that you just took the opportunity to make this change with this extension but then it should maybe be the spell out as a 'separate' change/improvement in the intro.

5) Really a nit but hard to read otherwise; you really need to use a comma here (sec 1.1):
OLD
"If I-DATA support has been negotiated for an association
   I-DATA chunks are used for all user-messages."
NEW
"If I-DATA support has been negotiated for an association,
   I-DATA chunks are used for all user-messages.“

(Spencer Dawkins; former steering group member) Yes

Yes (for -12)

                            

(Adam Roach; former steering group member) No Objection

No Objection (for -12)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -12)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2017-08-30 for -12)
See the "Re: [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12" email thread

(Deborah Brungard; former steering group member) No Objection

No Objection (for -12)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (2017-08-26 for -12)
TECHNICAL
I'm not sure I am following the rules about interleaving multiple
messages in the same flight.

   The sender MUST NOT fragment more than one user message in any given
   stream at any time.  At any time, a sender MAY fragment multiple user
   messages, each of them on different streams.

So, say I have one stream and the application sends M1 and M2 and both
need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this
mean that I can't send M2a until M1{a,b} has been acknowledged?
If so what's the need for that requirement? It seems like you could
use MID to reassemble correctly. And given this requirement, why do
you need MID?


Because fragementation is indicated by index, not range,
what happens if you have to reduce MTU? So, say I have a message of
size 2K which I fragment into 1K/1K and then I have to decrease
my MTU to 512 bytes?


EDITORIAL
I think it would be helpful to indicate that B has to be
set for the first chunk in S 2.1. Or perhaps move the overview of
how the sender behaves in S 2.2.2 up in the document?

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-08-30 for -12)
I looked at the references for security considerations, [RFC4960] and [RFC6458], and don't see an explicit mention of fragmentation overlap and in my skim, didn't see that it was covered for reassembly as a warning.  Does this need to be added?  If not, can you explain how it is covered?

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -12)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -12)