Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016

["Proshin, Maksim" <[e-mail]>]

Hi,


Thanks for the document! Please find below some comments. Only major comments are included while editorial/minor comments have been sent directly to Michael.

1. Section 1.1: "DATA chunks are not

   permitted when I-DATA support has been negotiated."

What exactly does it mean for implementation (both sending and receiving sides)? I think to avoid any problems with the sending side it should be "MUST NOT" in the sentence. For the receiving side I suppose it means stop processing of the packet and silently discard all further chunks in the packet, right? I think this should be clearly stated. It could also be good to clearly state that after association restart which was with DATA previously but became with I-DATA after the restart, SCTP still may receive packets with DATA and they should be silently discarded due to VTag mismatch following the rules of Section 8.5. from RFC4960 (I suppose this is important to avoid any "protocol violation" reaction).

2. Section 2.1:
The only differences between the I-DATA chunk in Figure 3 and the

   DATA chunk defined in [RFC4960<https://tecas.te.mera.ru/owa/redir.aspx?C=cbRl5poXmc3bXrctc3uiVJhAGgw8lHq8fEMsh4pFMXQYJAlLDCjUCA..&URL=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc4960>] and [RFC7053<https://tecas.te.mera.ru/owa/redir.aspx?C=KQmYepdRaXeHqN7xzNyvrZsuNBTchqp_hA5H-TmPQn4YJAlLDCjUCA..&URL=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7053>] is the addition of the

   new Message Identifier (MID) and Fragment Sequence Number (FSN) and

   the removal of the Stream Sequence Number (SSN).

The B bit now has a different (extended) purpose and also specifies if PPID or FSN is used. I think it should be stated.


3. I suppose the draft assumes that SCTP still MAY (i.e. not SHOULD/MUST) support fragmentation even with I-DATA and MUST (i.e. not MAY/SHOULD) support re-assembling. If so, I suggest to clearly state it.


4. Is RFC6096 impacted by new chunks?


5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated during the SCTP

   association setup via the Supported Extensions Parameter as defined

   in [RFC5061<https://tecas.te.mera.ru/owa/redir.aspx?C=aBhrHwPXB_sxOpD8zoHpwx03KKVyMGhVR1K5MrakT5wYJAlLDCjUCA..&URL=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc5061>].  Only if both end points support the I-DATA chunk and

   the I-FORWARD-TSN chunk, the partial reliability extension can be

   used in combination with user message interleaving.

Not sure how implementation should behave if either of these chunks is unsupported. I think it should be clearly stated.

Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the partial reliability functionality should be completely off, i.e. not fallback to FORWARD-TSN.

If I-DATA is not supported but I-FORWARD-TSN is supported (strange implementation but still according to the draft as it does not prohibit the opposite), it seems both functionalities message interleaving and partial reliability should be off, i.e. there is no way to fallback to FORWARD-TSN, right?

Should the draft state something like "If I-DATA chunk is not used, I-FORWARD-TSN chunk MUST NOT be used."?


6. Section 4.1:
MID is 32 bits while SSN is 16 bits so why a new SCTP Receive Information Structure cannot be introduced instead of using the existing one?

If the new SCTP Receive Information Structure is introduced then a new message receive function should also be introduced (instead of recv_msg() ). Is that the main problem?

Of course, it would also be a problem if the interleaving functionality requires enabling only on the sender side (see the next comment).


7. Section 4.3.1:

   User message interleaving is disabled per default.

I'm not sure about it. First of all I think it should be clearly stated what does it mean for the sender and for the receiver.

If the intention was that I-DATA is included to INIT and INIT ACK only when the user enabled this functionality then I think this is not a good way because then it impacts not only the sender but also the receiver.

In other words, if the feature is disabled by default on both sides while SCTP on both sides support it then it is not enough to just enable it on one side, it requires enabling it on the other side.


7. Section 4.3.1:  Why don't specify exactly value 1 for the enabled feature? Otherwise, in the future it will be difficult to use another value of this parameter for a different purpose as it will be non-backward compatible (old application and new SCTP may work improperly).


8. Section 5 does not cover I-FORWARD-TSN.



9. Section 6: In case of DTLS over SCTP support of the message interleaving functionality may increase the risk of receiving messages with new epoch after ChangeCipherSpec message and before Finished message.


BR, Maksim

________________________________
Am 08.12.2016 um 08:36 schrieb [e-mail]<mailto:[e-mail]>:


This mail announces a TSVWG Working Group Last Call (WGLC) on:

            Stream Schedulers and User Message Interleaving forSCTP
            draft-ietf-tsvwg-sctp-ndata
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata

This WGLC will last for 2 weeks weeks.

Comments should be sent to the [e-mail]<mailto:[e-mail]> list, although purely
editorial comments may be sent directly to the authors. Please cc: the
WG chairs at [e-mail]<mailto:[e-mail]>  if you would like the chairs to
track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-sctp-ndata.

Thanks,
Gorry
(TSVWG Co-Chair)